On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
Not uninstalled it, commented out from postfix master.cf the line; # dovecot unix - - y - - lmtp [...] systemctl shows the service is still active,
Life will be a lot easier if you shut that service down, and fix whatever configuration in Postfix that's needed to talk directly to Mailman (probably nothing since that configuration is in postfix_lmtp, and if you put that table in transport_maps it's highest priority so should work). You don't need a mailbox transport since you have no local users who should be getting mail on the Mailman host, except maybe root.
I configured mailbox transport because that was how I was able to get lmtp to run on port 24, 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.
Disabling this means there's no lmtp to be used by postfix, except I'm missing something.
I didn't end the service itself, I assumed the line above I
commented out would prevent the dovecot service from running under postfix.
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.
If Mailman and Dovecot are running, each will try to open a socket with parameters IP address and port number. The IP address is 127.0.0.1, and the port number of Mailman is 24 according to the "mailman info" output you provided. I don't know what the port number for Dovecot is, but its default is also 24. If so, the one that opens that listening socket first will win, and the other is going to be unable to open its socket. I'm not sure if Mailman can even open a privileged port (number less than 1024), since it should be running as 'mailman', not '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.
Yes, that's how it's configured.
Sure, but something is wrong with the configuration, and it might not be just one thing.
I agree.
I'll have to look at user authentication in lmtp then, because the
earlier passwd-file arguments seems to have no effect, I probably didn't configure it properly.
I don't understand why you have authentication for Mailman in any case. From what you wrote before, there should only be one active user on that host, and it's you, either as root or an ordinary user with sudo. If anybody else can get in there, you have bigger problems than connecting to ports 24 and 25.
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 may make sense for Postfix to authenticate to servers on other hosts if it is purely internal to your network and does not talk to the Internet. Similarly, it may make sense for Postfix to require authentication for incoming messages if all your posters are expected to send mail only from internal hosts. But if your Postfix talks to hosts outside of your network, authentication should be off, because almost certainly you have no way to configure it on the remote hosts.
This makes sense.
The listener on 24 is lmtp via postfix, the port opened after I added this line to postfix; mailbox_transport = lmtp:inet:localhost:24
Dovecot also has lmtp as a running protocol, but that didn't open the port.
This doesn't make sense. Mailman and Dovecot are LMTP servers, both *must* open ports in order to receive connections. On the other hand, Postfix is an LMTP client, it opens a connection to the port only when it is delivering a message.
What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592924 mailman 22u IPv6 177685051 0t0 TCP localhost:48638->localhost:postgresql (ESTABLISHED) postgres 1592939 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592941 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592943 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN) postgres 1592953 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592954 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP localhost:postgresql->localhost:48498 (ESTABLISHED) postgres 1592955 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592957 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592959 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592963 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592966 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592970 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1592974 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1607364 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 1607478 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN) postgres 3568035 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568037 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568038 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568039 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568040 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568041 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787 postgres 3568042 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787
The output shows mailman is indeed listening on the port, I now know Mailman is an LMTP server, I didn't know that before so there wasn't any need for me to do what I'd done.
[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.
[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.
[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.
I used the virtualenv method.
Good. That's the preferred method, as distro packages generally lag substantially, often a year or more.
Yep, that's why I used it.
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.
Yes, it points to a configuration problem, the recipient_delimeter for postfix is set to +
OK, then I don't know why mail is looping in that way.
How do I disable outgoing authentication? I don't remember enabling it.
As mentioned above, you leave smtp_user and smtp_pass empty.
I also just noticed this in the logs;
NOQUEUE: reject: RCPT from unknown[141.98.11.11]: 554 5.7.1 <allenmccathyesq@gmail.com>: Relay access denied; from=<marketing@lists.sugarlabs.org> to=<allenmccathyesq@gmail.com> proto=ESMTP helo=<LS57X2JsBM>
Reverse lookup for 141.98.11.11 returns axon-stall.riddlecamera.net, but that doesn't roundtrip (the lookup on that domain goes to a different customer address in Google Cloud). The IP address appears to be in Lithuania. Is any of that expected? 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.
The IP for the host that mailman is on does have a valid PTR record.
I turned submission back on, totally forgot it was used that way.
What do you mean by "submission"? This entry in Postfix's master.cf? submission inet n - y - - smtpd (along with any -o options you are using)
No, I mean smtps.
Someone uses that alias to send out emails, hence why I need it. Might have to disable smtps entirely as I just checked the old config and it's not used like I thought.
If so, Mailman isn't going to use it, because Postfix's submission service is an smtpd that listens on port 587 (unless you've changed that in /etc/services). But you've specified that Mailman talk to Postfix via port 25.
I had changed it, and I didn't do it for postfix.
I also added permit_auth_destination to smtpd_relay_restrictions for the Relay access denied issue.
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 thought this host is dedicated to Mailman? If so, you just want permit_mynetworks in relay restrictions, and mynetworks_style = host. This does what you want because Mailman is *not* an MTA. As far as Postfix is concerned, delivery to Mailman is a *local* delivery (LMTP, yes?), and the messages being delivered to subscribers are *new* messages being sent by a *local* user. It is not a relay as far as Postfix can tell. And $relay_domains should be empty, you don't want anything else permitted.
Yes, this host is dedicated to Mailman.
These are listed in smtpd_relay_restrictions; permit_mynetworks permit_sasl_authenticated reject_unauth_destination reject_unknown_recipient_domain reject_non_fqdn_recipient reject_unlisted_recipient
From Postfix docs: smtpd_relay_restrictions (default: permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination)
which is mostly what you want on a dedicated Mailman host. In fact, once I know things are working I would normally delete permit_sasl_authenticated, since I don't want third parties coming in through submission and relaying directly out through Postfix without going through the malware checking done by the milters that should be attached to Postfix's smtp service. I would also change defer_unauth_destination to either reject_unauth_destination or reject, since I don't want relay attempts to be retried.
I'll remove permit_sasl_authenticated, as my assumption no longer holds. That's why I disabled it earlier because I remembered it was never used for delivery, but then I remembered there was a conversation about the marketing alias so I assumed it was used for sending out emails.
I usually set postfix user authentication through saslauthd, which is configured to use /etc/shadow for user lookup.
But there shouldn't be any users with passwords on that host except you. You can set one and authenticate the 'mailman' user if you want, but there's little point to it. Furthermore, any system users that might send mail (eg, cron) won't be able to do so since there's typically no provision for them to do the SASL AUTH dance.
I did set one for the mailman user, seems I'll have to remove it and disable saslauthd too.
I was just reminded that it's needed though, the log entry above reminded me of that.
Well, there's always the alternative of doing what I suggested, which is to reconfigure the system to be as simple as possible, and add complexity only when the simple configuration is working.
Yes, this is where I'm headed as that's what I need.
Steve
-- 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