[Dovecot] Questions about differences to other mail servers
I just transferred over my first server from Suse Linux with uw-imap(ipop3/imap2003) to CentOS with Dovecot (0.99). I didn't find any problems in the testing phase, but when the actual transfer into production happened I found a few problems crop up:
Dovecot wants to chdir in the user's home directory even when logging in via POP3. However, the mailboxes for POP3 are all in /var/spool/mail. What's the reason for this and can I stop this?
In addition I found that the home directories need additional permissions I did not need when using ipop3/imap2003, although this imap server needs to write/read in the same directories as dovecot. Specifically, I had to change the permissions on the directory right above the pop user directories from 750 to 755. Those directories are owned by the user and the primary group he belongs to. It seems that dovecot somehow doesn't "use" the primary group of the user and so can't traverse thru and the chdir fails.
Furthermore, Dovecot created an IMAP directory structure within the home directory of most users like "mail/.imap/INBOX" (on some it reused the existing Mail -uppercase- directory). Just on a simple first POP3 login. What's the reason for doing this? Maybe that user is never going to use IMAP? Does it test for both mail and Mail before it creates it's own structure or what does it do? I assume this is related to default_mail_env?
Dovecot supports "auth plain", does it also support "auth login"? If so, how do I enable it?
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Kai Schaetzl wrote:
I just transferred over my first server from Suse Linux with uw-imap(ipop3/imap2003) to CentOS with Dovecot (0.99). I didn't find any problems in the testing phase, but when the actual transfer into production happened I found a few problems crop up:
- Dovecot wants to chdir in the user's home directory even when logging in via POP3. However, the mailboxes for POP3 are all in /var/spool/mail. What's the reason for this and can I stop this?
I remember this bug... I'm sure it was fixed. Which version of the ancient-but-venerable 0.99 are they shipping with CentOS?
- In addition I found that the home directories need additional permissions I did not need when using ipop3/imap2003, although this imap server needs to write/read in the same directories as dovecot. Specifically, I had to change the permissions on the directory right above the pop user directories from 750 to 755. Those directories are owned by the user and the primary group he belongs to. It seems that dovecot somehow doesn't "use" the primary group of the user and so can't traverse thru and the chdir fails.
Check in the config file which users Dovecot is set to use. It may be that you need to chown the dir, or set Dovecot to use a different user. NOTE: There's more than one use setting in Dovecot, because of security and the auth daemon.
- Furthermore, Dovecot created an IMAP directory structure within the home directory of most users like "mail/.imap/INBOX" (on some it reused the existing Mail -uppercase- directory). Just on a simple first POP3 login. What's the reason for doing this? Maybe that user is never going to use IMAP? Does it test for both mail and Mail before it creates it's own structure or what does it do? I assume this is related to default_mail_env?
Most likely, yes. What do you have default_mail_env set to? If you haven't set it, Dovecot will try to auto-detect.
- Dovecot supports "auth plain", does it also support "auth login"? If so, how do I enable it?
Does 0.99 support this? Honestly, even though I still use 0.99, new installs should be using the latest 1.0 release ( currently 1.0beta4)
-- Curtis Maloney cmaloney@cardgate.net
Curtis Maloney wrote on Tue, 04 Apr 2006 09:16:07 +1000:
First, thanks for the quick answer!
I remember this bug... I'm sure it was fixed. Which version of the ancient-but-venerable 0.99 are they shipping with CentOS?
The rpm says 0.99.11. As you may know CentOS4 is based on RHEL4 and if you use it usally for the reason that you want to be able to get security patches and such for a longer time period than those meagre two years major distributions support their SOHO versions. Recompiling with each security patch is feasible if you have one or two machines, but not with more. So, I don't have a choice other than rely on rpms. I just checked and there's no 1.0 rpm on the dag repo which supplies a lot of updated rpms for the Red Hat bunch. Maybe that's because there's no official 1.0 yet. I don't know. Usually, you will also not want to install a beta or RC on production machines. So, what actually got fixed in later versions do you think? It doesn't do the chdir for POP logins anymore? If so, I assume it also doesn't try to create the IMAP folder structure anymore as I reported down below?
Check in the config file which users Dovecot is set to use. It may be that you need to chown the dir, or set Dovecot to use a different user. NOTE: There's more than one use setting in Dovecot, because of security and the auth daemon.
I use PAM, so the only option is running it as root, per the documentation. So, this should not be a problem. I also see the dovecot processes appear after login under their uid in ps. (That's unique, I haven't yet seen another application that doesn't show the username but the uid.) I don't know or can't detect at which stage exactly it switches to that uid, but it seems to me that at authentication time it cannot traverse to its directories although a user belonging to that primary group (and the user is a member) should be able to do so. Could there be a connection to the uid thing? Maybe it then doesn't "grab" the gid of that user and acts "group-less"? (speculation, I don't know how this works on Linux.)
- Furthermore, Dovecot created an IMAP directory structure within the home directory of most users like "mail/.imap/INBOX" (on some it reused the existing Mail -uppercase- directory). Just on a simple first POP3 login. What's the reason for doing this? Maybe that user is never going to use IMAP? Does it test for both mail and Mail before it creates it's own structure or what does it do? I assume this is related to default_mail_env?
Most likely, yes. What do you have default_mail_env set to? If you haven't set it, Dovecot will try to auto-detect.
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?
- Dovecot supports "auth plain", does it also support "auth login"? If so, how do I enable it?
Does 0.99 support this? Honestly, even though I still use 0.99, new installs should be using the latest 1.0 release ( currently 1.0beta4)
Yes, I tried it by telnetting in to both uw-imap and dovecot. Dovecot 0.99 supports auth plain (only) and uw-imap supports auth login (only). Interesting mix ;-) Do later dovecot builds support auth login? Unfortunately, there's no documentation on the wiki about the supported POP and IMAP commands.
Kai
-- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Kai Schaetzl wrote:
I remember this bug... I'm sure it was fixed. Which version of the ancient-but-venerable 0.99 are they shipping with CentOS?
The rpm says 0.99.11. As you may know CentOS4 is based on RHEL4 and if you use it usally for the reason that you want to be able to get security patches and such for a longer time period than those meagre two years major distributions support their SOHO versions. Recompiling with each security patch is feasible if you have one or two machines, but not with more. So, I don't have a choice other than rely on rpms. I just checked and there's no 1.0 rpm on the dag repo which supplies a lot of updated rpms for the Red Hat bunch. Maybe that's because there's no official 1.0 yet. I don't know. Usually, you will also not want to install a beta or RC on production machines.
Well, the last 0.99 version is 0.99.14, which has been running well for me for quite some time now. The only reason I haven't migrated to 1.0 yet is time.
So, what actually got fixed in later versions do you think? It doesn't do the chdir for POP logins anymore? If so, I assume it also doesn't try to create the IMAP folder structure anymore as I reported down below?
I don't recall the specifics, but they are available on the dovecot web site: http://www.dovecot.org/oldnews.html
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.
Check in the config file which users Dovecot is set to use. It may be that you need to chown the dir, or set Dovecot to use a different user. NOTE: There's more than one use setting in Dovecot, because of security and the auth daemon.
I use PAM, so the only option is running it as root, per the documentation. So, this should not be a problem. I also see the dovecot processes appear after login under their uid in ps. (That's unique, I haven't yet seen another application that doesn't show the username but the uid.) I don't know or can't detect at which stage exactly it switches to that uid, but it seems to me that at authentication time it cannot traverse to its directories although a user belonging to that primary group (and the user is a member) should be able to do so. Could there be a connection to the uid thing? Maybe it then doesn't "grab" the gid of that user and acts "group-less"? (speculation, I don't know how this works on Linux.)
- Furthermore, Dovecot created an IMAP directory structure within the home directory of most users like "mail/.imap/INBOX" (on some it reused the existing Mail -uppercase- directory). Just on a simple first POP3 login. What's the reason for doing this? Maybe that user is never going to use IMAP? Does it test for both mail and Mail before it creates it's own structure or what does it do? I assume this is related to default_mail_env?
Most likely, yes. What do you have default_mail_env set to? If you haven't set it, Dovecot will try to auto-detect.
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.
- Dovecot supports "auth plain", does it also support "auth login"? If so, how do I enable it?
Does 0.99 support this? Honestly, even though I still use 0.99, new installs should be using the latest 1.0 release ( currently 1.0beta4)
Yes, I tried it by telnetting in to both uw-imap and dovecot. Dovecot 0.99 supports auth plain (only) and uw-imap supports auth login (only). Interesting mix ;-) Do later dovecot builds support auth login? Unfortunately, there's no documentation on the wiki about the supported POP and IMAP commands.
There was some talk recently on the list, I believe, about LOGIN, though I didn't pay much attention, tbh.
-- Curtis
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
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
On Mon, 2006-04-03 at 23:01 +0200, Kai Schaetzl wrote:
I just transferred over my first server from Suse Linux with uw-imap(ipop3/imap2003) to CentOS with Dovecot (0.99). I didn't find any problems in the testing phase, but when the actual transfer into production happened I found a few problems crop up:
- Dovecot wants to chdir in the user's home directory even when logging in via POP3. However, the mailboxes for POP3 are all in /var/spool/mail. What's the reason for this and can I stop this?
See bottom of http://wiki.dovecot.org/MailLocation
- In addition I found that the home directories need additional permissions I did not need when using ipop3/imap2003, although this imap server needs to write/read in the same directories as dovecot. Specifically, I had to change the permissions on the directory right above the pop user directories from 750 to 755. Those directories are owned by the user and the primary group he belongs to. It seems that dovecot somehow doesn't "use" the primary group of the user and so can't traverse thru and the chdir fails.
Hmm. It should use it. If you used 1.0betas, you could check what exactly it's using as gid by setting mail_debug=yes
- Furthermore, Dovecot created an IMAP directory structure within the home directory of most users like "mail/.imap/INBOX" (on some it reused the existing Mail -uppercase- directory). Just on a simple first POP3 login. What's the reason for doing this? Maybe that user is never going to use IMAP? Does it test for both mail and Mail before it creates it's own structure or what does it do? I assume this is related to default_mail_env?
Although the directory is named .imap, it doesn't mean that it's IMAP-specific. Perhaps I should have named it ".dovecot" instead. Index files are stored there, and they can speed up accessing mails also for POP3 users who keep the mails in the server.
- Dovecot supports "auth plain", does it also support "auth login"? If so, how do I enable it?
1.0betas do.
participants (3)
-
Curtis Maloney
-
Kai Schaetzl
-
Timo Sirainen