Recently, I wanted to configure a new service on my bare metal server hosted in a Scaleway data center that requires sending email. EMail by nature is difficult to configure, so I wasn’t surprised at first that it didn’t work. But whatever I tried, I could not get that server to work. At some point I pressed Wireshark into action and finally discovered the reason: The TCP connection to the eMail server was not established. So who is blocking this?
At first, I suspected that my email provider was the culprit, as a ‘telnet email-provider-domain 587‘ would work fine from my home IP address. When I tried to connect to port 587 from a number of IP addresses I rent from Scaleway for my bare metal infrastructure, however, none of them could connect. Not one of them! Even stranger: Trying the same thing from a virtual machine hosted by the competition in a Hetzner data center would work. Only Scaleway IP addresses were blocked. So in a somewhat morose mood, I shifted my focus to my data center provider and discovered this article in Scaleway’s knowledge base which explains that by default, all outgoing TCP connections to ports 25, 465, and 587 for any kind of virtual machine or bare metal server are blocked. So that’s the reason!
The fix: Authenticate yourself with an id card to get access to the settings that allow to remove the block. Fortunately, the authentication process is automated and done via the web cam. A picture of the front and back of the id card is taken and finally a picture of my face. Access to the un-blocking page was then granted within seconds.
OK, fine, spam is a problem, but that’s quite a heavy measure. At this point, I have given up trying to keep my id card and face out of the web, authentication is required for so many things today that one copy of my id card more or less floating out there probably won’t matter anymore. Also interesting is that Hetzner, i.e. the competition, has no outgoing email port blocks in place. At least not by default.