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 contents 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.)

Signature breakage

Mailman's transformations can break DKIM signatures. The DKIM specifications are sparse about best common practices in the face of message transforming mailing list remailers. The question then is, what are the best common practices for mailing lists generally, and Mailman specifically, for playing nice in a world filled with DKIM? Make no mistake though, DKIM cannot be ignored; the big players such as Y! and G are already signing messages, and sites are already using DKIM signature validity as part of their spamminess decision making process.

At the time of this writing, the topic is being hotly debated on the mailman-developers mailing list.

We have 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-Signature headers, 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.

• Parse the DKIM-Signature header in order to adjust or record the effects of Mailman transformations on it. Several outcomes could include refusing to perform transformations (such as adding footers) that break the signature, or removing the original DKIM-Signature header if we've broken the signature.

• Sign headers under Mailman's control. For example, as per RFC 2369 Mailman adds a List-ID header which points to the posting address of the mailing list. Mailman could sign this header, and possibly also the Sender header (which Mailman also adds, though this is not without some controversy). Verifiers could then easily check for a verified List-ID header and reduce the spaminess of the message even if the From header signature were broken.

• Remove all original DKIM-Signature headers just in case our transformations have broken the signature. This solution seems to be strongly disfavored by DKIM proponents.

Problems with Mailman signing headers

When Mailman (or its downstream components) signs list copies, it means that the list server system is vouching for the validity of the message. Could this get us into trouble?

Because Mailman is a remailer, such resigning could open an attack vector where spam sent through the list suddenly get verified by a third party (the mailing list). 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 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.

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.

Proposal

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.:

# 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

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 List-ID, possibly Sender and potentially other Mailman added headers get valid signatures. We may instead encourage that sites that want to play nicely with DKIM configure their outgoing MTAs to sign these headers, reducing the computational burden on Mailman itself. 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 DKIM 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.

Finally, we should encourage the DKIM working group to include language in the spec specifically relating to mailing list interoperability. Such language should say that verifiers SHOULD check for the existance of, and look favorably upon, a valid signed List-ID header even if other DKIM signatures fail to validate. IOW, a valid signed List-ID header should be indication enough that all other signatures were subject to breakage because of mailing list garbling.

Comments