[Mailman-Developers] New RFC on using DKIM with MLMs
Murray S. Kucherawy
msk at cloudmark.com
Thu Oct 13 20:21:14 CEST 2011
> -----Original Message-----
> From: Barry Warsaw [mailto:barry at list.org]
> Sent: Thursday, October 13, 2011 8:30 AM
> To: Murray S. Kucherawy
> Cc: mailman-developers at python.org
> Subject: Re: [Mailman-Developers] New RFC on using DKIM with MLMs
> For Mailman, I think we'd like to, and would generally be able to be
> more DKIM-friendly, if we actually knew what to do. Short of not
> modifying the incoming message at all, and absent clear guidelines in
> this or any other RFC, we're just flailing in the dark. I think the
> RFC makes it clear though that there really are no good answers. It's
> a minor point that has no practical effect, but I think it states our
> project's general policy of wanting to be as RFC-compliant as possible.
The document does point out that the "friendly" approach is to put stuff like URLs for querying archives and unsubscription instructions up in the header using the List-* fields specified in RFC2919 and RFC2369 rather than as body suffixes, and don't tag Subject: fields (or, at least, have that off-by-default).
Essentially to be "DKIM-friendly" you're free to make any changes you want to the message so long as they are confined to those parts of the message not "covered" by the DKIM signature. So if a signature doesn't cover Subject:, you're fine. Obviously there are many MUAs out there that filter/sort based on the Subject: tags that will be affected to some degree, but they could also take the same action on a List-ID: field just as easily. And any MUA that orders a mailbox based on threading using References: and In-Reply-To: won't be affected at all.
> Again, thanks. It's nice to see specific guidelines published as an
> RFC which we can then refer to for justification of Mailman's policy
> and features.
Glad we could be of service!
More information about the Mailman-Developers