On Wed, Feb 4, 2026 at 4:21 PM Stephen J. Turnbull <steve@turnbull.jp> wrote:
Chihurumnaya Ibiam via Mailman-users writes:
I've removed this [Dovecot?],
You mean you uninstalled it? If not, where did you remove it from?
Not uninstalled it, commented out from postfix master.cf the line; # dovecot unix - - y - - lmtp
and it does seem like dovecot still runs when mailman hands mail to lmtp,
I assume by "seem like dovecot still runs" you're referring to the log entry below. If not, what evidence are you seeing that dovecot is running?
systemctl shows the service is still active, I didn't end the service itself, I assumed the line above I commented out would prevent the dovecot service from running under postfix.
I realize now that it won't stop the service because I have lmtp set as the mailbox transport and it's configuration seems to be handled by dovecot.
but I don't see any authentication issues, the logs show this;
lists postfix/lmtp[1376243]: 458381A894B: to=< mailman@lists.sugarlabs.org>, orig_to=<mailman>, relay=localhost[127.0.0.1]:24, delay=0.03,
This says the postfix is sending to 127.0.0.1 over port 24. This is probably Mailman, since LMTP is the only way for Postfix to send mail to Mailman, and Mailman is trying to process mail according to your logs.
Yes, that's how it's configured.
delays=0.02/0/0.01/0, dsn=5.1.1, status=bounced (host localhost[127.0.0.1] said: 550 5.1.1 <mailman@lists.sugarlabs.org> User doesn't exist:
This means that whatever is listening on port 24 doesn't know about the 'mailman' user. Mailman only knows about lists in the postfix_lmtp file (that is compiled to postfix_lmtp.db).
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.
mailman@lists.sugarlabs.org (in reply to RCPT TO command))
The user does exist, which is the weird part.
Not really. Postfix knows how to deliver to local users in file-based mailboxes, but it's delivering via LMTP or SMTP to port 24. I suppose Dovecot does as well, but if it's been uninstalled by a package manager, the running instance will have been stopped and there won't be anything to run. Most likely the listener on 24 is Mailman, which does *not* know how to deliver to local users at all.
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.
I'm starting mailman via systemd, and the mailman config was passed through an environment variable - MAILMAN_CONFIG_FILE -.
You should run "mailman -C /etc/mailman3/mailman.cfg conf -s mta", which will tell you the basic information about Mailman's handling of external mail both incoming and outgoing.
[mta] configuration: python:mailman.config.postfix [mta] delivery_retry_period: 5d [mta] incoming: mailman.mta.postfix.LMTP [mta] lmtp_host: *.*.*.* [mta] lmtp_port: 24 [mta] max_autoresponses_per_day: 10 [mta] max_delivery_threads: 0 [mta] max_recipients: 10 [mta] max_sessions_per_connection: 0 [mta] outgoing: mailman.mta.deliver.deliver [mta] remove_dkim_headers: no [mta] smtp_host: 127.0.0.1 [mta] smtp_pass: ************** [mta] smtp_port: 25 [mta] smtp_secure_mode: smtp [mta] smtp_user: mailman [mta] smtp_verify_cert: yes [mta] smtp_verify_hostname: yes [mta] verp_confirm_format: $address+$cookie [mta] verp_confirm_regexp: ^(.*<)?(?P<addr>[^+]+?)\+(?P<cookie>[^@]+)@.*$ [mta] verp_confirmations: yes [mta] verp_delimiter: + [mta] verp_delivery_interval: 1 [mta] verp_format: ${bounces}+${local}=${domain} [mta] verp_personalized_deliveries: yes [mta] verp_probe_format: $bounces+$token@$domain [mta] verp_probe_regexp: ^(?P<bounces>[^+]+?)\+(?P<token>[^@]+)@.*$ [mta] verp_probes: no [mta] verp_regexp: ^(?P<bounces>[^+]+?)\+(?P<local>[^=]+)=(?P<domain>[^@]+)@.*$
This is as expected, as I set some of these myself.
The installation instructions <https://docs.mailman3.org/en/latest/install/install.html> don't say anything about mailman listening on a port
That's implied by using LMTP which is a network protocol. Mailman 3 defaults to using 8024 for that port. If you're using Postfix, that port will be in the postfix_lmtp file, so it's configured automatically. I forget how other MTAs get information about the Mailman host and port.
Which installation method did you use? Your package manager, or virtualenv? If it's a package manager, who knows what it has configured.
I used the virtualenv method.
I've removed authentication and the only error in the log is the one I shared above, although there are some errors in mailman smtp logs;
1551 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> smtp to sugar-devel@lists.sugarlabs.org for 1 recips, completed in 0.009501457214355469 seconds
This seems to be the incoming message to Mailman, which Mailman accepted. The Message-ID (in <> angle brackets) is not of the recommended form. It should have the full domain (presumably lists.sugarlabs.org) to ensure global uniqueness.
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?
1552 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> post to sugar-devel@lists.sugarlabs.org from
sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2edb17@lists.sugarlabs.org , 1707 bytes, 1 failures
I'm not sure what's going on here, but I think there's a serious configuration problem because Mailman is sending confirmation codes (probably for subscriptions) back to the list.
What is your postfix setting for recipient_delimiter? That needs to be '+' or possibly '+-'. If it's '-', that will cause this kind of mail loop, I think.
Yes, it points to a configuration problem, the recipient_delimeter for postfix is set to +
1553 Jan 31 12:44:03 2026 (4128778) <176979064563.3611678.6370323034981829398@lists> delivery to sarthakkad2005@gmail.com failed with code 444, SMTP AUTH extension not supported by server.
The above 2 say that you're trying to send to 1 user at Gmail, but some server doesn't handle the AUTH extension. You need to disable outgoing authentication, unless you're delivering only to MTAs you control.
How do I disable outgoing authentication? I don't remember enabling it.
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>
I turned submission back on, totally forgot it was used that way.
I also added permit_auth_destination to smtpd_relay_restrictions for the Relay access denied issue.
Is there anything in the Postfix logs that indicated it tried to connect to gmail.com, and the message was rejected? I suspect that there won't be, and that the problem is that you have smtp_user and smtp_pass configured. Then Mailman will use those and the AUTH command to try to authenticate to your Postfix. That can be done, but you need to configure Postfix (not a system user and password) to accept the AUTH command. There may be a way to get Postfix to /etc/passwd to authenticate a user, but I don't know what it is.
I did configure smtp_user and smtp_pass, but I commented it out after I disabled submission earlier.
I usually set postfix user authentication through saslauthd, which is configured to use /etc/shadow for user lookup.
1554 Feb 02 06:57:21 2026 (4128778) while connecting to SMTP: 1555 Feb 02 06:59:37 2026 (664714) <176979064563.3611678.6370323034981829398@lists> low level smtp error: [Errno 110] Connection timed out
I'm not sure what's going on with the above two.
The rest of the messages follow the same pattern for different lists.
I'm using port 25 for smtp, I wasn't sure I'll need submission because I'd done that earlier and it didn't seem to change anything, does mailman need submission?
No. submission doesn't make sense for Mailman in most configurations (that is, all the configurations I've ever seen).
Agreed, which is why I removed it as it wasn't needed. I was just reminded that it's needed though, the log entry above reminded me of that.
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