Dear Mark, Dear all,
(Asterisk makes a difference, see at the bottom)??? I didn't see what.
Sorry, my bad. While chasing the issue, I had thought I had seen a difference but can't reproduce it anymore. Then I forgot to remove the pointer.
I'm running a fresh package installation from Debian Bullseye with certificates from Certbot with nginx, so Certbot may have messed with my nginx config, but even that seems to be OK: Yes, Certbot has inserted http->https redirection, but I'd expect that a https base_url and ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https" circumvents that.
It should.
Note that your primary resource for help with issue with Debian packages should be Debian.
The state of the Debian Bullseye packages suggest a certain feeling of priority on that matter ☹ If I can't get this going "soon", I'll wipe the entire server, install a fresh Bullseye and install mailman3 through pip. Out of bad experience, I'd like to avoid mixing software lifecycle managers, but it seems to be the lesser evil.
To provide all possible information, I'm also adding the nginx log that seems to correspond to that request (no other requests at that time, give or take five minutes): Yes, everything yields 403 response codes.
[.] - - [19/Jan/2022:22:43:27 +0000] "GET /hyperkitty/api/mailman/urls?mlist=demo%40lists.pro-digi-par.de&key=[.] HTTP/1.1" 403 175 "-" "python-requests/2.25.1"
The issue here is accessing the hyperkitty API. The base URL for these accesses is configured in mailman-hyperkitty.cfg. From what I see here, that is something like
http(s)://host.example.com/hyperkitty/If you appendapi/to that base URL and go there in a web browser do you get a page of documentation of the HyperKitty API? If so, then figure out why it works from a web browser and not when Mailman core does it. If you get the 403, figure out why. This is probably an nginx issue.
Seems like an nginx issue indeed. However, I'm an apache guy, trying to re-educate myself on nginx.
OK, here's the result of changing mailman-hyperkitty.cfg from http(s)://host.example.com/hyperkitty/ to http(s)://host.example.com/hyperkitty/api/
Yes, if I open things from the web browser, I do get the HyperKitty API doc. With what follows below, I guess it's a timeout: Processing a message takes longer than rendering a HTML document.
Jan 22 20:26:27 2022 (149435) ACCEPT: <AM0PR04MB4785365CA1BB735884E149CEC25C9@AM0PR04MB4785.eurprd04.prod.outlook.com> Jan 22 20:26:28 2022 (149439) HyperKitty failure on https://[FQDN]/hyperkitty/api/api/mailman/urls:
(what follows is a lengthy HTML document, essentially a 404 not found message).
That corresponds to the nginx logfiles:
access.log: [IP4] - - [22/Jan/2022:20:26:29 +0000] "POST /hyperkitty/api/api/mailman/archive?key=6xpENHLEHQ0kD53vXt5RpKzPDOsKbcN9 HTTP/1.1" 404 1342 "-" "python-requests/2.25.1" 9
And error.log: 2022/01/22 20:26:29 [error] 128720#128720: *4375 readv() failed (104: Connection reset by peer) while reading upstream, client: [IP4], server: [FQDN], request: "POST /hyperkitty/api/api/mailman/archive?key=[key] HTTP/1.1", upstream: "uwsgi://unix:/run/mailman3-web/uwsgi.sock:", host: "[FQDN]"
So it all seems consistent in a way, except that error.log suggests that this could be a timeout.
Question: What happens if nginx issues a 403 "Forbidden" in that spot? - Does the mailman system as a whole (whichever subsystem is responsible...) _assume_ that there is an error with MAILMAN_ARCHIVER_FROM (as suggested in the mailman3 logfile) - so other possible reasons for 403 are theoretically possible, or are other possible reasons for 403 explicitly (e.g. a timeout) ruled out somewhere, somehow?
Following that, I've set the timeout in nginx to five minutes, but it doesn't change anything.
I'm sorry that I can't contribute any news. I guess I'll start over, using pip and virtualenv for installation.
Thank you for your help!