BSDHowTo.ch
| How To... | Why not..? | Scripts | Patches | |
Last update: 2018-10-01
The design of MTA-STS as described in RFC 8461 is broken because it enforces you to run a web server to publish the policy.
The basic idea behind MTA-STS is similar to HSTS (HTTP Strict Transport Security) header. Tell the clients that connect to your MTA that you want to encrypt all connections. This is a way to move from opportunistic to obligatory transport encryption for SMTP. That is a very good idea.
MTA-STS requires you to run a web server where you publish your policy about transport encryption for SMTP. So every MTA that wants to support MTA-STS requires at least a rudimentary HTTP client to fetch the policy from your server. More code adds more complexity and more sources of bugs to every MTA out there. Security is a chain. And as every chain security is only as strong as the weakest of its weakest link. The weakest link in MTA-STS is not HTTP but DNS. The standard requires the MTA to use DNS to find the URI of your policy and to detect changes in your policy. If an attacker manages to spoof the DNS answers the whole mechanism of MTA-STS can be blocked and becomes useless.
If you don't fear complexity you can use DANE to achieve the same goal. DANE requires DNSSEC and support for a new RR called TLSA. If you don't run your own servers for your zone you will need a provider that supports such “new” DNS stuff. Actually there was a simple solution in the past called SMTPS, which is just SMTP over TLS. For a short time end of the 90s the TCP port 465 was reserved by IANA for SMTPS. But back then the invention of STARTTLS seemed like a better solution, so the reservation was revoked.