Home
The email ecosystem currently has a couple of major problems:
- MTA-to-MTA connections are opportunistically upgraded to TLS.
- Since end users cannot indicate whether they prefer deliverability over security, MTAs almost always default to preferring deliverability.
- MTAs don’t validate certificates as a result, since if cert validation fails they’d default to plaintext (arguably worse than no TLS at all) As a result, MTA-to-MTA connections are extremely susceptible to very naive TLS stripping attacks.
One potential solution is to allow recipients to advertise their TLS policy through either a TOFU mechanism, or separate secure channel. You could make an analogy to HSTS on the web, but it is important to note the differences. This channel is much more important for the increased security of the email ecosystem than it is for web. MTAs cannot forward security decisions to users, and users cannot specify that they’d like a particular email to be delivered only across a secure channel (like explicitly typing “https” into the URL bar). Although we can promote something like REQUIRETLS for the latter, the former is something that cannot be solved without a complete rehaul of SMTP. Thus, since users cannot express their intentions, it is more important for recipient MTAs to do so.
The STARTTLS Policy List is a separate secure channel for MTAs to discover recipient MTAs’ TLS policies.
- Receiving MTAs opt-in to add their policy to the list.
- This is done by submitting a PR or submitting your website manually to this list thing.
- Sending MTAs should validate SMTP connections for outgoing mail against the policies in the list.
Getting the second bullet point is harder, because it involves convincing sysadmins to install software on their mailservers, but mailservers are sacred and should never be touched. So it’s important to get this right, and make it as easy and unintrusive and transparent as possible for people to install the list updater.