Chihurumnaya Ibiam via Mailman-users writes: > On Wed, Feb 4, 2026 at 4:21?PM Stephen J. Turnbull <[email protected]> > 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 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. 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'. > Yes, that's how it's configured. Sure, but something is wrong with the configuration, and it might not be just one thing. > 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. 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. > 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? > [mta] lmtp_host: *.*.*.* That should be 127.0.0.1. Mailman should not be listening on network interfaces other than the loopback (localhost). > [mta] lmtp_port: 24 This can't work if Dovecot is configured to use the same port, as is Dovecot's default. > [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. > I used the virtualenv method. Good. That's the preferred method, as distro packages generally lag substantially, often a year or more. > 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. > 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 > <[email protected]>: Relay access denied; > from=<[email protected]> to=<[email protected]> > 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. > 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) 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 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 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. >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 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 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. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ 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/CRFLAWEACFWKGH5EUSXYNBQGC7OHKPGX/ This message sent to [email protected]
