DomainKey Identified Mail (DKIM)
DKIM is a draft specification 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.
Comments
Looking favorably on List-Id tags is just opening a big bypass in dkim email checking. I really like the propositions that say we're going to get with DKIM and continue on to a brave new internet.
Good practice plan:
1. Encourage List managers to reject email with broken signatures or that conflicts with http://tools.ietf.org/html/draft-ietf-dkim-ssp-03 Author Signing Practices. I think this will deal with the "vouching for the validity" problem of signing.
2. Encourage List managers to DKIM sign content. This is just making a statement that the content came through the server and that you've done DKIM checking on the input.
3. Provide a mechanism for List managers not to mangle DKIM signatures. Provide or refer to "DKIM - A list managers' guide"
4. Encourage DKIM implementers to have a policy of configuring favorable DKIM signatures that will allow an email though even if the Author Signing Practices fail. This is mainly for those List managers that insist on breaking signatures.
DKIM IETF Working Group have started DomainKeys Identified Mail (DKIM) Development, Deployment and Operations Draft RFC that covers what Mailing List List Managers should do with DKIM and list email.
I think you have to take the message as it originally came in, extract the DKIM signature and headers that it covers, and then re-sign all those headers and content (after modification).
Think of it like a chain of custody. You get a message that is signed, and which may have some additional stuff associated with it that is not signed (like the "Received:" headers). Because you're going to do something that is likely to destroy the signature and the original message as you received it, you need to re-sign the stuff you got which was signed on input, to be able to demonstrate to others that it had come into you signed, that you verified that signature, and you're certifying what it is that you verified.
I have a suggestion on how this can be fixed:
Take the *whole mail* as sent as the user, and put this into a new message/rfc822 container, that has the envelope from *AND* "From:" set to the list mailing adress (eg the mail adress that users send their list posts to).
So a list mail like this:
From: listuser@example.org To: list@list.org Subject: Fix this Content-Type: text/plain
This is broken.
Can be sent out from the list as:
From: list@list.org To: list_subscriber@someotherhost.org Subject: Fwd: Fix this Content-Type: message/rfc822; boundary="
1234"
This is a MIME Message
1234 From: listuser@example.org To: list@list.org Subject: Fix this Content-Type: text/plain
This is broken.
1234--
The fixed mail can additionally be DKIM signed by the list software.
The advantages of this, is that it will BOTH fix DKIM problems (since the signing is done from the list domain and not the sender domain), *AND* SPF, since the SPF will then be validated against the list domain and not sender domain).
Another advantage by encapsulating the mail into a new message/rfc822 container, is that you don't break any previous DKIM signatures, and also do not break any S/MIME or PGP signatures.
The suggestion in the comment by SebastianNielsen is exactly what is done by the from_is_list Wrap Message setting first implemented in Mailman 2.1.16 and made more generally available (not requiring site option to enable) in Mailman 2.1.18. See DEV/DMARC.
Re: Problems with Mailman signing headers
You write that a Mailman signature could potentially "legitimize otherwise illegitimate message". Technically, this is confusing language. "Legitimate" is a local policy decision and will surely vary from site to site. I would express this kind of idea as "result in recipients accepting spam and undesired messages that they otherwise would reject."
You suggest not signing gated messages. This has its own problems, specifically that (1) it is useful to promise to sign all messages, but the list is deliberately not signing some of its output (2) many sites that know that this list signs will drop all unsigned posts. A plausible alternative strategy would be to sign Usenet-gated posts with a different key. I don't think this is generally going to be more than minor extra effort, as any decent signing agent will be prepared to deal with selectors. (I suppose this is mandated by DKIM, but I haven't checked.)
Re: Proposal
The language for 2.1.10 is excellent.
For 2.2/3.0, shouldn't all RFC 2369 headers be signed to prevent phishing attacks? Sender should be signed for Mailman's own potential benefit, I think, and of course DKIM itself mandates signing From.
The discussion of the DKIM status header should remark that DKIM does not even suggest a format for these headers, so they will be implementation-dependent. I think a call for Mailman advocates to participate in specification of a standard header, as well as to help with implementations' headers in the meantime, may be warranted.
Regarding the call for verifiers to "look favorably on" verified list signatures, I'm of two minds. Technically, I think it's a bug in the DKIM spec that it doesn't thoroughly distinguish between verifiers and policy agents (not to mention that it fails to mention the role of policy agents for the signing decision at all!) So I don't like language that suggests that verifiers make policy decisions. There's plenty of precedent for it in the latest DKIM draft, though.
Language to the effect that verifiers MAY make extra effort to find a valid list signature in the case where broken signatures are found is definitely appropriate, though.
As Michael has repeatedly emphasized, very little is known about the pragmatics of re-signing. Nonetheless, I think that a better way to try to accomplish this is to have a Mailman implementation that wants to take responsibility for broken signatures is to sign those signatures. (Remember, it can also create another signature without signing them. Then the signature signature might fail due to an intermediary reordering DKIM signatures, but the signature of the post itself would succeed.)
Then the BCP for policy agents could say that the presence of a broken signature which is nonetheless verified by a valid signature SHOULD be considered an indication that the verified signer verified the broken signatures on the way in, and that the verified signer then broke them. (This doesn't mean that a policy agent should trust the broken signature. That depends on how much it trusts the verified signer.)
Without signing the signatures, there's an obvious vector for reply attacks. I don't think that can be written into the standard or BCP.