DomainKey Identified Mail (DKIM)
DKIM is a specification (RFC 4871)for cryptographically signing certain parts of an email message. Signing using DKIM allows for domain name holders to vouch for the integrity of headers and/or body text. The public keys for the signatures are available through DNS so only the DNS administrators corresponding to claimed domains in the signed components will be able to produce valid signatures.
DKIM affects Mailman in several ways. Most importantly, the transformations that Mailman can inflict on original postings can break DKIM signatures. Mailman can remove headers, add headers, concatenate header or footer text, add or remove MIME parts, completely reorganize the MIME structure of a message, perform character set transformations, and more. Any one of these things can break a DKIM signature.
Other ways in which Mailman and DKIM interact include whether Mailman should validate DKIM signatures on incoming messages and whether Mailman should sign outgoing list copies with its DKIM signature. (Note that when I say Mailman above, I really mean Mailman proper or any assistive mail component Mailman relies upon, such as the incoming or outgoing MTA.)
It is important to note, as per the IETF charter, that DKIM is an anti-spoofing mechanism, not an anti-spam mechanism.
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. RFC 6377 directly addresses issues involving DKIM and MLMs.
The question then is, are these best common practices for mailing lists generally acceptable to the administrators that run them? Make no mistake though, DKIM cannot be ignored; the big players such as Y! and G, Cisco, government departments, banks etc. are already signing messages, and sites are already using DKIM signature validity as part of their mail filtering processes.
Once opon a time this topic was briefly being hotly debated on the mailman-developers mailing list. In September 2009 Daniel Black asked for solutions from the DKIM developers email list. Several opinions were mentioned though without concensus.
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
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.
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
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. email@example.com
simple - few code changes required
Fiddling with From: email header could bring up unknown behaviours.
Mailman verifying headers
As a remailer, mailman is in a unique position where there are unlikely to be email lists chained together. The upshot of this is that there is unlikely to be email invalidated before reaching mailman's input. Applying a strong filtering policy on mailman's input is easy - invalid signatures, drop/reject, ADSP failures (dkim=all and dkim=discard) - drop/reject.
As mentioned on the dkim-dev email list dropping emails from subscribers with a ADSP policy of dkim=discardable is recommended on lists that will break DKIM signatures. DKIM discardable ADSP policies are inherently incompatible with current lists.
Mailman signing headers
Signing headers and content provides a mechanism for the recipient to determine if any modification occured after the mailing list server processed the message. There is no explict or implict meaning beyond this. List operators are free to place more assertion here at their peril.
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 email integrity and not validity - this is mentioned explicitly in draft-ietf-dkim-deployment rfc
Because Mailman is a remailer, such resigning could open an attack vector where spoofed email is sent through the list suddenly gets relayed without verification. This could potentially legitimatize otherwise illegitimate messages. Thus if Mailman were to add its own DKIM signatures, you'd want to make sure Mailman were also checking the DKIM signatures of messages it receives, and potentially putting a hold (or rejecting or dropping) on messages that had a broken or non-existent signature. You probably also want to do more aggressive spam filtering on the message before it even hits Mailman (disputed - recipients shouldn't be using DKIM as a spam bias score - doing so will just ensure spammers DKIM sign emails. Aggressive spam filtering before mailman will not gain anything DKIM wise).
Spam directly mailed to the list isn't the only problem though; a much more likely scenario for some lists are that messages gated from Usenet come from a totally unverifiable source. Of course, Usenet gating is a pretty rare use case these days, but still, we shouldn't ignore it. Already
python.org occassionally gets labeled as a spam source because of its gating of spam messages from
comp.lang.python. It probably makes the most sense to simply not sign gated messages.
Because we're in feature freeze for Mailman 2.1, we can't add any new functionality. However, in Mailman 2.1.9, we explicitly began stripping
DKIM-Signature headers from incoming messages. This is what sparked the above mentioned developers thread. The original impetus for this change was a broken DKIM Sendmail milter which refused to sign outgoing messages that already contained a signature.
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.:
The default is
No in order to restore the behavior that came to be expected before the 2.1.9 release.
For Mailman 2.2/3.0 then, we should explore adding DKIM signing code as a handler module, such that definitely
Sender and potentially other Mailman added headers get valid signatures. However, if we do this, we'll need to have a way to tell the outgoing MTA not to sign certain messages (e.g. Usenet posts). That might require an MTA-specific solution.
We should also encourage the site's incoming MTA to check the validity of any
DKIM-Signature header on posted messages. We'd like to see something like a DKIMDKIM validity status header (RFC5451) validity status header added to the message Mailman sees. Then Mailman can put a hold on messages that its upstream MTA tells it has a bad DKIM signature.
We should enable our user's to configure their Mailman system to not break any
DKIM-Signature. Perhaps by offering a dkimfriendly=true global option.
Finally, we should encourage the DKIM working group to include language in the spec specifically relating to mailing list interoperability. We cannot ask verifiers to just favorably upon, a valid signed
List-ID header as this will just ensure spammers and phishers add List-ID headers to spam.
To develop standards to assist with email lists as an alternative to the last option above that provides a neat solution, there could be a third-party domain signing policies. Some standard that allows senders to define which third party signatures receipents should receive, even if the author domain signature is broken. An example could be a DNS records like list_python_org._3p._domainkey.example.com to indicate that recipients should accept a list.python.org third party DKIM signature. The same validation heirarcy could also be used by verifiers of arbitrary domains to see which domains really operate email lists.
A paper Daniel Black wrote on DKIM and email lists - https://community.cacert.org/dkim. Feedback/discussions welcome on dkim-ops list, personally or on dkim-user/dev lists.