European Tech Sovereignty
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.
view the rest of the comments
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.
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.
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.