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@cardgate.net