Mailman-coders September 2016

mailman-coders@python.org

7 participants
27 discussions

[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 1625599] [NEW] sender filter should take precedence over spam filter
by Vseerror 20 Sep '16

20 Sep '16

Public bug reported: Moderated list In Privacy options...Sender Filters (privacy/sender) I put an email address X(a)Y.Z in "List of non-member addresses whose postings will be automatically discarded." to be rejected In Privacy options...Spam Filters (privacy/spam) I have filters to match on spamassassin and other fields - in some cases to hold messages for moderation. Messages from X(a)Y.Z that match a Spam Filter are not being rejected. I detail this in https://bugzilla.mozilla.org/show_bug.cgi?id=1297763 ** 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/1625599 Title: sender filter should take precedence over spam filter To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1625599/+subscriptions

2 1

[Bug 265961] Re: mailman breaks PGP/MIME messages
by Mark Sapiro 15 Sep '16

15 Sep '16

** 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/265961 Title: mailman breaks PGP/MIME messages To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/265961/+subscriptions

1 0

[Bug 265961] Re: mailman breaks PGP/MIME messages
by Foss-4 15 Sep '16

15 Sep '16

Anybody in the mailman dev team? This bug has been obsolete for 13 years. Time to close 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/265961 Title: mailman breaks PGP/MIME messages To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/265961/+subscriptions

1 0

[Bug 1614841] [NEW] CSRF protection needs to be extended to the user options page
by Mark Sapiro 05 Sep '16

05 Sep '16

Public bug reported: There is a possibility of a CSRF attack via the user options page which could allow an attacker to discover a user's password. ** 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/1614841 Title: CSRF protection needs to be extended to the user options page To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1614841/+subscriptions

3 10

[Bug 775294] [NEW] Set lifetime for input forms
by Tokio Kikuchi 05 Sep '16

05 Sep '16

*** This bug is a security vulnerability *** Private security bug reported: We may have to set lifetime for input forms because of recent activities on cross-site request forgery (CSRF). The form lifetime is successfully deployed in frameworks like web.py or plone etc. Proposed branch lp:~tkikuchi/mailman/form-lifetime implement lifetime in admin, admindb, options and edithtml interfaces. Other forms like create and rmlist have confirmation by password thus are safe regarding CSRF. The form generation time is set by a hidden parameter whose value is calculated following the mailman cookie algorithm. The default lifetime is set 1 hour in Default.py thus configurable by a site administrator. If a password is set in request, authorization cookie is discarded so the password authentication is forced. Wget tricks to manage list in FAQ can be used as they are now. ** Affects: mailman Importance: Undecided Status: New ** Branch linked: lp:~tkikuchi/mailman/form-lifetime -- You received this bug notification because you are a member of Mailman Coders, which is a direct subscriber. https://bugs.launchpad.net/bugs/775294 Title: Set lifetime for input forms

2 5

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders September 2016