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
[Mailman-Developers] Author_is_list option in upcoming mailman 2.1.16
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 that's desirable, and for an announce list there's no problem, as the list (or an officer of the host) is already the author. I think you should just delete that sentence. While DEFAULT_AUTHOR_IS_LIST is important to avoid new lists and upgraded lists change behavior, setting ALLOW_AUTHOR_IS_LIST to Yes does not change how any list is handled (author_is_list in the GUI is No by default). it only provides an option to the list admin to change the list behavior. 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
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
