Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> 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 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.
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 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.ht...> 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.
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.
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.
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.
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.
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.
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?)
[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.
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.
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