Re: [Mailman-Developers] New RFC on using DKIM with MLMs
On Oct 12, 2011, at 02:46 PM, Murray S. Kucherawy wrote:
The IETF recently issued an RFC, with BCP status, regarding interaction between DKIM and MLMs. It seems like this community might be interested.
http://www.ietf.org/rfc/rfc6377.txt
Long ago I mentioned on this list that the IETF was undertaking this effort; this is the final product. I hope it's helpful.
It is, and thanks very much for sending us the reference.
I found myself nodding my head quite a bit as I read it, often thinking "yeah, we do that". I'm in general agreement with the recommendations, so just a few notes here.
$3.3
"In general, absent a general movement by MLM developers and operators toward more DKIM-friendly practices, an MLM subscriber cannot expect signatures applied before the message was processed by the MLM to be valid on delivery to a Receiver. Such an evolution is not expected in the short term due to general development and deployment inertia. Moreover, even if an MLM currently passes messages unmodified such that Author signatures validate, it is possible that a configuration change or software upgrade to that MLM will cause that no longer to be true."
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.
I do agree with the RFC's point that the output of a resending MLM (such as Mailman) is a new message, i.e. it is the originator. The original message has been received, and its existence in the mail infrastructure is complete.
$4.4 points to what I think is the right solution for us, and which we already largely implement. If a site running Mailman wants to verify signatures on incoming posts, it should do this in the receiving MTA that feeds messages to Mailman. And if they want to sign outgoing messages, again this is done in the outgoing MTA that Mailman feeds messages to ($5.8). Mailman should not verify or DKIM sign anything. Mailman's is moderately DKIM aware, in that it will simply remove DKIM headers if configured to do so, and this should be the default (backed up by $5.7 as I read it).
$5.2 "A resending MLM SHOULD reject outright any mail from an Author whose domain posts such a policy, as those messages are likely to be discarded or rejected by any ADSP-aware recipients."
Within Mailman's architecture, this would be the prerogative of the incoming MTA feeding messages to Mailman.
$5.3 Interesting that they recommend checking ADSP at subscription time, with periodic rechecks. Given that discardable is not a recommended policy, I can't see the value of Mailman doing this; the extra code and complexity isn't worth it. It would be useful though to make sure that a plugin could be written to add such verifications should some site decide they want it.
$5.6 is interesting too (using DKIM as input to posting privileges). I put this in the same general category as using OpenPGP signatures to verify posting permissions. Again, probably not something we'd support out of the box, but certainly we'd provide hooks for those who want it (and Mailman's internal OpenPGP verifier, which I hope we'll gain at some point, would use the same API).
$5.11 indicates possible enhancements to Mailman's bounce policy.
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.
Cheers, -Barry
-----Original Message----- From: Barry Warsaw [mailto:barry@list.org] Sent: Thursday, October 13, 2011 8:30 AM To: Murray S. Kucherawy Cc: mailman-developers@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!
-MSK
On 13 Oct 2011, at 16:30, Barry Warsaw wrote:
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.
Not modifying the message would work just fine.
Other than that:
Don't modify the body, unless the DKIM signature specifies that it's signed only part of the body. In this case, it's OK to append to the body.
Don't modify any headers that are signed. Adding headers is usually OK, but one should be careful not to add headers that already exist. For example, don't add a second "Subject" line.
Generally, there are three things that a list might do to break a signature:
a. Append text to the message. In the UK, though, this is essential for most mailing lists, since they're usually promoting something (Eg, this list is promoting Mailman), and therefore required to include an easy to use opt-out address. If only more mail clients would present List-Unsubscribe headers usefully, this might be avoided.
b. Prepend text to the subject line. This isn't really necessary at all, but would be easier to avoid if mail filtering systems offered better access to the List-ID headers.
c. Alter the "From:" header. Again, lists don't have to do this. However, this can get tricky with ADSP. If a domain publishes ADSP "discardable", then the list should probably reject messages with From: header addresses in that domain, if it's about to break the DKIM signature. Of course, if there's no good DKIM signature on the message, then the list should discard the message.
-- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148
participants (3)
-
Barry Warsaw
-
Ian Eiloart
-
Murray S. Kucherawy