homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Home / Forums Index / Hardware and OS Related Technologies / Linux, Unix, and *nix like Operating Systems
Forum Library, Charter, Moderators: bakedjake

Linux, Unix, and *nix like Operating Systems Forum

procmail: Unable to treat as directory
Fedora 10 + Postfix + Procmail

 10:50 pm on Mar 20, 2009 (gmt 0)

I am getting errors relating to the way Procmail is configured, however I am having big problems configuring it in a way that makes sense.

I am set up using Qmail-style mailboxes ($HOME/Maildir/).

I modified /etc/postfix/main.cf to reflect that and can send and receive mail just fine. With Procmail installed and enabled, I now get Procmail errors, one of which is the subject of this thread: "procmail: Unable to treat as directory"

I modified the source (configure.h and then autoconf.h, which is the file that really needed editing, but wasn't created until after installation) to set the MAILDIR variable to "$HOME/Maildir", DEFAULT (mail directories) to "$MAILDIR/", and the ORGMAIL (ORiGinal MAILbox) to "$DEFAULT". Nowhere in my configuration is "/var/spool/mail/anything" indicated. Note that used to be the default mailbox setting for Procmail, and it was completely unresponsive to attempts to modify that variable's value using the normal means, like including the setting in a procmailrc file. Just ignored it. (I could tell by running "procmail -v", plus there were lots of errors indicating that Procmail was trying to write to /var/spool/mail/USERNAME until I made those mods.)

So now "procmail -v" displays the correct settings. Frankly, I don't know why Procmail would need to write anything to ANY directory except for /dev/null, as I have NO forwarding rules, no locking rules ... nothing but "dump 'em if you see 'em" rules.

Since I have a lot of users who used to work with this company but who are now gone and still receiving valid messages from older clients, I use aliasing to direct their mail to valid accounts with Maildir's. These are all system (not virtual) users for many reasons. These are most of the accounts that produce Procmail errors. So I went through each user's configuration and adjusted their HOME directories to ALL point to the same "/home/catchall" directory, even though that directory should NEVER receive any mail for those users.

Of course, now I get errors about how Procmail can't create "/home/catchall/USERNAME" directories. I say "of course" because Procmail runs as the recipient user, and no user has permission to modify anything in the "catchall" directory.


The thing is, I was getting the same errors when their HOME directories were the traditional "/home/USERNAME", and in any case, the "procmail: Unable to treat as directory" error remains regardless of who's Maildir it is.

Scouring the web for about a week turns up the same bogus "fix", which is NOT to make the modifications I made, but rather to accept the default setup and simply MAKE /var/spool/mail CHMOD 777! World-executable! This goes against every notion of directory security I have ever learned.

Does anyone have anything to contribute that might be newer than 2003? The Procmail mailing list is useless, as their advice is to do the 777 thing. Same with Postfix lists.

Is it possible that Postfix and Procmail simply do not work well together?

Thanks for any tips and thoughts.



 9:30 pm on Mar 24, 2009 (gmt 0)

And the answer is: Don't mess with Procmail

I decided to start over (user-wise) and see what Postfix/Procmail would do, all by themselves.

I deleted all of my user accounts and then reinitialized them using a "clean" etc/skel. i.e. There was no mention of any type of mail directory in the template folder, just the usual shell and basic init settings.

Once that was done, I had a fresh group of near-empty home directories for the users, associated with the appropriate groups and login permissions. I had done nothing to address any mail functions with this set of users.

This differs markedly from the previous setup (and from every other installation I have done over the years), in that I ignored everything having to do with mail when creating the users and their home and mail directories. In my last attempt, I had added a Maildir with child cur, new and tmp directories to /etc/skel so that every new user had those ready to receive mail.

That was the problem. No matter how I set the permissions, Procmail ALWAYS disliked them and treated them as BOGUS and could not figure out how to treat them as directories.

By leaving out all mail directories during account creation, and by adding one modification to the way in which mail was handed off to Procmail by Postfix, I now have a setup where new mail directories are created by Procmail as they are needed and using permissions and ownerships that it recognizes.

So, to sum up:

1) Created new users like this:

useradd -g USERGROUP -m -s /sbin/nologin -b /home -c "User Name" USERNAME

2) Home directories used the contents of the default /etc/skel directory:

.bash_logout, .bash_profile, .bashrc, .gnome2

3) Modified /etc/postfix/main.cf:

WAS: mailbox_command = /usr/bin/procmail -t

NOW: mailbox_command = /usr/bin/procmail -a "$EXTENSION" DEFAULT=$HOME/Maildir/ MAILDIR=$HOME/Maildir

4) Restarted Postfix

That's it. No more "Unable to treat as directory" or any of the other errors noted above.

For the record, here are the changes I made to config.h before compiling and installing Procmail from source. These mods change the default mail directory to a QMail-style directory and removes individual procmailrc files in favor of one master file:

#define DEFmaildir "$HOME"
#define PROCMAILRC "$HOME/.procmailrc"

#define DEFmaildir "$HOME/Maildir"
#define PROCMAILRC "/etc/procmailrc"

Global Options:
 top home search open messages active posts  

Home / Forums Index / Hardware and OS Related Technologies / Linux, Unix, and *nix like Operating Systems
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved