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
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
** 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
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