[Mailman-Developers] mailman and DKIM

[Ian Eiloart]

--On 28 February 2011 17:15:45 -0800 "Murray S. Kucherawy" 
<msk at cloudmark.com> wrote:

>> -----Original Message-----
>> From: iane at sussex.ac.uk [mailto:iane at sussex.ac.uk]
>> Sent: Friday, February 25, 2011 6:09 AM
>> To: Murray S. Kucherawy; mailman-developers at 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 at 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/