Re: [Mailman-Developers] mailman and DKIM
--On 28 February 2011 17:15:45 -0800 "Murray S. Kucherawy" <msk@cloudmark.com> wrote:
-----Original Message----- From: iane@sussex.ac.uk [mailto:iane@sussex.ac.uk] Sent: Friday, February 25, 2011 6:09 AM To: Murray S. Kucherawy; mailman-developers@python.org Subject: Re: [Mailman-Developers] mailman and DKIM
I think this is only valuable for users of ADSP. Other people would expect their signatures to break, and be supplemented with a good signature generated by the list server.
I don't think that's the only class of users that would be interested in this problem.
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?
Maybe the l= syntax could be extended. Eg, l=12544+512 would mean "I'm signing 12544 octets, and permitting the addition of a further 512
I would simply add an "la" tag defining the amount that can be appended rather than changing the syntax of "l=", so as to be back-compatible with current implementations.
Good point.
Well, if the sender knows that the list is going to add a List-ID header, then it could add that before signing. I doubt this would scale well, though.
Why's that?
It's the "if the sender knows" bit that doesn't scale. On sites with more than a few users, managing a list of remote email addresses that are lists wouldn't be easy.
-MSK
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/iane%40sussex.a c.uk
Security Policy: http://wiki.list.org/x/QIA9
-- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/
-----Original Message----- From: iane@sussex.ac.uk [mailto:iane@sussex.ac.uk] Sent: Thursday, March 03, 2011 8:58 AM To: Murray S. Kucherawy; mailman-developers@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
participants (2)
-
Ian Eiloart -
Murray S. Kucherawy