Dne 06. 03. 26 v 18:05 Steve Litt via dovecot napsal(a):

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

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:

The trick is that you have to check from another host. Trying the "real address" 10.0.2.15 from the same host is treated the same as if you try "127.0.0.1"

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.

I know it is off topic, but can you be more specific, what should I watch for? I have several dovecot servers waiting for upgrade...

-- Best regards Vladislav Kurz

Vladislav Kurz via dovecot said on Mon, 9 Mar 2026 10:29:41 +0100

Dne 06. 03. 26 v 18:05 Steve Litt via dovecot napsal(a):

...

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.

I know it is off topic, but can you be more specific, what should I watch for? I have several dovecot servers waiting for upgrade...

The most specific I can get is watch out for EVERYTHING having to do with configuration. It's completely different, with different defaults, in some cases different meanings for the same config options, in other cases different names for the same config options, with meanings and possible values perhaps the same and perhaps changed.

Not only is it completely different, but it's superficially similar enough to fool you. Meanwhile, after all these months it's still difficult to locate 2.4.x specific Dovecot docs, so web searches, AI queries and even questions to live humans often get answered with 2.3.x answers.

Aki answered your "what should I watch for" question by mentioning you should review https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html . This is the best answer to your question, but in my opinion that question should come later. The first question should be "by what process do I convert my configuration file(s)? And the answer to that question depends on your situation, your abilities and disabilities.

Some people don't have Attention Deficit Disorder (ADD) and impatience. For such people, https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html doesn't look like "a wall of words" with heavy recursion to other pages. For such people, reading and understanding this document enables them to intelligently translate their 2.3 config to 2.4. Some people are highly skilled professional admins (not developers, admins, there's a big difference). Such people seem to just "know how" to do config. They use Aki's suggested page as a reference. Speaking of developers, some people are developers working on 2.4.x. Such people know this stuff because heck, they wrote it. They sometimes refer back to Aki's suggested page. Some people are geniuses with stratospheric IQs. They somehow just "figure it out" by means I can't even contemplate. All these people have an easier time translating 2.3 to 2.4, but every one of them should do it first on a test setup, because only a crazy person deploys something new on the live system before running it in a test environment.

Then there are people like me, and there are a lot of us. Average intelligence, ADD, impatient, either lightly or moderately familiar with Dovecot (after all, til now once you got it working you could coast for years). People like me must rewrite the config files from scratch, starting with a 127.0.0.1 no-SSL "Hello World", and building up, step by step, to what we need, on our test environment. In such a situation, Aki's suggested document becomes an educational tool, as does the conversion program at https://dovecot.org/upgrader/ , as does (very badly at this point) AI, as does this mailing list.

So, to reiterate, my answer to your question "what should I watch for?", my answer is "everything concerning configuration, but the bigger priority is matching your process to your abilities and disabilities, assets and liabilities."

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