-----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] Sent: Friday, February 25, 2011 6:09 AM To: Murray S. Kucherawy; email@example.com 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 +subject+ 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.
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.
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.