Marvin Gülker writes:
Am 10. Dezember 2019 um 17:09 Uhr +0900 schrieb Stephen J. Turnbull:
You're the "it's 2019, let's use SMTP UTF8 everywhere" guy, right?
No, I'm not that guy.
I'm sorry about that. I knew I didn't know for sure, but not being able to get at the moderation queue seemed urgent enough to be worth the chance of being wrong.
I have not used it, but it turns out that it is enabled by default. I can turn it off and see if that makes any difference in the future. Testing with telnet, Postfix indeed announced "250 SMTPUTF8" on EHLO.
If you're right about the umlaut being the trigger, the first thing I'd look at is a feature-negotiation problem in the MTA delivering to Mailman. I'm pretty sure our LMTP does not offer the SMTP UTF8 feature.
In that case the problem should go away with disabling SMTPUTF8, I suppose?
Well, since it's predicated on a bug in Postfix, I wouldn't bet on it, especially since Postfix probably dominates Mailman 3 installations. But it's cheap to test, and since you don't explicitly want SMTP UTF8 at this point, little harm in turning it off. *If* there is a bug, that will prevent the problem in the future, but it wouldn't fix the problem in the held messages queue.
I would guess this is in the shunt queue. If there's only one file there, you can just delete it.
This was a bad guess. I'm not sure why it isn't in the shunt queue (it shouldn't have been able to escape into the main rule chains with that bad breakage in the header), but Mailman doesn't try to moderate shunted messages, that's the whole point of the shunt queue -- they're out of the way.
There was a whole bunch of files in that directory. I've taken a look several of them, and as they were all spam, I've taken the liberty to delete them all (this list is so low volume that I know all the senders personally anyway).
A tiny bit of good came of it, at least.
However, even after restarting mailman, the 500 error persists when visiting the held messages page in postorius.
I've also looked into all the other queue directories, they were all empty.
I guess it's in the MessageStore, then, which is by default in /var/tmp/mailman/messages/. (Defined in schema.cfg.) I guess it's a standard qfile that you can examine with "mailman qfiles /path/to/file". (I've never actually looked at a "raw" held message file in Mailman 3, haven't had a failure of this type.) If not, you can unpickle it with Python (if that makes no sense to you, ask; I'm running out of steam and need sleep).
Assuming you're right about your name being the trigger, U+FFFD REPLACEMENT CHARACTER is not in your name.
I'm starting to wonder about this. It's still possible, but if you don't deliberately use SMTP UTF8 then your mail client probably doesn't either, and equally possibly it's a different message causing the problem (something spammy).