On Sep 17, 2013, at 6:21 PM, Mark Sapiro <m...@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. _______________________________________________ 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