[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Franck Martin]

On Sep 17, 2013, at 6:21 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 09/17/2013 05:28 PM, Barry Warsaw wrote:
>> On Sep 15, 2013, at 08:24 AM, Mark Sapiro wrote:
>> 
>>> Because the issue remains controversial, I will soon release 2.1.16
>>> final with the feature disabled by default, and will consider the
>>> message encapsulation approach or other possibilities based on
>>> experience with 2.1.16 for a 2.1.17 release perhaps early next year.
>> 
>> This makes sense to me, although I would label the feature "provisional" or
>> "experimental".  There just isn't any good experience here we can draw on, so
>> it seems reasonable to provide the knobs that will allow motivated folks to
>> gather such experience, but generally keep it out of the way for the majority
>> of users.
> 
> 
> I intend to so indicate in the NEWS about the feature.
> 
> I have given some thought to the encapsulation approach and have some
> questions about it.
> 
> My thoughts on how to do it include the following if the feature is enabled.
> 
> CookHeaders saves the original Subject: before prefixing in the metadata.
> 
> A new handler before ToOutgoing but after ToDigest, ToArchive and
> ToUsenet creates a new message From: the list with Content-Type:
> message/rfc822, a unique Message-ID: and Subject:, References: and
> In-Reply-To: copied from the current message. It then replaces the
> Subject: in the current message with that saved in the metadata and sets
> the payload of the new message to the current message.
> 
> This will result in a single-part message with a payload of the content
> filtered original message. If content filtering hasn't removed anything,
> the original message's DKIM signatures if any should still be valid.
> 
> The message then goes to ToOutgoing and eventually OutgoingRunner and
> SMTPDirect which will call Decorate and if any msg_header or msg_footer
> is added, these will be added as is currently done which will result in
> the message becoming multipart/mixed with the addition of one or two
> text/plain, Content-Disposition: inline parts containing the header
> and/or footer.
> 
> The idea is the message/rfc822 part preserves as much of the original as
> possible so its DKIM sigs if any may still validate and to put enough
> into the headers of the new message so MUAs can still thread it properly
> and render it nicely. Also, the message is unchanged over current
> behavior for digests, archives and usenet.
> 
> The sticky questions are what to do with the original From: and
> Reply-To: in the face of possible Reply-To: munging options and so on.
> Presumably, we want to still be able to reply to the original author,
> and preserve the behavior of a simple MUA 'reply' going to the original
> author and not the list in the absence of Reply-To: munging, and that
> could be accomplished by putting the original author's Reply-To: (or the
> original From: if no original Reply-To:) in the new message's Reply-To:,
> but it's not yet clear to me how to handle the munging options (maybe
> just ignore them ;).
> 
> I could actually implement this approach for the 2.1.16 release, but
> that would negate the i18n work that's already been done as the
> descriptive string on General Options would change, so I'm more inclined
> to label this feature as experimental and subject to change
> significantly in a future release.
> 

1) If you keep the From: header as it is then, we will still have the same problems
2) the purpose of the encapsulation message/rfc822 is not meant to preserve the DKIM signature, DKIM is not meant to be verified by MUAs
3) encapsulation is not there to provide a transitive trust, there is another method explored for that which is Original-Authentication-Results (OAR). There is an expired Internet Draft on it.

I think, it is risky to code this encapsulation method directly and now, it requires a branch some testing and then merging back into the main branch.

The author_is_list has had deployment and testing for over a year in a DMARC environment. Limited testing I agree but nevertheless proved not to break things ( besides people ideal view of email  ;) ) and be useable with many MTAs and especially MUAs

Here is a recent test, deployment and analysis: http://sys4.de/en/blog/2013/08/11/mailman-dmarc-konform-betreiben/

I'd like to see somebody operating a mailing list with this encapsulation method first, before merging.