On Wed, Feb 4, 2026 at 4:21 PM Stephen J. Turnbull <[email protected]>
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=<
> [email protected]>,
> > 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 <[email protected]> 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.
> > [email protected] (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
> [email protected] 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
> [email protected] from
>
> sugar-devel-confirm+edc5e1df6d76fe7955475023efd08101ed2ed...@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
> [email protected] 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 <
[email protected]>: Relay access denied; from=<
[email protected]> to=<[email protected]> 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
[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/RQZYS62ATAKIBP3LN44QYXVANP7JDTXC/
This message sent to [email protected]
