7 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Maildir - creates...
FromSent OnAttachments
SteveAug 10, 2006 12:31 pm 
Jay LeeAug 10, 2006 12:45 pm 
Gordon MessmerAug 10, 2006 12:47 pm 
Ben KennedyAug 10, 2006 12:55 pm 
SteveAug 10, 2006 5:05 pm 
Phillip HutchingsAug 10, 2006 5:47 pm 
Jeff JansenAug 11, 2006 2:01 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Maildir - creates file called maildir in mbox formatActions...
From:Jeff Jansen (ivb_@sil.org)
Date:Aug 11, 2006 2:01:46 am
List:net.sourceforge.lists.courier-users

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Steve wrote:

What I get is mail delivered to a file in the user directory called "Maildir" If I use the maildirmake utility, the mails will sit in the queue forever (or until they expire.)

If courier is creating the file "Maildir" then that's where it expects to deliver the mail . So it expects to find a "maildir" directory called "Maildir" in that location. When it doesn't find one, it creates a standard mbox message file with the same name and sticks all your mail in there.

So the first step (as you realized) is to create the directory "Maildir" for your users in that location using the maildirmake utility that comes with courier.

If mail is sitting in the queue after that instead of delivering to Maildir, then there should be a message in your logs telling you what's wrong. Have you looked in /var/log/maillog to see what it says about failed delivery attempts?

One simple reason it might not be working is the ownership of the maildir. If you used the maildirmake utility, then the permissions and directory structure should be correct, but the ownership could be wrong. Courier delivers mail as the "owner" of that mail account. The process changes UID first and then delivers mail. It knows who owns the account based on where it looks the account up. If you're delivering mail for system user 'steve' then courier will first change to become user 'steve' and *then* try and deliver the mail. So if you created the directory "/home/steve/Maildir" as root, then courier is NOT going to be able to deliver to that directory because user "steve" doesn't have permission to enter and write to that directory. (Maildirs are have permissions: rwx------.)

If you using virtual accounts defined in userdb, mysql, etc. then somewhere in your definitions, you should have specified which system account owns each virtual mail account. On my server all virtual accounts are owned by system user "courier". So when a message comes in for one of my virtual users, then the courier program first becomes system user "courier", then it tries to deliver the mail to the Maildir specified in that record.

So check the ownership of the Maildir directories. Make sure the they are owned by the same system account as courier is going to use to deliver the mail. The easiest way to do this is to create the maildir using the maildirmake utility as the actual owner. Become user 'steve' to create steve's maildir, become user 'courier' (or whomever owns your virtual users) to create the virtual users' maildirs, etc. But if that's not possible (or already been done incorrectly) then you can always "chown -R <username> Maildir" and it ought to work after that.

And do check the maillog. There should be something in there which tells you why it can't deliver. Incorrect ownership is just my guess based on my own (many!) mistakes, but the log should tell you more of what's gone wrong.

HTH

iD8DBQFE3EeRZxtYeNk78A8RAuomAJ98pNjRefoS8QBTov/oS7xO/vfDQwCdGFbd fkxXhznyhug5LMo/2CDFUtc= =Fbnj -----END PGP SIGNATURE-----