MTA-STS Policy Generator

When one mail server hands a message to another, the two begin in plain text. The receiver may offer to switch to an encrypted channel, and the sender may accept. Most do. Nothing obliges either side.

That was a deliberate choice. RFC 3207, which defined STARTTLS for mail in February 2002, says a publicly referenced mail server must not require the extension in order to deliver mail locally, and gives the reason in the same breath: the rule keeps the extension from damaging the interoperability of the Internet’s mail infrastructure. Mail that arrives unprotected was judged better than mail that does not arrive.

RFC 7435, published in December 2014, gave the approach a name: opportunistic security. Encrypt whenever both ends can, even without proof of who the other end is. That defeats a listener. It does not defeat someone who can change what passes.

The offer that can be deleted

The weakness sits in the first few lines of the conversation. The offer to encrypt is itself sent in the clear, before any protection exists. RFC 3207 describes the attack in its own security section: a man in the middle can delete the “250 STARTTLS” response from the server, and the client, seeing no offer, will not try to start a protected session. Both machines support encryption. Neither uses it. The message crosses in plain text and nobody is told.

RFC 7672, the document that brought DANE to mail in October 2015, is blunt about this. The server’s indication of TLS support can easily be suppressed, it says, and no TLS security feature can prevent that, because the attacker simply disables TLS. It also explains why mail cannot copy the web. A web address says https and the browser knows to insist. A mail address says nothing about transport, and it could not usefully do so, since encryption between servers protects one hop at a time while an address describes the whole journey.

There is a second hole. A sender finds the receiving server by asking the DNS for the domain’s MX records. An attacker who can forge that answer can name a server of their own, obtain an ordinary certificate for that name, and receive the mail over a perfectly encrypted connection. Encryption alone does not help when the wrong party is at the far end.

So a fix needs two things: a way for a domain to say that its servers always offer TLS, and a way to say which servers are really its own. DANE does both with signed DNS records, and it requires DNSSEC. MTA-STS, published as RFC 8461 in September 2018, does both without DNSSEC, and pays a price for that which is worth understanding before you deploy it.

A file, a record, and a rule for names

The policy is a short text file. It lives at a fixed address on a host named mta-sts under the mail domain, at the path .well-known/mta-sts.txt, and it must be served over HTTPS by a server whose certificate is valid for that exact host name. The file has four kinds of line: version, mode, max_age, and one mx line for each allowed mail server. The IANA registry for the protocol lists those four fields and no others.

Fetching a web page before every delivery would be wasteful, so a TXT record at _mta-sts under the domain announces that a policy exists and carries an id. A sender that already holds the policy compares the id with the one it saw last. If they are the same it does nothing more. If they differ it fetches the file again. The id has no meaning and no order, and it can be at most 32 characters of letters and digits. Its one job is to be different every time the file changes, which is easy to forget and silently fatal: change the file, keep the id, and senders keep enforcing the old copy.

The mx lines are where most mistakes hide. Each is either a full host name or a star followed by a dot and a name. The specification borrows its matching rule from the one used for certificates and then narrows it: the star may only stand for the entire left-most label. A label is one dot-separated part of a name, and names are compared without regard to upper or lower case. The star therefore stands for exactly one label. The RFC’s own example shows a star pattern matching a host one label below the name that follows it, but not that bare name and not a host two labels down.

Here is a policy you can reproduce. A domain, example.org, receives mail at mx1.example.org and at two hosts run for it elsewhere, in1.mail.example.net and in2.mail.example.net. Its file has five lines: the version STSv1, mode testing, an mx line for mx1.example.org, an mx line for *.mail.example.net, and a max_age of 604800, which is one week. Each line ends with a carriage return and a line feed, as the specification describes, and the whole file comes to 93 octets.

Now test some names against it. Both in1 and in2 match the wildcard. The bare mail.example.net does not, because there is no label for the star to stand for. A host named a.b.mail.example.net does not either, because there are two. If the outside service ever moves the domain to a host with a differently shaped name, the policy stops covering it, and under enforcement that means mail is held back. The opposite error is as real. A pattern of a star over your own whole domain accepts any machine that holds a name under it and a certificate, a risk the RFC lists under weak policy constraints.

Testing first, and the reports that make it worth doing

The mode line has three values. In enforce, a sender that honours the policy must not deliver to a server that fails the name match, fails certificate validation or does not offer STARTTLS. In testing, mail is delivered as though nothing had failed, and the failure is reported. In none, the sender behaves as if there were no policy at all.

Testing mode is only as good as the reports, and reports need their own record. RFC 8460, published alongside RFC 8461, defines a TXT record at _smtp._tls under the domain that names where reports should go, by mail or by an HTTPS address, with several addresses allowed in one comma-separated list. Sending systems that implement it send a summary that should cover a full day in UTC: how many sessions succeeded, how many failed, and why. The failure types include a policy file that could not be fetched, a policy that was invalid, and a policy host whose certificate did not check out.

Publish that record first. Then serve the file in testing mode, then add the TXT record that announces it. The RFC asks for that order whenever the policy changes: update the file before the record, so that a sender who notices a new id never fetches a stale file. Read the daily reports until every failure is one you can explain. Only then change the mode to enforce, with a new id.

The reports are imperfect instruments. Only senders that implement reporting send them. A report sent by mail must go through despite TLS failures, the RFC says, which may mean it travels unencrypted. And a report describes the reporter’s own configuration to some degree, a point the document raises under privacy. They are a view through a keyhole. It is still far more than the silence that came before.

Trust on first use, and how to leave

The max_age line says how long a sender may keep the policy, in seconds, up to 31557600, a year of 365.25 days. The RFC expects values of weeks or more and tells implementers to prefer values as long as practical. The reason is the price mentioned earlier. A sender learns that a policy exists by asking the unsigned DNS. An attacker who can block that answer the first time, or at every refresh, makes the domain look as though it has no policy, and the sender falls back to ordinary opportunistic delivery.

MTA-STS therefore protects a sender only after it has fetched the policy once, and only for as long as the copy lasts. The RFC says so plainly, and it names the comparison: resistance to this kind of downgrade is a feature of DANE, because signed DNS can prove that a record is absent. The two can be deployed together, and where they overlap a sender must not let a passing MTA-STS check override a failing DANE one.

A long max_age has a cost of its own. Whatever you publish, senders may hold for that long, so a mistake takes that long to drain from every cache. This is why withdrawing a policy is a procedure and not a deletion. Remove the record and the file abruptly and senders are left enforcing a cached policy they can no longer refresh. The RFC’s suggested path is to publish the file with mode none and a small max_age, such as one day, publish a new id so that senders fetch it, and wait until every earlier copy has expired before removing anything. The wait is the longest max_age you ever served, not the most recent.

None of this encrypts a message from writer to reader. It protects one hop, between servers that both take part, against an attacker on the path between them. It rests on the same certificate authorities the web relies on, so a wrongly issued certificate for a mail host defeats it. And it is voluntary on the sending side: a sender that has never heard of MTA-STS will go on delivering as it always did.

What it changes is who gets to decide. Before, the decision to encrypt belonged to whoever controlled the wire at the moment of delivery. With a policy published and cached, it belongs to the domain that receives the mail. A text file of five lines is a modest thing to hang that on, which is a good reason to get every line of it right.