Re: [Mailman-Developers] mailman and DKIM

--On 28 February 2011 17:15:45 -0800 "Murray S. Kucherawy" <msk@cloudmark.com> wrote:
I think that's the same thing, isn't it?
Good point.
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.
-- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/

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

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