Here is the data that I promised:
98% of global IP connections are encrypted
30% of private IP connections are encrypted.
"Connections" are
- Unique tuples of HELO/ReverseDNS/SourceIP
- For accepted mail (blocked mail is not in this data source)
- Where the Received header indicates SMTP protocol (*MTP*) or an encryption string includes "TLS"
For what it's worth,
Doug Foster
On Wed, Oct 30, 2024 at 9:58 PM Douglas Foster <dougfoster.emailstandards@xxxxxxxxx> wrote:
Some observations as a system admin in an organization that worries a lot about HIPAA, reflecting our operating practice.1) Transport security is the responsibility of the sender, not the receiver, so we accept unencrypted connections.2) For outbound mail, we require TLS. If an organization cannot to TLS (and they exist), we fail over to secure web relay. This is a bit of a sham, because if am MTM attacker can intercept your direct content, he may also intercept the replacement "log in here to get your message" link. It all depends on where the MTM is positioned and which server sends the replacement email.2) STARTTLS does not ensure an encrypted session. Mandating STARTTLS does not mandate transport encryption.3) A lot of mail flows from originators, to third-party outbound gateways, to third-party inbound gateways, to hosting services. The two biggest hosting services either admit or imply that they read client emails for their own purposes. MTM eavesdropping is the least of my concerns about information leakage.4) To the comment about internal traffic: I am pretty sure that a lot of internal relays use unencrypted sessions. I could get a percentage tomorrow, as I have been parsing and logging Received chains for several months.The SHOULD statement can certainly wait for the A/S. In the real world, people who care have already implemented the defenses that they deem important.DougOn Wed, Oct 30, 2024 at 6:33 PM Nick Hilliard <nick@xxxxxxxxxx> wrote:Brian E Carpenter wrote on 30/10/2024 21:04:
> Good arguments have been made why STARTTLS shouldn't be a MUST. I haven't
> seen a convincing argument why it shouldn't be a SHOULD. That doesn't
> preclude elaboration on that requirement in the AS.
"SHOULD" is a good idea for STARTTLS. "MUST" invites a discussion about
how granny should handle CA list updates on her 2008-era printer, and
what sort of cipher list or tls protocol version she should configure,
whatever about every other piece of obsolete software/firmware in every
SMTP MTA client ever produced.
Maybe at some point in the future we could look at MUST but we're
nowhere near that stage right now.
Nick
--
Emailcore mailing list -- emailcore@xxxxxxxx
To unsubscribe send an email to emailcore-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
