Mailman-coders April 2016

mailman-coders@python.org

14 participants
41 discussions

[Bug 1562408] [NEW] German translation typo 'letzte'
by 4dro 19 Apr '16

19 Apr '16

Public bug reported: A typo in the German version of the options page, letze should be letzte. diff /tmp/options.html-orig /tmp/options.html 1 ↵ 177c177 < erhalten Sie noch eine letze Zusammenfassung. --- > erhalten Sie noch eine letzte Zusammenfassung. I'd be nice to have an easier way to submit a translation update request. ** 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/1562408 Title: German translation typo 'letzte' To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1562408/+subscriptions

3 3

[Bug 1555798] [NEW] bin/arch can throw ValueError on bad Date: headers
by Mark Sapiro 19 Apr '16

19 Apr '16

Public bug reported: Various ValueError exceptions can be thrown when trying to archive a message with a Date: header that's off by multiple centuries. This does not normally occur in Mailman's archiving of posts because ArchRunner has code to fix bogus dates so archived messages and messages in the cumulative mbox normally have good Date: headers. However, no such checks or guarantees are made on a mbox file imported from elsewhere. There is a script at https://www.msapiro.net/scripts/cleanarch2 (mirrored at http://fog.ccsf.edu/~msapiro/scripts/cleanarch2) which is the standard bin/cleanarch modified to also check Date: headers and replace them with the date from From_ if they differ by more than mm_cfg.ARCHIVER_ALLOWABLE_SANE_DATE_SKEW (default = 15 days). This script may help, but the code in the _set_date method in Mailman/Archiver/pipermail.py should check for wildly out of range dates and do something reasonable with them. ** Affects: mailman Importance: Low Assignee: Mark Sapiro (msapiro) Status: 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/1555798 Title: bin/arch can throw ValueError on bad Date: headers To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1555798/+subscriptions

2 3

[Bug 1553888] [NEW] CommandRunner shunts message with TypeError if message body is a null byte
by Mark Sapiro 19 Apr '16

19 Apr '16

Public bug reported: We've seen spam sent to a list's -request address with no Subject and a body consisting of '\x00\n'. This causes CommandRunner to __import__('Mailman.Commands.cmd_\x00') which throws TypeError because of the Null byte. We need to catch this exception. ** Affects: mailman Importance: Low 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/1553888 Title: CommandRunner shunts message with TypeError if message body is a null byte To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1553888/+subscriptions

2 3

[Bug 1551075] [NEW] Content filtering breaks some PGP Mime signed messages.
by Mark Sapiro 19 Apr '16

19 Apr '16

Public bug reported: In some cases it is inevitable that Mailman's content filtering will break a PGP MIME signature. I.e., if content filtering removes signed content, the signature will be broken. For example, assume an original message is multipart/alternative and it is then wrapped in a multipart/signed outer message along with a signature part. If content filtering collapses alternatives, the signature will be broken. Likewise, if the original has an attached image/png part or any MIME type part which content filtering removes, the signature will be broken. These are inevitable results of content filtering, and content filtering should override signature preservation or people could avoid having their content filtered just by signing their posts. There is however a situation that has developed where signature breaking can be avoided. The latest (at the time of writing) versions of enigmail will sign a message in the following way. Assume the original unsigned message is just text/plain. It could be more complex, but the following still holds. The text/plain (or whatever) message is first recast as multipart mixed like: Content-Type: multipart/mixed; boundary="bbbbbb" From: (Original from) To: (Original to) Message-ID: (original message-id) Subject: (original subject) --bbbbbb Content-Type: (original message's content-type) Content-Transfer-Encoding: (original message's content-transfer-encoding) (remainder of original message) --bbbbbb-- Then the signed message is created with structure multipart/signed multipart/mixed text/plain (or whatever the original was) (original message) application/pgp-signature (signature of the multipart/mixed part) The problem is Mailman has logic to detect multipart parts with only one sub-part and collapse them to just the sub-part, so in this case, even though content filtering doesn't remove anything, it still collapses the above to multipart/signed text/plain (or whatever the original was) (original message) application/pgp-signature (signature of the multipart/mixed part) and the signature is no longer valid. This can be fixed by short- circuiting the "collapse multipart parts with only one sub-part" logic when encountering a multipart/signed part and not collapsing anything below it. ** 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/1551075 Title: Content filtering breaks some PGP Mime signed messages. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1551075/+subscriptions

2 3

[Bug 557955] Re: usenet threading improvements
by Mark Sapiro 19 Apr '16

19 Apr '16

** Changed in: mailman Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/557955 Title: usenet threading improvements To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/557955/+subscriptions

1 0

[Bug 1568547] [NEW] admindb POST fails due to absolute addressing
by Rob Button 11 Apr '16

11 Apr '16

Public bug reported: The shared server I use employs re-directs from my domain name to their local server domain name. This is causing form submission POSTs to fail in the ADMINDB pages used to moderate user posts, but not in the ADMIN pages used to manage the Mailman list. A review of the server code reveals why - The ADMIN pages use relative addressing in the form POST, so redirects are not an issue. Whereas the ADMINDB pages use absolute addressing in the form POST. See examples below from my website - THIS WORKS - From http://just63.justhost.com/mailman/admin/humor_noonway.com <FORM action="../admin/humor_noonway.com/general" method="POST" > THIS DOESN'T WORK - From http://just63.justhost.com/mailman/admindb/humor_noonway.com <FORM action="http://noonway.com/mailman/admindb/humor_noonway.com" method="POST" > This hasn't been an issue for the 12 years I've used Mailman to manage user posts, but all of a sudden user post management is non-functional. I can't tell if this is a change in my shared server setup, or an update to Mailman 2.1.20 causing this. There are probably Apache server settings I could change to solve this, but I can't access the folders needed to do so on a shared server. Is there a reason why the ADMINDB code couldn't be changed to use relative addressing like the code in ADMIN? ** 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/1568547 Title: admindb POST fails due to absolute addressing To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1568547/+subscriptions

2 2

[Bug 1565002] [NEW] RFC 2047 encoded display name in From: header not decoded in digests.
by Mark Sapiro 04 Apr '16

04 Apr '16

Public bug reported: When a message contains a From: header like From: =?utf-8?b?Sm9obiBEb2U=?= <jdoe(a)example.com> the display name is shown as '=?utf-8?b?Sm9obiBEb2U=?=' in the digest TOC and in the pseudo From: header in the plain text digest instead of being decoded as "John Doe". ** 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/1565002 Title: RFC 2047 encoded display name in From: header not decoded in digests. To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1565002/+subscriptions

1 1

[Bug 557955] Re: usenet threading improvements
by Mark Sapiro 03 Apr '16

03 Apr '16

The fix adds the original Message-ID: to References: and also adds X -Mailman-Original-Message-ID: and X-Mailman-Original-References: headers for 'forensics'. Hopefully this will help at least partially mitigate threading issues that result from Message-ID: munging. Also note that Munging the Message-ID in CookHeaders.py as suggested here is not a full solution as there still may be direct To: or Cc: recipients from 'reply all' and these are people likely to generate additional replies so the issue of multiple Message-ID:s is not solved by that approach. ** 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/557955 Title: usenet threading improvements To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/557955/+subscriptions

1 0

[Bug 557955] Re: usenet threading improvements
by Launchpad Bug Tracker 03 Apr '16

03 Apr '16

** 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/557955 Title: usenet threading improvements To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/557955/+subscriptions

1 0

[Bug 557955] Re: usenet threading improvements
by Mark Sapiro 01 Apr '16

01 Apr '16

I don't intend to replace the Message-ID: in CookHeaders.py as suggested in this patch, but I will put the original Message-ID in References: and perhaps make other modifications in NewsRunner.py for the posts actually gated to Usenet. ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: None => 2.1.22 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/557955 Title: usenet threading improvements To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/557955/+subscriptions

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders April 2016