[Dovecot] Questions about differences to other mail servers

[Curtis Maloney]

Kai Schaetzl wrote:
> 
> Not for POP. Mail gets delivered by local MDA to /var/spool/mail in mbox format, pretty 
> standard sendmail+procmail setup, nothing special. When a POP client wants to get mail 
> he should simply login and the pop3 server "works" on /var/spool/mail/username. Nothing 
> else, no user directory involved at all. That's how the other pop servers I have used in 
> the past, do it (ipop3 and qpopper). However, when I login to a user account via 
> pop3/dovecot the first time the following happens:

OK.  Now I'm getting the picture.  Now, important fact #1:  Dovecot is an IMAP 
server.  It has POP3 thrown in as a convenience.  So, all the decisions are made 
with IMAP in mind.  This includes needing a place to store indexes.

However, in the later 1.0 versions, Timo added an option to disable indexing for 
POP access, since most POP users just collect all their mail, so indexing is 
wasted effort.

So this immediately opens two options:  either 1) move to 1.0 and disable 
indexing on POP access... or 2) set INDEX=MEMORY on your default_mail_env and 
see if it then stops creating the folders.

> - it wants to chdir to the user's homedir, if it can't the login fails with 
> "authentication failed" or so sent to the client. The log says "cannot cxhdir to ..." or 
> something like that.

Knowing exactly what this message is could help me find where it's actually failing.

> This can be fixed by allowing read/traversal permissions for the 
> pop user to that path. In my case the *group* of that user had access to the path, but 
> not the user itself because an upper dir belongs to a different user. This was fine with 
> uw-imap, no problems it all, it can read and write there. Dovecot cannot even chdir to 
> that path. And I very much think it should not chdir there at all when doing pop. It's 
> obviously necessary for IMAP but not at all for POP.

I've taken a quick look through the code, and it seems that if you're not 
chrooting, and the home dir doesn't exist, it will fall back to /tmp.  But 
that's a 2minute examination...

> - next thing that happens is that it creates a folder mail, a folder .imap below it and 
> an INBOX file if they don't exist. If it can't (which happened to be the case with one 
> of my users who had accidentally deleted the path above it) it throws the user out 
> again, now with message "cannot create INBOX". Again, this happens with POP3 logins. 
> There's no use for a mail folder and anything beneath it when only POP is used.

What is your default_mail_env set to?

> So, to summarize, when a POP3 login ahppens it should not chdir to the user's homedir 
> and it should not try to access or create *anything* in the suer's homedir. It should 
> only work on /var/spool/mail/username or whereever the mailbox sits.

You'll be hard pressed to get a lot of help on 0.99, since pretty much everyone 
has moved onto 1.0 - for the very simple reason of "it's much better".  Don't 
let the 'beta' scare you; it's in production use at some very large installs.

> This is how the other clients I know work. And as they do this quite fine there doesn't 
> seem to be a good reason to do it otherwise. Maybe there is a reason, then i would like 
> to know it. And I'd say something like "we create this stuff because one day the user 
> may want to login via IMAP and we don't want then to bother about this" is not a good 
> reason. I'm sure that the imap-login program checks for that path, anyway, and if not 
> present will create it. So, doing it for POP is really mute and just creates pre-known 
> possible points of failure. In my case the one or the other disallowed my users to login 
> although none of this would have been necessary for POP.


So... if you wanted a POP server, why did you pick an IMAP server?

--
Curtis Maloney
cmaloney at cardgate.net