Mailman 3 December 2016 - Mailman-coders

[Bug 1525954] [NEW] mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters
by sphakka 03 Jun '17

03 Jun '17

Public bug reported: Trailing blanks on option "subject_prefix" are removed on subject lines with non-ASCII characters. F.i., with options preferred_language = "Français" subject_prefix = "[prefix] " (irrespective of encode_ascii_prefixes) sending this (via Seamonkey Mail, LANG=en_US.UTF-8): Subject: "[prefix] c'est du français" results in reception of: Subject: "[prefix]c'est du français" ** 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/1525954 Title: mailman-2.1.20: option "subject_prefix": prefix trailing blanks are removed when subject lines have non-ASCII characters To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1525954/+subscriptions

3 8

[Bug 1645901] [NEW] DKIM signatures stripped from -owner messages with anonymous lists
by Robert Mathews 03 Jun '17

03 Jun '17

Public bug reported: If a list is set to be an anonymous list, and a message is sent to the -owner address, Mailman strips any existing DKIM header. This means that if someone from a DMARC-restricted address (e.g. yahoo.com) is sending a message that would get forwarded to an owner at a DMARC-checking ISP (e.g. yahoo.com), the message is rejected: it fails the DMARC check due to non-matching SPF and missing DKIM headers. If the DKIM header was left intact, it should work, since Mailman didn't modify the body for an -owner message. It makes privacy sense to always strip DKIM headers on messages that will be posted to an anonymous list. And it can work out okay because DMARC munging mitigation can be applied afterwards. But it doesn't seem to make sense to do the same for -owner messages on anonymous lists. Mailman doesn't apply other anonymous list modifications, like hiding the "From:" header, for -owner messages, as far as I can tell. This happens, by the way, due to Defaults.py: # This is the pipeline which messages sent to the -owner address go through OWNER_PIPELINE = [ 'SpamDetect', 'Replybot', 'CleanseDKIM', 'OwnerRecips', 'ToOutgoing', ] Is 'CleanseDKIM' really helpful in this -owner flow? Removing it would solve this problem. Alternately, perhaps CleanseDKIM could be taught to exempt -owner addresses on anonymous lists. ** Affects: mailman Importance: Undecided Status: New ** Tags: dkim 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/1645901 Title: DKIM signatures stripped from -owner messages with anonymous lists To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1645901/+subscriptions

3 3

[Bug 1637061] [NEW] Incorrect URLs in admin Membership List when chunked
by Mark Sapiro 03 Jun '17

03 Jun '17

Public bug reported: If the list's membership is large enough that the "letter" chunks need multiple pages, the "view more members" links at the bottom of the page are not correct. ** 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/1637061 Title: Incorrect URLs in admin Membership List when chunked To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1637061/+subscriptions

2 3

[Bug 1621172] [NEW] paths.py should add dist-packages
by Mark Sapiro 03 Jun '17

03 Jun '17

Public bug reported: Mailman's paths.py adds the path to the invoking Python's /usr/lib/pythonx.y/site-packages directory to sys.path in case it's missing due to Python being invoked with -S or some other reason. It should also add /usr/lib/pythonx.y/dist-packages. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) 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/1621172 Title: paths.py should add dist-packages To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1621172/+subscriptions

2 4

[Bug 1604544] [NEW] Letter links on admin Membership List rendered as Unicodes.
by Mark Sapiro 03 Jun '17

03 Jun '17

Public bug reported: Following a search which returned more than admin_member_chunksize hits, the letter links on the admin Membership List are Unicodes and renderd as u'http... which doesn't work. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: 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/1604544 Title: Letter links on admin Membership List rendered as Unicodes. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1604544/+subscriptions

2 6

[Bug 1643210] [NEW] 'from_is_list' does not RFC2047 encode correctly when translation contains non-ascii char
by Yasuhito FUTATSUKI＠POEM 03 Jun '17

03 Jun '17

Public bug reported: If from_is_list feature is used, From: header's `realname' field is composed by original realname and translation of '%(realname)s via %(lrn)s' which may contain non-ascii character. The realname field is encoded before compose if nessesary, but translation part is not. So From header may contain raw non-ascii character. To fix this, do RFC 2047 encode after compose. (There is another bug..., if servers language setting and mail list preferred language is differ, translation has taken from servers language, not from mail list one. Attached patch contains fix of it) ** Affects: mailman Importance: Undecided Status: New ** Attachment added: "CookHeaders.py.diff.txt" https://bugs.launchpad.net/bugs/1643210/+attachment/4780159/+files/CookHead… ** 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/1643210 Title: 'from_is_list' does not RFC2047 encode correctly when translation contains non-ascii char To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1643210/+subscriptions

2 16

[Bug 1602779] [NEW] Some German language templates are utf-8 encoded
by Mark Sapiro 03 May '17

03 May '17

Public bug reported: The templates/de files adminaddrchgack.txt masthead.txt nomoretoday.txt probe.txt refuse.txt subauth.txt are incorrectly encoded as utf-8 instead of iso-8859.1. ** Affects: mailman Importance: Medium Assignee: Mark Sapiro (msapiro) Status: 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/1602779 Title: Some German language templates are utf-8 encoded To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1602779/+subscriptions

2 4

[Bug 1539384] [NEW] Non-blocking DMARC mitigations should also be done for p=none
by Jakob Bohm 30 Dec '16

30 Dec '16

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: ...<at ourdomain> 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

5 14

[Bug 1648933] [NEW] admin_immed_notify=yes and respond_to_post_requests=yes has no effect for member posts even when emergency=yes
by Stephan 10 Dec '16

10 Dec '16

Public bug reported: Our configuration includes 'admin_immed_notify' = 'yes', and 'respond_to_post_requests' = 'yes'. Due to spam with targeted spoofing of list member addresses we had to configure 'emergency' = 'yes'. But both the notifications to the moderators as well as the reply to the poster informing them of the hold action only works for non-members! Member posts are held without the poster being notified, they get confused about what happened to their post, they will sometimes re-post several times, until the next day a moderator gets the digest of their piled-up posts. ** 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/1648933 Title: admin_immed_notify=yes and respond_to_post_requests=yes has no effect for member posts even when emergency=yes To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1648933/+subscriptions

2 3

[Bug 266760] Re: moderation approval should send email notification
by Stephan 10 Dec '16

10 Dec '16

I'm sorry, please disregard my comment #5. Our issue is somewhat different, see https://bugs.launchpad.net/mailman/+bug/1648933 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266760 Title: moderation approval should send email notification To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/266760/+subscriptions

1 0