Timo Sirainen wrote:
Which is good, except it never defines what "authentication mechanism" really means, and how it is distinct from how the password is stored.
How about:
Looks great.
Now that the more detailed documentation seems to be migrating into the Wiki, what do you plan to do with the text files in the distribution? Will auth.txt become a text equivalent of this page? Or maybe turn auth.txt into just an intro paragraph with a pointer to the above URL?
I noticed a few of the new Wiki documents have references to things like "doc/variables.txt" that aren't hyperlinked. It'd be better if they were.
- Authentication Mechanisms
Although in section 3 you address the point that PLAIN passwords are more flexible when mapping them to storage schemes, I think it wouldn't hurt to be a bit redundant and repeat that point at the end of section 2. Essentially pointing out the down side to using encrypted mechanisms.
Should there be a list of common clients and what mechanisms they support? Bound to get out of date, but it would be nice, for example, to know that Mozilla/Thunderbird is one of the clients supporting CRAM-MD5.
With PLAIN authentication mechanism it doesn't matter in which format the password is stored locally...
I'd complete that thought and explain why... "...because Dovecot will encrypt the password to match the storage scheme..."
Your comments seem to imply that Dovecot won't translate a plain password to a digest-md5 storage scheme (perhaps also cram-md5), though it seems this should be possible.)
It's possible.
But it doesn't currently, right? (At least not in .99) I'm assuming that's why my initial attempts to use the PLAIN mechanism with the DIGEST-MD5 scheme failed to work.
If the behavior is inconsistent, then it need to be more explicit in the documentation.
-Tom