[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16

[Mark Sapiro]

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.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan