Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Mail control not given from Mailman 3 to postfix

by Mark Sapiro

To follow up, I received the traceback and the dump of the shunted message off-list. The traceback is ``` Jul 07 21:36:47 2020 (26815) Uncaught runner exception: sequence item 0: expected str instance, Header found Jul 07 21:36:47 2020 (26815) Traceback (most recent call last): File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, in _one_iteration self._process_one_file(msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, in _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line 37, in _dispose process(mlist, msg, msgdata, pipeline) File "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, in process handler.process(mlist, msg, msgdata) File "/var/lib/mailman/mailman/src/mailman/handlers/avoid_duplicates.py", line 59, in process addrs = getaddresses(msg.get_all(header, [])) File "/usr/lib64/python3.6/email/utils.py", line 112, in getaddresses all = COMMASPACE.join(fieldvalues) TypeError: sequence item 0: expected str instance, Header found Jul 07 21:36:47 2020 (26815) SHUNTING: 1594138007.5613732+1a5932f41fb4cfcd18c9b0b0ac6f999c84408577 ``` This was apparently caused by an invalid RFC 2047 encoded To: header which encoded the entire header including the address as one base64, unknown-8bit character set encoded word. However, despite trying with several different Python versions, I was unable to recreate the TypeError, so the reason for this exception remains unknown.

6 years, 3 months

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Mark Sapiro

On 6/20/20 1:37 PM, Ruth Ivimey-Cook wrote: > Thanks Mark, Ignore bracketed numbers below ([1], [2], etc.) They come from conversion of the HTML only post to plain text. > On 20/06/2020 03:53, Mark Sapiro wrote: > > What are your Django settings for MAILMAN_REST_API_URL, > MAILMAN_REST_API_USER and MAILMAN_REST_API_PASS and do these agree with > the [webservice] settings for hostname, port, use_https, admin_user and > admin_pass in mailman.cfg in core and is the port open to the outside on > the core machine? > > greyarea-post is the mailman-core and exim server. > > greyarea-web1 is the postorius and hyperkitty server. > > On greyarea-web1, in django-settings.py, > > MAILMAN_REST_API_URL = '[1]http://greyarea-post:8870' > MAILMAN_REST_API_USER = 'restadmin' > MAILMAN_REST_API_PASS = XXXX > > and both the above-named hosts are also included in ALLOWED_HOSTS along > with localhost. > > On greyarea-post, in mailman.cfg: > > [webservice] > admin_pass: XXXXX > admin_user: restadmin > api_version: 3.1 > hostname: 0.0.0.0 > port: 8870 > use_https: no > > The password and username are as on web1. That all looks good. > Do you see REST requests from the Postorius machine in core's > mailman.log and access.log? > > Yes, there are lots of requests of the form: > > [07/Jun/2020:15:00:01 +0000] "GET /3.1/lists?count=10&page=1 > HTTP/1.1" 200 470 "-" "GNU Mailman REST client v3.3.1" > > I made a new list using the core CLI, and as a result of navigating > directly to the list archive page I get to see: > > [06/Jun/2020:23:00:02 +0000] "GET /3.1/lists/chbcdaily(a)ch-bc.org.uk > HTTP/1.1" 200 365 "-" "GNU Mailman REST client v3.3.1" > > ... but in neither case do I get a complete screen on the browser or > 'follow-up' requests. > > I don't have a file access.log on the greyarea-post. Yes, that's actually a gunicorn log so would only be on greyarea-web1, but the mailman.log tells us the requests are getting to the core REST API, so we don't need that info. > On the greyarea-web1 I have mailmansuite.log with the last few lines: > > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/ba > se.py", line 74, in rest_data > response, content = self._connection.call(self._url) > File > "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/co > nnection.py", line 124, in call > 'Could not connect to Mailman API: ', repr(e)) > mailmanclient.restbase.connection.MailmanConnectionError: ('Could > not connect to Mailman API: ', > 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'0.0.0.0\', > port=8870): Max retries exceeded with url: /3.1/domains/ch-bc.org.uk > (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection > object at 0x7f5416db8518>: Failed to establish a new connection: > [Errno 111] Connection refused\',))",),)') > ERROR 2020-06-03 01:02:06,115 29002 django.request Service > Unavailable: /postorius/lists/ OK. This is telling us that mailmanclient (the REST API Python bindings that Postorius uses to access core) is having trouble establishing a connestion to the core REST server, but it clearly gets there some of the time based on the mailman.log entries. > the uwsgi-error_*.log contains many lines of the form: > > api: url is > [2]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= > 1 > api: url is > [3]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= > 1 > > My reason for thinking, in my original post, that the wrong host > address is being used is that the ConnectionError above contains > 0.0.0.0 in its url for /3.1/domains/... but 0.0.0.0 is only present as > the listen address on the core web service and does not appear in the > config for postorius. The ConnectionError above comes from requests.request (docs at <https://requests.readthedocs.io/en/master/>). Client only provides a URL in the call to request and the URL is the baseurl + the path and the baseurl is MAILMAN_REST_API_URL which you have as http://greyarea-post:8870. Entries above have http://greyarea-post.cam.ivimey.org:8870/. Is that the correct FQDN? I suspect a DNS lookup issue. How does greyarea-web1 resolve greyarea-post? You could try a FQDN that greyarea-web1 can lookup in DNS rather than relying on /etc/resolv.conf and/or /etc/hosts. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

[MM3-users] Re: UnpicklingError on mailman lists command

by Mark Sapiro

On 8/3/21 7:35 AM, Bryan Loniewski wrote: > Okay, that helped identify possible culprits. Three of our lists are hitting/over the max BLOB length (65,535 bytes) for accept_these_nonmembers. I executed this SQL command for each of the BLOB cols you referenced and only accept_these_nonmembers is borked: > > MySQL [mailman]> SELECT list_name, OCTET_LENGTH(accept_these_nonmembers) as howManyBytes from mailinglist where OCTET_LENGTH(accept_these_nonmembers) > 64000; > +---------------+--------------+ > | list_name | howManyBytes | > +---------------+--------------+ > | <snip> | 65535 | > | <snip> | 65535 | > | <snip> | 65535 | > +---------------+--------------+ > 3 rows in set (0.01 sec) > > So, putting aside *why* these lists are so large wrt that column, can or should I alter the col type(s) to MEDIUMBLOB? If yes, would that remain on suite upgrades? If no, is there a better alternative? Or some recommendation in between? Modifying the column type at this point will not help because the data has already been truncated and the missing piece is gone. It may help avoid future issues, but I suspect it's not necessary. It would probably 'stick' on an upgrade as long as there were no new migration affecting those columns, but if there were such a migration, it could fail due to the existing type not being as expected. I suspect these lists were imported from Mailman 2.1 with the `mailman import21` command. The goal of that is to import the addresses as non-members with the appropriate action and put only the regexps in the MM 3 *_these_nonmembers. Prior to Mailman 3.3.2, import21 would add the entire 2.1 *_these_nonmembers and then delete the non-regexps. Possibly something went wrong in that process because of the truncation and left the new *_these_nonmembers in a broken state. Or possibly you just have a huge number of regexps in these list's accept_these_nonmembers. I suggest you use mysql to update this column's data for these three lists. to a value which unpickles as an empty list. This value is the python bytes b'\x80\x04\x5d\x94\x2e' (i.e. 5 bytes with hex values 80, 04, 5d, 94 and 2e). I'm not sure how that is stored in a MySQL BLOB, but I'm sure you can determine that. This will allow you to actually access those lists in Mailman. Also note that beginning with Postorius 1.3.3, the *_these_nonmembers settings are exposed on the List Settings -> Message Acceptance form. If you still have the original MM 2.1 config.pck files, you can examine them with Mailman 2.1's bin/dumpdb command to see what was in accept_these_nonmembers, and then see if the appropriate MM 3 nonmembers were created and if the remaining regexps are not too long, add them. If you need help with this, I will help. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

[MM3-users] Re: moving list from mm3 -> mm3

by Mark Sapiro

On 12/8/23 08:01, Jens Günther wrote: > > This is a nice collection of the configuration of a certain list. Does > anybody know how I would get this data back to the newly created list in > the second working mm3-instance? Shouldn't it be possible via POST > command? I thought of something like: > > curl -u restadmin:restpass -d @short.domain -H "Content-Type: > application/json" localhost:8001/3.1/lists/&short.&domain/config > > But it returns {"title": "405 Method Not Allowed"} and I don't know > where to look in the docs, since it shows almost always a way through > mailman shell. You need a PUT command, not POST. Try the above with `-X PUT`. > ## Members, moderators, owners > > To export all members I normally run within mm-core-container as user > mailman the following command: > > mailman members &short.&domain > &short.txt > > To fill them back in, it can be done in Postorius (or is there a way > through API?). You can use Postorius -> Mass operations -> Mass subscribe to add the members, but you can't do that for owners and moderators. Also you lose information about the members such as Delivery status, Delivery mode and other user settings. > What I would love to know is how to get out Owners of the corresponding > lists and reimport them in the new one (which will be the same at the > end :-D but different instance). You can use the --role option with `mailman members` to get owners and moderators, but short of a custom script, you have to add them manually. > ## registered users > > This part is somehow tricky, since I have no clue how to do it. Some of > the mailinglist-admins don't want to bother their list-owners again with > registering newly on the other system. Is there a way to export all > users (I think I found them in the DB in the table auth_users, somehow > in combination with account_emailaddress) and get them over to the new > instance (actually I just need part of them, but that's another question > that I might solve lateron on my own). > > Maybe the answer is already here: > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… > -> but can somebody help to get this working (import/export)? That is not the answer. Those are Mailman core users, not Django (web login) users. You need to get the relevant entries from the auth_users and account_emailaddress tables and add them to the new DB. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

[MM3-users] Re: Enable delivery

by Mark Sapiro

On 12/9/24 17:35, Hirayama, Pat wrote: > Greetings, > > I'm finding something a bit odd with our listserv. Please see https://wiki.list.org/DOC/Mailman%20is%20not%20Listserv > Some of the members of some of the lists are reporting that they aren't receiving messages sent to the list. When I review the member options for the person in question, I see that Delivery Status shows nothing selected (i.e. neither radio button is selected for Enabled or Disabled). If you look in the MTA logs is mail being sent to them. As far as the Delivery Status showing nothing, that means the member's delivery_status is None. The ultimate delivery status is determined by checking first the member's delivery_status, then the address's delivery_status, then the user's delivery_status and finally Mailman's global preferences. The first non-None value is what's used. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… Also see the various tabs at https://www.example.com/mailman3/accounts/subscriptions/ > If I select Enabled and Save, then delivery starts working for that user. This should only happen if the users address or user based preference or the global preference is Disabled. > There are other members of the list that have neither Enabled or Disabled selected, but they are working. Which also seems to mean that when I run: > > mailman members --nomail any listname@listserv > > Nothing is returned. Because all members ultimately have delivery enabled. > If anyone has any ideas about why this might be the case, or how I might proactively identify other members who aren't receiving mail, that would be appreciated. Alternately, any thoughts on how I might force all members to Delivery Status Enabled, that would also be great. It shouldn't be necessary to do that. For one of these members, e.g. user(a)example.com, that isn't getting mail, do this in mailman shell ``` mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list(a)example.com mailing list >>> from mailman.core.constants import system_preferences >>> mbr = m.members.get_member('user(a)example.com') >>> print(mbr.delivery_status) (this will print the ultimate delivery_status, for the components do) >>> print(mbr.preferences.delivery_status) (output) >>> print(mbr.address.preferences.delivery_status) (output) >>> print(mbr.address.user.preferences.delivery_status) (output) >>> print(system_preferences.delivery_status) (output) >>> ``` The first of the (output) lines which is not None should be the same as the output from print(mbr.delivery_status). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 10 months

[MM3-users] Re: Installing mailman 3

by Rafael Mora

ok, thanks Mark, I'm getting an error doing: (env) [mailman@localhost mailman-suite_project]$ python2 manage.py migrate Traceback (most recent call last): File "manage.py", line 8, in <module> from django.core.management import execute_from_command_line ImportError: No module named django.core.management What do you suggest?? El vie., 21 jul. 2017 a las 14:31, Mark Sapiro (<mark(a)msapiro.net>) escribió: > On 07/21/2017 12:07 PM, Rafael Mora wrote: > > Installing mailman-suite for web ui. I did this: > > > > (env) [mailman@localhost ~]$ git clone > > https://gitlab.com/mailman/mailman-suite/ > > Cloning into 'mailman-suite'... > > error: RPC failed; result=22, HTTP code = 404 > > fatal: The remote end hung up unexpectedly > > > > > > but it returned an error, what should I do?? > > > It's another case of incorrect docs. It should be > > git clone https://gitlab.com/mailman/mailman-suite.git > > See <https://gitlab.com/mailman/mailman-suite-doc/issues/15>. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

9 years, 2 months

[MM3-users] Re: user self registration

by Christian Stalberg

That worked. Thank you! -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Sunday, December 7, 2025 9:26 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user self registration On 12/7/25 07:46, Christian Stalberg via Mailman-users wrote: > Spammers have been registering and not subscribing. I want to turn off > the user self registration at https://lists.ccalternatives.org/mailman3/ . > > I edited /etc/mailman3/settings.py adding ACCOUNT_ALLOW_REGISTRATION = > False and restarted the services, but the ' Sign Up' option remains. I > assume /etc/mailman3/settings.py is my active settings file. > > What am I doing wrong? Web searches may find reference to a django-allauth setting ACCOUNT_ALLOW_REGISTRATION, but this setting doesn't exist in current django-allauth The setting you want is ACCOUNT_ADAPTER = ‘django_mailman3.views.user_adapter.DisableSignupAdapter’ See https://docs.mailman3.org/en/latest/faq.html#how-to-disable-signup or https://docs.mailman3.org/projects/mailman-web/en/latest/settings.html#mail… -- 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/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to csa(a)web-analysts.net

10 months, 1 week

[MM3-users] Re: Messages disappearing into hole??

by Mark Sapiro

On 8/30/20 6:15 AM, Ruth Ivimey-Cook wrote: > > I looked around the interface and decided to set up the sender as a > non-member, as that appeared to permit them to be "special" and outside > of the normal access rules for the list. Before I did that I could send > a message from this sender and that would be sent to me as list owner > for moderation, so both incoming (from my mailserver) and outgoing (to > it) can be completed. > > However, with a non-member who is auto-accepted the message is passed > from my mailserver to mailman and then disappears. I cannot find > anything in the logs to indicate what happened next. I have tried > setting the default non-member policy to both 'hold' and 'default' with > no change in that behaviour. The logs for the mailserver show the > message being sent to mailman; mailman's "smtp.log" shows an LMTP > message being received ok, and then nothing. > > Any ideas how to find out what is going on? I can share config if that > helps but not sure what would be useful. First, this is a bad way to configure an announce list because anyone can post by spoofing the authorized posting address. The better way is to set a list moderator password and post using an Approved: <password> header or pseudo header. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs…> for details. As far as the disappearing message is concerned, it's hard to say. What is the non-member's moderation action? Unless it is 'list default' setting the list's default non-member policy has no effect. Also, if the non-member's address or a pattern matching it is in accept_these_nonmembers, that takes precedence over whatever the non-member's moderation action is. One guess about the disappearing message is content filtering may be removing all the message. What is the setting for Filter Action? > As a side-issue, at one point I added a regex matching the sender > address to the acceptable members list, but find that I cannot now > delete it (using postorius): If I delete the field and Save, it returns > on page refresh. There is an issue with Postorius. You can't empty these settings. If you clear the box or or have it contain only whitespace, Postorius won't change the prior setting. In order to remove the only entry in Postorius, you have to replace it with a bogus entry or you can remove it with `mailman shell`. I've just filed <https://gitlab.com/mailman/postorius/-/issues/444> for this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

[MM3-users] Re: archiving problem & updates

by Mark Sapiro

On 2/19/21 7:19 AM, Christian Stalberg via Mailman-users wrote: > I see two messages waiting to be archived. Below is excerpt from the > logfile: > > Feb 10 13:40:49 2021 (974) held message approved, message-id: > <CAGrL7FsaX8EG9pMUZreJrQt1xkEyR3ySuw2-xn3m443O0N3j1A(a)mail.gmail.com> > [10/Feb/2021:13:40:49 +0000] "POST > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held/5 HTTP/1.1" 204 0 "-" "GNU > Mailman REST client v3.3.1" > [10/Feb/2021:13:40:49 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=0&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > [10/Feb/2021:13:40:49 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=10&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > [10/Feb/2021:13:40:50 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/requests HTTP/1.1" 200 90 "-" "GNU > Mailman REST client v3.3.1" > [10/Feb/2021:13:40:50 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=50&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > Feb 10 13:40:55 2021 (846) HyperKitty failure on > https://lists.ccalternatives.org/archives/api/mailman/archive: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M > </html>^M > (413) > Feb 10 13:40:55 2021 (846) Exception in the HyperKitty archiver: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M > </html>^M > Feb 10 13:40:55 2021 (846) Traceback (most recent call last): > File > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ > _.py", line 154, in _archive_message > url = self._send_message(mlist, msg) > File > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ > _.py", line 210, in _send_message > raise ValueError(result.text) > ValueError: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M The issue is that one of the messages in var/archives/hyperkitty/spool/ is throwing this exception and that effectively stops archiving of new messages. I'm not sure what causes Request Entity Too Large, but I suspect it is a very large message body. You can examine the messages in var/archives/hyperkitty/spool/ with Mailman's `bin/mailman qfile` command, but I suspect the problem is caused by the largest of the files. You can just move it aside, and that should allow archiving to resume. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 01:31 PM, Darren Smith wrote: > So it appears that there was a message sent to one of our mailing lists > that was put into the held message queue. However, when attempting to go to > the message to do the moderation, the web page returns and Error 500. > > Looking in the mailman log, I found this: > > Apr 23 14:21:02 2018 (17878) REST request handler error: > Traceback (most recent call last): > File "/opt/mailman3/conda/lib/python3.6/wsgiref/handlers.py", line 137, > in run > self.result = application(self.environ, self.start_response) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/transac > tion.py", line 50, in wrapper > rtn = function(*args, **kws) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/wsgiapp.py" > , line 214, in __call__ > return super().__call__(environ, start_response) > File "/opt/mailman3/conda/lib/python3.6/site-packages/falcon/api.py", > line 227 , in __call__ > responder(req, resp, **params) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 167, in on_get > resource = self._make_collection(request) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in _make_collection > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in <listcomp> > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 100, in _make_resource > make_header(decode_header(resource['subject']))) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 174, in > make_he ader > h.append(s, charset) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 295, in > append > s = s.decode(input_charset, errors) > UnicodeDecodeError: 'gb2312' codec can't decode byte 0x87 in position 2: > illegal multibyte sequence > > It LOOKS as if there might be a character in the email somewhere - possibly > in the subject or sender fields? - that is somehow unexpected. It appears that the Subject: header is RFC 2047 encoded and there is an encoded word with charset gb2312 that contains an invalid encoding. The message is apparently defective, but this kind of defect shouldn't cause a 500 error. I can't tell for sure from the traceback if this is Postorius or some other application accessing the REST api. Is it Postorius or something else? > I am attempting to find the held message - can someone point me where I can > go to see the message so that I can see what might be causing the problem? It's in Mailman's database in the 'message' table. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 5 months

Search results for query "sapiro"