OK chalk another one up to a python newbie...
commit() was the magic sauce that we needed. The error 500 is no longer happening on that mailing list.
We have three different lists so far that have gotten into this state, and we are going to work on the other two to make sure that this all works.
FYI if this is fixed somehow in a later release (later than 3.1.0) we are working on migrating to the latest mailman code.
-Darren
On Mon, Apr 23, 2018 at 4:20 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 04/23/2018 02:59 PM, Darren Smith wrote:
Well, using the mailman shell we were able to find the request that was causing the problem - it was apparently a spam message that had some chinese characters in it.
I am trying to duplicate this issue in a test environment. I can create a message with an invalid RFC 2047 encoded subject, i.e.,
Subject: =?gb2312?Q?=ff=fe=de=21=a2?=
and send it to a list where it gets held, but I don't get a 500 in postorius and I see the held message with a raw (not decoded) header.
I think there were some recent changes that affect this. I'll look some more.
We used the shell to delete the held request...
And postorius is still giving me an error 500.
If I'm not mistaken the held messages are kept in .pck files - do you know if when postorius asks for held messages through the API, does mailman go to the database or to the .pck? I would actually suspect the latter, or removing the request should have fixed the problem.
They were held in .pck files in Mailman 2.1, but not in Mailman 3. They should just be in the database and deleting them via mailman shell should delete them as long as you quit the shell or commit().
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/