Is there a simple procedure or script to turn off insecure user Email access in CB 2.

IT_Architect

Verified User
Joined
Feb 27, 2006
Messages
1,114
Is there a simple procedure or script to turn off insecure user Email access in CB 2.0?
 
Hello,

What is "insecure user Email access"?

Is it an unauthenticated access to SMTP? Or is it non SSL/TLS authentication in POP/IMAP/SMTP?

Or other?


Anyway CB 2.0 does not have anything for first two listed options as of now, as far as I know.
 
What is "insecure user Email access"?

It is unencrypted access to POP, IMAP, and SMTP E-Mail submission/Port 587. It is the most common way E-Mail accounts get compromised.

Thanks!
 
Last edited:
I believe an unauthenticated access to POP, IMAP is impossible, and an unauthenticated access to SMTP 587 from outside is not possible either.
 
Oh Duh! LOL! I wrote unauthenticated and I should have written unencrypted access. I will edit those now.
 
Got it! sigh, I was hoping CB 2.0 would have something. My edits would get hosed on the first rewrite configs, and it would probably be quite a chore to figure out how, or if, I could incorporate all of that into custom files. None of the large mail box providers have allowed it in over a decade.

Thanks!
 
https://wiki.dovecot.org/SSL/DovecotConfiguration

The main difference between ssl=required and disable_plaintext_auth=yes is that if ssl=required, it guarantees that the entire connection is protected against eavesdropping (SSL/TLS encrypts the rest of the connection), while disable_plaintext_auth=yes only guarantees that the password is protected against eavesdropping (SASL mechanism is encrypted, but no SSL/TLS is necessarily used). Nowadays you most likely should be using SSL/TLS anyway for the entire connection, since the cost of SSL/TLS is cheap enough. Using both SSL/TLS and non-plaintext authentication would be the ideal situation since it protects the plaintext password even against man-in-the-middle attacks.
Also;
NOTE2: With both ssl=yes and ssl=required it's still possible that the client attempts to do a plaintext authentication before enabling SSL/TLS, which exposes the plaintext password to the internet. Dovecot attempts to indicate this to the IMAP clients via the LOGINDISABLED capability, but many clients still ignore it and send the password anyway. There is unfortunately no way for Dovecot to prevent this behavior. The POP3 standard doesn't have an equivalent capability at all, so the POP3 clients can't even know if the server would accept a plaintext authentication.

I always create a custom conf for dovecot/conf/ssl.conf and add:
ssl = required
ssl_prefer_server_ciphers = yes

and disable plaintext_auth in the main dovecot.conf. Is this what you are looking for?
 
Back
Top