Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Mailman's transformations can break DKIM signatures. The official DKIM specifications about best common practices in the face of message transforming mailing list remailers is still in draft form - dkim deployment RFC (link is not resolving). Of larger importance than DKIM signatures is the effect of RFC5617 Author Domain Signing Practiceswhich defines which domains are DKIM signing all email. There is a draft spec being proposed that directly RFC 6377 directly addresses issues involving DKIM and MLMs.


There are several options for dealing with DKIM signature breakage. They are not necessarily mutually exclusive.




Ignore the problem

This is the simplest solution because it mean we don't have to change Mailman at all. If the original message has DKIM-Signatureheaders, we just leave them in there even if Mailman's transformations break the signature. We do no parsing or verification of the signature, nor do we limit any Mailman transformations we would otherwise apply to the message because of the signature.

The effects of this are that recipients of list copies of the message may fail to verify the signature, potentially treating the message as spammy.
Ignoring the problem limits the ability of recipients to filter based on DKIM signatures (not  just for email lists)

Parse the DKIM-Signature header in order to adjust the effects of Mailman transformations on it.

Allows recipients to validate and filter based on DKIM

will end up lots of exception handling code and an inconstant emails to the subscriber that may not meet the list owner's policy

Remove all original DKIM-Signature headers if after parsing the DKIM-Signature header we've broken the signature.

Simple. Solves DKIM validation.

ADSP tells the recipient that a signature should exist where a From address contains the author's domain. Removing DKIM-Signatures is just as bad as invalidating them in the and will result in ADSP rejections.

sign list-ID headers and ask verifiers to check for list-id tags in a spamyness way


complicates verification, provides spoofing loophole as DKIM is antispoofing more that antispam

remove DKIM-Signature always

as per other similar option (up 2)

as per other similar option (up 2). This solution seems to be strongly disfavored by DKIM proponents.

rewrite From: email header field to contain the list domain in the From header field. e.g.

simple - few code changes required

Although all modifications of DKIM email signature still occur, it is not as critical as the email is nolonger the author domain (based on the from address).
As the From: address is now belonging to the list operator, DKIM signing by mailman will be able to be cleanly validated by recipents without having to manage as many whitelists of DKIM-signature invalidating intermediaries.
Doing this by default will enable DKIM validation to occur easier.


Fiddling with From: email header  could bring up unknown behaviours.

If a reply-to address doesn't exist in the email headers add the from address here to preserve MUA behaviour.

Desirable is a remap from the From address back to the user validated in a way that it cannot be used as a arbitrary spam address. e.g. validating against the list subscribers.

Mailman verifying headers


A misconception is that when Mailman (or its downstream components) signs list copies, it means that the list server system is vouching for the validity of the message. Answer no - the RFCs talk in terms of emaill email integrity and not validity - this is mentioned explicitly in draft-ietf-dkim-deployment rfc


The proposal for Mailman 2.1.10 then is to add a variable to (configurable via that controls whether DKIM-Signature headers are removed or not in outgoing list copies, e.g.:

No Format

# Controls whether all existing DKIM-Signature headers in posted messages
# get stripped in the outgoing list copies.  In general, you should leave
# this disabled so that original DKIM signatures will be retained for
# forensic purposes, even if broken.  Enable this feature only if your site
# has specific problems with outgoing pre-signed (broken or unbroken) messages.