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
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
>> 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?