[Dovecot] Questions about differences to other mail servers
maillists at conactive.com
Wed Apr 5 19:31:26 EEST 2006
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:
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 Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
More information about the dovecot