...
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.
Option | Pros | Cons |
|---|---|---|
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 | 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. |
Parse the | 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 | 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 | simple | 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. mailman-users-relay+daniel=cacert.org@python.org | simple - few code changes required | Fiddling with From: email header could bring up unknown behaviours. |
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 Defaults.py.in (configurable via mm_cfg.py) 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.
STRIP_DKIM_SIGNATURE = No
|
...