After making the above changes I talked about, mail transfer seems to work as expected, although I noticed users signing up don't get their confirmation emails delivered for some reason, saw this in the logs;
(1632818) <[email protected]> delivery to [email protected] failed with code 550, b'5.1.1 < [email protected]>: Recipient address rejected: User unknown in local recipient table' What would be the best way to ensure that these get delivered? Thank you for all your help, I really appreciate it. I think I went into this rabbit hole because of this particular issue above, and I thought something was wrong, mail was always sent to the mailman user and I thought that was odd, but now I know that's expected as that's the user that Mailman runs on. -- Ibiam Chihurumnaya [email protected] On Wed, Feb 4, 2026 at 10:15 PM Chihurumnaya Ibiam < [email protected]> wrote: > On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <[email protected]> > wrote: > >> 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 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.html#postfix> > 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 >> > <[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. >> > > 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 > [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/WQ6ITZG4PA56KNJJOUSYNUOCRXI2PVYG/ This message sent to [email protected]
