Yeah we got those good old network ppl or their corporate (don't knows much about tech) overlord to thank for that.
If you ever using wifi in the airport or even some hotel with work suite unit around the world, you will notice that Apple Mail can't send or receive emails. It is probably some company wide policy to first block port 25 (that is even the case with some hosting providers) all in the name of fighting SPAM. Pretty soon, 143, 587, 993, 995.... are all blocked. Guess 80 and 443 are the only ones that can go through any firewalls now days. It is a shame really. Hopefully v6 will do better.
So there you go. And know EU wants to do ChatControl!!!! Please stop this none-sense, listen to the people who actually knows tech.
Port 25 is insecure and unencrypted; EU doesn't even need ChatControl to hoover up that data, and you'd better believe anything going through an airport wifi router unencrypted is being hoovered by someone no matter what jurisdiction you're in. Apple mail prefers 587 for secure SMTP and 993 for secure IMAP.
People were (wisely) blocking port 25 twenty years ago.
Port 25, which you call insecure and unencrypted, is using the same protocol as port 587, which you call secure - SMTP with STARTTLS.
The main problem with port 25 isn't that it's unencrypted, but rather that it's mixing two two concerns: (Often unauthenticated) server-to-server mail forwarding, and (hopefully always authenticated, these days) client-to-server mail submission.
A network admin can reasonably want to have the users of their network not run mail servers on it (as that gets IPs flagged very quickly if they end up sending or forwarding spam), while still allowing mail submission to their servers.
> People were (wisely) blocking port 25 twenty years ago.
20 years ago (2005) STARTTLS was still widely in use. Clients can be configured to call it when STARTTLS isn't available. But clients can also be served bogus or snake oil TLS certs. Certificate pinning wasn't widely in use for SMTP in 2005.
Seems STARTTLS is deprecated since 2018 [1]
Quote: For email in particular, in January 2018 RFC 8314 was released, which explicitly recommends that "Implicit TLS" be used in preference to the STARTTLS mechanism for IMAP, POP3, and SMTP submissions.
[1] https://serverfault.com/questions/523804/is-starttls-less-sa...
Ah thanks for the correction. Just changed my post above to 587. What I mean is why block all the ports, just keep it open let the user decide if they want to use it. And linux people can always use ufw on their side to be safe. Back in the dot com days, there were people also using telnet, but that got changed to ssh.
Is it because it is hard to detect what type of the request that is being sent? Stream vs Non Stream etc?
Having all protocol look the same makes traffic shaping harder. If you develop a new protocol, do not make your protocol stand out, you won't win anything from it. Ideally all protocols should look like stream of random bytes without any distinctive features.
Blocking outbound port 25 is completely reasonable, just like blocking inbound port 80 or 443 would be (if inbound connections even were an option, which they aren't in most networks, at least for IPv4).
Blocking ports 587, 993, 995 etc. is indeed silly.