[Mailman-Developers] dkim-signature headers
barry at python.org
Tue Feb 6 22:31:43 CET 2007
-----BEGIN PGP SIGNED MESSAGE-----
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:
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
> 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).
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
More information about the Mailman-Developers