Skip to content

Actors in the DMARC Drama

May 18, 2014

DMARC has been debated recently in some of the mailing lists to which I subscribe because of recent changes at Yahoo.  The complaint was that users of Yahoo e-mail could no longer receive messages from these mailing lists that were sent by other Yahoo users.  The purpose of DMARC is to prevent e-mail forgery, certainly something to be celebrated by people who have fallen victim to this misuse of e-mail.  It’s used in conjunction with the e-mail signing protocols DKIM and SPF.

Before I retired, I was the e-mail administrator for a large organization.  As part of our spam control system, I had set up DKIM validation of incoming messages, along with DCC.  There was, however, a missing piece: there was no systematic way to determine an other organization’s signing policy, based on their e-mail domain.  I had to do this myself, with a case-by-case decision.  Forged messages from banks and other financial institutions had the most serious consequences.  For these, if they used DKIM signing, I had our e-mail system reject unsigned messages or messages that were incorrectly signed.  Specifying this behavior was a manual process and one that was doubtless incomplete.  Our e-mail server did not sign outgoing messages, although it had the ability to do so.  At that time signing was of little benefit to us but could have caused troubles with our e-mail.

Forged e-mail messages, typically phishing attempts, are not sent by the purported author, although they appear to be authentic.  This means that they are sent with forged header fields.  Before e-mail signing and DMARC, all header fields could be forged.  Likewise, any e-mail server could be used to send forged e-mail.  A forged header might look like this example:

From: Big Bank Account Services <service@big-bank.com>

DMARC records are advertized in DNS by the owner of the e-mail domain.  Such a record asserts that all e-mail from that domain is signed or otherwise validated.  It also specifies what to do with unsigned e-mail that appears to come from that e-mail domain.  The domain owner certainly has a right to make these assertions.  DKIM signing works by cryptographic methods.  SPF authentication is an alternative method, based on the IP addresses of e-mail servers for the domain.  The two methods are sufficiently different, and used by different groups, that they are unlikely to be merged into one method.

Now we come to the actors in this drama.  The recipient e-mail user should not have to determine if a message is genuine.  Some won’t know how to do this.  Others will do it incorrectly.  Let the computer do it.  It can make this determination more quickly and more accurately than a human can.  Even the person’s e-mail reader should not be expected to validate messages.  There are just too many e-mail readers for this to work properly.  All the e-mail reader has to do is to display the author of the message.  The recipient e-mail server, however, can validate a message with DMARC and DKIM or SPF.  It can also return an error during the SMTP transaction with the sending e-mail server, an error indicating that the message has failed validation.  This will happen if the message is unsigned or improperly signed, and the owner of the e-mail domain asserts that all of their messages are signed.  On receipt of such an error, the sending e-mail server can notify the message sender that delivery has failed.  This is normal behavior of a sending SMTP server: no modification is required for it.  Finally, the client computer must authenticate to its e-mail server in order to send e-mail.  Likewise, this is normal practice these days.  The drama is complete, with authentication or validation all the way.  Forgery has been vanquished.

Eliminating forgery does have some advantages.  For the user, it eliminates some spam.  That’s always welcome.  It also improves the reputation of the domain owner by eliminating false reports of spam or phishing attempts.

The originator fields of the e-mail header are key to preventing forgery.  These are defined by e-mail standards.  There are three of these headers.  The `From:’ field specifies the author of the message.  The `Sender:’ field specifies the person or agent who sent the message.  If the two differ, both header fields must be included in the message.  The third originator field is `Reply-To:’.  It specifies the e-mail address for replies, which can be any address.  Because of that, this header is not useful for signing or DMARC.

Interpersonal e-mail works correctly now, using the actors cited above.  That’s certainly a good start, but that’s also the easy part.  E-mail addresses that are specified as the author of a message without signing will be broken by DMARC, when the owner of the e-mail domain begins using it.  Some e-mail sent by web sites use this technique.  It will have to be abandoned as there’s no solution in the DMARC world.  E-mail forwarding is doubtful now.  Typically, the sending server forwards e-mail by modifying some headers and adding others.  Signing by DKIM is intended to survive some forwarding, but it depends how it’s done.  SPF validation will almost certainly break when e-mail is forwarded to another domain.  It’s possible that adjustments to DMARC processing at the recipient e-mail server, along with DKIM signing will allow forwarding.  Otherwise, this facility will have to be abandoned too.

Mailing lists seem to cause the most complaints now that DMARC has begun to be deployed.  The reason is that e-mail messages are received by the mailing list server and then redistributed to the subscribers,  with different headers but the same author.  Unless it’s carefully done, DKIM signing is broken.  SPF validation is beyond hope in this case.  One solution is to employ the originator fields correctly.  Unfortunately, most mailing list servers have constructed these header fields for their own purposes, in a way that breaks signing.  I don’t know if this practice can be rectified.  The other solution is for the mailing list server to re-sign its outgoing messages with its own e-mail domain.  At the moment, of course, it only needs to specify its own domain as the originator of the message without signing.  The problem with doing it that way is that the author of the message disappears.  This is not a very good solution.

The short-term solution seems to be to send e-mail with an author domain that does not employ signing or DMARC.  People with Yahoo addresses are being told to get an e-mail address someplace else, and use that for sending to mailing lists.  This is also not a very good solution.  It will become impossible as DMARC becomes more widely deployed.  A better solution is for e-mail servers to sign all outgoing e-mail and to advertize DMARC policy.  Mailing list servers will have to be fixed before this can be done.

What will the world look like once everybody is using DMARC?  It will eliminate e-mail forgery.  A lot of facilities and services that we take for granted will be broken along the way.  Unfortunately, there will still be opportunities for forgery, at least of the look-alike sort.  Here’s an example of an author header:

From: Big Bank Account Services <service@big-bank.xx>

In this case, the message will be correctly signed, and the big-bank.xx domain will advertize its DMARC policy.  The message will pass DMARC processing.  Some people will still be taken in by this phishing attempt, particularly if they have an account at Big Bank, and their mail reader only shows the comment field of this header.  Spam senders too will correctly sign their messages.  What’s going to be the next big thing in phishing and spam prevention?

 

Advertisements

From → Uncategorized

2 Comments
  1. jadrevenge permalink

    Google use a version of DMARC that marks failed messages as “SPAM” … however it does deliver them … you can then set up “filters” that specify “Never send to spam” for mailing lists that you care about.

    developer@lists.illumos.org seems to have gotten it right though, it changes the “From” to be the list, with the name of the person as is with ” via illumos-developer” appended, it adds a “Reply To:” of the originator (you do have to remember to “reply-all”), and adds all the usual list garbage to allow systems to know it’s from a mailing list.

    • This is a solution, but arguably not a good one. It overloads the `From:’ header to fool the DMARC processor. This header is supposed to contain the author of the message, including the e-mail address of the author. I hope that a better solution can be developed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: