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 transaction,
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).
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!
--
Amelia A. Lewis amyzing {at} talsever.com
The less I seek my source for some definitive, the closer I am to fine.
-- Indigo Girls
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 (andcut 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 at pixeltechs.com
On Sun, 2003-01-05 at 06:46, Amelia A.Lewis wrote:> 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?).Not really. I don't think it'd be worth the trouble.> 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 think Outlook supported only NTLM besides the plaintext auth. There's specs for it now so it would be possible to be supported too.> 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?It uses different algorithm, although Dovecot could be made to support that too.. The Dovecot's algorithm is very simple and is compatible with pwdfile PAM module, it's simply the MD5 sum of a given text, eg: perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("pass")."[34]\n"' Digest-MD5 passwords should probably rather be used so that could be used also by people who can. The description was a bit broken it seems, for plaintext authentication it works only if the realm is empty, so this should work: perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex("user::pass")."[56]\n"'> imap(user:@omain.realm): Failed to create storage with data: > domain.realmGuess I should have actually tested this :) It tried to replace the ':' char with '@'. Fixed.> 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%n was then "user:", so it didn't work.> The solution was to remove the realm (which isn't useful except for > digest md5, anway, right?).It's not really useful for digest-md5 either. It's mostly to support multiple realms running in same server. I'm not yet sure how I'd actually even properly support those .. probably fallback to user at realm style in plaintext passwords. Maybe I should consider anyway using Cyrus SASL library, at least optionally. Would make life so much easier :) Everyone keeps wanting LDAP and MySQL and whatever support, but I'd rather concentrate on the IMAP side for now.