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 <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ 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