I am administrating the server that hosts this blog myself, and this includes running and maintaining my own mail server. Email is a messy and complicated bit of infrastructure, born in a more innocent age where everyone connected to the internet trusted each other. Over time, is has grown many layers of band-aids to provide at least some level of security. Email is also beautiful, it is the most widely used example of federated infrastructure: in principle, anybody can set up a mail server and communicate with everyone else, no matter which provider they are using. This is an amount of organizational resilience and user freedom that most messenger services can only dream of.
Perhaps surprisingly, I have had very little trouble with my own server; most big email providers do a good job blocking spam while permitting small independent mail servers to operate smoothly (this includs even Gmail, to my astonishment). There is just one exception: Microsofts Outlook.com (formerly Hotmail.com) and the other services using the same underlying infrastructure (such as live.com).
Over the years, except for one brief issue with AT&T, only Microsoft ever rejected mails from my server. This recently started happening again:
<...>: host eur.olc.protection.outlook.com[22.214.171.124] said: 550 5.7.1 Unfortunately, messages from [126.96.36.199] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3140). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [DB8EUR06FT011.eop-eur06.prod.protection.outlook.com] (in reply to MAIL FROM command)
So somehow, this server outright blocks everything coming from my IP, even though I am not listed on the usual blacklists. Usually, the process is to find the form that Microsoft expects sysadmins to fill out for such cases (the URL of that form keeps changing and even much of Microsoft’s documentation points to broken pages; the current form seems to be this one). I fill out that form, and after a week or so emails work again. I had to do this maybe four times over the last eight years (compared to once for AT&T and never for every other provider). Last time, their guidelines insisted that I set up SPF, which I did even though I am not a fan of that technology since it breaks email forwarding. The better alternative is DKIM, but amusingly, Microsoft does not implement DKIM (“Microsoft currently only validates inbound mail via SPF and Sender ID authentication”).
However, setting up SPF seemingly was not enough. This time, my request for unblocking my IPs was rejected. I requested that I be told the reason for this, since as far as I am aware I am following all the usual best practices for mail servers. The only response I was able to get is
As previously stated, your IP’s (188.8.131.52, 184.108.40.206) do not qualify for mitigation at this time. I do apologize, but I am unable to provide any details about this situation since we do not have the liberty to discuss the nature of the block.
They did claim that “Hotmail customers have reported email from this IP as unwanted”, but were unwilling to provide any details, so this is not an issue that I can diagnose. Instead each new response linked to a different set of guidelines or whitepaper. The only explanation I have is that my mailman instance could have caused backscatter spam, which I have since tried to mitigate.
They also referred me to various “programs” I could join to help manage my IPs reputation, but all of these programs require a Microsoft account. I have created such accounts in the past several times, most recently to experiment with Azure CI, and after a few months when I try to log in, I always get a message like this:
(They also reject “+” characters in email addresses, hence the use of an “_” above. They say “+” is an invalid character, which of course is just plain wrong.)
I am not sure what “activity” they have detected while I was not using my account for a month (yes I used a strong password); maybe that on its own is already violating their ToS. Subsequently, they insist on me giving them my mobile phone number. Needless to say, that is an entirely unacceptable request; my phone number is a way too sensible piece of personal information (comparable to my physical mail addresses) for me to share it with Microsoft. Better stay away from Azure CI if you care about such matters.
Given the lack of proper security for text messages, this process is also unsuited to establish account security; if that was really their interest, they would insist on setting up two-factor authentication via some standard OTP protocol. But this is not about the security of my account, it is a cheap method to prevent mass account creation and a thinly veiled attempt to collect more personal information. Google at least requests the phone number upon account creation (so I know to stay away from the beginning); Microsoft is more sinister in that they let you use their service for some time so you start relying on it before they force you to hand over your phone number or be locked out.
To conclude, if you are using Outlook.com for your email, I am afraid I cannot respond to messages you are sending to me. I can only recommend finding a better email provider. Microsoft clearly could not care less about a decentralized internet; their policies are actively driving us towards a small oligopoly of big email providers with little choice left for users. They are not even themselves implementing a reasonable minimum of email security technology (such as DKIM), but at the same time block servers without any means for sysadmins to learn what they are accused of. I am only happy that I hardly notice this because most people already use more reasonable email providers.