procmail
[Top] [All Lists]

Re: Incorrect Resolution of $HOME Variable

2009-04-01 19:20:41
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.

Of course, you are correct. $HOME comes from (in my case) /etc/passwd

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
location.

So why does procmail think $HOME/Maildir/ is equivalent to
/var/spool/mail? SELinux issues? chroot issues?

Excellent! This reflects what I am seeing with 'procmail -v':

Your system mailbox: $HOME/Maildir/user

Note that this is verbatim ... $HOME is presented exactly like that,
without being resolved.

So take that ($HOME/Maildir/user) and add MAILDIR (/Maildir) and you get
what I've got: /home/user/Maildir/user/Maildir

It's not an SELinux issue, because that essentially deals with
permissions. I'm pretty confident about that.

Maybe a chroot issue? Hmmm. The man pages say that everything is relative
to MAILDIR. So procmail might be taking $MAILDIR ($HOME/Maildir/) and
appending its tree to it ($HOME/Maildir/user/Maildir...).

This sounds like it is failing to resolve the $HOME variable, instead
treating is as a string literal, which is then prepended onto the string
to resolve during runtime, which is when $HOME is resolved. So maybe there
IS a chroot or some runtime user permissions issue of some sort.

I wish I had more process evaluation tools for this, independent of what
procmail provides with its logging function.

By the by, does 'user' contain any unusual characters, or is the user
name strictly alphanumeric?

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
match.

What happens if you make the target of a rule $DEFAULT?

In my /etc/procmailrc I've got:

MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

(And no match means successful delivery.)

If not set it in a procmailrc, $DEFAULT would = $ORGMAIL. $ORGMAIL, unless
modified by a procmailrc = /var/spool/mail/$USER

This is the most thought-provoking bit, yet.

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
it has.

No it's NOT! If that were true, it would deliver to:
/home/user/Maildir/home/user/Maildir

Your logic is infallible. ;) Mine seems to be slightly queasy ...

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.

I'll try to get some more investigating in while the office is closed,
just to try and solve this. I really appreciate your thoughtful response,
Charles. It's guys like you (and Michelle) that kept me coming back to
this list.

The bad news is that I am under orders to get some other filtering process
together so I can put this new server into action. I'm out of time. As a
result, I'll probably be abandoning Procmail in favor of Dovecot's Sieve,
which installed without modification, earlier today.

Thank you very much, Charles.

James

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>