[Mailman-Developers] mailman and DKIM

[Ian Eiloart]

--On 24 February 2011 19:36:31 -0800 "Murray S. Kucherawy" 
<msk at cloudmark.com> wrote:

> Hi,
>
> I'm authoring a document within the DKIM working group at the IETF to
> talk about the use of DKIM in the context of mailing lists.  I believe
> one or more of you is already at least monitoring the working group
> traffic on that topic, and thanks for that.
>
> Mailing Lists Managers legitimately modify messages sent through them.
> (After all, lists are, essentially, re-posting a new message and they can
> do what they want.) DKIM has a minimal feature that attempts to allow a
> signature to survive transiting mailing lists, by ignoring text added to
> the end.
>
> A suggestion has come up that I'd like to bounce off of you. We're
> interested in doing a better job of surviving the transit.  That means
> that DKIM would have to adjust to other modifications made by MLMs, such
> as altering Subject: field contents.

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.


> What a few of us would like to explore is the idea of collaborating with
> the MLM community to develop a profile for MLM message modifications that
> DKIM can be enhanced to survive.  For example, a new canonicalization
> algorithm might tolerate the addition of a "[...]" string at the
> beginning of a Subject line.  We would document this profile and MLM
> implementers can choose to support it.
>
> This would be a voluntary and cooperative effort.  DKIM signers would
> have one more configuration choice.  MLM operators would have a special
> kind of profile that could apply to a list.  Or not.
>
> Our initial discussions have come up with a few idea.  No doubt some are
> unworkable, but they should at least serve to get further discussion
> going:
>
> 1) add a way to DKIM to have small Subject: modifications be tolerated;
> something like "exclude from the signed portion any leading text in the
> Subject: field that is contained within square brackets and includes only
> letters, numbers, hyphens and underscores, to a maximum of 32
> characters", which would allow MLMs to add a short token such as the list
> name for use by receivers in mailbox sorting but would make it tough for
> abusers to put a URI there;

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.

> 2) encourage people to sign with "l=" tags, but recommend that receivers
> enforce a policy that says any appended text must be no more than a
> couple of lines long and contain no URLs, or some other similar
> restriction;

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

>
> 3) explore ways to increase use and utility of the List-* header fields.

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.

> I'd like to hear your views on such an approach and any other suggestions
> you may have.  As a representative of The OpenDKIM Project, which is used
> by AOL and Yahoo to perform DKIM verifications, I can say we're in a
> position to conduct some real experiments and get the code out to a wide
> distribution if we come up with something that has the potential to be
> successful.
>
> Let me know what you think.
>
> Cheers,
> -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/