[Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 3, 2007, at 12:43 AM, Stephen J. Turnbull wrote:

> I think this points in the exact opposite direction from what you
> claim: users already understand what From means in the mailing list
> context, so if From and the DKIM signature are in conflict, the latter
> SHOULD be adjusted.  Since the ML is not in possession of the relevant
> key, removal is the only option.

ISTM that the DKIM spec is in agreement with you Stephen:

http://www.dkim.org/specs/draft-ietf-dkim-overview-02.html#anchor61

I think we can say Mailman is in compliance with choice #3 in this  
list.  I will also agree with the Note at the beginning of this  
section that this "may be controversial".  Indeed.

>> The very basic test I use is what's in the From: address. That's
>> the thing that's pretty universally displayed and one that users
>> are most likely to grok. Anything beyond From, and you've probably
>> lost at least half of the user population at least.
>
> If the users don't know the difference between "From" and "Sender",
> they have little chance of using DKIM as intended *except in the case
> where From == Sender* (or they are in the same DKIM domain).  Doesn't
> this amount to saying "we don't know what DKIM BCP for mailing lists
> is---that will be determined by the ability of average users to grok
> RFC 2822 (and we believe that is quite low)".

I'll just also comment that it is controversial that Mailman is  
adding a Sender header at all to outbound copies.  We've had this  
discussion in the past (no time to find the archive threads), and  
IIRC we've decided that the relevant RFCs are ambiguous wrt mailing  
list best practices.  No surprise there, but we also decided that  
adding Sender is a valid interpretation of the RFCs and the most  
reasonable thing for us to be doing.

However, Sender isn't useful to people because they never see it.   
Every MUA I've ever used simply displays the From header as who the  
message was originally written by, and I don't think we would provide  
clarity to our users if we munged that, under normal circumstances.   
We /have/ to do so for digests or anonymized lists, but that's a  
different situation.

> DKIM can help here.  Eg, if DKIM-enabled clients are told that they
> SHOULD recognize RFC 2369 headers and try to match the list identity
> to the DKIM signature, and DKIM is extended to provide for resenders
> (including lists that move domains---the List-ID will have a different
> domain then).

Agreed.

> Again, your argument bites the other way around.  I think it's a
> reasonable presumption that the user has *already* established the
> relevant trust relationship with the mailing list, because either the
> list is run by the user's employer (or similar), or the user opted in.
> Certainly you can presume that of any mailing list willing to
> cooperate with DKIM!

Agreed!  How many of you have trust relationships with the other  
members of this list?  What about your trust relationship with  
python.org, and this mailing list in particular?

> I think that all of this really points to issues that need to be
> resolved in the DKIM specification, not with mailing lists or any
> other existing infrastructure.  It's DKIM that needs to establish BCPs
> for user interface and user education, not other parts of the
> infrastructure that need to cover for DKIM's weaknesses at this point.
> Once DKIM has established its own BCPs, and technical analysis shows
> that it *requires* cooperation with other protocols to resolve
> important ambiguities, *then* it's time to ask MLMs etc to help with
> those issues.

Agreed!
- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcjzwHEjvBPtnXfVAQLPOgP/awMIcfI7J92Z9Lqvt7MYdm1mMFoHdpzU
VjO8RBTf7d3468TtCVowwKskduRcQazbsXAHnvl4FfoIqVlVI/mnktD0Tr1N0/3h
56CIu5cVbrTZc1wISPvBhs2zzGZNRxy7BfkbK5YZxFZZ9VnaNtcue9C/WgHiQ4HA
XosqMDkMm3E=
=3MXm
-----END PGP SIGNATURE-----