Email Security - dovecot method=PLAIN seems weak?

Running latest Virtualmin on Centos 8.2. Curious to know how I can improve my mail security. I see TLS is enabled, but I’m not liking that this method=PLAIN is actively printing. What are the recommended steps to enable a higher level of security for my email here?

Oct 18 09:20:41 dev dovecot[625532]: imap-login: Login:, method=PLAIN, rip=[iphere], lip=[iphere], mpid=1205868, TLS, session=<eoThs/KxNsvUZi1z>

Any diagnostic insight on this would be great for me to understand if this is in fact unsecure or if TLS supersedes that PLAIN value and it is handling the job of security in its’ entirety.

I’m trying to understand better which cipher this TLS connection is using, 128 or 256bit encryption, or if I need to be looking at working with another method to supply AES 128/256 bit encryption here.

I figure if I’m going to take on the responsibility of running a mail server with so many sensitive credentials being sent by various companies, banking institutions, etc, I should probably lock this down the best I can. Thanks for the insight.

I think the standard, out-of-the-box Dovecot configuration has disallowed plaintext authentication on non SSL/TLS connections for quite some time now. So the apparently insecure plaintext login is made [somewhat] more secure by SSL/TLS by default. I think it’s been that way for years.


Ok, cool @RJM_Web_Design . Looks like mail can be encrypted on the disk through Dovecot via a plugin called mail-crypt-plugin:

I’ll start here and then work on securing the connection. I’ll post my findings after I do some more research for anyone that’s interested. :slight_smile:

So it seems method=PLAIN is just a redundancy due to the way these architectures were developed (not with security in mind initially), and with TLS being added on at a later date. The TLS value being shown in the output I pasted above supersedes method=PLAIN and is entirely secure.

After further research, openssl s_client -connect gave me the cipher to my TLS certificate. I compared it with’s certificate. Both keys are using the TLS_AES_256_GCM_SHA384 cipher, which feels good. The only difference was google uses a 256 bit ECDSA key versus my 4096 bit RSA key.

A 256 bit ECDSA key is equvalent to a 3248 bit RSA key. This puts into question if it is fact stronger than my current 4096 bit RSA key, crypographically, the answer is yes, with the additional benefit of ECDSA keys loading incredibly faster, about 9.5x faster, saving a lot of CPU cycles. This is just a little bit of information I remembered from past research now that I’m touching on this again.

I may consider changing my key-type, but if I remember right, ECDSA keys are not widely accepted by various platforms right now and it can make transferring keys between services a bit tough. Maybe in the future I will. Until then, being that I haven’t touched a computer in a while, this was a good refresher and I hope this is valuable to any googlers or virtualmin forum searchers out there.


Yeah, pretty much having to do with email had been patched and kludged over the decades to make it more secure (actually, to make it secure at all) while still maintaining some semblance of backward-compatibility. The system was built around trust and interoperability back when only geeks and nerds knew it existed.

Nowadays, on the other hand, supermarkets want me to use 2FA to see how many points I have on my loyalty cards. Times have changed… sigh…


This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.