Public bug reported:
When a message contains an invalud unicode sequence in its header,
qrunner flat out crashes on that:
May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't decode byte
0xe9 in position 18: invalid continuation byte
May 17 15:32:20 2015 (981) 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/IncomingRunner.py", line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 239, in process
i18ndesc = uheader(mlist, mlist.description, 'List-Id', maxlinelen=998)
File "/var/lib/mailman/Mailman/Handlers/CookHeaders.py", line 65, in uheader
return Header(s, charset, maxlinelen, header_name, continuation_ws)
File "/usr/lib/python2.7/email/header.py", line 183, in __init__
self.append(s, charset, errors)
File "/usr/lib/python2.7/email/header.py", line 267, in append
ustr = unicode(s, incodec, errors)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18: invalid
continuation byte
May 17 15:32:20 2015 (981) SHUNTING:
1431869540.389822+156779307d54473d0eb732994bb67eee95733285
A solution for this specific case is to have Mailman/Handlers/CookHeaders.py pass the erorrs='replace' parameter.
I would say that this is actually a bug in python-email, since I think it doesn't make sense to set errors to "strict" rather than something like "replace" when the intention is to parse stuff so free-formed, under-specd
and user-controlled as email. Nonetheless, Mailman already sets errors='replace' in some places so it might aswell add it here.
** 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/1462755
Title:
qrunner crashes on invalid unicode sequence
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1462755/+subscriptions
Public bug reported:
We need a script, documentation, or other procedure to help people
migrate from Mailman 2 to Mailman 3.
** Affects: mailman
Importance: Undecided
Status: New
** Tags: mailman3
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/965532
Title:
Need a script to upgrade from MM2 to MM3
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/965532/+subscriptions
Public bug reported:
If DNS lookup of TXT records for a domain finds more than one v=DMARC1; record, it checks them all for policy = reject or quarantine.
RFC 7849, Sec 6.6.3 item 5 says
5. If the remaining set contains multiple records or no records,
policy discovery terminates and DMARC processing is not applied
to this message.
Thus, if we find multiple records we should assume no DMARC policy for this domain.
** Affects: mailman
Importance: Low
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/1931029
Title:
DMARC policy lookup violates RFC 7849.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1931029/+subscriptions
Public bug reported:
If a simple text/plain message has a Content-Disposition: header and
does not have a Content-Type: header with a charset parameter, the body
will be scrubbed to a file with a .ksh extension.
It is only text/plain attachments that should be scrubbed in this way
and they should be given a .txt extension.
** Affects: mailman
Importance: Low
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/1917968
Title:
A text/plain message body is scrubbed with a .ksh extension
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1917968/+subscriptions
Public bug reported:
In Bouncer.Bouncer.__sendAdminBounceNotice(), default value of "did"
argment is evaluated only once on method definition and not evaluated at
runtime. This causes that the translation of 'disabled' is never used
other than default one.
A fix will be like a patch below (but not checked).
--- a/Mailman/Bouncer.py
+++ b/Mailman/Bouncer.py
@@ -226,12 +226,14 @@ class Bouncer:
if self.bounce_notify_owner_on_disable:
self.__sendAdminBounceNotice(member, msg)
- def __sendAdminBounceNotice(self, member, msg, did=_('disabled')):
+ def __sendAdminBounceNotice(self, member, msg, did=None):
# BAW: This is a bit kludgey, but we're not providing as much
# information in the new admin bounce notices as we used to (some of
# it was of dubious value). However, we'll provide empty, strange, or
# meaningless strings for the unused %()s fields so that the language
# translators don't have to provide new templates.
+ if did = None:
+ did = _('disabled')
siteowner = Utils.get_site_email(self.host_name)
text = Utils.maketext(
'bounce.txt',
** Affects: mailman
Importance: Undecided
Status: New
** 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/1922843
Title:
bounce action notice message never use the translation for 'disabled'
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1922843/+subscriptions
Public bug reported:
Hi,
When mailing list is configured with:
preferred_language = 'ja'
available_languages = ['en', 'ja']
send_goodbye_msg = 0
And mailman receives confirmation email for unsubscription with multipart message encoded in
different encoding than euc-jp, then mailmans command runner crashes with traceback:
Feb 10 18:08:00 2021 (1270) Uncaught runner exception: 'euc_jp' codec can't decode bytes in position 280-281: illegal multibyte sequence
Feb 10 18:08:00 2021 (1270) Traceback (most recent call last):
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 119, in _oneloop
self._onefile(msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 190, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 291, in _dispose
res.send_response()
File "/usr/lib/mailman/Mailman/Queue/CommandRunner.py", line 208, in send_response
results = MIMEText(NL.join(encoded_resp), _charset=charset)
File "/usr/lib64/python2.7/email/mime/text.py", line 30, in __init__
self.set_payload(_text, _charset)
File "/usr/lib64/python2.7/email/message.py", line 226, in set_payload
self.set_charset(charset)
File "/usr/lib64/python2.7/email/message.py", line 264, in set_charset
self._payload = charset.body_encode(self._payload)
File "/usr/lib64/python2.7/email/charset.py", line 390, in body_encode
s = self.convert(s)
File "/usr/lib64/python2.7/email/charset.py", line 273, in convert
return unicode(s, self.input_codec).encode(self.output_codec)
UnicodeDecodeError: 'euc_jp' codec can't decode bytes in position 280-281: illegal multibyte sequence
Here is an example of a mail which triggers this:
Date: Wed, 11 Nov 2020 14:13:16 +0900
Subject: Re: ###CONFIRM###
From: <testuser2@###SERVER###>
To: userlist-request(a)###SERVER###.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="000000000000663b1c05b3cdda78"
--000000000000663b1c05b3cdda78
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
44GT44KT44Gr44Gh44Gv5LiW55WM
--000000000000663b1c05b3cdda78
Also its maybe worth pointing out that setting RESPONSE_INCLUDE_LEVEL to <=1 mitigates this.
I've managed to fix this issue by decoding the message part with its original charset and then encoding it to preferred encoding of mailing list.
I'm attaching my patch. Could you please consider merging it?
Thanks for any help you can provide.
** Affects: mailman
Importance: Undecided
Status: New
** Attachment added: "mailman-cmd-replies.patch"
https://bugs.launchpad.net/bugs/1921682/+attachment/5481811/+files/mailman-…
--
You received this bug notification because you are a member of Mailman
Coders, which is subscribed to GNU Mailman.
https://bugs.launchpad.net/bugs/1921682
Title:
Japanese language prevents user from unsubscribing
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1921682/+subscriptions
Public bug reported:
dnspython >=2.0 requires Python >=3.6 and won't work with Mailman 2.1.
./configure should check for dnspython <2.0 and mention this requirement
of not found.
** 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/1895451
Title:
Mailman 2.1 does not support dnspython >=2.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1895451/+subscriptions
Public bug reported:
If the list has no subject_prefix, DMARC Wrap Message will not include
the Subject: in the wrapped message.
** Affects: mailman
Importance: High
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/1915655
Title:
DMARC Wrap Message doesn't include Subject: in the wrapper.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1915655/+subscriptions