[Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Michael Thomas writes:

 > What it seems to me is that maybe we should look close at that
 > behavior of when a list ought to take From: responsibility for a
 > message ala digests. When a list completely mangles a message, is
 > it really reasonable for it to keep acting as if it came from the
 > original From: address? There's probably not a bright line here,
 > but maybe we should force the issue with DKIM

"Force"?!  You've got the tail wagging the dog here.

>From is an *author* header, not property of the MTA.  It indicates the
*author*, not the editor or delivery agency.  If the author approves
the message munging (and this is implicit in Internet custom or even
the mailing lists terms of use in most cases), DKIM MUST live with it.
So there's your bright red line.

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.

 > 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)".

 > So the bottom line is that a valid third party signature from, say,
 > a mailing list is not safe a priori. It requires special handling
 > by the ultimate receiver in the form of a trust relationship with
 > that domain which needs be done out of band. The same is not of a
 > first party signature because you're only vouching for yourself
 > which is already as good you trust that domain (or not).

That's specious IMO.  Technically, when the mailing list signs a
message, it's vouching for that message as the mailing list re-sent
it.  This is exactly the same as for the originating domain.  From the
UI standpoint, if a DKIM-enabled MUA doesn't present information
(including their roles as originators or resenders) about *all* of the
"DKIM senders" to the user, it is hopelessly broken for use in a
resending environment.

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!

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.