Chihurumnaya Ibiam via Mailman-users writes:
About disabling dovecot:
I don't plan on shutting down the host anytime soon, so hopefully, I remember to the next time it restarts.
systemctl stop dovecot systemctl disable dovecot systemctl daemon-reload
should do the trick without rebooting the host.
Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps.
Do you have lists.sugarlabs.org in $virtual_mailbox_domains? As Mark points out, virtual mailboxes make life more complicated. Also, I don't think postfix_lmtp should be in $relay_domains (that table contains addresses which won't match domains being looked up). If anything it should be postfix_domains.
It's problematic for Mailman because that means that *all* local mail will be delivered to Mailman, which will reject it if it's not list-related.
I'm totally fine with this because that's why we setup the host,
I'm sorry, that was unclear. By "list-related", I meant that "the key Postfix is trying to match is an exact match for a key in the postfix_lmtp table". Because these are hash tables, it is Postfix's responsibility to strip "+extension" from the recipient address before presenting the stripped address to the table for matching -- the table can't do it.
Specifically, this applies to the confirmation and VERP cookies that may be attached to addresses for various reasons.
a mailing list, which should work just fine but then it seems they need to connect to this host.
165968 Feb 5 04:48:46 lists postfix/smtp[1941010]: connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused 165969 Feb 5 04:48:46 lists postfix/smtp[1941010]: B785D1A897F: to= <root@weblate.sugarlabs.org>, relay=none, delay=17323, delays=17323/0.02/0.33/0, dsn=4.4.1, status=deferred (connect to weblate.sugarlabs.org[2001:5a8:601:f::214]:25: Connection refused)
This is a problem at weblate.sugarlabs.org. Is it supposed to be receiving mail? I don't think that this is an authentication problem (SASL authentication takes place after connection), although if "weblate" expects authenticated TLS that might be the problem. So "lists" needs to be whitelisted (eg in $mynetworks) at weblate (I suppose Postfix is also the MTA at "weblate"?) If you have only the toplevel domain sugarlabs.org whitelisted, you may need to set another parameter to automatically include subdomains such as lists.sugarlabs.org.
No, I'm not running mailman as root, it's run as mailman. Seeing as that's the case, would I still need to change lmtp_port?
Yes, as far as I know. That's because by convention ports < 1024 can only bound to programs running as root (enforced by the kernel). I don't understand how Mailman is receiving mail configured to listen on port 24. This may have something to do with dovecot running.
However I really don't understand the lsof output, because you present logs that indicate that Mailman is processing mail for lists, but nothing was listening or connected on port 24. You also say Postorius and HyperKitty are running, but nothing showed up on port 8000, which is where they would be listening. Maybe I got the lsof options wrong, but it did find Postgres and Mailman's REST API.
It did get it working, I can see mail being sent in the logs. I sent a ping to the systems list just to get delivery confirmation and I'm yet to get a response.
I don't have an idea what's going on yet. The mail you see being sent in the logs, is that to a gmail address? Or is it a sugarlabs.org address? (Both of these seem to be problematic at the moment.)
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for connections to its REST API. These are HTTP listeners used by Postorius and HyperKitty (I guess those aren't running?), not for email.
Postorius and HyperKitty are running.
But they should show up as several Python applications running as mailman, listening or connected on port 8000. But they're not here. Try "lsof -i :8000 -i :24".
This is one that's consistent with Dovecot in the logs;
This is Postfix sending a non-delivery notification about A26F71A8977:
157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978
The <> tells us that this is the nondelivery notification referred to as AC7381A8978 so there's no return address to send to:
157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active)
postfix/local looks at mailbox_transport and sends it to lmtp, where dovecot is listening;
157325 Feb 4 12:27:02 lists postfix/local[1593315]: AC7381A8978: passing <mailman@lists.sugarlabs.org> to transport=lmtp 157326 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Connect from 127.0.0.1
Postfix is done with A26F71A8977, and pops it off the queue:
157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed
dovecot denies knowing about a local user named "mailman", rejecting it:
157328 Feb 4 12:27:02 lists postfix/lmtp[1593316]: AC7381A8978: to=<mailman@lists.sugarlabs.org>, relay=localhost[127.0.0.1]:24, delay=0.04, delays=0.02/0/0/0.01, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist: mailman@lists.sugarlabs.org (in reply to RCPT TO command))
dovecot says "I'm done here":
157329 Feb 4 12:27:02 lists dovecot: lmtp(1600482): Disconnect from 127.0.0.1: Logged out (state=READY)
Which we've established that mailman doesn't know how to deliver to local users.
So that's a bounce from dovecot. I don't know enough about dovecot or your configuration of dovecot to guess what happened.
Could be, doesn't seem to be an issue at the moment so I won't worry about it.
The Message-ID is syntactically well-formed. I'm worried about side effects from the hostname not being the FQDN in mail protocols. As long as all the configurations for Postfix use the FQDN (Postfix is smart enough to abbreviate when that's useful), there shouldn't be any problems like that.
Yes, earlier when I set it up I had set the port for Mailman to use as 465.
OK.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan