Some user e-mails being written to /var/mail instead of being delivered to Maildir

[catdude]

A small handful of my users have their e-mail being written to /var/mail/<domaina_name>_<user name> instead of being delivered to the apropriate Maildir. I haven't been able yet to determine what sets these users apart. So far it's happening to 6 users out of more than 250.

I've verified that they have proper entries in /etc/passwd. I've also verified that they do appear in /etc/postfix/virtusertable, that they are listed in /etc/courier/userdb and that userdb.dat is current with userdb.

I've also examined the contents of the domain top level directory and of the user directory under the domain top level directory.

Any ideas as to why these few users aren't delivering normally?

[catdude]

Additional info to go with my previous post:
The users in question have not rached their mail quota (their mail quota is entered in the system as -1).

Mail log shows normal delivery:
Sep 14 11:31:46 ge postfix/local[3283]: C5F8B6D4039: to=<<cust domain>.com_jewelry@ge.<my work domain>.net>, orig_to=<jewelry@<customerdomain>.com>, relay=local, delay=0, status=sent (delivered to command: /usr/bin/procmail -f-)

The mail log entry for an e-mail that got delivered normally looks like:
Sep 14 11:29:51 ge postfix/local[3284]: C7EBA6D4039: to=<<another domain>.info_dan@ge.iowatelecom.net>, orig_to=<dan@<another domain>.info>, relay=local, delay=0, status=sent (delivered to command: /usr/bin/procmail -f-)

The users that are affected with this problem are all mail admin users. However, not all mail admin users are experiencing this problem.

[falko]

What's the output of repquota -avug, and what's in /etc/postfix/main.cf?

[catdude]

What's the output of repquota -avug, and what's in /etc/postfix/main.cf?

repquota -avug returns nothing:
ge:~# repquota -avug
ge:~#

/etc/postfix/main.cf contains:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

myhostname = ge.<my work domain>.net
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = /etc/postfix/local-host-names
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# DCM
virtual_maps = hash:/etc/postfix/virtusertable
unknown_local_recipient_reject_code = 450

#debug_peer_level = 12

[till]

Please execute the following commands:

postconf -e 'home_mailbox = Maildir/'
postconf -e 'mailbox_command ='
/etc/init.d/postfix restart

[catdude]

Please execute the following commands:

postconf -e 'home_mailbox = Maildir/'
postconf -e 'mailbox_command ='
/etc/init.d/postfix restart

I performed these steps, and mail for the users in question still goes to their mbox files in /var/mail.

After executing the commands shown above, mail.cf now contains:
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

myhostname = ge.<my work domain>.net
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = /etc/postfix/local-host-names
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command =
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

# DCM
virtual_maps = hash:/etc/postfix/virtusertable
unknown_local_recipient_reject_code = 450

#debug_peer_level = 12

home_mailbox = Maildir/

[till]

1) Is this a vserver?
2) Please post the output of:

df -h

[catdude]

1) Is this a vserver?
2) Please post the output of:

df -h

If you mean, are the affected users all in domains vhosted under ISPConfig, the answer is yes.

DocumentRoot is /its/isp/hosted. Mail for user@affecteddomain.com should be going to /its/isp/hosted/www.affecteddomain.com/useraffecteddomain.com_user/Maildir/new, is instead going to /var/mail/affecteddomain.com_user.

The handful of users experiencing this problem are constant - it's always the same 6 users, and all messages sent to these 6 users go to /var/mail. When new users are added, they experience normal mail delivery.


ge:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p2 28G 2.7G 24G 11% /
tmpfs 1.5G 0 1.5G 0% /dev/shm
/dev/cciss/c0d1p1 67G 689M 63G 2% /var
192.168.200.52:/webhost/hosts
40G 25G 15G 64% /its/isp/hosted
ge:~# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/cciss/c0d0p2 3719168 132802 3586366 4% /
tmpfs 222012 1 222011 1% /dev/shm
/dev/cciss/c0d1p1 8896512 5063 8891449 1% /var
192.168.200.52:/webhost/hosts
10297344 70103 10227241 1% /its/isp/hosted

[falko]

Did you restart Postfix?

What's the output of repquota -avug?

[catdude]

Did you restart Postfix?

What's the output of repquota -avug?

Yes, I've restarted Postfix several times.

ge:~# repquota -avug
ge:~#
(i.e. no output)

[falko]

Looks as if you aren't using quota.

Can you check the .procmailrc file of each of the six users (in the users' homedirs) and see if Maildir is enabled there?

[catdude]

Looks as if you aren't using quota.

Can you check the .procmailrc file of each of the six users (in the users' homedirs) and see if Maildir is enabled there?

MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
ORGMAIL=$MAILDIR

INCLUDERC=/its/isp/hosted/web1132/user/<her domain>_jewelry/.mailsize.rc

Likewise for the other users experiencing this problem.

[falko]

Looks good.

Can you check if the entries for these six users in /etc/passwd look different from the other users? Also check if they have unique user IDs.

[catdude]

Looks good.

Can you check if the entries for these six users in /etc/passwd look different from the other users? Also check if they have unique user IDs.

In the excerpt below, the <domain3> user is one of the 6 with this problem:

<domain1>.com_web:x:14942:10801:web:/its/isp/hosted/web801/user/<domain1>.com_web:/bin/false
<domain2>.com_cityclerk:x:13941:13281:City Clerk:/its/isp/hosted/web3281/user/<domain2>.com_cityclerk:/bin/false
<domain3>.com_jewelry:x:15012:11132:Jewelry:/its/isp/hosted/web1132:/dev/null
<domain4>.com_akelley:x:11531:10561:A Kelley:/its/isp/hosted/web561/user/<domain4>.com_akelley:/bin/false
<domain4>.com_all_staff:x:11541:10561:All staff:/its/isp/hosted/web561/user/<domain4>.com_all_staff:/bin/false
<domain4>.com_ayoung:x:11551:10561:A Young:/its/isp/hosted/web561/user/<domain4>.com_ayoung:/bin/false


The user in <domain3> is defined as admin user in her domain.

Also,
ge:~# grep 15012 /etc/passwd
<domain3>.com_jewelry:x:15012:11132:Jewelry:/its/isp/hosted/web1132:/dev/null
ge:~#


I also looked at /etc/postfix/virtusertable:
ivan@www.<domA>.com <domA>.com_ivan
<domA>.com_ivan@www.<domA>.com <domA>.com_ivan
ivan@<domA>.com <domA>.com_ivan
<domA>.com_ivan@<domA>.com <domA>.com_ivan
jewelry@www.<domB>.com <domB>.com_jewelry
<domB>.com_jewelry@www.<domB>.com <domB>.com_jewelry jewelry@<domB>.com <domB>.com_jewelry
<domB>.com_jewelry@<domB>.com <domB>.com_jewelry
richard@www.<domA>.com <domA>.com_richard
<domA>.com_richard@www.<domA>.com <domA>_richard
richard@<domA>.com <domA>.com_richard
<domA>.com_richard@<domA>.com <domA>.com_richard
jmdavis1@www.<domA>.com <domA>.com_jmdavis1
<domA>.com_jmdavis1@www.<domA>.com <domA>.com_jmdavis1


where jewelry@<domB>.com and ivan@<domA>.com are both experiencing this problem.

[falko]

Can you enable FTP for the web sites where this happens so that the users' shell gets changed from /dev/null to /bin/false?

[catdude]

Can you enable FTP for the web sites where this happens so that the users' shell gets changed from /dev/null to /bin/false?

I did so, and verified that the user's shell got changed from /dev/null to /bin/false. I also manually rebuilt Courier's userdb and manually reloaded postfix just to be sure everything is current. It didnt' make any difference - mail for the affected users still goes to /var/mail/<domain>_<user>

FWIW, other users who have /dev/null for their shell are receiving mail to their Maildirs just fine.