Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On Sep 14, 2013, at 04:49 AM, Stephen J. Turnbull wrote: I have no idea what MUAs would do with that, though. :-( Me neither, but experience indicates it wouldn't be pretty. :/ -Barry ___ 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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
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 suspect we still have a long way to go before we understand how DKIM and mailing lists will work best together in practice, from the end-user's point of view. -Barry ___ 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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
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.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter 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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/17/2013 10:04 PM, Franck Martin wrote: 1) If you keep the From: header as it is then, we will still have the same problems Perhaps I wasn't clear. The From: of the outer message would contain the list address. The From: of its message/rfc822 payload would be unchanged from that of the incoming message. My questions only had to do with the Reply-To: of the outer message in cases where the list was set to mung Reply-To: in some way. 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 No, but that is a side effect, at least where content filtering has not altered the message. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter 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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On Sep 17, 2013, at 10:36 PM, Mark Sapiro m...@msapiro.net wrote: On 09/17/2013 10:04 PM, Franck Martin wrote: 1) If you keep the From: header as it is then, we will still have the same problems Perhaps I wasn't clear. The From: of the outer message would contain the list address. The From: of its message/rfc822 payload would be unchanged from that of the incoming message. My questions only had to do with the Reply-To: of the outer message in cases where the list was set to mung Reply-To: in some way. Ah, makes sense, sorry 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 No, but that is a side effect, at least where content filtering has not altered the message. Yes indeed ___ 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
