[Mailman-Developers] dkim-signature headers

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Me too.  Here's my discussion on the topic, including a concrete  
 > proposal for Mailman 2.1.10 and 2.2/3.0.  Feel free to comment on the  
 > wiki on in this thread.

I'll try to post to the wiki later (I'm not a member yet and I'm
suffering mail delays---I expect I'll need to do an email confirm),
but assuming "on" should be "or" I'll reply here first.

In "Problems with Mailman signing headers" you write that a Mailman
signature could potentially "legitimize otherwise illegitimate
message".  Technically, this is confusing language.  "Legitimate" is a
local policy decision and will surely vary from site to site.  I would
prefer that this kind of idea be expressed as "result in recipients
accepting spam and undesired messages that they otherwise would
reject."

You suggest as a solution not signing gated messages.  This has its
own problems, specifically that (1) the list is deliberately not
signing some of its output, which will cost the host site the
advantages of the claim that all of its mail is signed, and (2) many
sites that know that this list signs, and will drop all unsigned
posts.  I think a plausible alternative strategy would be to sign
Usenet-gated posts with a different key.  I don't think this is
generally going to be more than minor extra effort, as any decent
signing agent will be prepared to deal with selectors.  (I suppose
this is mandated by DKIM, but I haven't checked.)

In "Proposal", the language for 2.1.9 is excellent.

For 2.2/3.0, I think that all RFC 2369 headers must be signed to
prevent phishing attacks.  Sender should be signed for Mailman's
own potential benefit, I think, and of course DKIM itself mandates
signing From.

The discussion of the DKIM status header should note that DKIM does
not even suggest a format for these headers, so they will be
implementation-dependent.  I think a call for Mailman advocates to
participate in specification of a standard header, as well as to help
with implementations' headers in the meantime, may be warranted.

Regarding the call for verifiers to "look favorably on" verified list
signatures, I'm of two minds.  Technically, I think it's a bug in the
DKIM spec that it doesn't thoroughly distinguish between verifiers and
policy agents (not to mention that it fails to mention the role of
policy agents for the signing decision at all!)  So I don't like
language that suggests that verifiers make policy decisions.  There's
planty of precedent for it in the latest draft, though. :-(

I think that language to the effect that verifiers MAY make extra
effort to find a valid list signature in the case where broken
signatures are found is definitely appropriate, though.

As Michael has repeatedly emphasized, very little is known about the
pragmatics of re-signing.  Nonetheless, I think that a better way to
try to accomplish this is to have a Mailman implementation that wants
to take responsibility for broken signatures is to sign those
signatures.  (Remember, it can also create another signature without
signing them.  Then the signature signature might fail due to an
intermediary reordering DKIM signatures, but the signature of the mail
itself would succeed.)

Then the BCP for policy agents could say that the presence of a broken
signature which is nonetheless verified by a valid signature SHOULD be
considered an indication that the verified signer verified the broken
signatures on the way in, and that the verified signer then broke
them.  (This doesn't mean that a policy agent should trust the broken
signature.  That depends on how much it trusts the verified signer.)

I think your current language is a non-starter without signing the
signatures.  It's an obvious veector for reply attacks.