[Mailman-Developers] mailman and DKIM

[Murray S. Kucherawy]

> -----Original Message-----
> From: iane at sussex.ac.uk [mailto:iane at sussex.ac.uk]
> Sent: Thursday, March 03, 2011 8:58 AM
> To: Murray S. Kucherawy; mailman-developers at python.org
> Subject: Re: [Mailman-Developers] mailman and DKIM
> 
> >> Perhaps you could modify the syntax of the h= tag, to allow, say
> >> [12]+subject+[5] to mean that 12 unknown characters may prefix the signed
> >> header, and 5 may follow, provided they are bracketed. I'd suggest only
> >> permitting bracketed additions, so perhaps this could be expressed as
> >> 12+subject+5 instead. I suppose all of this might break existing
> >> implementations, so perhaps a separate tag would be required.
> >
> > Perhaps, but the verifier needs to be told exactly how to identify the
> > signed part in order to feed it to the hash algorithm.  So instead,
> > something like a rule that says "remove up to x bytes from the Subject:
> > field, including any enclosing square brackets", with a constraint on
> > allowed characters inside the square brackets, might be a better approach.
> 
> I think that's the same thing, isn't it?

It wouldn't break existing implementations because it would name a new "c=" value.  Existing (compliant) implementations would simply ignore such signatures.

I think your idea was to delete up to 12 in front of whatever "subject" is and 5 after, where mine was just to go left-to-right deleting up to the specified number in only the first such block of characters.  Slightly different.  But either mechanism would mess with an otherwise legitimate Subject: that used square brackets for some reason, so that's a concern.

The other suggestions made here discuss the body as more of a concern, since Mailman flattens a multipart/alternative into a simpler form.  It could be that the proposed MIMEAUTH would work here; sign both parts of the original, and then even if Mailman tosses all but the text/plain part and even adds its own, the signature on the original text/plain part would still pass.  That, coupled with a new header canonicalization mode that tolerates rudimentary Subject tagging, might be useful.

(MIMEAUTH: http://tools.ietf.org/html/draft-crocker-doseta-mimeauth-00)

-MSK