On Dec 06, 2011, at 10:17 AM, Murray S. Kucherawy wrote:
I think this is the one big lesson from these discussions: DKIM is mostly incompatible with mailing lists. Where the two must be integrated, some usability will likely be compromised.
It depends on your expectations. If there's an expectation that the author's signature will/should/must persist through a mailing list, then I agree that they're largely incompatible. If on the other hand you intend for lists to re-sign mail and for receivers to evaluate the message based on the list signature rather than the author signature, then it's entirely workable. Of course, sometimes the author signature will indeed survive, and then you have two domains to evaluate instead of one. Bonus!
My own personal feeling is that having lists re-sign messages is the best expectation to put forward. You're subscribed to a mailing list, so you trust that list much more than you trust the senders on that list. So having the mailing list site re-sign the outgoing messages seems to me to be best practice. My inclination is that removing the original author's signature first is not entirely inappropriate.
Note too that Mailman supports anonymizing list traffic to the extent that it would wipe out the original From header. Some lists turn this on for a higher degree of privacy than you see on most open discussion lists. In that case, the From header would look like it's coming from the mailing list, and then it would make the most sense to remove any original signature and leave only the list's signature.
It seems to me that relying on From header signing of mailing list messages just isn't that useful.
As Monica points out, DKIM itself is oblivious to the context in which it's being used.
I'm no DKIM expert by far, but it seems to me that a mailing list message has enough clues that a DKIM verifier could do a better job at helping recipients make good choices. For example, all Mailman messages have a List-Id header that contains the domain name hosting the list server. With re-signing, why couldn't you verify the signature against the List-ID host instead of the original sender?
You could. The issue isn't that doing so is wrong or impossible. It's simply that those semantics aren't built into DKIM, largely because we have no evidence that that's a useful test.
The ESP community has argued that third-party signatures (those different than the one in the From: field) shouldn't be valued any less than one that does match, for various reasons. That argument was apparently persuasive.
ADSP, and a draft I'm advancing called ATPS, extend DKIM's semantics to do more than just say "domain X handled this message" (which is really all a valid DKIM signature tells you). They both attempt to say things based on whether the domain delivered as part of a valid DKIM signature matches some identifier in the message, like the domain in the From: or in the List-ID field. If Mailman (or an MUA, or a filter, or something) implements such checks and finds that it's operationally beneficial to end users do so, then it could publish that mechanism in an RFC or elsewhere, and people could start to use it. The resistance isn't that this is a bad idea, but just that there's no evidence to back it up that would justify its standardization.
In that case, it would be interesting and feasible for you to perhaps line up some mailing list sites to enable this and gather some statistics. It would be pretty easy to do (I think) in Mailman 3 (though that's unreleased) and probably not hard to do in Mailman 2.
The trick, of course, is not just to do something like this, but to get MUA buy-in. That is, when a signature validates and it presents a domain name that matches some identifier, change the presentation of the message to show this in some meaningful way. And then make sure in doing so that you don't inadvertently discredit legitimate messages for which that's not true.
Right. So, Gmail is probably the 800lb MUA gorilla here. Monica, do you have any thoughts on how you could run such an experiment and find out what is most useful to your users?
Cheers, -Barry