this post was submitted on 21 Jun 2026
2 points (75.0% liked)

European Tech Sovereignty

237 readers
1 users here now

Welcome to European Tech Sovereignty. This online community is born from the idea of passionate tech enthusiasts and industry experts dedicated to fostering a self-sufficient and resilient technological landscape in Europe. Our mission is to unite individuals, startups, and organisations that believe in the importance of building a robust European tech stack, free from over-reliance on external platforms and technologies.

In an era where digital sovereignty is paramount, we aim to create a collaborative space where members can share knowledge, resources, and best practices. Our community encourages open discussions on topics such as software development, cybersecurity, data privacy, and sustainable technology solutions. By leveraging our collective expertise, we strive to empower European innovators to create homegrown technologies that reflect our values and meet the unique needs of our diverse societies.

Join us in our quest to shape a future where Europe leads in technological innovation, ensuring that our digital infrastructure is secure, ethical, and aligned with our cultural and economic interests. Together, we can drive the change needed to establish a thriving tech ecosystem that champions European sovereignty and independence in the digital age.

founded 1 year ago
MODERATORS
 

The rumor is that domainepublic.net treats Microsoft’s mail server with the same reciprocity of Microsoft’s treatment of other mail servers and thus blocks MS.

IIRC, small email services are forced to solve a CAPTCHA to prove to MS that their server has a human administrator before the server can connect to MS’s server. Is that true?

Can anyone confirm or deny the rumor as well as whether MS forces other ESPs to solve CAPTCHAs? I would be quite interested in having an email account that blocks MS until an MS admin solves a CAPTCHA (which I assume would not happen).

you are viewing a single comment's thread
view the rest of the comments
[–] autonomousPunk@belgae.social 1 points 3 days ago (1 children)

Any email service could be configured to block Microsoft.

Indeed, whoever controls the server could do that. But who does? I don’t have an always-on WAN-facing machine, so I am interested in finding an email provider who does the blocking.

I’m not sure why you want to do that at the platform level though. That’s a great way to not have delivered legitimate email traffic.

Microsoft is a surveillance advertiser who I boycott. I do not want to feed MS’s ad machine. For outbound mail, I can do an MX lookup first and only send email to non-MS non-Google recipients, but that’s not reliable because some recipients mask their email providers using a firewall like barracuda networks. So when such users try to email me, I would like their email to be refused.

About blocking “legit” traffic, MS does that anyway. I’ve seen MS reject RFC-compliant non-spam email 1st hand. I am happy to reciprocate.

[–] unmagical@lemmy.ml 2 points 3 days ago (1 children)

Most legit providers offer filter rules you can configure as you need. Particularly if you're using a paid enterprise service. You could check to see what rules a provider has available and if you can block by MX record or IP. You wouldn't need to control the server, just have a provider that let's you customize your needs.

Unless you are intentionally finding services that do not use M$ infrastructure then you risk losing a lot of access. Flights, trains, hospitals, schools, stores, events may all use M$ as a provider whether or not they are sending from their own domain. Personally I'd rather receive my tickets that I pay for than not.

[–] autonomousPunk@belgae.social 1 points 3 days ago* (last edited 3 days ago)

Most legit providers offer filter rules you can configure as you need.

Filters are for email post-delivery. By the time a server is executing your filter instructions, Microsoft’s server has already delivered the message and disconnected. It’s too late at that point. If some rare mail service were to bounce a message based on user-specified filters, it would have to be after the msg has already been delivered. This would risk “backscatter”, whereby the bounced response attempts to connect to the /perceived/ sending server, which could be incorrect. And even if it is correct, the sending server may not accept the bounced msg.

The configuration I describe can only competently be done on the server and it necessarily must be the same behavior for all users on that server because the refusal happens before the sending server even has a chance to send an SMTP “RCPT TO” line.

Unless you are intentionally finding services that do not use M$ infrastructure then you risk losing a lot of access.

It would be senders who lose access. I’m already happy to not connect to surveillance advertisers. The idea is that users on surveillance ad platforms lose access so they cannot deliver to my inbox.