On Fri, Feb 6, 2026 at 7:57 AM Stephen J. Turnbull <[email protected]> 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= > > <[email protected]>, 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 [email protected] -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 <[email protected]> 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=<[email protected]>, 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 <[email protected]> User doesn't exist: > > [email protected] (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 > 465. > > 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 [email protected] _______________________________________________ Mailman-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/[email protected]/message/3FPZQJHYXDYVJC7CGZNSZDEHXY7IWTPO/ This message sent to [email protected]
