Dunno how you set up dovecot so impossible to answer if itâs default that maybe a different answer. But I would research the subject fully try everything on a vm before applying anything to a production server. Note the title of the thread
Dovecot has nothing to do with it. Virtualmin configures Cyrus saslauthd.
IMAP/POP3 (which is what Dovecot provides in a Virtualmin system) do not authenticate via SASL. Only SMTP is authenticated via SASL. So, Dovecot is not using Cyrus saslauthd or the Dovecot SASL implementation.
Dovecot has a SASL implementation, and weâve considered switching to it just to remove one of our additional dependencies, but thereâs some thought to adding JMAP support to Virtualmin the future, and it seems like that would necessitate a switch to Cyrus for POP3/IMAP, since Dovecot has no near-term plans to implement JMAP. I am unsure if we have any near-term plans, either, though, since client support is very minimal right now and itâs mostly only useful for webmail clients.
Youâre just looking in the wrong place. You donât want that. Itâd make it impossible for anyone to send you mail. (Theyâd have to have an account on your server.)
Edit: Oops, Ilia pointed out to me that this is the client-side options, not server-side. Please include the page title in screenshots! This is for relaying mail, and has nothing to do with how your users interact with your server.
You canât us CRAM-MD5 (or any of those other options) with system users without also storing plaintext passwords. The way the email protocols treat passwords and the way Linux treats passwords donât have any overlap, so thereâs gotta be a plaintext password somewhereâŠVirtualmin sets up SSL on all mail protocols (and we recommend you use them) so passwords are not transmitted in plain text. We donât support any of those other options.
"Non-plaintext mechanisms have been designed to be safe to use even without SSL encryption. Because of how they have been designed, they require access to the plaintext password or their own special hashed version of it. This means that itâs impossible to use non-plaintext mechanisms with commonly used DES or MD5 password hashes.
If you want to use more than one non-plaintext mechanism, the passwords must be stored as plaintext so that Dovecot is able to generate the required special hashes for all the different mechanisms. If you want to use only one non-plaintext mechanism, you can store the passwords using the mechanismâs own Password Schemes."
We plan a refactor of the mail stack, maybe for Virtualmin 8 (development starting later this year), which likely ends this particular dichotomy by severing âmailâ and âsystemâ users. That has far-reaching implications, but is probably better for most use cases; easier to scale across multiple systems, for instance. That may wait until JMAP is more mature, since that will also require a mail stack refactor (which would probably involve dropping Dovecot in favor of Cyrus).
This is a world full of compromises. We made the compromises that made the most sense at the time. Iâm still trying to decide what compromises will be worth making dramatic changes forâŠthere have been many suggestions made over the years for quite bad compromises (things like âWhy donât you put users in MySQL?â).
I may think different things are important than other folks. And, thatâs OK, you can solve these problems in any way you want to; everything in the mail stack is open, you can modify anything you want. We certainly wonât stop you.
But, if you want to do it differently, youâll have to implement it yourself, and I would advise caution, since mail is very complex and has a lot of compatibility and interaction concerns that are not intuitive of immediately obvious; there are things about the way mail works that seem absolutely bonkers on the surface (and sometimes even after you understand it and why they did it that way). We used to see a lot of folks following some Virtualmin guide on the internet that involved a very complicated mail stack, with MySQL users. It wasnât pretty and it wasnât easy to help them solve problems because there were so many places for problems to occur. Our stack has the benefit of being close to as simple as possible (Iâm a little iffy about our use of multiple layers of procmail, which is my primary motivation for a refactor, but mostly there arenât any pieces we could remove to make it simpler).
I want to keep things simple and as close to the virtualmin default install. My journey is more about documenting virtualmin as I go which can be used as a reference, but I have found issues on the way, things like out of date settings or some that just need removing so I report them.
Having SASL is useful for things like using LDAP for authentication but I just want normal email authentication setup using the latest standards.
One small improvement example is to add a Cyrus SASL module with only the edit config button which will have all of the relevant config files listed.
When I started I did not know what SASL was and why I needed it, I do now
I am using Virtualmin to make running a server easier and provide a GUI but using the CLI when needed.