Mailman-coders August 2018

mailman-coders@python.org

4 participants
14 discussions

[Bug 1787690] [NEW] Mailman rejects multipart content from Gmail/android
by Jeremy Gregson 28 Aug '18

28 Aug '18

Public bug reported: With a mailman list set to apply content filtering, and with the default settings to pass_mime_types of text/html, multipart/mixed and multipart/alternative, mail sent from anyone using the Gmail app on an android device is bounced. The same user can send the same message from the native Mail client on an Android device, or from an Apple device. The problem seems to be that the Gmail app includes a header in the form Content-Type: multipart/mixed; boundary="===============8130305584729002058==" ...with no carriage return after the semi-colon. The only way I've been able to get a list to accept mail from that client app (which is very popular) is to remove pass_mime_types altogether. ** 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/1787690 Title: Mailman rejects multipart content from Gmail/android To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1787690/+subscriptions

2 4

[Bug 1778363] [NEW] exception (utf8 codec) in pipermail
by Olivier GERARD 28 Aug '18

28 Aug '18

Public bug reported: After upgrading Mailman from 2.1.23 to 2.1.26-1 on Debian, things went smoothly, the list's mbox is updated but the archives are not updated. In the error log, one sees, for every message Jun 23 19:59:03 2018 (20419) SHUNTING: 1529776742.660616+f4a3eea82ed27ce3f481064f194162863c62b280 Jun 23 21:35:24 2018 (20419) Uncaught runner exception: 'utf8' codec can't decode byte 0xaa in position 26: invalid start byte Jun 23 21:35:24 2018 (20419) Traceback (most recent call last): File "/var/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop self._onefile(msg, msgdata) File "/var/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/lib/mailman/Mailman/Queue/ArchRunner.py", line 77, in _dispose mlist.ArchiveMail(msg) File "/var/lib/mailman/Mailman/Archiver/Archiver.py", line 214, in ArchiveMail h.processUnixMailbox(f) File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 596, in processUnixMailbox self.add_article(a) File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 640, in add_article author = fixAuthor(article.decoded['author']) File "/var/lib/mailman/Mailman/Archiver/pipermail.py", line 63, in fixAuthor while i>0 and (L[i-1][0] in lowercase or UnicodeDecodeError: 'utf8' codec can't decode byte 0xaa in position 26: invalid start byte This is always the same complaint. I have checked shunted messages and the mbox itself and I have not found any 0xaa value in them. ** Affects: mailman Importance: Undecided Status: New ** Tags: pipermail unicode -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1778363 Title: exception (utf8 codec) in pipermail To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1778363/+subscriptions

3 4

[Bug 377840] Re: enhancement: allow fullname to be required
by Mark Sapiro 14 Aug '18

14 Aug '18

** 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/377840 Title: enhancement: allow fullname to be required To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/377840/+subscriptions

1 0

[Bug 1787054] [NEW] Attempts to get organizational domain data fail
by Mark Sapiro 14 Aug '18

14 Aug '18

Public bug reported: As part of DMARC mitigation processing, Mailman looks up the DMARC policy for the From: domain. If it doesn't find a DMARC policy it attempts to look up the policy for the "organizational domain" corresponding to the From: domain if the organizational domain is different. To determine the organizational domain it uses information from the list at https://publicsuffix.org/list/public_suffix_list.dat. Recent changes at publicsuffix.org are causing Mailman's attempt to retrieve the list to fail with urllib2.URLError: <urlopen error [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure> This failure has been observed with Python 2.7.6 but not with Python 2.7.12. There are changes 2.7.9 which affect the underlying ssl module, and I think retrieval of this URL via urllib2, urllib or the Python requests module will all fail with Python < 2.7.9. The effect of this issue other than writing an error log entry for every failed retrieval is that in some cases, the organizational domain will not be properly found. If the TLD is .com, .net, .gov, .edu, etc. There will be no issue, but if for example the From: domain is some.sub.domain.school.k12.ca.us and that domain doesn't publish a DMARC policy, we should look up the policy for the school.k12.ca.us organizational domain, but instead we will look up ca.us. This will probably be more of an issue with non-US lists than with US lists, and it is not known how significant the issue is. At present, the only known workaround is to upgrade the underlying Python. ** 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/1787054 Title: Attempts to get organizational domain data fail To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1787054/+subscriptions

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders August 2018