Mark Sapiro writes:
Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail,
That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by "useful".
The whole point of this option is to allow lists to do what we've come to expect them to do (discard or quarantine attachments, add header and footer text, munge Subject) while still presenting a valid DKIM signature to the receiver.
Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it.
Too late. The reason we should consider adding this feature at all is that the big email providers are heading in the direction of imposing that responsibility whether list owners want it or not.
The only real alternative to DKIM signingby Mailman or its MTA is to pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted.
There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like
multipart/mixed
text/plain ; Mailman list header
message/rfc822
text/plain ; Mailman list footerI have no idea what MUAs would do with that, though. :-(
All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default.
If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code.
See my reply to Franck for more detailed comments on the actual proposed changes.
Steve