Curtis Maloney wrote on Wed, 05 Apr 2006 09:57:42 +1000:
I don't recall the specifics, but they are available on the dovecot web site: http://www.dovecot.org/oldnews.html
I read all the release notes since 0.99.11 and there's no mention about the chdir and create IMAP structure at all, so maybe it's not fixed at all?
As for creating folders, there isn't an "IMAP" folder structure per se, just a mail store structure: either Maildir or mbox, both well established standards.
But there's no point creating anything in the user's dir when using POP. See below where I answer your question in length.
Yeah, seems so and it's ok that way. The main reason for my question was why it did that. There's no need or use for an imap structure if that is a "simple" pop login. Is that related to the bug we where talking about above and also got fixed in the meantime?
What do you mean by "IMAP structure"? Exactly which part of what it's doing don't you want? Dovecot is, primarily, an IMAP server, so it approaches things always with IMAP in mind. Wherever you store your mail, you will need an INBOX and possibly some other folders.
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:
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. 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.
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.
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.
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.
If both have not been fixed yet I'd consider both a bug.
There was some talk recently on the list, I believe, about LOGIN, though I didn't pay much attention, tbh.
From reading the older release notes it seems that PLAIN got removed again becuase it was not working. At least for me it seemed to be working. And CRAM-MD5 was added, no LOGIN it seems.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com