2018-09-18
There’s a common belief online that DMARC, an anti-phishing technology, prevents the proper operation of electronic mailing lists. To get around the perceived problem, many articles advise reconfiguring listserv software in ways that break the norms of SMTP.
However there is a configuration that allows mailing lists to work perfectly and still be able to relay messages in the presence of DMARC. Before describing it, let’s get some terminology straight.
While earlier methods such as PGP have existed to unmask mail forgery, DMARC has become the popular choice and is honored today on all major mail servers. However people whose domains employ DMARC are unable to send messages through traditionally-configured mailing lists. During DMARC adoption on major domains such as gmail and yahoo, mailing lists started having widespread problems.
Some people called DMARC a broken standard. They failed to implement elegant adjustments to mailing list behavior, and used hacky workarounds to fix the problem instead.
Let’s examine how a message passes or fails DMARC, and then learn how to fix lists. A message passes if either SPF or DKIM passes, and only fails if both SPF and DKIM fail. This way SPF-only and DKIM-only messages can pass DMARC, but messages without either SPF/DKIM will always fail.
Secondly, the message must pass “DMARC alignment.” Alignment means two different things:
Visualization of DMARC alignment from a Dmarcian
article:
A mailing list is going to have a hard time relaying messages for any domain that uses DMARC and SPF but not DKIM. Consider this message:
Return-Path: <bounce@dmarcdomain.com>
From: "Sally Sender" <sender@dmarcdomain.com>
To: "Fun List" <fun@mailinglist.org>
Subject: Hi
Hi everyoneThis would ordinarily be a proper reflection to a subscriber:
Return-Path: <fun-bounce@mailinglist.org>
From: "Sally Sender" <sender@dmarcdomain.com>
Sender: "Fun List" <fun@mailinglist.org>
To: "Roger Reader" <reader@destination.com>
Subject: Hi
Hi everyoneHowever destination.com will reject this message if
mailinglist.org is not in the SPF record for
dmarcdomain.com. Furthermore a good SPF record is not
enough, since the Return-Path and From are out of alignment (they
specify different domains).
Dealing with this situation is what causes the hacky workarounds. Lists have to use techniques like From-munging or MIME message wrapping to get the mail through.
Here is what From-munging looks like:
Return-Path: <fun-bounce@mailinglist.org>
From: "Sally Sender via Fun List" <fun@mailinglist.org>
Reply-To: "Sally Sender" <sender@demarcdomain.com>
To: "Roger Reader" <reader@destination.com>
Subject: Hi
Hi everyoneThe recipient would only have to check DMARC for
mailinglist.org which would pass. However this is a poor
use of email, since it’s misrepresenting who originated the message.
Also email clients often have a degraded interface with respect to the
Reply-To header. It’s usually not visible in the message
list, not used for sorting, and not added to the address book.
If the sending domain uses DKIM, it avoids the need for From-munging or other hacks. It works under the condition that the list does not modify the message.
Consider the properly reflected message again:
Return-Path: <fun-bounce@mailinglist.org>
From: "Sally Sender" <sender@dmarcdomain.com>
Sender: "Fun List" <fun@mailinglist.org>
To: "Roger Reader" <reader@destination.com>
Subject: Hi
Hi everyoneSPF will fail, as we saw earlier, so DMARC will try a DKIM check. The From, Subject and body were not modified so they will be properly signed. DKIM checks alignment between RFC5322.From and the signature’s domain, which will also match. DKIM passes, and message gets delivered.
Should be perfect, right? Well it could be, except lists traditionally add extra information in the subject and body of relayed messages, and the modified fields don’t pass a DKIM check. Messages from traditional mailing lists typically look more like this:
Return-Path: <fun-bounce@mailinglist.org>
From: "Sally Sender" <sender@dmarcdomain.com>
Sender: "Fun List" <fun@mailinglist.org>
To: "Roger Reader" <reader@destination.com>
Subject: [fun] Hi
Hi everyone
--
You are subscribed to the fun list, to unsubscribe
visit https://mailinglist.org/unsub/123The subject line tag is typically used to sort the messages into a separate mailbox following user-defined rules in the email client. The unsubscribe link in the body is a convenience (and avoids government fines from violating the CAN-SPAM act.)
We need to give the client a way to sort mail, unsubscribe, etc without modifying the parts of the message signed by DKIM. Fortunately, there are RFCs for this. RFC2369 from 1998 and RFC2919 from 2001 both predate the DMARC machinery. The first introduces header fields for list information and control.
For our example RFC2369 allows us to add
List-Unsubscribe: <https://mailinglist.org/unsub/123>.
It also introduces headers like List-Help, List-Subscribe, List-Post,
List-Owner, and List-Archive. What’s more, many mail clients understand
these headers. Gmail adds an unsubscribe button to the web interface
when it detects List-Unsubscribe.
The second RFC offers a way to identify a list with another header,
like List-Id: The Fun List <fun.mailinglist.org>.
Mail client rules can query this header rather than checking whether the
subject field contains [fun].
It is reasonable nowadays to require that mailing list users whose domains use DMARC also enable DKIM. In fact the list software could check the sender’s domain at subscription time and raise an error if their domain uses DMARC but not DKIM.
Lists should keep the From address, the Subject, and the Message totally unchanged. They should add a Sender header to indicate their relay role, and set at least the List-Id and List-Unsubscribe headers for mailbox rules and subscription management.
This configuration will allow mailing lists to function as proper SMTP citizens in the age of DMARC.
Written by Joe "begriffs" Nelson