On Fri, Feb 6, 2026 at 7:57 AM Stephen J. Turnbull <steve@turnbull.jp> wrote:
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.
That did, showed it was removed from /etc/systemd/system/multi-user.target.wants/.
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.
No, I don't have virtual_mailbox_domains set, I didn't need to.
Yes, postfix_lmtp isn't in relay_domains, that was my fault, it's 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.
Now I understand why it's a problem.
Going by your earlier assumption that perhaps the same thing doesn't happen for mailbox_transport, how would I use that as a fallback in such cases?
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, weblate isn't supposed to receive email. It runs a service that sends emails just like MM3. Yes, postfix is also the MTA at weblate.
I can include subdomains, but I don't see a reason for doing so at the moment.
One thing I had done to remediate the error - which didn't do anything from the logs - is add check_client_access hash:/etc/postfix/client_access in smtpd_client_restrictions.
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.
Me configuring lmtp_port to 24 earlier did interfere with Mailman because I had dovecot running on the same port at the time, after disabling dovecot and commenting out lmtp_port, I noticed Mailman listening on 8024, postfix_lmtp also showed this.
I don't know why Postorious and Hyperkitty didn't show up at the time, but I just ran lsof and this is the output; $ lsof -i TCP@127.0.0.1 -i 'TCP@[::1]' | grep 24 python3 1983955 mailman 26u IPv4 181237054 0t0 TCP localhost:8024 (LISTEN) uwsgi 1985531 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) uwsgi 1985547 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) uwsgi 1985548 mailman 9u IPv4 181247623 0t0 TCP localhost:8000 (LISTEN) mailman-w 1985554 mailman 44u IPv6 185803776 0t0 TCP localhost:60244->localhost:postgresql (ESTABLISHED) postgres 2458591 postgres 9u IPv6 185580185 0t0 TCP localhost:postgresql->localhost:43102 (ESTABLISHED) postgres 2458595 postgres 9u IPv6 185581026 0t0 TCP localhost:postgresql->localhost:43140 (ESTABLISHED) postgres 2458607 postgres 9u IPv6 185579124 0t0 TCP localhost:postgresql->localhost:43234 (ESTABLISHED) postgres 2482767 postgres 9u IPv6 185805780 0t0 TCP localhost:postgresql->localhost:60244 (ESTABLISHED) postgres 2482831 postgres 9u IPv6 185807057 0t0 TCP localhost:postgresql->localhost:56188 (ESTABLISHED) postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN)
Which shows the expected ports being listened on, I'll assume the issue with Postorious was probably because the mailmanweb service stopped at some point as I tried to restart it and that was basically running uwsgi, it didn't run and when I looked further I noticed uwsgi was running so there was no need to do this, as that's what it was trying to do.
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.)
It was to a sugarlabs.org address, I've been able to receive mail owner messages to my inbox, I configured a gmail address as the admin for Mailman suite, which indicates that mail delivery works as expected.
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".
I agree, I've explained a probable cause above. They now show up in the lsof output.
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;
mailbox_transport currently doesn't have a value.
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:
Yes, this probably because I haven't properly configured user lookup on dovecot.
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.
At the moment, I've disabled the service and have no configurations for it. I commented out my earlier configs before disabling it.
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.
All the configurations that are supposed to contain the FQDN does; mydestination, mydomain, myhostname.
Am I missing any?
Yes, earlier when I set it up I had set the port for Mailman to use as
OK.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
--
Ibiam Chihurumnaya ibiamchihurumnaya@gmail.com