Home / Blogs

DKIM for Discussion Lists

J.D. Falk

There's a pernicious meme floating around that DomainKeys Identified Mail (DKIM) doesn't work with discussion lists, particularly those hosted on common open source software packages like MailMan. It's particularly odd to see this claim after I set it up successfully on a stock Debian server in less than half an hour, just a few weeks ago. Here's how it can, should, and does work:

1.  The inbound MTA handles DKIM signature verification, and applies an Authentication-Results header (or a custom X header.) For example, Sendmail's DKIM Milter does this out of the box for Sendmail, Postfix, and other popular MTAs.

2.  If the list /won't/ be modifying the message — in other words, if it acts like a simple forwarder — skip to step 5.

3.  Either the MDA or the list handler strips the DKIM-Signature header, effectively rendering the message unsigned.

4.  The list handler modifies the message in accordance with its configuration, often by adding a footer, placing a tag in the Subject: header, and adding List-* headers.

5.  The MSA or outbound MTA (re-)signs the message. This is appropriate because even if the message is passing through the system unchanged, the list handler is now the Originator, and thus responsible for that message (from a technical perspective, if not in a legal sense). I'd recommend using a different selector (perhaps a different subdomain) for each list, or at least for lists vs. non-list mail from that host, but that's not required.

6.  The outbound MTA transmits the message as per usual.

There's no wacky hacking required — it all works exactly as documented, and exactly as intended.

(Much of the terminology used in this article — MTA, MSA, Originator, et cetera — is defined in draft-crocker-email-arch-15.)

By J.D. Falk, Internet Standards and Governance. More blog posts from J.D. Falk can also be read here.

Related topics: Cybersecurity, Email, Spam


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


Oops, one correction: step #3 above doesn't J.D. Falk  –  Jun 02, 2009 3:38 PM PDT

Oops, one correction: step #3 above doesn't happen by default, but MailMan and other list software can easily be configured to strip particular headers — or you can use procmail or other mail filtering software between the MTA and the list handler.

Works great John Levine  –  Jun 03, 2009 2:12 AM PDT

I did the same thing for majordomo2, and it was similarly easy.

I don't bother to put in an authentication-results header since the list software has plenty of logs in the unlikely event that I need to track how a particular message got through a list.

Authentication-results Jim Fenton  –  Jun 04, 2009 11:38 AM PDT

A couple of things relating to the application and use of the Authentication-Results header field in step 1:

- Does the signature applied in Step 5 include the Authentication-Results header field just added?  The signing of Authentication-Results header fields strikes me as implying somewhat different semantics (correctness of the header field) than a DKIM signature has (taking responsibility for the message, but saying nothing about its correctness) which makes me a bit conflicted on this idea.

- Prior to applying Authentication-Results, the list software should look for and remove any existing Authentication-Results header fields that purport to be from the list.  Otherwise it's possible for an attacker to spoof the A-R header field.

Are there any other recommendations on header fields that the list should sign, such as List-Id?

To my mind, signing the Authentication-Results header J.D. Falk  –  Jun 05, 2009 11:14 AM PDT

To my mind, signing the Authentication-Results header still has the same concept of taking responsibility for that header.  Downstream entities will have to make up their own minds whether that responsibility is sufficient to denote correctness.  Even so, I'm also conflicted about whether it's a good idea.

Shouldn't hurt for the list software to remove it, though — or to remove any other Authentication-Results headers that might be lying around — because recipients will only be using the new signature to decide whether the message is trustworthy.

additional discussion J.D. Falk  –  Jun 13, 2009 5:52 AM PDT

There's been some additional discussion about this on the ietf-dkim list, with a few people vehemently against the recipe above.  Hector Santos summed up the differences nicely in this message.  My reply is here.

If all you care about is making sure that your discussion list is signing effectively with DKIM, though, just read the original article above.  This particular debate is lost deep in the weeds.

draft-ietf-dkim-mailinglists J.D. Falk  –  Sep 01, 2010 11:12 AM PDT

There's now an IETF draft being developed with additional advice for mailing list operators:


That draft has now been published as J.D. Falk  –  Sep 25, 2011 9:17 AM PDT

That draft has now been published as RFC 6377.


To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper


Sponsored by Verisign

Mobile Internet

Sponsored by Afilias Mobile & Web Services

DNS Security

Sponsored by Afilias

IP Addressing

Sponsored by Avenue4 LLC

Promoted Posts

Buying or Selling IPv4 Addresses?

Discover ACCELR/8, a transformative IPv4 market solution developed by industry veterans Marc Lindsey and Janine Goodman that enables organizations buying or selling blocks as small as /20s. more»

Industry Updates – Sponsored Posts

Verisign Named to the Online Trust Alliance's 2017 Audit and Honor Roll

Attacks Decrease by 23 Precent in 1st Quarter While Peak Attack Sizes Increase: DDoS Trends Report

Leading Internet Associations Strengthen Cooperation

Verisign Releases Q4 2016 DDoS Trends Report: 167% Increase in Average Peak Attack from 2015 to 2016

Verisign Q3 2016 DDoS Trends Report: User Datagram Protocol (UDP) Flood Attacks Continue to Dominate

2016 U.S. Election: An Internet Forecast

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Don't Gamble With Your DNS

Defending Against Layer 7 DDoS Attacks

Understanding the Risks of the Dark Web

New TLD? Make Sure It's Secure

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Facilitating a Trusted Web Space for Financial Service Professionals

MarkMonitor Partners with CYREN to Deepen Visibility into Global Phishing Attacks

Verisign Named to the Online Trust Alliance's 2016 Honor Roll

Port25 Announces Release of PowerMTA V4.5r5

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year