[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Murray S. Kucherawy]

On Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> 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