Take the 2-minute tour ×

I've been beating my head against a wall for a while now on this one. Basically, here is the rundown:

Our MX record points to a frontend SMTP server, which contains aliases for actually routing the mail. No alias, no access to the backend storage server, which is what our clients connect to.

I'm upgrading the backend email server. Currently, a user is created for every email user on the server, which creates the mailbox. On the new server, everything autheticates through PAM to an LDAP server (all of which is working properly). My goal is to get Postfix to create the Maildir directory for the user automatically. This works fine when I have the /home directory with 777 permissions, but for obvious reasons, this should be avoided. I would like to do this with 775 permissions on /home with a group owner of whatever user Postfix is running as, but I can't seem to figure out what user to use. With the 777 permissions, the /home/$user/Maildir directory is created on message delivery. Does anybody know how I can do this without 777 permissions?

The system I am working on is a 64-bit Debian Lenny 5.07 install.

Any advice would be appreciated.

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

The answer to this varies depending on how your Postfix system is configured. You mention pam and LDAP, so I assume you have all your domains in $mydestination, or you use only one domain (example.com, for instance)

It may be easier for you to configure virtual_mailbox_domains with LDAP maps instead of mysql/pgsql maps (the logic is exactly the same though).

You create a single system user, without login privileges. I shall assume a username and group of vmail:vmail here, but the specific name is not important.

In LDAP, create your mailbox path relative to $HOME for vmail (so the maildir becomes /home/vmail/user/Maildir/).

Add your domains to virtual_mailbox_domains. Create a virtual_mailbox_maps map which takes in the username as input and returns username/Maildir as output.


virtual_mailbox_domains = example.com
virtual_mailbox_base = /home/vmail/
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual.cf
virtual_uid_maps = static:$uid_of_vmail
virtual_gid_maps = static:$gid_of_vmail
#$uid_of_vmail and $gid_of_vmail are obtained from the output of 
#id vmail
in main.cf.

See http://www.postfix.org/ldap_table.5.html and http://www.postfix.org/VIRTUAL_README.html for more information (and what you need to put in ldap_virtual.cf).

FWIW, Postfix runs the local delivery process as the uid/gid of the system user you are delivering to.

The general permissions for /home are 755 with owner and group both root, but the user can write within ~user. Hence Postfix will happily deliver to ~user/Maildir/, but will not be able to create ~user. Using virtual users will sidestep this issue by granting access to all mailboxes to a single uid/gid, which is then accessed only by your pop3/imap software. Direct access to the mailbox by users will not be possible.

share|improve this answer
add comment

If postfix (which is a member of the mail group) can't write to the directory, it won't be able to complete the delivery. The secret is to get the mail group to have read-write access in the user's home directory. 775 will be enough to get postfix into /home; but once there, it might not be enough to allow it to create a directory in /home/$user, because the group assigned is probably not mail, and the owner certainly isn't mail, and the world bits are most assuredly not set to rwx. So, for postfix, it's "no soup for you".

As a stop-gap measure, you could always set the group of the user's directory to mail, but I really don't recommend this.

A better solution would be to use extended attributes, available in EXT3 and EXT4. This would allow you to define multiple groups, not just one. So you could add the mail group to every user directory with rwx, not r-x, bypassing the problem and allowing directory creation.

Just curious, why not use /var/spool/mail/$user and be done with it? Using that arrangement would solve the entire issue; the group for the directory is defacto mail, bypassing the entire "I need 777" issue. I can only guess that you have a need to NFS-mount user home directories or somesuch.

share|improve this answer
The reason we are doing things the way we are is because the /home/$user directory might not exist depending on whether or not the user has ever connected to the server. This is because the users are all authenticate through LDAP, thus they might not have a home directory on the server if they have never authenticated before. Your explanation makes perfect sense. I'll have to come up with some other way to accomplish what I am trying to do. –  Eugene Jan 6 '11 at 19:14
add comment

Your Answer


