On Wed, 1 Apr 2009, James Butler wrote:
I had thought that this was true: default $HOME = /var/spool/mail/user
Actually, no THAT should never be true. $HOME should always in some way
equate to the user's home directory. So $DEFAULT would = the above, but
$home should *always* be the user's 'home' path from the password file
until you explicitly define it.
modified $HOME = /home/user [my system shows this for 'echo $HOME']
therefore: $HOME/Maildir/ = /home/user/Maildir/ But procmail does
something different, in my case: $HOME/Maildir/ =
/home/user/Maildir/user/Maildir/ This is my main question: Why would
procmail add the extra 'user' substructure when it comes time to deliver
The 'clue' comes in the repetition of "Maildir/". Clearly for this to
happen, the word "Maildir" is REPEATED in TWO different specifications
that are concatenated to make the final result. If $HOME is correct, then
we must presume the concatenation occurs in steps:
$HOME + "Maildir/" + "user/" + "Maildir/"
With "user/" appearing in the middle, it can be said that some portion of
procmail's logic has been 'convinced' that $HOME + "Maildir/" is of the
same level of specification as "/var/spool/mail/". Procmail wants to
append a "user/" then the specified folder, "Maildir/" from a third
So why does procmail think $HOME/Maildir/ is equivalent to
/var/spool/mail? SELinux issues? chroot issues?
By the by, does 'user' contain any unusual characters, or is the user
name strictly alphanumeric?
.... it is failing to deliver the message into the IMAP structure
(new/cur/tmp) when a message matches a rule. IT DELIVERS JUST FINE WHEN
THERE IS NO MATCH!
This statement has GREAT significance. This means that the 'delivery line'
of the rule is somehow *different* from the 'default' when there is no
What happens if you make the target of a rule $DEFAULT?
I have no idea why procmail is having an issue when a rule is matched.
Is there some piece of code in there somewhere that says, "if (MATCH)
then MAILDIR = MAILDIR+MAILDIR" ? Probably not, but it's behaving like
No it's NOT! If that were true, it would deliver to:
No, you've got something more subtle going on. It's like it's taking the
value of $MAILDIR and attempting to append a partial path after it. Almost
like you have a THIRD setting for a barebones "Maildir/" which somehow
tells procmail to treat $MAILDIR as a system directory, but only for
matching rules. I would suggest you look for occurences of "Maildir" in
your specifications, and CHANGE each one to a test value, for example
MailFOLDER and MailPLACE, so that you can tell which occurences of
"Maildir" are being used at each place in that generated path.
procmail mailing list Procmail homepage: http://www.procmail.org/