On Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull step...@xemacs.orgwrote:
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.
I'm familiar with RFC 822 and up, but can you specify what exactly is being
violated? I'm not saying I disagree, I just want to go to the
reference/rule you have in mind.
If the concern is with replacing the From: field on a relayed message, then
one could argue Mailman is issuing a new message anyway, so it's free to
replace or rewrite anything it chooses. Again referring to RFC 5598, it's
a Mediator, not a Relay, though it could also be configured to act as a
Relay. But if it were doing that, DKIM signatures would almost always
survive.
If it's something else, I'd like to understand.
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.
Relay vs. Mediator mode, basically.
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 footer
Right, that's an option.
I have no idea what MUAs would do with that, though. :-(
Me either.
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.
I definitely agree that it should be off by default as it violates the
Principle of Least Astonishment.
-MSK
___
Mailman-Developers mailing list
Mailman-Developers@python.org
https://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:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
