Amelia A.Lewis wrote:
Heyas ...
I'm trying to use dovecot to set up a 'closed server' (actually, mixed) sort of environment, for a box to be deployed co-located. I wanted to talk about some of that, and see if some of my experience qualifies as 'bug'.
Note that I'm notoriously verbose, so if that bothers you, read no further ....
Since it's a more-or-less closed server, I didn't want to use pam (well, I wouldn't mind, for users with shell accounts, but I can't see a way to mix pam and passwd-file ... is there a way to do that?).
It turns out that digest-md5 support for clients is, well, not very widespread. I expect this box to be used by various windoze clients, eventually, and while I'm willing to lay down the law a little, I can't find enough digest-md5 support to lay down that law. So, regretfully, I abandoned that plan. This kinda bothers me, since I think TLS/STARTTLS is absolutely the *wrong* solution for mailbox access (or for anything that deals with a store-and-forward transport).
I therefore tried md5 passwords in a passwd-file, with STARTTLS enabled. Didn't work. I turned off SSL, and reenabled plain-text, and watched the login go by. Very sniffable, of course. But correct username and password ... failed. There are instructions for creating digest-md5 style secrets in auth.txt, but none for md5 passwords; I used openssl passwd -1 [password] (and cut and paste). It seems odd to me that this didn't work; does that command use a different algorithm than dovecot?
Falling back ... since it *shouldn't* matter if the passwords are weak, as long as they're inside TLS (along with the entire rest of the transaughction, ugh), I used mkpasswd to generate a standard unix passwd (and cut and paste). This worked. It worked with TLS, and it worked without (as long as I remembered to allow sniffable logins).
Not to be confrontational at all, but I'm very curious as to why you have such an aversion to SSL/TLS for IMAP access? I think actualy an entirely encrypted transport for something as (possibly sensitive) email is a good thing.
One more oddity: I originally had a realm in the passwd-file, which also established the mail location and 'home' directory (most of the users can't actually log in and don't have accounts in /etc/passwd, so it's not a real home directory). There was an odd message in syslog, approximately like so (where 'user' represents the username, and 'domain.realm' represents both my domain name and the realm in the passwd-file):
imap(user:@omain.realm): Failed to create storage with data: domain.realm
Note the missing first letter after user:@ And I don't know what it was trying to do; the maildirs already exist. /etc/dovecot.conf sets the default mail location to /home/users/%n/Maildir (non-shell users are all inside /home/users; shell users have mail there, with symlinks to ~/Maildir); the passwd-file establishes the location of the INBOX pretty definitively, I would think. The solution was to remove the realm (which isn't useful except for digest md5, anway, right?).
Hey, it's working! Wahoo! *laugh* Anyway, if someone can offer suggestions on what's up with the pieces that *aren't* working, I'd be interested to know. It might give me a greater range of options.
Amy!
-- Jesse Peterson / jesse@pixeltechs.com