[Mailman-Developers] mailman and DKIM

[Mark Sapiro]

Murray S. Kucherawy wrote:
>
>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;


Some MLMs will add a subject prefix other than at the beginning or will
move an existing prefix. E.g.

Subject: Re: Something

becomes

Subject: Re: [List] Something

or

Subject: Re: [List] Something

becomes

Subject: [List] Re: Something

Mailman will do the former if mm_cfg.OLD_STYLE_PREFIXING is True and
will do the latter if mm_cfg.OLD_STYLE_PREFIXING is False.


>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;


Many lists add short message footers that contain URLs such as a list
information or an unsubscribe link.


>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.


I think there is a good possibility for simple plain text only messages
to pass through an MLM without breaking signatures, however, if the
original message is more complex and the list filters content, e.g.
say a multipart/alternative message has its text/html alternative
removed and the message collapsed to a text/plain message containing
only the text/plain alternative, I don't see a way for signatures to
surve such a transformation.

Since many MUAs compose multipart/alternative messages by default
without the users necessarily even being aware of it, and many lists
transform such messages into simple text/plain messages, I think this
will always be an issue.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan