From 1530734 at bugs.launchpad.net Sun Jan 3 20:10:44 2016 From: 1530734 at bugs.launchpad.net (Giovanni Pellerano) Date: Mon, 04 Jan 2016 01:10:44 -0000 Subject: [Bug 1530734] [NEW] python3 compatibility Message-ID: <20160104011044.26331.88382.malonedeb@gac.canonical.com> Public bug reported: Storm is currently not supporting python3 Starting from Ubuntu 16.04 (LTS) [21th April 2016] ubuntu will include by default support for only python 3, so this is becoming a fundamental requirement: http://summit.ubuntu.com/uos-1511/meeting/22568/python3 -only-on-the-images/ Aside from various minor code changes the main problem will be probably in fixing the storm/cextensions.c. This ticket if for asking for a clarification on the status of the project in order to understand if it is abandoned or there is a plan for porting it to python 3. ** Affects: launchpad Importance: Undecided Status: New ** Affects: mailman Importance: Undecided Status: New ** Affects: storm Importance: Undecided Status: New ** Also affects: mailman Importance: Undecided Status: New ** Also affects: launchpad Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1530734 Title: python3 compatibility To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/1530734/+subscriptions From 1530734 at bugs.launchpad.net Sun Jan 3 20:18:12 2016 From: 1530734 at bugs.launchpad.net (Giovanni Pellerano) Date: Mon, 04 Jan 2016 01:18:12 -0000 Subject: [Bug 1530734] Re: python3 compatibility References: <20160104011044.26331.88382.malonedeb@gac.canonical.com> Message-ID: <20160104011814.18760.48970.malone@wampee.canonical.com> This patch fix all python3 compatibility issues present in ez_setup.py ** Patch added: "ez_setup.py.patch" https://bugs.launchpad.net/launchpad/+bug/1530734/+attachment/4543672/+files/ez_setup.py.patch -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1530734 Title: python3 compatibility To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/1530734/+subscriptions From 1530734 at bugs.launchpad.net Sun Jan 3 20:30:19 2016 From: 1530734 at bugs.launchpad.net (Barry Warsaw) Date: Mon, 04 Jan 2016 01:30:19 -0000 Subject: [Bug 1530734] Re: python3 compatibility References: <20160104011044.26331.88382.malonedeb@gac.canonical.com> Message-ID: <20160104013019.1232.19796.malone@soybean.canonical.com> GNU Mailman got ported to SQLAlchemy quite a while ago. https://gitlab.com/mailman/mailman I suspect Storm won't see much new development. ** Changed in: mailman Status: New => Invalid -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1530734 Title: python3 compatibility To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad/+bug/1530734/+subscriptions From me at williamgrant.id.au Mon Jan 4 02:19:06 2016 From: me at williamgrant.id.au (William Grant) Date: Mon, 04 Jan 2016 07:19:06 -0000 Subject: [Bug 1530734] Re: python3 compatibility References: <20160104011044.26331.88382.malonedeb@gac.canonical.com> Message-ID: <20160104071906.25861.81934.launchpad@gac.canonical.com> ** No longer affects: launchpad -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1530734 Title: python3 compatibility To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1530734/+subscriptions From 1530734 at bugs.launchpad.net Mon Jan 4 04:17:25 2016 From: 1530734 at bugs.launchpad.net (Giovanni Pellerano) Date: Mon, 04 Jan 2016 09:17:25 -0000 Subject: [Bug 1530734] Re: python3 compatibility References: <20160104011044.26331.88382.malonedeb@gac.canonical.com> Message-ID: <20160104091725.26081.40360.malone@gac.canonical.com> William can i ask why you removed also launchpad? also launchpad is abandoning storm? :( ** No longer affects: mailman -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1530734 Title: python3 compatibility To manage notifications about this bug go to: https://bugs.launchpad.net/storm/+bug/1530734/+subscriptions From 1532399 at bugs.launchpad.net Sat Jan 9 02:19:08 2016 From: 1532399 at bugs.launchpad.net (Yuichi Hatanaka) Date: Sat, 09 Jan 2016 07:19:08 -0000 Subject: [Bug 1532399] [NEW] Rejected notice message is not use i18n in Errors.py Message-ID: <20160109071908.16395.85010.malonedeb@gac.canonical.com> Public bug reported: Rejected notice message gets code defined in Errors.py as follows --- rejection = _('Your message was rejected') notice = _('Your message was rejected') --- But "_" function is not used Mailman.i18n. Defined in Errors.py as follows: --- def _(s): return s --- ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532399 Title: Rejected notice message is not use i18n in Errors.py To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532399/+subscriptions From mark at msapiro.net Sat Jan 9 15:27:58 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 09 Jan 2016 20:27:58 -0000 Subject: [Bug 1532399] Re: Rejected notice message is not use i18n in Errors.py References: <20160109071908.16395.85010.malonedeb@gac.canonical.com> Message-ID: <20160109202758.8750.32430.malone@wampee.canonical.com> There are issues in this area, but not because of the definition of _ in Errors.py. This definition is intentional because at the time the module is imported, the ultimate language context for the message is not known. Thus, the messages can't be translated as the module is imported. I'm aware of two places where the message is ultimately not translated correctly. If the list's preferred_language is different from the user's language on the list and a message is held, the default rejection reason in the admindb interface is in the list's preferred_language and if the post is ultimately rejected, the reason in the notice to the user is still in the list's preferred_language and not in the user's language. I do not intend to try to fix this because at the time to post is rejected, we don't know if the default reason was changed by the moderator and we have no way to translate it into the user's language. The other place I'm aware of is in the automatic rejection of a post from a moderated user when member_moderation_action is Reject and there is no member_moderation_notice. In this case the default reason to the user is in English rather than the user's language. I will work on a fix for this one. Note that here also, if there is a member_moderation_notice, we have no way to translate that so it will always be in the language in which it was entered. If you are aware of other contexts in which the default notice is not appropriately translated, please report what they are. ** Changed in: mailman Status: New => Incomplete -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532399 Title: Rejected notice message is not use i18n in Errors.py To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532399/+subscriptions From mark at msapiro.net Sat Jan 9 22:11:38 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 10 Jan 2016 03:11:38 -0000 Subject: [Bug 1532504] [NEW] Galician language templates are encoded in the wrong Character set. Message-ID: <20160110031138.18565.38579.malonedeb@soybean.canonical.com> Public bug reported: Mailman's Character set for Galician is utf-8 but many templates are iso-8859-1 encoded. The html templates should all use html entities where possible and everything should be properly utf-8 encoded. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: In Progress -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532504 Title: Galician language templates are encoded in the wrong Character set. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532504/+subscriptions From 1532504 at bugs.launchpad.net Sat Jan 9 22:36:02 2016 From: 1532504 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Sun, 10 Jan 2016 03:36:02 -0000 Subject: [Bug 1532504] Re: Galician language templates are encoded in the wrong Character set. References: <20160110031138.18565.38579.malonedeb@soybean.canonical.com> Message-ID: <20160110033604.10402.93345.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532504 Title: Galician language templates are encoded in the wrong Character set. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532504/+subscriptions From mark at msapiro.net Sat Jan 9 22:36:13 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sun, 10 Jan 2016 03:36:13 -0000 Subject: [Bug 1532504] Re: Galician language templates are encoded in the wrong Character set. References: <20160110031138.18565.38579.malonedeb@soybean.canonical.com> Message-ID: <20160110033613.8326.84357.launchpad@wampee.canonical.com> ** Changed in: mailman Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532504 Title: Galician language templates are encoded in the wrong Character set. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532504/+subscriptions From 1532399 at bugs.launchpad.net Wed Jan 13 02:10:05 2016 From: 1532399 at bugs.launchpad.net (Yuichi Hatanaka) Date: Wed, 13 Jan 2016 07:10:05 -0000 Subject: [Bug 1532399] Re: Rejected notice message is not use i18n in Errors.py References: <20160109071908.16395.85010.malonedeb@gac.canonical.com> Message-ID: <20160113071005.29834.64861.malone@chaenomeles.canonical.com> I understood, I can send the reason for the non-English (However, one language) by setting the member_moderation_notice. Thank you. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1532399 Title: Rejected notice message is not use i18n in Errors.py To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1532399/+subscriptions From 1535194 at bugs.launchpad.net Mon Jan 18 01:30:50 2016 From: 1535194 at bugs.launchpad.net (Sudhir Khanger) Date: Mon, 18 Jan 2016 06:30:50 -0000 Subject: [Bug 1535194] [NEW] highlight enabled lists with green color and disabled with red color Message-ID: <20160118063050.14508.43497.malonedeb@wampee.canonical.com> Public bug reported: >From UX point of view subscription based preference would be much less overwhelming if we used some form of highlighting to separate lists that have enabled email delivery and those that have disabled delivery. Green highlight for email delivery enabled and red highlight for email delivery disabled would be very useful. ** Affects: postorius Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1535194 Title: highlight enabled lists with green color and disabled with red color To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1535194/+subscriptions From mark at msapiro.net Mon Jan 18 01:49:10 2016 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 18 Jan 2016 06:49:10 -0000 Subject: [Bug 1535194] Re: highlight enabled lists with green color and disabled with red color References: <20160118063050.14508.43497.malonedeb@wampee.canonical.com> Message-ID: <20160118064911.25821.37778.malone@soybean.canonical.com> All Mailman 3 related bugs should now be reported on gitlab. Postorius in particular is at https://gitlab.com/mailman/postorius and issues should be reported at https://gitlab.com/mailman/postorius/issues ** Changed in: postorius Status: New => Invalid -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1535194 Title: highlight enabled lists with green color and disabled with red color To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1535194/+subscriptions From 1535194 at bugs.launchpad.net Mon Jan 18 02:00:07 2016 From: 1535194 at bugs.launchpad.net (Sudhir Khanger) Date: Mon, 18 Jan 2016 07:00:07 -0000 Subject: [Bug 1535194] Re: highlight enabled lists with green color and disabled with red color References: <20160118063050.14508.43497.malonedeb@wampee.canonical.com> Message-ID: <20160118070007.29470.67780.malone@chaenomeles.canonical.com> Why is this kept active? Can that information be added to the front of Postorius's launchpad page so that users aren't misled. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1535194 Title: highlight enabled lists with green color and disabled with red color To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1535194/+subscriptions From mark at msapiro.net Mon Jan 18 02:13:24 2016 From: mark at msapiro.net (Mark Sapiro) Date: Mon, 18 Jan 2016 07:13:24 -0000 Subject: [Bug 1535194] Re: highlight enabled lists with green color and disabled with red color References: <20160118063050.14508.43497.malonedeb@wampee.canonical.com> Message-ID: <20160118071324.29871.67162.malone@chaenomeles.canonical.com> Done! At the time of the switchover, we did update https://launchpad.net/mailman/, but we overlooked https://launchpad.net/postorius. Thanks for the nudge. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to Postorius. https://bugs.launchpad.net/bugs/1535194 Title: highlight enabled lists with green color and disabled with red color To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1535194/+subscriptions From mark at msapiro.net Thu Jan 21 17:36:13 2016 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 21 Jan 2016 22:36:13 -0000 Subject: [Bug 1536816] [NEW] Mailman can create a non-ascii or improperly RFC 2047encoded From: header. Message-ID: <20160121223614.30742.29986.malonedeb@gac.canonical.com> Public bug reported: When creating the new From: header for a message with from_is_list or dmarc_moderation_action set to Munge From or Wrap Message, if the incoming From: has no display name so Mailman gets the display name from the poster's list member data, and that name contains non-ascii, Mailman puts the non-ascii display name in the new From: header and subsequent processing can see the non-ascii and attempt to RFC 2047 encode it, but do that improperly. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: Fix Committed ** Summary changed: - Mailman can create a non-ascii or improperly RFC 2047encoded From" header. + Mailman can create a non-ascii or improperly RFC 2047encoded From: header. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1536816 Title: Mailman can create a non-ascii or improperly RFC 2047encoded From: header. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1536816/+subscriptions From 1536816 at bugs.launchpad.net Thu Jan 21 17:44:33 2016 From: 1536816 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Thu, 21 Jan 2016 22:44:33 -0000 Subject: [Bug 1536816] Re: Mailman can create a non-ascii or improperly RFC 2047encoded From: header. References: <20160121223614.30742.29986.malonedeb@gac.canonical.com> Message-ID: <20160121224434.2174.37453.launchpad@ackee.canonical.com> ** Branch linked: lp:mailman/2.1 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1536816 Title: Mailman can create a non-ascii or improperly RFC 2047encoded From: header. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1536816/+subscriptions From mark at msapiro.net Thu Jan 21 17:44:45 2016 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 21 Jan 2016 22:44:45 -0000 Subject: [Bug 1536816] Re: Mailman can create a non-ascii or improperly RFC 2047encoded From: header. References: <20160121223614.30742.29986.malonedeb@gac.canonical.com> Message-ID: <20160121224446.29509.29969.launchpad@soybean.canonical.com> ** Changed in: mailman Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1536816 Title: Mailman can create a non-ascii or improperly RFC 2047encoded From: header. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1536816/+subscriptions From jb-debbugs at wisemo.net Thu Jan 28 23:01:00 2016 From: jb-debbugs at wisemo.net (Jakob Bohm) Date: Fri, 29 Jan 2016 04:01:00 -0000 Subject: [Bug 1539384] [NEW] Non-blocking DMARC mitigations should also be done for p=none Message-ID: <20160129040100.28859.40339.malonedeb@soybean.canonical.com> Public bug reported: If you read the DMARC informational RFC (no longer just a draft), you will see that there are 3 possible policies a mail domain (of a poster) can set p=reject All recipients should reject/drop mails with From: ... that have neither DKIM not SPF pass for our ourdomain. Send automatic reports of this to our postmaster at the specified rua address. p=quarantine All recipient spam filters should penalize ditto. Send the same automatic reports. p=none Recipients should act as if this policy was not there, but send the automatic reports so we can decide if our policy needs fine tuning before switching to a tougher p value. Currently Mailman 2.1.20+ has code that applies reasonable adjustments to avoid failures with posters from p=reject domains (such as Yahoo). Mailman 2.1.20+ also has an option to do the same for p=quarantine. But when a domain is set to p=none because the postmaster is trying to figure out what will break if he/she/they turn on quarantine, Mailman will continue sending mail in a way which causes all the backscatter reports from everybody except the list owner. As a postmaster I find this very annoying as it makes it hard to find actual problems in the flurry of backscatter noise from making even a few posts to a single Mailman list. Especially annoying is reports that some servers received mails with failed DKIM from a 4th party IP, as it is impossible to tell if those 4th parties were forwarding mails that were broken by Mailman munging the Subject header or were handling mails of some other kind needing a different correction. I would therefore suggest the following change to the 2.1 branch (since 3.x is still not in a usable state): * If dmarc_moderation_action is set to a value other than Reject or Discard, the specified mitigation should be applied to domains with any valid DMARC policy, not just reject. The effect of this would be: + List admins need to do nothing extra, since this works with the existing Mailman settings. + Domains that use p=none with a user posting to a list with action other than Reject/Discard will see the true effects that setting p=reject would have, and their users will see any change in the Mailing list behavior and be able to complain to the local postmaster before the domain goes to p=reject. Which is exactly the intended purpose of p=none. + Domains that use p=none with a user posting to a list with action set to Reject/Discard will receive a flurry of error reports reflecting how badly things will break if they go to p=reject, but the users will not loose their ability to post (because the reject/discard action is not applied to domains with p=none). Again this is consistent with the intended purpose of p=none. + Domains that use p=quarantine with a user posting to a list that has not set dmarc_quarantine_moderation_action will see the same effects as domains that use p=none (see above). + Domains that use p=quarantine with a user posting to a list that has set dmarc_quarantine_moderation_action will see the same behavior as for the current 2.1.20 code. + Domains that use p=reject will see the same behavior as for the current 2.1.20 code. ** Affects: mailman Importance: Undecided Status: New ** Tags: dmarc -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539384 Title: Non-blocking DMARC mitigations should also be done for p=none To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions From jb-debbugs at wisemo.net Thu Jan 28 23:27:31 2016 From: jb-debbugs at wisemo.net (Jakob Bohm) Date: Fri, 29 Jan 2016 04:27:31 -0000 Subject: [Bug 1539390] [NEW] Alternative DMARC mitigation: Keep Headers Message-ID: <20160129042731.30940.24159.malonedeb@gac.canonical.com> Public bug reported: This is just a suggestion: The current Mailman code offers two alternative DMARC mitigation values: "Munge From" and "Wrap Message". I would suggest a 3rd and even simpler mitigation: "Keep Headers" This setting would have the following effects within Mailman: * Preserve the Subject header intact, as well as all other headers listed in the DKIM-Signature header of the actual post. * Do not remove the DKIM-Signature header, even if the Mailman option to do so is set. * Do not add a DKIM-Signature for the mailing list, even if otherwise configured to do so. * If there is no DKIM-Signature in the post, none of the above applies. * When gatewaying from NNTP to SMTP and there is no DKIM-Signature header in the post, use the "Munge From" procedure because most NNTP servers and newsreaders do not add the required DKIM signatures anyway. The expected effect on message delivery would be: + The posting passes DKIM validation for the signature placed there by the posters domain + DMARC checking recipients will therefore (according to the DMARC spec) accept the message as validly sent by the original poster and let it pass. + Because the number of DKIM-Signature headers is not increased from 1 to 2, there is no issue with the common case where buggy DMARC checkers use only the first or last DKIM-Signature header, even though the RFC says to check all DKIM signatures that match the From header domain and accept if at least one is good. + Spoofed posts via SMTP with an invalid DKIM-Signature header will be correctly rejected as spoofs by anyone checking the DKIM signatures according to DMARC or ADSP. + Spoofed posts via SMTP with no DKIM-Signature header will be correctly rejected as spoofs by anyone checking the DKIM signatures according to DMARC or ADSP. Note: Older Mailman versions happen to already do this for replies (but not original posts) by accident because they lack the code to rearrange the "Re: " in the Subject header. ** Affects: mailman Importance: Undecided Status: New ** Tags: dmarc -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539390 Title: Alternative DMARC mitigation: Keep Headers To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539390/+subscriptions From mark at msapiro.net Fri Jan 29 00:33:58 2016 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 29 Jan 2016 05:33:58 -0000 Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done for p=none References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com> Message-ID: <20160129053359.11026.9404.malone@chaenomeles.canonical.com> I think I see what you are saying. If I have it right, you admin a domain that publishes DMARC p=none to get reports to assess the effect of going to a stronger DMARC policy, but you see reports due to Mailman list mail because Mailman does not apply DMARC mitigations to mail From: domains that publish DMARC p=none. So you would like Mailman to apply disruptive message transformations to mail From: your domain that would be transformed if you applied a stronger DMARC policy. My opinion is DMARC and mailing lists do not play well together. DMARC was originally intended to be used by domains such as those of financial institutions where mail From: those domains would only be for business purposes and not posted by individuals to mailing lists. It was mis-used by Yahoo and later AOL in a misguided attempt to make upo for prior security lapses, but was never intended to be used by domains that provided email service to users for personal use. While I don't understand what your domain is or what it is used for, I suggest that if individuals are allowed/encouraged to send personal mail From: your domain to email lists, that DMARC p=quarantine or p=reject policies are inappropriate. ** Changed in: mailman Importance: Undecided => Wishlist ** Changed in: mailman Status: New => Won't Fix -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539384 Title: Non-blocking DMARC mitigations should also be done for p=none To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions From mark at msapiro.net Fri Jan 29 00:42:59 2016 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 29 Jan 2016 05:42:59 -0000 Subject: [Bug 1539390] Re: Alternative DMARC mitigation: Keep Headers References: <20160129042731.30940.24159.malonedeb@gac.canonical.com> Message-ID: <20160129054259.11237.10420.malone@chaenomeles.canonical.com> I think you are suggesting that the 'Keep Headers' option would apply no transformations whatsoever to the mail, i.e.no content filtering, no subject prefixing and no msg_header or msg_footer. I don't see that not making these transformations, especially the lack of content filtering would be acceptable. Would you really want to allow me to post anything at all to a list and bypass all content-filtering just by posting from my Yahoo address? ** Changed in: mailman Importance: Undecided => Wishlist ** Changed in: mailman Status: New => Won't Fix -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539390 Title: Alternative DMARC mitigation: Keep Headers To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539390/+subscriptions From jb-debbugs at wisemo.net Fri Jan 29 01:53:21 2016 From: jb-debbugs at wisemo.net (Jakob Bohm) Date: Fri, 29 Jan 2016 06:53:21 -0000 Subject: [Bug 1539390] Re: Alternative DMARC mitigation: Keep Headers References: <20160129042731.30940.24159.malonedeb@gac.canonical.com> Message-ID: <20160129065321.14123.3224.malone@gac.canonical.com> I was not suggesting not doing policy/security filtering of posts. If such filtering changes a message, that message obviously cannot be handled in "Keep Headers" mode and needs to fall back to one of the other methods. I was suggesting simply not doing the purely cosmetic message munging where that munging would invalidate an enforced DKIM signature (or a PGP signature if a poster uses that). In other words, no suffix prefixing, no reordering of "Re: " prefixes, no msg_header and no msg_footer. For many messages this would be enough to leave the message intact so it passes signature validation. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539390 Title: Alternative DMARC mitigation: Keep Headers To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539390/+subscriptions From jb-debbugs at wisemo.net Fri Jan 29 02:19:28 2016 From: jb-debbugs at wisemo.net (Jakob Bohm) Date: Fri, 29 Jan 2016 07:19:28 -0000 Subject: [Bug 1539384] Re: Non-blocking DMARC mitigations should also be done for p=none References: <20160129040100.28859.40339.malonedeb@soybean.canonical.com> Message-ID: <20160129071928.15773.95792.malone@gac.canonical.com> Please reconsider. In my specific case, these are domains where regular users (including me) send mails. I am adding DMARC (initially in p=none mode) because recipients are beginning to refuse direct e-mails not having a DMARC policy, and that is obviously bad for business. I am referring to the use of "p=none" as a way to test the waters, because that is the RFC defined purpose of that setting. While you may be politically opposed to DMARC, it has now become a reality of how large parts of the e-mail system works, and so it can no longer be ignored or omitted outside very small gated communities of people not e-mailing to and from the users that are signed up to the big providers or to any other providers pushed into setting up DMARC for interoperability. So ignoring DMARC is no longer a realistic option, and neither are the "Accept/Reject/Discard" Mailman settings that simply ignore the problem or penalize users for using domains that try to keep up with best current practices. Hence my suggestion that DMARC handling be done in ways that maximize interoperability, rather as some obscure "protest against Yahoo! Inc" special case. The only conflict between mail lists and DMARC (and ADSP) is that forwarding or generating mail with someone else's From header is no longer OK, just as SPF previously made it no longer OK to use someone else's envelope "MAIL FROM" domain. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539384 Title: Non-blocking DMARC mitigations should also be done for p=none To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539384/+subscriptions From mark at msapiro.net Fri Jan 29 22:04:22 2016 From: mark at msapiro.net (Mark Sapiro) Date: Sat, 30 Jan 2016 03:04:22 -0000 Subject: [Bug 1539390] Re: Alternative DMARC mitigation: Keep Headers References: <20160129042731.30940.24159.malonedeb@gac.canonical.com> Message-ID: <20160130030422.31275.21787.malone@wampee.canonical.com> I think many list owners and members would be disappointed to not see msg_footer in 'some' posts. In fact, in some jurisdictions lists are required to have visible unsubscribe links and msg_footer or (msg_header) is often used for that. Further, I think most lists apply some content filtering in that many modern MUAs create multipart/alternative messages by default and Mailman by default will collapse these to just the first alternative part. Thus, I see this feature as having very limited applicability, and I'm not interested in implementing it. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1539390 Title: Alternative DMARC mitigation: Keep Headers To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1539390/+subscriptions