On Sun, Feb 1, 2026 at 7:25 AM Stephen J. Turnbull <[email protected]>
wrote:

> Ibiam Chihurumnaya via Mailman-users writes:
>
>  > I finished installing mailman3, setup lmtp and smtp for mail
>  > delivery and I followed the instructions on the mailman 3
>  > installation page.
>
> First, make sure that all the mail services are listening on the same
> protocol for localhost (IPv4 or IPv6), as Mark says in his reply.
>
> Is this a separate host (hardware, VM, or container) that handles ONLY
> mailman lists? Or do you want this host to handle other incoming mail
> as well?  If it's dedicated to Mailman, you don't need Dovecot, and it
> complicates the system by quite a bit.  Removing it from the system
> will simply configuration considerably.  If the host is handling other
> incoming mail, then Dovecot is a good system for providing IMAP (and I
> seem to recall POP3 as well) for user mailboxes and well worth the
> complexity.
>

Yes, it's a separate host that handles only mailman lists, it doesn't
handle other incoming
mail.

I'll remove dovecot, and report back.


>
> I've folded log messages below for readability.
>
>  > Jan 31 12:53:54 lists postfix/lmtp[4128841]: 348981A8A2A:
>  >   to=<[email protected]>, orig_to=<mailman>, relay=none,
>  >   delay=113, delays=0.04/52/61/0, dsn=4.4.1, status=deferred (connect
>  >   to localhost[::1]:24: Connection refused)
>
> The log entry above says that you are sending Mailman (list) mail to
> port 24, the port used in Dovecot's documentation for 'inet' LMTP
> services.  This may be in contention with Dovecot, unless you are
> trying to pass Mailman traffic through Dovecot.  If Dovecot is
> listening on an 'inet' socket, what port is Dovecot listening on?
> What port is Mailman listening on?
>

Yes, I used port 24 because of Dovecot's documentation, and the goal was to
pass mailman
traffic through Dovecot for authentication.

I only configured lmtp for Dovecot to listen on port 24, I didn't configure
any other service.


>
> I recommend that you NOT have Mailman pass through Dovecot, because it
> will be confusing to anyone familiar with Mailman operations trying to
> help you.  Normally, Mailman listens on 8024, which is routed directly
> by the MTA (Postfix, in your case).
>

I don't see mailman listening on 8024 from my end, the port isn't open.


>  > Jan 31 12:54:53 lists dovecot:
>  >   lmtp([email protected])<4131586><qMl1NuFrfmkCCz8AOj1W/w>:
>  >   Error: auth-master: userdb lookup([email protected]):
>  >   Disconnected unexpectedly
>
> The log entry above says that Dovecot is trying to handle Mailman
> traffic, but something went wrong with the userdb lookup.  I can't
> help you with that.
>
>  > Jan 31 12:55:18 lists postfix/smtpd[4132212]: fatal:
>  > open dictionary: expecting "type:name" form instead of "dovecot"
>  >
>  > I setup lmtp with dovecot, and I have this in dovecot.conf;
>
> If you are referring to the log message above, that is from Postfix,
> and it appears that one of Postfix's tables is configure as "dovecot"
> rather than a proper Postfix database.
>
>  > passdb passwd-file {
>  >   driver = passwd-file
>  > }
>  >
>  > I also have these set in postfix main.cf;
>  >
>  > lmtp_sender_dependent_authentication = yes
>  > lmtp_sasl_auth_enable = yes
>  > lmtp_sasl_password_maps = hash:path_to_passwd_file
>
> I assume that "path_to_password_file" is a placeholder for the
> password file, which is typically /etc/postfix/sasl/sasl_passwd.db,
> compiled from the source in /etc/postfix/sasl/sasl_passwd using
> postmap.
>
> Yes, it's a placeholder for the password file, and yes it was compiled
using postmap.


>  > I'm wondering if I need to disable sasl because I set dovecot not
>  > to use ssl because lmtp is only running internally.
>
> SASL authentication is independent in the SMTP protocol with a
> separate keyword "AUTH", so disabling SSL is irrelevant unless Postfix
> always uses TLS (a very unusual configuration for a Mailman site).
> However, as long as LMTP is running only internally, I believe
> authentication is not very useful since any attacker who can access
> internal communications likely can read the password file and
> authenticate.
>
> Too many things can go wrong.  I recommend that you disable all the
> authentication until you have all mail flows working without
> authentication, then add authentication as you require for your
> applications.
>

I'll try this, thank you!

>
> 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/72IDANVC5BJYPBEK6PQVDBFWO3NRDNDR/

This message sent to [email protected]

Reply via email to