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.

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;

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;

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

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@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/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to