On Thu, Feb 5, 2026 at 4:35 AM Stephen J. Turnbull <[email protected]> wrote:
> Chihurumnaya Ibiam via Mailman-users writes: > > On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <[email protected]> > > wrote: > > > > > Chihurumnaya Ibiam via Mailman-users writes: > > > > > systemctl shows the service is still active, > > > The fact that there is a systemd service implies that dovecot > > > will be running by default unless it is disabled. > > There's no service file for dovecot, I didn't create one. > > As far as I know, if systemd knows about a service, there's a control > file somewhere. systemd will create a unit from an rc file in > /etc/rcN.d if there is one. (I was perfectly happy with SysV init, > but I guess systemd makes hyperscalars happy.) I don't know if > "systemctl disable" works on those. > I don't plan on shutting down the host anytime soon, so hopefully, I remember to the next time it restarts. I started out with Fedora the year before it adopted systemd, so I never really knew about SysV init until today. > > I configured mailbox transport because that was how I was able to get > lmtp > > to run on port 24, > > Something like that would be necessary for Dovecot, which I believe > can be configured to automatically create a mailbox for any address. > It is not necessary for Mailman, which tells Postfix how to deliver to > Mailman lists in the postfix_lmtp table. You can find that in > /opt/mailman/mm/var/data, if you followed the virtualenv installation > to the letter. > Yes, postfix_lmtp table is set in transport_maps, virtual_mailbox_maps, relay_domains, local_recipient_maps. > > 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, although one thing I noticed in the logs was that other servers trying to connect to the host was rejected, they're trying to send logs to a mailing list, which should work just fine but then it seems they need to connect to this host. connect to weblate.sugarlabs.org[192.184.220.214]:25: Connection refused 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) I tried to fix this with check_client_access hash:/etc/postfix/client_access, which contains a wild card for the main domain and subdomains, which seems to have no effect. > I'm not sure this is why the confirmation mails are getting rejected, > but at a guess, for some classes of mail Postfix will first try the > whole address, and if that fails to route, it will remove the > extension (starting with "+"), and try again. Perhaps it does NOT do > that for the mailbox_transport. > > > there wasn't any service before that and the documentation > > < > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.html#postfix > > > > for setting up a mail server mentions postfix delivering > > by default over port 24. > > What it says is this: > > Postfix will deliver via LMTP over port 24 by default, however if > you are not running Mailman as root, you’ll need to change this to > a higher port number, as shown above. > Are you running Mailman as root? If so, stop it, change lmtp_port > back to 8024 in mailman.cfg, and stop and start Mailman to regenerate > the postfix_lmtp.db. There's no need for running as root unless you > have an MTA that is hard-coded to think that 24 is the one and only > lmtp port handed down from Mount Olympus. Postfix knows better. > 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? > > Furthermore, you should NOT run mailman as root if there's any > alternative. Mailman occasionally crashes for various reasons (I've > never seen it take Python down, but then, if there were an exploit, I > wouldn't), and is not securely authenticated (I mean, it's reasonably > secure, but it is just a password, and once you get in to Mailman > core, you're the superuser for Mailman) and if there *is* an exploit > and Mailman is running as root, you've got system root, too. > > Don't run Mailman as root. Please. > I haven't, I was never going to. > > > Disabling this means there's no lmtp to be used by postfix, except I'm > > missing something. > > Yes, you're missing something. Postfix is always able to speak LMTP, > and is very flexible about when to do so. If you followed the virtualenv > installation to the letter, you have > > transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp > > in main.cf (perhaps there's other maps there), and in that file you > have lines that end in "lmtp:[127.0.0.1]:24", which tell Postfix > "connect to IP address 127.0.0.1, port 24, and speak LMTP to that > connection." If you change lmtp_port to 8024 and restart Mailman as > suggested, all those lines will change to "lmtp:[127.0.0.1]:8024" and > Postfix will be happy to deliver to Mailman that way without being root. > After your comment about Postfix being an LMTP server, I understood this better. > > > I set the port number for lmtp to be 24, and that's what I used, I'm not > > sure if Mailman sets up lmtp itself, > > if it does then I'll have to remove the config for that. > > > > I've stopped dovecot after our conversation so it's no longer running, > the > > only way the port is open is through the > > config I set in postfix for mailbox_transport. > > That should get it working, except that with mailbox_transport set > there's a good chance that Mailman functions that use "+" extensions > will mess up as described above. Those functions are confirmations > and I think VERP probes. > > 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. > > There's just one active user, which is me, and I also have root access. > > I setup authentication for postfix because I'm used to setting it up > that > > way, this was a force of habit. > > I assumed postfix would run just fine if I set postfix up the way I > usually > > set it up. > > It might. But "Internet Mail" is another name for Dante's Third Circle > of Hell. (You must have committed a horrible felony to be sentenced > to administer an Internet mail host. :-D That's just a joke, it > sounds to me like your "usual setup" is quite solid and secure.) > Anyway, any deviation from the setup described in virtualenv.html is a > chance for everything to go wrong. "What I usually do" is just not > deep enough knowledge if you're working with a new mail application > with complex routing needs. > 😅😅 Funniest thing I've read today. I agree with your last sentence, needed to be reminded of that. > > > > 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. > > postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP > localhost:postgresql (LISTEN) > > postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP > localhost:postgresql (LISTEN) > > These are PostgreSQL listening for database connections. > > > python3 1592924 mailman 22u IPv6 177685051 0t0 TCP > localhost:48638->localhost:postgresql (ESTABLISHED) > > This is Mailman talking to Postfix. > > postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP > localhost:postgresql->localhost:48498 (ESTABLISHED) > > postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP > localhost:36787->localhost:36787 > > + 21 more copies of the above, differing only in the PID. Don't know > what's going on with those, not a PostgreSQL wizard. I probably > should have specified TCP in the lsof command, UDP applications are > either trivial or they are black magic. > > It appears that *nothing* is listening on or connected to port 24. > I'm not sure how that works. I'm guessing that when mail was getting > to Mailman, Mailman had opened port 24 and Dovecot was cut out of the > loop (maybe check logs for Dovecot complaining it couldn't bind to > port 24?) > The logs don't show Dovecot complaining about binding to port 24, the only thing. This is one that's consistent with Dovecot in the logs; 157322 Feb 4 12:27:02 lists postfix/cleanup[1593312]: AC7381A8978: message-id=<[email protected]> 157323 Feb 4 12:27:02 lists postfix/bounce[1587396]: A26F71A8977: sender non-delivery notification: AC7381A8978 157324 Feb 4 12:27:02 lists postfix/qmgr[1593314]: AC7381A8978: from=<>, size=3129, nrcpt=1 (queue active) 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 157327 Feb 4 12:27:02 lists postfix/qmgr[1593314]: A26F71A8977: removed 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)) 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. > > > > > [mta] lmtp_host: *.*.*.* > > > > > > That should be 127.0.0.1. Mailman should not be listening on network > > > interfaces other than the loopback (localhost). > > > > Yes, it is. > > OK > > > > > [mta] lmtp_port: 24 > > > > > > This can't work if Dovecot is configured to use the same port, as is > > > Dovecot's default. > > > I've stopped the service. > > OK > > > > > [mta] outgoing: mailman.mta.deliver.deliver > > > > [mta] smtp_host: 127.0.0.1 > > > > [mta] smtp_port: 25 > > > > > > Those are normal. > > > > > > > [mta] smtp_pass: ************** > > > > [mta] smtp_user: mailman > > > > > > This is going to cause Mailman to try to authenticate to Postfix. > > > That's OK if it's what you want and Postfix / saslauthd has been > > > properly configured to accept Mailman's credentials. Otherwise, > > > they must be left empty to disable authentication. > > > Okay. > > > > > The Message-ID being the way it is doesn't seem like a > > > > configuration issue, if it is then how do I look into it? > > > > > > Probably you don't have the full hostname in Postfix's myorigin or > > > myhostname parameter. > > > > I do have the full hostname there, I also have it in /etc/mailname. > > I don't understand it then. Perhaps the mail composition client is > providing the Message-ID. > Could be, doesn't seem to be an issue at the moment so I won't worry about it. > > > > If not, I would guess that's a spammer who is somehow spoofing > > > the PTR record. > > > The log entry before that warned of the same, they're definitely a > spammer. > > Relay access is denied though, so no mails are going through. > > OK. > > > No, I mean smtps. > > Same problem except the port that Mailman is *not* using is 465. > Yes, earlier when I set it up I had set the port for Mailman to use as 465. > > > > I don't think permit_auth_destination does what you think it does. > > > Here's the Postfix doc: > > > > > > permit_auth_destination > > > Permit the request when one of the following is true: > > > > > > - Postfix is a mail forwarder: the resolved RCPT TO domain > > > matches $relay_domains or a subdomain thereof, and the address > > > contains no sender-specified routing (user@elsewhere@domain), > > > - Postfix is the final destination: the resolved RCPT TO domain > > > matches $mydestination, $inet_interfaces, $proxy_interfaces, > > > $virtual_alias_domains, or $virtual_mailbox_domains, and the > > > address contains no sender-specified routing > > > (user@elsewhere@domain). > > > > > > > I did read the documentation before adding it, I definitely > misunderstood > > what it meant, and after looking at the old > > documentation, it makes sense not to add it. > > > > Could you help me understand what the above means? > > I gotta run now, I'll come back to it later. You're probably asleep, > anyway. :-) > > -- > 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/4CXNPDR33IJNVRUA52G2KGQCS4CN7ISN/ This message sent to [email protected]
