From 1838866 at bugs.launchpad.net Thu Oct 3 23:19:34 2019 From: 1838866 at bugs.launchpad.net (Keith Brian Tomo) Date: Fri, 04 Oct 2019 03:19:34 -0000 Subject: [Bug 1838866] Re: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts References: <156490528078.28889.17410140899278165529.malonedeb@wampee.canonical.com> Message-ID: <157015917525.21419.14667838466811962703.launchpad@chaenomeles.canonical.com> ** Also affects: ubuntu 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/1838866 Title: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1838866/+subscriptions From 1838866 at bugs.launchpad.net Fri Oct 4 08:12:43 2019 From: 1838866 at bugs.launchpad.net (Paul White) Date: Fri, 04 Oct 2019 12:12:43 -0000 Subject: [Bug 1838866] Re: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts References: <156490528078.28889.17410140899278165529.malonedeb@wampee.canonical.com> Message-ID: <157019116493.22779.17697476607603178935.launchpad@gac.canonical.com> ** Package changed: ubuntu => mailman (Ubuntu) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1838866 Title: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1838866/+subscriptions From futatuki at poem.co.jp Sat Oct 5 19:31:24 2019 From: futatuki at poem.co.jp (Yasuhito FUTATSUKI at POEM) Date: Sat, 05 Oct 2019 23:31:24 -0000 Subject: [Merge] lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1 Message-ID: <157031828148.3162.17151125589515950666.launchpad@ackee.canonical.com> Yasuhito FUTATSUKI at POEM has proposed merging lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1. Commit message: Update Japanese translation for new msgids added on r1820..1823 Requested reviews: Mailman Coders (mailman-coders) For more details, see: https://code.launchpad.net/~futatuki/mailman/2.1-ja-translation/+merge/373704 Add new msgstr for "Sync Membership List" and "Sync Membership List" in Japanese message catalogue. In Japanese, there is no space in translation words of those, they are same. -- Your team Mailman Coders is requested to review the proposed merge of lp:~futatuki/mailman/2.1-ja-translation into lp:mailman/2.1. -------------- next part -------------- A non-text attachment was scrubbed... Name: review-diff.txt Type: text/x-diff Size: 1011 bytes Desc: not available URL: From 1838866 at bugs.launchpad.net Tue Oct 8 10:30:58 2019 From: 1838866 at bugs.launchpad.net (Robie Basak) Date: Tue, 08 Oct 2019 14:30:58 -0000 Subject: [Bug 1838866] Re: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts References: <156490528078.28889.17410140899278165529.malonedeb@wampee.canonical.com> Message-ID: <157054505872.637.12380056986296918928.malone@chaenomeles.canonical.com> Please could someone confirm if this actually requires patching in Ubuntu? I'm not aware that Ubuntu uses "lib64", and "/usr/local" isn't used by system-provided packages anyway. What is the use case that fails in Ubuntu? Once answered please change the Ubuntu bug task status accordingly (Invalid or New depending on the answer I guess). ** Changed in: mailman (Ubuntu) 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/1838866 Title: Mailman 2.1: hardcoded site-packages dir prefix doesn't work on some 64 bit filesystem layouts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1838866/+subscriptions From mark at msapiro.net Thu Oct 10 12:44:04 2019 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 10 Oct 2019 16:44:04 -0000 Subject: [Bug 1832740] Re: init script / mailmanctl fails to stop mailman 2, reports success References: <156044220339.2385.3922595287292981602.malonedeb@wampee.canonical.com> Message-ID: <157072584498.22855.9279314206486703760.malone@gac.canonical.com> A workaround for your issue is to run (as root or the mailman user) /usr/lib/mailman/bin/mailmanctl restart instead of systemctl restart mailman systemctl restart is actually doing a stop followed by start as you observed whereas mailmanctl restart will just signal the qrunners to restart. You might also be able to adjust your systemd mailman service script to do mailmanctl restart instead of stop/start. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1832740 Title: init script / mailmanctl fails to stop mailman 2, reports success To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1832740/+subscriptions From 1845751 at bugs.launchpad.net Fri Oct 11 09:45:10 2019 From: 1845751 at bugs.launchpad.net (Eric Blake) Date: Fri, 11 Oct 2019 13:45:10 -0000 Subject: [Bug 1845751] Re: cc modification due to nodup setting breaks DKIM & thus DMARC References: <156963231161.15808.17034191154411525924.malonedeb@gac.canonical.com> Message-ID: <157080151083.9599.10418740641567194219.malone@wampee.canonical.com> I have long argued that there are two orthogonal things, currently both being managed by the single Avoid Duplicates settings. One is good, one is horrible. I would really love to have TWO separate knobs so that users can choose which of the two features they want. 1. Suppress duplicates - if a user does not want the same mail received twice through two paths, the list should not mail that user when their name is on a to or cc. This feature is good. 2. Rewrite CC - when the list suppresses sending to a given user, it rewrites mail headers to drop that user from cc, on the grounds that anyone replying to the list will still get their reply to the original author (through the list, rather than through cc). This feature is bad. I _really_ want a way to enable JUST feature 1, and NOT feature 2, for the mailman lists I am subscribed to. Here's several scenarios where I find feature 2 to be a misfeature, where User A is a user with the feature enabled, users B and C are list subscribers, and user D is not a list subscriber. Scenario 1: User B writes to the list and to user A in cc (to catch user A's attention). User A gets a copy of the email where they are on CC, but user B and user C get a copy of the email where user A is not on CC. If user C replies to all, the reply will reach user A via the list, but will NOT have user A in cc, failing to catch user A's attention on the followup. Scenario 2: User D writes to the list and to user A in cc (unaware that user A is subscribed to the list, and trying to catch user A's attention). User A gets the copy of the email where they are on cc, but user B and user C do not see that user A was in CC. Furthermore, user B replies all to the list and to user D, and now user D sees that user A was dropped from the CC. User D now wonders why user B dropped user A from the conversation. Avoiding the munging of CC when DMARC rules are involved is nice, but does not go as far as I want, which is to have a knob for an individual user to ALWAYS avoid the munging of their own email, regardless of whether duplicate delivery is suppressed, and regardless of 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/1845751 Title: cc modification due to nodup setting breaks DKIM & thus DMARC To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1845751/+subscriptions From mark at msapiro.net Fri Oct 11 14:23:08 2019 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 11 Oct 2019 18:23:08 -0000 Subject: [Bug 1845751] Re: cc modification due to nodup setting breaks DKIM & thus DMARC References: <156963231161.15808.17034191154411525924.malonedeb@gac.canonical.com> Message-ID: <157081818996.6723.7011464850397273950.malone@gac.canonical.com> I've been thinking about this report and patch, but hadn't formed a clear idea of a response. Now comments #2 has arrived which is really a separate issue. With respect to comment #2, it asserts "when the list suppresses sending to a given user, it rewrites mail headers to drop that user from cc". This is backwards. A member's address is removed from Cc only if the member's "avoid duplicates" setting is off, not on. This only affects the scenarios in that the premise becomes "User A is a user with the feature disabled". With respect to the original proposal/patch, I'm concerned that the patch only bypasses the Cc alteration when the From: domain publishes a relevant DMARC policy and won't be otherwise changed. It fails to consider whether other DKIM signature breaking transformations such as subject prefixing, addition of headers/footers and content filtering are being done. I'd be more inclined to accept a new "don't break DKIM" setting which if enabled would trump all settings that alter the message in a DKIM signature breaking way. However, that all said, There are a few other considerations. I will soon release Mailman 2.1.30 which will be the last Mailman 2.1 release from the GNU Mailman project. I think the way to deal with DMARC in the future is with ARC, https://www.rfc-editor.org/info/rfc8617. There is ARC support in Mailman 3, although I think it can also be implemented in the MTA without involving Mailman. Also, I have never fully understood why Cc dropping is dependent on the member's "avoid duplicates" setting at all (this predates my involvement with Mailman). It is intended to prevent Cc lists from growing without bound in long threads where everyone is doing reply-all, but why only Cc: and not To:, and why only addresses that don't "avoid duplicates". In short, I'm reluctant to make a change without a clear direction which I don't have. ** Changed in: mailman Importance: Undecided => Wishlist ** Changed in: mailman Status: New => Triaged -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1845751 Title: cc modification due to nodup setting breaks DKIM & thus DMARC To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1845751/+subscriptions From mark at msapiro.net Fri Oct 11 14:33:48 2019 From: mark at msapiro.net (Mark Sapiro) Date: Fri, 11 Oct 2019 18:33:48 -0000 Subject: [Bug 1845751] Re: cc modification due to nodup setting breaks DKIM & thus DMARC References: <156963231161.15808.17034191154411525924.malonedeb@gac.canonical.com> Message-ID: <157081882852.6395.7926021180125135191.malone@gac.canonical.com> My comment #3 is incorrect and comment #2 is correct in that "when the list suppresses sending to a given user, it rewrites mail headers to drop that user from cc" is correct, not backwards as I claimed. I.e., the paragraph ``` With respect to comment #2, it asserts "when the list suppresses sending to a given user, it rewrites mail headers to drop that user from cc". This is backwards. A member's address is removed from Cc only if the member's "avoid duplicates" setting is off, not on. This only affects the scenarios in that the premise becomes "User A is a user with the feature disabled". ``` should be ignored and the final "why only addresses that don't "avoid duplicates" should be "why only addresses that "avoid duplicates". My apologies for my confusion and any that I caused in others. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1845751 Title: cc modification due to nodup setting breaks DKIM & thus DMARC To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1845751/+subscriptions From ian at iankelling.org Wed Oct 16 18:04:16 2019 From: ian at iankelling.org (Ian Kelling) Date: Wed, 16 Oct 2019 22:04:16 -0000 Subject: [Bug 1845751] Re: cc modification due to nodup setting breaks DKIM & thus DMARC References: <156963231161.15808.17034191154411525924.malonedeb@gac.canonical.com> Message-ID: <157126345643.9523.3825335114766656612.malone@soybean.canonical.com> Mark, regarding this point "It fails to consider whether other DKIM signature breaking transformations such as subject prefixing, addition of headers/footers and content filtering are being done." It checks that no DMARC mitigation is on. In that case, having any DKIM signature breaking is already going to send invalid DMARC email, which seems to me to be a bigger separate problem: I don't think mailman should allow that combination of settings at all: don't send dmarc failing messages. Also, in the case the list has no DMARC mitigation and is breaking DKIM, not modifying the cc here will also prevent mailman from sending as many DMARC failing messages, because it will detect more duplicates and not send them. And, as you said, mailman 2 is going away. So, I think the patch is good as is. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1845751 Title: cc modification due to nodup setting breaks DKIM & thus DMARC To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1845751/+subscriptions