Vladislav Kurz via dovecot said on Fri, 6 Mar 2026 09:29:23 +0100

Dne 06. 03. 26 v 0:04 Steve Litt via dovecot napsal(a):

...

Hi all,

I put auth_allow_cleartext = no in my 2.4.2 dovecot.conf, but my Claws-Mail client can still access it, even though there are no key files. I tried putting this setting in several different places: Didn't prevent plain access. I tried switching from 127.0.0.1 to 10.0.2.15, same problem.

In my experience (dovecot 2.3.13 with disable_plaintext_auth = yes), it allowed plaintext on loopback interface, but not when accessing remotely. This is imho good, so that local webmail can access imap at localhost without wasting cpu cycles on ecnryption.

I have the option near the top of the file, not in any block. E.g. right after listen.

Thanks Vladislav,

First, thanks for the good information about *where* you placed disable_plaintext_auth = yes. I wish the Dovecot docs would consistently do that.

2.4.x has replaced disable_plaintext_auth = yes with auth_allow_cleartext = no , but it doesn't seem to be an exact replacement. Trying on both Localhost and a real address was the first thing I thought of, but with 2.4.2, my results were that auth_allow_cleartext = no placed right after the listen did not prevent plain text access on 10.0.2.15, which is the address of my Qemu VM guest:

[slitt@dovecotvoid ~]$ ip route default via 10.0.2.2 dev ens3 proto dhcp src 10.0.2.15 metric 1002 10.0.2.0/24 dev ens3 proto dhcp scope link src 10.0.2.15 metric 1002 [slitt@dovecotvoid ~]$

If you haven't yet transitioned from 2.3.x to 2.4.x, I'd suggest that you get it running on a test machine before cutting over, because there are some surprises.

SteveT

Steve Litt

http://444domains.com

Aki Tuomi via dovecot said on Fri, 6 Mar 2026 11:58:56 +0200 (EET)

...

On 06/03/2026 01:04 EET Steve Litt via dovecot <dovecot@dovecot.org> wrote:

Hi all,

https://doc.dovecot.org/2.4.2/core/summaries/settings.html , the auth_allow_cleartext section, says "If no, disables the LOGIN command and all other cleartext authentication unless SSL/TLS is used (LOGINDISABLED capability) or the connection is secured (see ssl).

See SSL configuration for more detailed explanation of how this setting interacts with the ssl setting.

This setting replaces the disable_plaintext_auth setting."

I put auth_allow_cleartext = no in my 2.4.2 dovecot.conf, but my Claws-Mail client can still access it, even though there are no key files. I tried putting this setting in several different places: Didn't prevent plain access. I tried switching from 127.0.0.1 to 10.0.2.15, same problem. The following is the output of my dovecot -n command:

Hi, auth_allow_cleartext=no is the default setting.

However, as https://doc.dovecot.org/2.4.2/core/config/ssl.html#secured-connections states, connections from login_trusted_networks or from the host listener itself (in your case 10.0.2.15) are considered trusted, so they are allowed to use plaintext login.

So basically set ssl=required

Thanks Aki,

I've seen no documentation indicating *where* ssl=required should go, and so had to experiment. If I go 2.3x style and put it within imaps:

listen = 10.0.2.15 auth_allow_cleartext = no

The IMAP service declarations

service imap { #Plain text listener at port 143 #inet_listener imap-login { #port = 0 #}

SSL IMAP (imaps) is port 993

inet_listener imaps { #port = 993 ssl = required } }

With the preceding config, the following error occurs:

[root@dovecotvoid dovecot]# dovecot -F doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 29: ssl: Invalid boolean value: required (use yes or no) [root@dovecotvoid dovecot]#

If I move the ssl=required right below auth_allow_cleartext = no, or right below service imap { , then with or without ssl=yes inside inet_listener imaps { , dovecot -F runs, but Dovecot's accessible without SSL.

Let me explain my goal and what I'm doing. My goal is to reject any plain text, non-SSL queries from anyone anywhere, full stop. Basically, what ssl=required inside inet_listener imaps gave us in 2.3x. I'm using a Qemu VM guest to test 2.4.2 config before upgrading my real machine. My immediate next step is to, before even dealing with SSL, to prevent plain text access, regardless of localhost or non-localhost, haproxy or non-haproxy, whatever. Once that's done, I'll begin enabling SSL. For security's sake, I need to *prove* that plain text access fails in all cases.

So, how do I prevent plain text access, full stop?

Thanks,

SteveT

Steve Litt

http://444domains.com

Aki Tuomi said on Fri, 6 Mar 2026 19:07:38 +0200 (EET)

...

On 06/03/2026 18:52 EET Steve Litt via dovecot <dovecot@dovecot.org> wrote:

Aki Tuomi via dovecot said on Fri, 6 Mar 2026 11:58:56 +0200 (EET)

...

...

On 06/03/2026 01:04 EET Steve Litt via dovecot <dovecot@dovecot.org> wrote:

Hi all,

https://doc.dovecot.org/2.4.2/core/summaries/settings.html , the auth_allow_cleartext section, says "If no, disables the LOGIN command and all other cleartext authentication unless SSL/TLS is used (LOGINDISABLED capability) or the connection is secured (see ssl).

See SSL configuration for more detailed explanation of how this setting interacts with the ssl setting.

This setting replaces the disable_plaintext_auth setting."

I put auth_allow_cleartext = no in my 2.4.2 dovecot.conf, but my Claws-Mail client can still access it, even though there are no key files. I tried putting this setting in several different places: Didn't prevent plain access. I tried switching from 127.0.0.1 to 10.0.2.15, same problem. The following is the output of my dovecot -n command:

Hi, auth_allow_cleartext=no is the default setting.

However, as https://doc.dovecot.org/2.4.2/core/config/ssl.html#secured-connections states, connections from login_trusted_networks or from the host listener itself (in your case 10.0.2.15) are considered trusted, so they are allowed to use plaintext login.

So basically set ssl=required

Thanks Aki,

I've seen no documentation indicating *where* ssl=required should go, and so had to experiment. If I go 2.3x style and put it within imaps:

listen = 10.0.2.15 auth_allow_cleartext = no

The IMAP service declarations

service imap { #Plain text listener at port 143 #inet_listener imap-login { #port = 0 #}

SSL IMAP (imaps) is port 993

inet_listener imaps { #port = 993 ssl = required } }

With the preceding config, the following error occurs:

[root@dovecotvoid dovecot]# dovecot -F doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 29: ssl: Invalid boolean value: required (use yes or no) [root@dovecotvoid dovecot]#

If I move the ssl=required right below auth_allow_cleartext = no, or right below service imap { , then with or without ssl=yes inside inet_listener imaps { , dovecot -F runs, but Dovecot's accessible without SSL.

Let me explain my goal and what I'm doing. My goal is to reject any plain text, non-SSL queries from anyone anywhere, full stop. Basically, what ssl=required inside inet_listener imaps gave us in 2.3x. I'm using a Qemu VM guest to test 2.4.2 config before upgrading my real machine. My immediate next step is to, before even dealing with SSL, to prevent plain text access, regardless of localhost or non-localhost, haproxy or non-haproxy, whatever. Once that's done, I'll begin enabling SSL. For security's sake, I need to *prove* that plain text access fails in all cases.

So, how do I prevent plain text access, full stop?

Thanks,

SteveT

Steve Litt

ssl = required

goes on top level, not inside anything.

If you put it inside inet_listener it's actually https://doc.dovecot.org/2.4.2/core/config/service.html#inet_listener_ssl, so totally different setting.

Aki

That explains it. Thanks Aki.

ssl = required at the top level does not prevent plain text access, however, as shown by both claws-mail and doveadm fetch. What more should I do to prevent all plain text access?

Thanks,

SteveT

Steve Litt

http://444domains.com

Aki Tuomi said on Fri, 6 Mar 2026 19:34:48 +0200 (EET)

...

On 06/03/2026 19:23 EET Steve Litt via dovecot <dovecot@dovecot.org> wrote:

...

That explains it. Thanks Aki.

ssl = required at the top level does not prevent plain text access, however, as shown by both claws-mail and doveadm fetch. What more should I do to prevent all plain text access?

Thanks,

SteveT

Steve Litt

Apologies, I read the documentation wrong and it fooled me.

"Localhost connections are secured by default, but they are not trusted by default. If you want localhost to be trusted, it needs to be included in this setting."

I guess the easiest way is to do

service imap-login { inet_listener imap { port = 0 } }

service pop3-login { inet_listener pop3 { port = 0 } }

Note that the listeners are on *login* processes (except for lmtp). This has not changed since 2.2.

Thanks Aki! The preceding sentence is the key to everything. When I changed the outer service imap { to service imap-login { , everything worked as expected, I did not get duplicate port errors when specifying a default port, and I was able to toggle ability and inability to access via plain text by goggling port= between 143 and 0. I'll tell all my friends about this key distinction that listeners are on *login* processes, which of course makes perfect sense from a sockets point of view.

Unfortunately, a lot of web lookups and AI suggest the outer service imap rather than service imap-login, and I ended up with imap instead of imap-login. I'll now insert warning comments about this in my config file.

Thanks,

SteveT

Steve Litt

http://444domains.com

Sebastian Robin Nielsen via dovecot said on Fri, 06 Mar 2026 20:52:25 +0100

However, it should still prevent plain if you have ssl = required, because that will require clients to EITHER use STARTTLS *OR* use a non-PLAIN login method over unencrypted IMAP.

This is good information. Thanks Sebastian. I confirmed approximately what you said by toggling Claws mail receiving SSL between "Use SSL" as opposed to "Don't use SSL" and "Use STARTTLS", restarting Claws-mail with each toggle. However, my desire is to have Dovecot have absolutely no dealings with anything not SSL, regardless of the setup of their client.

By setting listen to 0, you actually disable STARTTLS and require clients to use a dedicated TLS port like 993.

The preceding is *exactly* what I want, and my testing confirms that yes, it works just that way.

Thanks,

SteveT

Steve Litt

http://444domains.com