Recently, there was an announcement made regarding a new proposal for Domain-based Message Authentication, Reporting & Conformance: DMARC. It represents another step forward in the effort to reclaim Internet messaging from abusers. Some people find it mystifying why we can’t just solve “the spam problem”. We know who’s sending the mail, right? Just block the bad guys! But it turns out, alas, we don’t know who’s sending the mail.
That’s actually what the problem is.
When Alice sends Bob an email, the way it normally works is this: Alice sends the mail to her Internet Service Provider’s (ISP) mail server. That mail server checks to make sure it’s Alice sending the mail.
Then the mail server sends the mail along to the mail server for Bob’s domain (if Bob’s address is firstname.lastname@example.org, then this is the mail server for example.com). That mail server stores the mail and when Bob checks his email, he gets the mail from his domain’s mail server.
There are ways to secure each of the steps along the way of this mail delivery chain and we have lots of protocols for making this happen. What we do not have is a policy layer that allows Alice to be confident Bob will be able to tell that the mail came from her and not some evil person pretending to be Alice.
Today, Bob can check to see how the mail that is supposed to be coming from Alice was handled in various spots along the chain.
If everything checks out, then Bob can know that the mail did come from Alice. But if things don’t check out, Bob just has to guess: he can’t tell what Alice intends. Worse, if Alice’s ISP gets things wrong, then Alice’s mail will look like spam and Bob might never see it. But there’s no easy or convenient way for Bob (or his mail server) to tell Alice’s ISP that they made a mistake. On the Internet, good and effective policy needs coordination and that coordination has to be automatic.
You can’t send millions of mails every day and expect to do anything by hand.
There’s one other problem: the Internet is made of many independent networks. It is impossible to deploy anything on the Internet that everyone has to turn on at the same time. That’s like asking two billion people to turn on all their lights at the same time. The Internet mail system is, in Internet terms, very old. It’s been around for more than 35 years and it’s still working, so we can’t just break it. Now all of this might seem like a lot of work for nothing. Who’s going to pretend to be Alice? Well, if “Alice” is instead “email@example.com”, you can see what the problem is. DMARC is an effort to provide the missing pieces.
It lets Alice’s ISP (who sends her mail) say what to do in case mails that look like they’re from her don’t meet the tests she expects them to meet. It lets Bob (and his mail server) tell Alice’s ISP when something is going wrong. It allows both of them to communicate about apparent attempts at abuse and it is designed to do all of this at Internet scale, permitting a high degree of automation.
There is still work to be done.
The work today is experimental, but the results of the experiment are intended to become an IETF standard. There are bound to be controversies about the mechanisms as they are currently specified and experience in the experiment is bound to uncover some problems that need fixing. But all of this is a big step forward in making mail more usable again and anything that improves the email environment and ensures deliverability of legitimate mail makes us at Dyn enthusiastic.
Expect more news from us on DMARC soon.