On Tue, Aug 19, 2003 at 04:23:00PM +0300, Timo Sirainen wrote:
On Tue, 2003-08-19 at 03:18, Bob Hall wrote:
FBSD 4.8, Dovecot-0.99.10 1)
From maillog: Aug 18 16:39:46 kongemord imap(philrodrigues): mkdir_parents(/var/mail/philrodri gues/.imap/INBOX) failed: Permission denied
All files and directories in /var/mail/* are in the mail group. I tried adding dovecot to that group, but that didn't help.
Since everyone can log on to Dovecot, but can't access their mail unless I own their files, I'm assuming that there's some simple ownership setting that I'm overlooking. But I haven't a clue what it is. Can someone tell me what I need to change?
What userdb are you using? Dovecot gets the uid/gid for users from
The userdb is ldap. What are the uid and gid supposed to do? I have the default uid in dovecot-ldap.conf and the individual uidNumber and values in the LDAP registry set to the mail account (the one I want to own the mail files). The default gid and the individual gidNumbers are set to the mail group, which is the group assigned to all files in /var/mail. If the mail account owns the files, users can't access them. If I own the files, everthing works fine, but my uid and gid numbers are not listed anywhere that dovecot has access to. I know that imap-master checks uids and gids for validity, but aside from that I don't know what they're used for.
I thought that maybe the fact that I'm a wheel and the mail user is not had something to do with it, but adding the mail account to the wheel group had no effect. I tried adding dovecot and the mail user to the mail group, again with no effect. I still have to be the owner of the mail files.
there. Whatever you do, don't use the "dovecot" user's uid there :) Rather create a new one. Hm. Maybe I should rename it to dovecot-login to make it more clear what it's supposed to used for..
I don't think that will make it clearer. Both dovecot.conf and "ps waux | grep dovecot" make it clear what the dovecot processes are used for. If you name it dovecot-login, I think it would be just as easy for someone to get confused and try to use the dovecot uid for themselves, in the belief that they need it to log in.
I think you're at a point where you need to think about how you are going to explain Dovecot to users. If relatively ignorant users like me can install it easily and securely, then Dovecot will have a reputation for being easy to use and secure. If we don't know how to install Dovecot easily and securely, then it will get a reputation for being complicated and insecure, regardless of the reality. An application's reputation, earned or unearned, tends to be established by the lowest tier of users. If I feel I understand how to install and set up Dovecot, then I will feel that my installation is secure. If I have doubts about what I've done, then I'm going to have doubts about my security. And I don't think you want to spend all your spare time explaining Dovecot to us foolish beginners.
- The Macs have Eudora 4.2 installed, and the Win boxes have Eudora 5.1. The Macs can delete mail, put it in the trash, and empty the trash. The Win clients can mark mail deleted, but they can't remove it. The mail stays in the IMAP folder until the same user accesses their mail from a Mac and deletes it. If a user drags a message to another folder, a copy is created in the new folder but the old copy remains in the original folder. I'm not having this problem with Mutt, so it the problem seems to be specific to the Windows verson of Eudora. Is there a fix?
Are there error messages in log file? /var/log/maillog probably. I can't think of any reason why it does that..
No. Nothing in maillog, and nothing in dovecot.rawlog. That's something else I'm confused about: When exactly does Dovecot write to the raw logs? I've got a boatload of entries from 20030814, and nothing before or since.
Also, I get the following in the output from "ps waux | grep dovecot":
dovecot 1004 0.0 0.9 2208 536 ?? S 7:58AM 0:01.48 imap-login: imap-login [IP address] (imap-login)
The machine at [IP address] is physically shut down. Should there still be an imap-login process for it?