> 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...

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.

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?