Updating e-mail security features on my server.

I recently learned of a new security process called SMTP MTA Strict Transport Security, or MTA-STS for short. It’s not new, exactly, but it hasn’t been talked about a lot, either. Basically, it does what HTTP Strict Transport Security, HSTS, does for websites and informs the connecting client that not only is encryption available but it should be used, in this case for delivering mail to the SMTP server. Google officially rolled out support for this in April of this year and I am receiving reports that my rule is being used so that’s encouraging. This solves the opportunistic encryption vulnerability whereas a MITM attacker could downgrade an otherwise encrypted connection.

How MTA-STS actually works.

First, a mail client (usually a mail server) queries a DNS server to determine the domain’s MX record so it knows where to send the mail. A mail client could also query the DNS server to determine if a MTA-STS record exists as well. If the record exists, then the server connects to a predetermined URL (mta-sts.<domain>/.well-known/mta-sts.txt) and obtains the rule that has been established by the system owner. This rule is cached by the system and doesn’t change unless the DNS record’s ID changes so, like HSTS, once the server connects the first time, it knows that it should always connect to that domain’s SMTP server(s) using encryption. If there is a downgrade attack, or some other problem where encryption is not available, the connection fails and mail is not sent.

It should be noted that the DNS records should/must be secured with DNSSEC for this whole thing to work well.

But what about DANE?

Oh, lets not forget about DANE which is another great way of advertising encryption possibilities. DANE not only shows your encryption possibilities but also provides your public key so your clients can compare it when they connect. A bad actor trying to imitate you wouldn’t be able to unless they were able to steal your private key. And this isn’t HPKP where you can completely lock your domain off of the web for months because you lost control of your keys or did something incorrect.

So what feedback are you getting?

I’ve been running this for only a few days and, so far, I’ve received feedback from two providers: Google and Comcast. Google is using MTA-STS and has successfully read my rule and is enforcing encryption for all messages coming to my domain. Comcast is using DANE and is successfully sending messages to my domain not only encrypted but is verifying my certificate as well.

Others may also be using these technologies but not reporting using the RFC8460 SMTP TLS report.

Postfix Encryption

I've been tinkering with the encryption options in Postfix for a while. Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email. The body of the message is also …

Sparks's Journal

Other articles

Postfix Encryption