Sv: Preventing Plain Auth

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.
By setting listen to 0, you actually disable STARTTLS and require clients to
use a dedicated TLS port like 993.

Note however that the server will still ADVERTISE plain (which will be
visible in clients and such), because its in the client where you set "use
STARTTLS", otherwise the client may not proceed at all if it only support
PLAIN (but still supports TLS) but sees the server not advertise PLAIN at
the non-encrypted stage.

However, it SHOULD still reject logins using PLAIN over non-encrypted
connections if you have ssl = required, which will display a error message
to the customer, and then the customer has to change settings in email
client to use STARTTLS.

-----Ursprungligt meddelande-----
Från: Steve Litt via dovecot <[email protected]> 
Skickat: den 6 mars 2026 20:22
Till: [email protected]
Ämne: Re: Preventing Plain Auth

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

>> On 06/03/2026 19:23 EET Steve Litt via dovecot <[email protected]>
>> 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
_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]