Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On Sun, Sep 22, 2013 at 2:12 PM, Barry Warsaw ba...@list.org wrote: End users just care about how the email looks in their mail readers. I'm concerned that this will be a nice, RFC-compliant feature that makes things easy and workable for all the automated systems involved, but will look horrible to end-users and just make them upset. If that's the case then IMHO, it a failure. OTOH, maybe we won't know for sure until it gets *a lot* more testing. But I think it's a mistake to say well, we just have to force MUA developers to catch up. As we've seen with something presumably as simple as reply-to-list, it (almost) never happens. We as developers and standards people often avoid engaging UI people (MUAs, in our case) and issues specifically because it's a space that doesn't follow rules, which is what we're used to. That partition allows us to be able to declare victory on our side of the line most of the time, but it leaves us with the frustrations you've described here. I wonder how long we can hold out before we start trying to drag them into our conversations, which might be the only way to solve these pain points long term. It seems to me that Gmail, Yahoo Mail, Thunderbird, etc., must have either a team or an individual that spends time thinking about and testing user-visible solutions to these problems, so perhaps it's time to start asking them for help. -MSK ___ 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
Murray S. Kucherawy writes: I wonder how long we can hold out before we start trying to drag [the MUA developers] into our conversations, which might be the only way to solve these pain points long term. It seems to me that Gmail, Yahoo Mail, Thunderbird, etc., must have either a team or an individual that spends time thinking about and testing user-visible solutions to these problems, so perhaps it's time to start asking them for help. To be honest, I don't think they really care. Even larsi, who never saw an internet-draft he wouldn't implement, is not terribly systematic about it -- as long as things are smooth between Gnus users, well, tough luck for the rest of the world. When I was talking to MUA developers about best practices for dealing with reply-to-list the basic response was we already have a function for that or sounds great, patches welcome. The Mozilla people were clearly much more interested in features like calendars and vcards. I think it's important we get started on it (and maybe I can contribute something now that GSoC is almost over), but I don't have much hope that the MUA developers will put a high priority on it. It's not really in their purview (see Franck Martin's comments about MUA irrelevance in this thread, for example, and he's not even an MUA developer). And of course the worst offender is Microsoft, which AFAICS is somewhat actively undermining the RFC 822 standard for reasons I don't understand. Regards, ___ 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 18, 2013, at 05:04 PM, Stephen J. Turnbull wrote: I don't read German, but I don't see anything that looks like data, nor is there room for analysis. Nor does the blog by Patrick Koettner referenced therein. (The Google translations confirm that.) Please show us something that looks like data and analysis. Specifically of interest: Number of lists, number of users on each list (min, mean, max would do), duration of operation in this mode, type of users (mail admins vs. general technical vs non-technical), the MUAs in use, any discussion from the users themselves. Indeed. I'm skeptical about how well encapsulation will go over with end-users who have no understanding about these issues (nor should they). End users just care about how the email looks in their mail readers. I'm concerned that this will be a nice, RFC-compliant feature that makes things easy and workable for all the automated systems involved, but will look horrible to end-users and just make them upset. If that's the case then IMHO, it a failure. OTOH, maybe we won't know for sure until it gets *a lot* more testing. But I think it's a mistake to say well, we just have to force MUA developers to catch up. As we've seen with something presumably as simple as reply-to-list, it (almost) never happens. -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/22/2013 02:12 PM, Barry Warsaw wrote: OTOH, maybe we won't know for sure until it gets *a lot* more testing. But I think it's a mistake to say well, we just have to force MUA developers to catch up. As we've seen with something presumably as simple as reply-to-list, it (almost) never happens. I think what we already know for sure is that people will continue to use their favorite, brain dead MUA regardless of how well or how often we point out the better choices. I think we have some limited influence, but we are definitely not the 600 lb. gorilla in this jungle. Because of that and because of the need for better real world data, I am convinced that I need to release 2.1.16 final with the options of going with simple From: munging (as in RC2) or encapsulation and a default of neither. To that end, I will work on getting it out as soon as I can and will definitely describe the feature as experimental and subject to change in future releases, but encourage people to try it and report so their experience can influence future direction. OT - I just registered for PyCon. I haven't been to Montreal since 1975. I'm committed. I'm stoked! -- 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
I really wish I could keep up with all the lists where interesting stuff is going on. We produced an RFC a few years ago that tries to tackle the names and definitions of all the various roles (RFC 5598). That document deliberately avoided defining what a Sender is because that word has become so overloaded as to be hyper-ambiguous. Thus: On Fri, Sep 13, 2013 at 12:13 PM, Stephen J. Turnbull step...@xemacs.orgwrote: Franck Martin writes: In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list Replace the sender Before you release, s/sender/author/, please. When discussing Internet email, sender != author. The name of the feature, author is list, is an obvious falsehood: lists don't write posts, they relay them. These policies do not conform to the email RFCs. (Given the semantics of From set out in RFC 5322, they may even constitute copyright infringement in the absence of a license from posters permitting From-munging. But that's not the topic here.) I disagree. Formally, Mailman is creating a new message using (likely) a large portion of the original message. Unless the output is completely identical, Mailman is an Author. So I think the name is right, unless you want to tie the name of the feature to the list's configuration, and I'm sure you don't want to do that. This isn't absolute of course. There are mushy topics like Did the Message-Id change? (One could argue that if the Author changes, a new Message-Id should be generated.) Should a new Message-Id have been generated? (Yes, if there was any meaningful content change whatsoever.) Either way, I think the name is right as-is. -MSK ___ 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 Fri, Sep 13, 2013 at 12:49 PM, Stephen J. Turnbull step...@xemacs.orgwrote: That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by useful. I'm familiar with RFC 822 and up, but can you specify what exactly is being violated? I'm not saying I disagree, I just want to go to the reference/rule you have in mind. If the concern is with replacing the From: field on a relayed message, then one could argue Mailman is issuing a new message anyway, so it's free to replace or rewrite anything it chooses. Again referring to RFC 5598, it's a Mediator, not a Relay, though it could also be configured to act as a Relay. But if it were doing that, DKIM signatures would almost always survive. If it's something else, I'd like to understand. The only real alternative to DKIM signingby Mailman or its MTA is to pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted. Relay vs. Mediator mode, basically. There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like multipart/mixed text/plain; Mailman list header message/rfc822 text/plain; Mailman list footer Right, that's an option. I have no idea what MUAs would do with that, though. :-( Me either. All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code. I definitely agree that it should be off by default as it violates the Principle of Least Astonishment. -MSK ___ 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
Franck Martin writes: 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. First, the risk is zero, except to volunteers, as long as it's not default. Second, it's been tested for decades. A MIME digest is nothing but one or more encapsulated message/rfc822 parts. In multipart/digest form, it has an obvious defect of requiring an extra click for readers using the MUAs I refuse to use (the MUAs I use can be taught to explode digests automatically, or read them as mini-folders). It would be nice to find alternative ways to accomplish the same goals, but this is already proof of concept. Third, it has the advantage of preserving as much or as little of the original message as the list would like without interfering with DKIM validation of the encapsulation. The author_is_list has had deployment and testing for over a year in a DMARC environment. Limited testing I agree but nevertheless proved Limited testing is not proof that something works. Limited testing can only *prove* that something is *broken*. More extensive testing is still not *proof*, but it can give you confidence that it's not *too* broken. Here is a recent test, deployment and analysis: http://sys4.de/en/blog/2013/08/11/mailman-dmarc-konform-betreiben/ I don't read German, but I don't see anything that looks like data, nor is there room for analysis. Nor does the blog by Patrick Koettner referenced therein. (The Google translations confirm that.) Please show us something that looks like data and analysis. Specifically of interest: Number of lists, number of users on each list (min, mean, max would do), duration of operation in this mode, type of users (mail admins vs. general technical vs non-technical), the MUAs in use, any discussion from the users themselves. I'd like to see somebody operating a mailing list with this encapsulation method first, before merging. Any list with MIME digests enabled and in use is a test of the basic usability. Do so on a site with DKIM-signing and you're done. All my proposal does is tune the encapsulation a bit. It might or might not work. ___ 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 06:21 PM, Mark Sapiro wrote: 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. I have had another thought. I will look at provisionally making ALLOW_AUTHOR_IS_LIST a 3 way switch for 2.1.16 with 0 or False (No) meaning current (2.1.15) behavior, 1 or True (Yes) meaning the 2.1.16rc1 behavior and 2 meaning the encapsulated message behavior. If implementation doesn't turn into a can of worms or delay the release too long, I'll do that and encourage interested people to try it and report so we can get some practical experience with which to compare the different approaches. It will still be labeled experimental and subject to future change. -- 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
Mark Sapiro writes: I have had another thought. I will look at provisionally making ALLOW_AUTHOR_IS_LIST a 3 way switch for 2.1.16 with 0 or False (No) meaning current (2.1.15) behavior, 1 or True (Yes) meaning the 2.1.16rc1 behavior and 2 meaning the encapsulated message behavior. If you do, please change the name to DKIM_CONFORMANCE_METHOD or similar. But I don't think this is a very good API, because AUTHOR_IS_LIST[1] and DKIM_ARMOR (= encapsulate messages) are independent. Of course if encapsulation is used, there's very little point in rewriting From. But it doesn't interfere with doing so. Footnotes: [1] Barf - can we name this something that isn't a lie, like LIST_REWRITES_FROM, or better LIST_HIJACKS_FROM to distinguish it from the behavior of anonymous lists? ___ 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 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
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On Sep 14, 2013, at 5:16 PM, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Indeed, we have to assume that the MUAs are broken in this respect. See Daniel Gillmor's posts on the problems MUAs have with indicating which parts of a message are signed MIME parts in the testing MUAs thread. The basic state of the art seems to be that MUAs can't handle anything safely except a signature that applies to the whole message. I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs. ___ 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
When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Anyhow, it does not matter, this is a religious discussion. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. On Sep 14, 2013, at 1:27 AM, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. Nonsense. Here's what RFC 5322 says: The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The list obviously isn't responsible for the writing of the message body, and you could argue that in adding header/footer and munging attachments and Subject field it's acting as the agent of the author, who is therefore responsible for them too.[1] If that's not convincing, ask any of your users if they think the list is an author of their posts, or anybody else's. OTOH, if you want to make an authorship claim validly, there's an easy way to accomplish it: encapsulate the whole thing in message/rfc822. Steve Footnotes: [1] Note that RFC 5322's phrasing also clearly refutes the same argument when made for Reply-To. ___ 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
Franck Martin writes: When a list goes bad, usually the members are not blamed but the list admin, therefore making the list the system responsible of the writing of the message. Please stop being evasive. The RFC's use of responsible is intended to point to the person who wanted the content of the message injected into the email system. You know that, I know that, and you're just looking for an excuse to let your patch escape from its responsibility for undermining the standards on which electronic mail is founded. Anyhow, it does not matter, this is a religious discussion. Religious maybe, but it does matter. Open source lives and dies by open standards. Microsoft can (and does) get away with ignoring standards if they think that will enable them to destroy the competition by making non-Microsoft software inable to interoperate with Microsoft's. (Consider the number of complaints we get about Outlook's brain-damaged handling of the Sender field.) Let's *not* do it to ourselves *if we can avoid it*. Maybe we can't avoid it, but we really ought to try. Please feel free to code and test your solution of encapsulating the message in a mime rfc822. This seems an interesting and good alternative. I'd like to see it in practice so we can compare data. Without funding, I probably can't do it soon. My GSoC student Abhilash might be willing to do it after GSoC though. ___ 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
Franck Martin writes: I'm not sure if DKIM was ever meant to be exposed to the end user, but the current trend is to try to protect the end user as much as possible and this is done best by MTAs than MUAs. I disagree fundamentally. It's best done by *both* MTAs and MUAs. Not all threats attack you from the outside, nor can MTAs stop everything that comes at them without help. That's why mail services provide spam folders to quarantine suspect mail. I agree that altogether too many MUA authors agree with you, so we can't expect much good to happen if we try to do things that depend on capable MUAs. That doesn't mean we shouldn't lobby for better MUAs. MUAs have the advantage of interacting with the user, and they can take advantage of the user's knowledge and intuition. ___ 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/14/2013 11:18 PM, Franck Martin wrote: this is a religious discussion. Religious or not, it is controversial, and this discussion has raised valid points. 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. -- 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
Franck Martin writes: One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. Nonsense. Here's what RFC 5322 says: The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The list obviously isn't responsible for the writing of the message body, and you could argue that in adding header/footer and munging attachments and Subject field it's acting as the agent of the author, who is therefore responsible for them too.[1] If that's not convincing, ask any of your users if they think the list is an author of their posts, or anybody else's. OTOH, if you want to make an authorship claim validly, there's an easy way to accomplish it: encapsulate the whole thing in message/rfc822. Steve Footnotes: [1] Note that RFC 5322's phrasing also clearly refutes the same argument when made for Reply-To. ___ 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 13, 2013, at 7:48 PM, Mark Sapiro m...@msapiro.net wrote: On 09/13/2013 12:18 PM, Franck Martin wrote: Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). Not necessarily. It depends on the DKIM signature and how much of the body is signed. Granted, you are correct in most cases, but it might be of interest to some to go to https://mail.python.org/pipermail/mailman-developers/2007-February/ and review the dkim-signature headers threads. Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Even cisco does not use them in its signatures anymore. Jim Fenton did a good document on DKIM threats: http://tools.ietf.org/html/rfc4686 ___ 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
Franck Martin writes: Unfortunately z= and especially l= are not used practically by senders because they create a risk. One could add an attachment containing malware to the message for instance. Indeed, we have to assume that the MUAs are broken in this respect. See Daniel Gillmor's posts on the problems MUAs have with indicating which parts of a message are signed MIME parts in the testing MUAs thread. The basic state of the art seems to be that MUAs can't handle anything safely except a signature that applies to the whole message. ___ 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
Hi Franck, At 22:44 12-09-2013, Franck Martin wrote: In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list Replace the sender with the list address to conform with policies like ADSP and DMARC. It replaces the poster's address in the From: header with the list address and adds the poster to the Reply-To: header, but the anonymous_list and Reply-To: header munging settings below take priority. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. There is an effort (not mailman-related) to mark ADSP as not recommended. Regards, -sm ___ 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 12, 2013, at 11:30 PM, SM s...@resistor.net wrote: Hi Franck, At 22:44 12-09-2013, Franck Martin wrote: In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list Replace the sender with the list address to conform with policies like ADSP and DMARC. It replaces the poster's address in the From: header with the list address and adds the poster to the Reply-To: header, but the anonymous_list and Reply-To: header munging settings below take priority. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. There is an effort (not mailman-related) to mark ADSP as not recommended. yes I'm aware, it will take a bit of time before the ADSP RFC move to historical status. We are not doing this feature for ADSP...but DMARC. I guess we will drop the word ADSP for 2.1.17 ;) ___ 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 12, 2013, at 10:44 PM, Franck Martin wrote: Unfortunately some list admins cannot edit mm_cfg.py (like CPANEL type install), therefore it would be nice to remove ALLOW_AUTHOR_IS_LIST or set it to Yes by default to let the list admin decide how he/she wants the list to behave. Otherwise the list admin needs to contact the mailman admin to enable this config. Please indicates if you are ok to set ALLOW_AUTHOR_IS_LIST to Yes or remove this option from mm_cfg.py I will leave it to Mark for final decision on this, but my own opinion is that the mm_cfg.py option should stay. cPanel already customizes their Mailman installation, so I think they should set it to Yes when they upgrade their systems to 2.1.16. -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
Mark Sapiro writes: Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, That's nonsense. There's no reason to do this in the absence of correct DKIM signatures by Mailman or its MTA, and every reason (starting with RFCs 724, 733, 822, 2822, and 5322) not to do so. Of course if the point is to violate the RFCs, then this will still violate the RFCs without the MTA and DNS changes. But surely that's not what Franck means by useful. The whole point of this option is to allow lists to do what we've come to expect them to do (discard or quarantine attachments, add header and footer text, munge Subject) while still presenting a valid DKIM signature to the receiver. Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it. Too late. The reason we should consider adding this feature at all is that the big email providers are heading in the direction of imposing that responsibility whether list owners want it or not. The only real alternative to DKIM signingby Mailman or its MTA is to pass the original message through, optionally with additional headers (eg, RFC 2369), but otherwise verbatim, ensuring valid DKIM existing signatures won't be corrupted. There is an alternative to From-munging, though, which is to encapsulate the whole message (either as message/rfc822 MIME type, or as a one-message digest). Then the Mailman host can DKIM sign the wrapper message without invalidating the signature on the main message. In theory this could also be done with a multipart/mixed (*not* multipart/digest), with a structure like multipart/mixed text/plain; Mailman list header message/rfc822 text/plain; Mailman list footer I have no idea what MUAs would do with that, though. :-( All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. If the Mailman host is using DKIM, then list owners will definitely want the option available. So site owners should have to make a conscious decision to shut it off. On the other hand, since it does involve a serious systematic RFC violation, I think it would be a good idea to eliminate the DEFAULT_AUTHOR_IS_LIST option. Ie, require list owners to set it explicitly, or site owners to hack code. See my reply to Franck for more detailed comments on the actual proposed changes. Steve ___ 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/13/2013 08:06 AM, Barry Warsaw wrote: I will leave it to Mark for final decision on this, but my own opinion is that the mm_cfg.py option should stay. cPanel already customizes their Mailman installation, so I think they should set it to Yes when they upgrade their systems to 2.1.16. I don't feel strongly about this either way except for the general principle of least surprise. Enabling this by default has three downsides that I see. It can render a fully i18n translated General Options page a bit ugly with one relatively large English paragraph; it gives list owners yet another bullet with which to shoot themselves in the foot, and it complicates list configuration by adding yet another decision. None of these is a deal breaker. I researched the i18n issue, and it turns out only 4 languages currently have a fully translated General Options page. One of these has already been updated and the other 3 are being addressed. Most languages already have between 1 and 3 untranslated strings on this page from prior changes so it could be argued that one more is not important. The other two considerations are relatively minor, but I still lean towards requiring overt action by the site admin to enable the feature. I wanted this brought to mailman-developers in the hope that whatever discussion ensued would lead to some consensus. I confess, I'm not at all up to speed on DMARC. Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, but it seems to me that enabling author_is_list will almost guarantee that any incoming DKIM signatures will be broken (the From: is almost certainly included in the signed headers) which will cause problems if the outgoing mail is not signed with a valid DKIM signature. Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it. All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. Please help me understand if I'm wrong. -- 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
- Original Message - From: Mark Sapiro m...@msapiro.net To: mailman-developers@python.org Sent: Friday, September 13, 2013 11:31:44 AM Subject: Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16 On 09/13/2013 08:06 AM, Barry Warsaw wrote: I will leave it to Mark for final decision on this, but my own opinion is that the mm_cfg.py option should stay. cPanel already customizes their Mailman installation, so I think they should set it to Yes when they upgrade their systems to 2.1.16. I don't feel strongly about this either way except for the general principle of least surprise. Enabling this by default has three downsides that I see. It can render a fully i18n translated General Options page a bit ugly with one relatively large English paragraph; it gives list owners yet another bullet with which to shoot themselves in the foot, and it complicates list configuration by adding yet another decision. None of these is a deal breaker. I researched the i18n issue, and it turns out only 4 languages currently have a fully translated General Options page. One of these has already been updated and the other 3 are being addressed. Most languages already have between 1 and 3 untranslated strings on this page from prior changes so it could be argued that one more is not important. The other two considerations are relatively minor, but I still lean towards requiring overt action by the site admin to enable the feature. I wanted this brought to mailman-developers in the hope that whatever discussion ensued would lead to some consensus. I confess, I'm not at all up to speed on DMARC. Franck has assured me that this feature can be useful even in the absence of the DNS and MTA changes necessary to DKIM sign outgoing list mail, but it seems to me that enabling author_is_list will almost guarantee that any incoming DKIM signatures will be broken (the From: is almost certainly included in the signed headers) which will cause problems if the outgoing mail is not signed with a valid DKIM signature. DKIM does not require that the d= to be linked to the domains in the From: that's what DMARC do. Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). The rule with DKIM is to consider any broken DKIM signature as if there was no signature at all. So for instance this list mailman-developers will break all DKIM signatures when resending emails. Mailman could in fact strip DKIM at reception and this would be same effect. So let me explain what author_is_list achieves. if I post to this list using any of these domains which have a p=reject DMARC policy (linkedin.com, paypal.com, twitter.com,...). The original DKIM signature will be broken, and SPF while being valid, will not be aligned, not the same organizational domain as in the From: Return-Path: mailman-developers-bounces+franck=peachymango@python.org So DMARC will fail, creating the email to be bounced when being resent to members at gmail,yahoo,hotmail,aol,comacast,.. Note: This add to the unsubscription count for these members. With Author is list, the From: becomes (I simplified): From: mailman-developers@python.org python.org does not have a DMARC policy, therefore the email will not be bounced due to DMARC for members at gmail,yahoo,hotmail,... For a receiver, the IP is known, the headers contains the List-Id, so what is in the From has not much impact (besides the DMARC check), because it is mainly about the reputation of the sending IP that makes the email delivered to your mailbox. Also, it seems that an installation would want to validate in some way incoming mail before taking responsibility, even in a minor way, for resending it. This would be appreciated, but I'm not sure why adding this extra burden on author_is_list is needed. All installations of mailman should validate somehow messages before resending them, with or without author_is_list. All of this leads me to think that making this available to list owners should be an installation decision rather than being done by default. I'm not bent on if this option stays in the config file, I find already awesome that the option is present and we (the people using DMARC) have the opportunity to build adoption. Just trying to reduce adoption friction ;) ___ 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
Franck Martin writes: we (the people using DMARC) have the opportunity to build adoption. Just trying to reduce adoption friction ;) The direction you're heading will *create* adoption friction. The only way you're going to be able to sell this to admins like me is to wait until our users start getting unsubscribed because of DKIM bounces. Otherwise, I'm going to prefer RFC conformance and not messing up my users' rules (eg, killfiles) and autocitation functions. ___ 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
One may argue that since the list is modifying the message, it is now the new author of it, this proposal just make it more clearly. In an ideal world, lists should only forward the email, preserving the DKIM signature, but few lists are doing that except the notable exception of apache.org lists. When spam is received from a list (which is rare), the onus is on the list administrator to maintain his/her list content and membership. This option is off by default and at no time it is proposed to change the behavior of any list being in place or upgraded or imported without the list admin consent and action. On Sep 13, 2013, at 12:13 PM, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: In the upcoming mailman 2.1.16 there has been the introduction of the optional feature author_is_list Replace the sender Before you release, s/sender/author/, please. When discussing Internet email, sender != author. The name of the feature, author is list, is an obvious falsehood: lists don't write posts, they relay them. These policies do not conform to the email RFCs. (Given the semantics of From set out in RFC 5322, they may even constitute copyright infringement in the absence of a license from posters permitting From-munging. But that's not the topic here.) AFAICS there's an easy way for Mailman to adapt to DKIM without violating RFC 5322: wrap every message in a MIME message/rfc822 part (ie, every message is a one-post digest). The wrapper message obviously can conform to DMARC (From: LIST@DOMAIN with appropriate DKIM signature), and Mailman can DTRT with the wrapped message. with the list address to conform with policies like ADSP and DMARC. It replaces the poster's address in the From: header with the list address and adds the poster to the Reply-To: header, Another RFC violation. :-( What if the poster already set Reply-To because she *doesn't* want mail at the From address? What if the list's address *isn't* in Reply-to, but the author expects wide replies to go to the list? but the anonymous_list This is probably OK. and Reply-To: header munging settings below take priority. Does this make sense? See above. If setting this to Yes, it is advised to set the MTA to DKIM sign all emails. Please change this to This setting is useful when your host signs outgoing mail according using DKIM. As written, the advice is inaccurate anyway. DKIM requires more than just MTA settings. There must be cooperation from the nameserver. Usage of this feature on lists have indicated no adverse issue for the members, s/no adverse issue/only minor annoyance/ (I disagree with minor, but sure, Outlook users probably won't notice). You should remember that Reply-To munging works as expected for almost all subscribers almost all the time on most lists, and for that reason is widely used despite its ex post obvious deficiencies. When it fails, though, it's at minimum a minor pain in the ass and at maximum an inadvertant privacy violation. Please go slowly on screwing with From, which (unlike Reply-To) is a required field and so appears in *every* email and has well-defined semantics *with which this feature is in deliberate non-conformance*. provided proper communication is done when the feature is enabled (as to allow inbox rules to be changed if needed). Isn't this a lie? If the From header is corrupt, then there is no reliable indication of who the author is. If you're lucky you can fish it out of the body or .signature. Reply-To won't do: not only are its semantics such that there's no guarantee that it's an alias for author, but it complicates the rules significantly because you need different rules for From-corrupting lists and other lists and non-list mail. In the 2.1.16 Release Candidate the feature author_is_list is controlled by the following switches in the mm_cfg.py ALLOW_AUTHOR_IS_LIST = No DEFAULT_AUTHOR_IS_LIST = No The first one will enable the GUI to present an option to the list admin to enable the author_is_list feature, the second controls if new lists or upgraded lists should have the author_is_list feature set to yes Upgraded lists? If upgrading to Mailman 2.1.16 causes all my lists to be corrupted by this feature, I will not be pleased. An option called DEFAULT should only apply to new lists. If you insist on making this a fallback if the list doesn't have an explicit setting, call the option AUTHOR_IS_LIST. While it is better for the MTA to DKIM sign emails if author_is_list is enabled, this is not a requirement and the list will work fine without DKIM. But why would anybody want to do this in the absence of DKIM? Mailman already has the RFC 2369 and 2919 fields to tell MUAs that it's a list post, and a plethora of ways (Subject, header, footer) to tell users that it's a list post. Anonymous list is already an option for obscuring the author if
Re: [Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
On 09/13/2013 12:18 PM, Franck Martin wrote: Mailman breaks DKIM as soon as you add a footer or tag in the subject line, which a lot of lists do (including this one). Not necessarily. It depends on the DKIM signature and how much of the body is signed. Granted, you are correct in most cases, but it might be of interest to some to go to https://mail.python.org/pipermail/mailman-developers/2007-February/ and review the dkim-signature headers threads. -- 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
