A Fedora 43 and Dovecot 2.4 upgrade may have uncovered an old Microsoft Outlook behavior where SSL/TLS settings allegedly failed to properly encrypt POP3 email connections.
In my experience, no large business would decide to only accept encrypted inbound SMTP. So as usual with SMTP you try to handle the worst clients sending you mail with nothing security wise (no DKIM, no SPF, no TLS) and still try to filter all the spam out of it and that’s about it.
And I acknowledge the effort from google to push the security to get better but even then nobody wants to accept to miss a few dirty emails for the sake of security.
The stance is unfortunately to never be the one refusing emails even when they are absolutely and completely unsecured. It really sucked being an admin on that kind of systems. SMTP is one of the worst protocols I have ever seen so widely used and there is still this idea that you should accept mail even when they dont fully respect the basic security requirements Gmail has made mandatory.
Most of the time the higher ups didn’t seem to care about the confidentiality of mails received.
In my experience, no large business would decide to only accept encrypted inbound SMTP
For submission (connections coming from users that have an account on the server) or for relay/target (connections coming from other email clients)? All email clients support encryption so I think requiring encryption for submission is reasonable. Server-to-server (port 25) can’t have it enforced though, like you said.
SMTP is one of the worst protocols I have ever seen so widely used
It’s from a era where everyone trusted everyone else. All connections were unencrypted, spam protection and rate limiting weren’t needed, and security really wasn’t on people’s minds. Modern security and spam protection is hacky because it’s built on top of protocols that weren’t designed for it.
The other major issue with old protocols is that they’re stateful. Modern protocols are mostly stateless since it’s generally easier to deal with. They’ve also had more and more features hacked into them over time, so the specs are enormous.
There’s been one major attempt at modernizing it: JMAP. It’s stateless, uses JSON, and intends to replace both IMAP and SMTP. FastMail started the project. https://jmap.io/why-jmap/
However, they’ve only looked at the “easier” part to replace: Communication between a user and their email server. They’re not looking to replace server-to-server communication at all.
My mail provider optionally supports this. They have a subdomain with an SMTP server that rejects unencrypted connections, I just have to hand out …@secure.mailbox.org instead of …@mailbox.org as my mail address.
In my experience, no large business would decide to only accept encrypted inbound SMTP. So as usual with SMTP you try to handle the worst clients sending you mail with nothing security wise (no DKIM, no SPF, no TLS) and still try to filter all the spam out of it and that’s about it.
And I acknowledge the effort from google to push the security to get better but even then nobody wants to accept to miss a few dirty emails for the sake of security.
The stance is unfortunately to never be the one refusing emails even when they are absolutely and completely unsecured. It really sucked being an admin on that kind of systems. SMTP is one of the worst protocols I have ever seen so widely used and there is still this idea that you should accept mail even when they dont fully respect the basic security requirements Gmail has made mandatory.
Most of the time the higher ups didn’t seem to care about the confidentiality of mails received.
For submission (connections coming from users that have an account on the server) or for relay/target (connections coming from other email clients)? All email clients support encryption so I think requiring encryption for submission is reasonable. Server-to-server (port 25) can’t have it enforced though, like you said.
It’s from a era where everyone trusted everyone else. All connections were unencrypted, spam protection and rate limiting weren’t needed, and security really wasn’t on people’s minds. Modern security and spam protection is hacky because it’s built on top of protocols that weren’t designed for it.
The other major issue with old protocols is that they’re stateful. Modern protocols are mostly stateless since it’s generally easier to deal with. They’ve also had more and more features hacked into them over time, so the specs are enormous.
There’s been one major attempt at modernizing it: JMAP. It’s stateless, uses JSON, and intends to replace both IMAP and SMTP. FastMail started the project. https://jmap.io/why-jmap/
However, they’ve only looked at the “easier” part to replace: Communication between a user and their email server. They’re not looking to replace server-to-server communication at all.
My mail provider optionally supports this. They have a subdomain with an SMTP server that rejects unencrypted connections, I just have to hand out …@secure.mailbox.org instead of …@mailbox.org as my mail address.