Search results for "2021" - Mailman-users

Re: Exception with processing subscription confirmation email

by Eric Broens

Thanks Mark, We are indeed running mailman core 3.3.2 and using mysql. The data appears indeed to be truncated judging from the missing closing curly bracket (see below). Would it be OK to already extend the data column to VARCHAR(510) before upgrading to mailman core 3.3.3, or will this cause problems with upgrading to a newer version? +--------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------+ | data | +--------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------+ | {"pre_approved": false, "pre_confirmed": false, "pre_verified": false, "invitation": false, "address_key": "******************@************", "subscriber_key": 1, "user_key": "a44e8b9a34c64775b712f383d438ce1d", "token_owner_key": 1, "send_welcome_message" | +--------------------------------------------------------------------------- ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- ------------------------------+ Best Regards, Eric -----Original Message----- From: Mark Sapiro [mailto:mark@msapiro.net] Sent: donderdag 29 april 2021 18:43 To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: Exception with processing subscription confirmation email On 4/29/21 7:56 AM, Eric Broens wrote: > Hi, > > A new user tried to subscribe to a mailinglist, received the confirmation > mail, and replied to it. > > The subscriber is however not subscribed and remains listed in the "pending > confirmation" list. > > The following exception appears in the error.log. > > Does anyone knows how to resolve this? In the past we didn't experience any > issues and no changes but security updates have been installed. > > Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify > > Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 69, in __next__ > > return step() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 356, in _step_send_confirmation > > raise StopIteration > > StopIteration Tracebacks like the above are normal and probably shouldn't be logged at all. > Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':' > delimiter: line 1 column 256 (char 255) > > Apr 29 16:16:28 2021 (1490) Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/runners/command.py" > , line 208, in _dispose > > mlist, msg, msgdata, parts, results) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/eml_confir > m.py", line 54, in process > > mlist).confirm(token) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 578, in confirm > > workflow.restore() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 146, in restore > > data = json.loads(state.data) > > File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads > > return _default_decoder.decode(s) > > File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode > > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > > File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode > > obj, end = self.scan_once(s, idx) > > json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256 > (char 255) > > Apr 29 16:16:28 2021 (1490) SHUNTING: > 1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5 This one is the issue. There was some problem with the user's confirmation reply. View the shunted message with the command ``` mailman qfile path/to/var/queue/shunt/1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfc c27dda5.pck ``` although that probably won't show anything wrong as it appears that the issue is with the saved workflow. You can get the token from the shunted message and then look at the database with something like ``` SELECT data FROM workflowstate WHERE token = '<the token>' ``` but I suspect the issue is because the database is MySQL or MariaDB, your Mailman core is older than 3.3.3 and your database server mode is such that data too long for column results in truncation, and the data in this case is truncated to 255 bytes. In Mailman 3.3.3, this column was changed from VARCHAR(255) to VARCHAR(510) for MySQL. As far as subscribing the user is concerned, you can in Postorius view the subscriptions waiting user confirmation and delete this one and then `mass subscribe` the user. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

4 years, 2 months

Re: Reason for Shunting

by Brian Carpenter

On 2/9/21 5:25 PM, Mark Sapiro wrote: > On 2/9/21 2:03 PM, Brian Carpenter wrote: >> Is there a way to determine why a message keeps ending up in the shunt >> queue? >> > > Look in mailman.log for the `SHUNTING` message and the traceback that > immediately preceeds it. Thanks Mark. The reason was: Feb 09 16:40:11 2021 (2614) Uncaught runner exception: Multiple rows were found for one_or_none() sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for one_or_none() Feb 09 16:40:11 2021 (2614) SHUNTING: 1612906811.2642436+cd8e97a66b6d0c2b73c2adde71a4914108c3e673 I have no idea what that means. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 4 months

outgoing.py mailman@example.com issue

by dancab＠caltech.edu

I deployed Mailman3 last night and today we've had some "bounced" messages with headers referencing mailman(a)example.com. This has only happened with a few lists. Any ideas what causes this? We are using an SMTP relay server for incoming and outgoing messages in front of the Mailman3 service. Thanks! Received: from [172.17.0.2] (ec2-52-25-39-43.us-west-2.compute.amazonaws.com [52 .25.39.43]) by smtp2.caltech.edu (Postfix) with ESMTP id B97472076421 for <xxxxxxx(a)caltech.edu>; Fri, 5 Nov 2021 12:34:34 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.caltech.edu B97472076421 From: Mailman <mailman(a)example.com> To: Mailman Bounces <mailman-bounces(a)example.com> Subject: SMTP Delivery Failure Message-ID: <163614051784.271.12319265021103466218@badc5045e1e5> Date: Fri, 05 Nov 2021 12:28:37 -0700 -- Dan

3 years, 8 months

API errors making member changes to one list but not others

by Stephen Willey Mats Mats

We had an issue with the UI getting API timeouts for a single list for specific functions but not other lists or other functions. This started happening after we accidentally filled the disk partition used by most of the system including the database. There was a single person testing at the time when the disk fullness happened and it was only the single list that got ‘damaged’. After disk cleanup and restarting the docker images the single list would give API errors ("HTTP Error 400: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5)” ) on the screen and logged errors (below) when list members were either subscribed or removed. The issue was repeatable in Postorius and did not ‘heal’. Oddly the issue was resolved by making seemingingly the same API calls from the command line via curl. Making the below call to add a member succeeded and fixed being able to add members in the UI. Similarly sending a DELETE cal from curl worked where unsubscribe requests from postorius (either mass removal or picking addresses from the list member and unsubscribing selected) failed. Again, the unsubscribe from the curl DELETE call ‘healed’ the list such that subsequent unsubscribes in Postorius worked. curl --user user:password -X POST -d 'list_id=laura-test.mm3.aca-aws.s.uw.edu' -d 'subscriber=ssw(a)uw.edu' -d 'pre_verified=true' -d 'pre_confirmed=true' -d 'pre_approved=true' http://172.19.199.2:8001/3.1/members We’re running the current rolling docker images (up to date as of 25Jan2021) Obviously, people should run their servers better than letting disk partitions fill-up but it’s going to happen and mailman3 should do a better job of reporting errors and recovering when accidents happen. thanks, steve I’ve included mailman.log lines from going to the mass subscribe [26/Jan/2021:20:42:49 +0000] "GET /3.1/lists/laura-test.mm3.aca-aws.s.uw.edu HTTP/1.1" 200 434 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:42:49 +0000] "GET /3.1/lists/laura-test(a)mm3.aca-aws.s.uw.edu/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:42:49 +0000] "GET /3.1/lists/laura-test(a)mm3.aca-aws.s.uw.edu/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:43:01 +0000] "GET /3.1/lists/laura-test.mm3.aca-aws.s.uw.edu HTTP/1.1" 200 434 "-" "GNU Mailman REST client v3.3.2" Jan 26 20:43:07 2021 (48) deque: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 426, in _make_request six.raise_from(e, None) File "<string>", line 3, in raise_from File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 421, in _make_request httplib_response = conn.getresponse() File "/usr/lib/python3.8/http/client.py", line 1347, in getresponse response.begin() File "/usr/lib/python3.8/http/client.py", line 307, in begin version, status, reason = self._read_status() File "/usr/lib/python3.8/http/client.py", line 268, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "/usr/lib/python3.8/socket.py", line 669, in readinto return self._sock.recv_into(b) socket.timeout: timed out During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 439, in send resp = conn.urlopen( File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 724, in urlopen retries = retries.increment( File "/usr/lib/python3.8/site-packages/urllib3/util/retry.py", line 403, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/lib/python3.8/site-packages/urllib3/packages/six.py", line 735, in reraise raise value File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen httplib_response = self._make_request( File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 428, in _make_request self._raise_timeout(err=e, url=url, timeout_value=read_timeout) File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 335, in _raise_timeout raise ReadTimeoutError( urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/mailman/app/workflow.py", line 69, in __next__ return step() File "/usr/lib/python3.8/site-packages/mailman/app/subscriptions.py", line 343, in _step_do_subscription self.member = self.mlist.subscribe( File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File "/usr/lib/python3.8/site-packages/mailman/model/mailinglist.py", line 507, in subscribe notify(SubscriptionEvent( File "/usr/lib/python3.8/site-packages/zope/event/__init__.py", line 32, in notify subscriber(event) File "/usr/lib/python3.8/site-packages/mailman/app/membership.py", line 176, in handle_SubscriptionEvent send_welcome_message(mlist, member, member.preferred_language) File "/usr/lib/python3.8/site-packages/mailman/app/notifications.py", line 51, in send_welcome_message welcome_message = wrap(getUtility(ITemplateLoader).get( File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 188, in get contents = getUtility(ITemplateManager).get( File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper return function(args[0], config.db.store, *args[1:], **kws) File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 110, in get contents = protocols.get(actual_uri, **auth) File "/usr/lib/python3.8/site-packages/mailman/utilities/protocols.py", line 38, in get response = requests.get(url, timeout=REQUEST_TIMEOUT, **kws) File "/usr/lib/python3.8/site-packages/requests/api.py", line 76, in get return request('get', url, params=params, **kwargs) File "/usr/lib/python3.8/site-packages/requests/api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 530, in request resp = self.send(prep, **send_kwargs) File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 643, in send r = adapter.send(request, **kwargs) File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 529, in send raise ReadTimeout(e, request=request) requests.exceptions.ReadTimeout: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) [26/Jan/2021:20:43:07 +0000] "POST /3.1/members HTTP/1.1" 400 130 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:43:07 +0000] "GET /3.1/lists/laura-test(a)mm3.aca-aws.s.uw.edu/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:43:07 +0000] "GET /3.1/lists/laura-test(a)mm3.aca-aws.s.uw.edu/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" Then the results of a successful subscribe: [26/Jan/2021:20:46:20 +0000] "GET /3.1/lists/list2.mm3.aca-aws.s.uw.edu HTTP/1.1" 200 388 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:46:20 +0000] "POST /3.1/members HTTP/1.1" 201 0 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:46:20 +0000] "GET /3.1/lists/list2(a)mm3.aca-aws.s.uw.edu/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2" [26/Jan/2021:20:46:20 +0000] "GET /3.1/lists/list2(a)mm3.aca-aws.s.uw.edu/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.2” >

4 years, 5 months

Re: Exception with processing subscription confirmation email

by Mark Sapiro

On 4/29/21 7:56 AM, Eric Broens wrote: > Hi, > > A new user tried to subscribe to a mailinglist, received the confirmation > mail, and replied to it. > > The subscriber is however not subscribed and remains listed in the "pending > confirmation" list. > > The following exception appears in the error.log. > > Does anyone knows how to resolve this? In the past we didn't experience any > issues and no changes but security updates have been installed. > > Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify > > Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 69, in __next__ > > return step() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 356, in _step_send_confirmation > > raise StopIteration > > StopIteration Tracebacks like the above are normal and probably shouldn't be logged at all. > Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':' > delimiter: line 1 column 256 (char 255) > > Apr 29 16:16:28 2021 (1490) Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/runners/command.py" > , line 208, in _dispose > > mlist, msg, msgdata, parts, results) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/eml_confir > m.py", line 54, in process > > mlist).confirm(token) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 578, in confirm > > workflow.restore() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 146, in restore > > data = json.loads(state.data) > > File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads > > return _default_decoder.decode(s) > > File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode > > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > > File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode > > obj, end = self.scan_once(s, idx) > > json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256 > (char 255) > > Apr 29 16:16:28 2021 (1490) SHUNTING: > 1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5 This one is the issue. There was some problem with the user's confirmation reply. View the shunted message with the command ``` mailman qfile path/to/var/queue/shunt/1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5.pck ``` although that probably won't show anything wrong as it appears that the issue is with the saved workflow. You can get the token from the shunted message and then look at the database with something like ``` SELECT data FROM workflowstate WHERE token = '<the token>' ``` but I suspect the issue is because the database is MySQL or MariaDB, your Mailman core is older than 3.3.3 and your database server mode is such that data too long for column results in truncation, and the data in this case is truncated to 255 bytes. In Mailman 3.3.3, this column was changed from VARCHAR(255) to VARCHAR(510) for MySQL. As far as subscribing the user is concerned, you can in Postorius view the subscriptions waiting user confirmation and delete this one and then `mass subscribe` the user. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Request Entity Too Large

by Stephen J. Turnbull

Christian Stalberg via Mailman-users writes: > Now mail sent to mm3 for distribution is not going out, for two > different lists. Check whether stuff is stuck in your MTA queue, and your MTA logs. Also check Mailman's queues (usually in /var/lib/mailman/qfiles, I think). As for why it's two different lists, is it possible that somebody cross-posted to those lists, or one is subscribed to the other? The mailman.log shows this error: > Oct 17 21:50:00 2021 (491) ACCEPT: > <030601d7c3a0$ee342f20$ca9c8d60$(a)somedomain.com> > Oct 17 21:50:04 2021 (488) HyperKitty failure on > https://somedomain.net/archives/api/mailman/archive: <html> I don't think this should affect mail going out in itself, because this appears to be delivery to HyperKitty, not to any remote host. Why nginx is involved is a mystery to me, though. > <head><title>413 Request Entity Too Large</title></head> > <body bgcolor="white"> > <center><h1>413 Request Entity Too Large</h1></center> > <hr><center>nginx/1.14.2</center> > </body> > </html> > (413) > Oct 17 21:50:04 2021 (488) Exception in the HyperKitty archiver: <html> > <head><title>413 Request Entity Too Large</title></head> > <body bgcolor="white"> > <center><h1>413 Request Entity Too Large</h1></center> > <hr><center>nginx/1.14.2</center> > </body> > </html> It appears that nginx is complaining that a request from HyperKitty is too large. I don't know much about nginx, but usually a request is sent FROM a client TO an HTTPd, and it's saying it's too big. I guess if nginx is the front end for HyperKitty, it could be that some client is requesting a huge email from HyperKitty. I guess you could have nginx between Mailman core and HyperKitty, in which case this is apparently an nginx configuration issue: it has an upper limit on the size of messages it's willing to accept from core and pass on to HyperKitty. If your Mailman is getting messages large enough that an HTTPd balks, I wouldn't be surprised if your MTA is on strike, or is getting "you gotta be kidding, I'm too busy, try tomorrow" from remote recipients. It could be a Mailman problem, but there's nothing in your report to suggest that it is.

3 years, 8 months

Re: Reason for Shunting

by Mark Sapiro

On 2/9/21 2:57 PM, Brian Carpenter wrote: > > On 2/9/21 5:25 PM, Mark Sapiro wrote: >> On 2/9/21 2:03 PM, Brian Carpenter wrote: >>> Is there a way to determine why a message keeps ending up in the shunt >>> queue? >>> >> >> Look in mailman.log for the `SHUNTING` message and the traceback that >> immediately preceeds it. > > > Thanks Mark. The reason was: > > Feb 09 16:40:11 2021 (2614) Uncaught runner exception: Multiple rows > were found for one_or_none() > > sqlalchemy.orm.exc.MultipleResultsFound: Multiple rows were found for > one_or_none() > > Feb 09 16:40:11 2021 (2614) SHUNTING: > 1612906811.2642436+cd8e97a66b6d0c2b73c2adde71a4914108c3e673 > > I have no idea what that means. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> and <https://gitlab.com/mailman/mailman/-/issues/657> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

Re: API access to Hyperkitty

by Mark Sapiro

On 2/9/21 10:23 AM, Brian Carpenter wrote: > Is it possible to download Hyperkitty's archives to a remote server via > an API? Is there documentation that explains how to accomplish this task? > I don't think there is documentation, but if you look at the target of any `download` button, it should be obvious. I.e. the link to download the entire archive for this list is https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/export/… The `mailman-users(a)mailman3.org-2021-02.mbox.gz` part is the name of the file to download to and the `-2021-02` part can be anything or nothing, but the name must begin with the list posting address and end with `.mbox.gz`. If the archive is large, this can time out in which case adjust `start` and `end` to download it in pieces. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

Correct way to filter auto-replies to list?

by Gary Holman

I have seen a few messages on this list regarding handling 'out of office' auto-replies. However I do not see a final resolution. What is the best practice to filter auto-replies to list: header filter or postfix milter-reject or something else? We are running dockerized Mailman 3 version 1.3.4. A list user auto-replied their vacation message to list and then the listserv created a chain-reaction of continuously replying to auto-replies by that user. There isn't really a good header option to filter from, as the subject seems to be randomized. For example: From <SENDER ADDRESS> Tue May 4 19:02:29 2021 From: Sender Name <SENDER ADDRESS> To: <LIST ADDRESS> Subject: [electronics-daq] Re: 25ad Date: Tue, 04 May 2021 20:59:57 +0200 Message-ID: <A2FB195E-5261-4F26-AF19-7AFE0B0632A5> In-Reply-To: =?utf-8?q?=3C0101017937874647-cf4b59ca-737e-4db0-9a01-85d9d43c8?= =?utf-8?q?d68-000000=40us-west-2=2Eamazonses=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7283775935526227777==" --===============7283775935526227777== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you, Gary

4 years, 2 months

Re: Held for notification - runner exception: 'ascii' codec can't encode character

by Mark Sapiro

On 1/2/22 11:00 AM, Seth Seeger wrote: > > I have a case where a user (set to be moderated), posts a message. She got the appropriate email back saying she was being held for moderation. However, the moderator did not get the email. I found the following block in mailman.log: > > Dec 28 19:37:44 2021 (33) Uncaught runner exception: 'ascii' codec can't encode character '\u2019' in position 5: ordinal not in range(128) > Dec 28 19:37:44 2021 (33) Traceback (most recent call last): > File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 173, in _one_iteration > self._process_one_file(msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 266, in _process_one_file > keepqueued = self._dispose(mlist, msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/runners/incoming.py", line 79, in _dispose > process(mlist, msg, msgdata, start_chain) > File "/usr/lib/python3.8/site-packages/mailman/core/chains.py", line 79, in process > link.function(mlist, msg, msgdata) > File "/usr/lib/python3.8/site-packages/mailman/chains/hold.py", line 234, in _process > text = MIMEText(expand(template, mlist, substitutions), > File "/usr/lib/python3.8/email/mime/text.py", line 42, in __init__ > self.set_payload(_text, _charset) > File "/usr/lib/python3.8/email/message.py", line 315, in set_payload > payload = payload.encode(charset.output_charset) > UnicodeEncodeError: 'ascii' codec can't encode character '\u2019' in position 5: ordinal not in range(128) > Dec 28 19:37:44 2021 (33) SHUNTING: 1640720264.0541506+b139f885caa9444586b43093a09991b7c19581e6 > > There are two owners listed, one of them is also listed as the moderator. This is redundant. Having the same user as both owner and moderator only results in possible duplicate notifications. There is no reason to have an owner also be a moderator. > "mailman version" says: GNU Mailman 3.3.4 (Tom Sawyer) We are running from Docker. I can send you the pck file offline if that would help. Please do send me the shunted .pck. what is going on is this is an English language list which has character set `ascii` and the notice for some reason has non-ascii, possbbly the Subject: or the user's display name has non-ascii. But possibly the message itself is defective. In any case, I'd like to get the shunted message to see if there's something we should fix. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

Mailman-users search results for query "2021"