procmail
[Top] [All Lists]

Re: Incorrect Resolution of $HOME Variable

2009-03-31 16:22:34
For the record:
== system info ==
Fedora 10
Postfix 2.5.5
Procmail 3.22
=================

When you set the directory permissions to 777, this allows it to create
the destination files for Maildir format. Who is listed as OWNER and GROUP
for those created files? Might offer a bit hint.

Correct. Except that I do not have my directory permissions set so
permissively ... that was just to test whether procmail was capable of
writing MAIL to any directory. Here are my permissions, and procmail can
create Maildir folders within that structure, it just can't do the
MESSAGES:

/home = 755
/home/user = 700
/home/user/Maildir = 700
/home/user/Maildir/cur = 700 <= has mail in it
/home/user/Maildir/new = 700 <= has mail in it
/home/user/Maildir/tmp = 700 <= has mail in it

Procmail insists on going further by adding a nest of unused directories
within that active Maildir:

/home/user/Maildir/user = 700 <= nothing but Maildir in it
/home/user/Maildir/user/Maildir = 700 <= nothing but empty directories
/home/user/Maildir/user/Maildir/cur = 700 <= has no mail in it
/home/user/Maildir/user/Maildir/new = 700 <= has no mail in it
/home/user/Maildir/user/Maildir/tmp = 700 <= has no mail in it

/home/user on down are owned by user:USERGROUP.

This structure is very much like the output from 'procmail -v':

"Your system mailbox: $HOME/Maildir/user"

where $HOME = /home/user

As long as mail has NOT matched any procmail recipe, destination
directories in the Maildir format are created by procmail as
user:USERGROUP.

The ONLY issue arises when a recipe is matched and procmail needs to
change or fork the original delivery destination. Hence my focus on
procmail.

If a message matches any procmail recipe, the process breaks ... no
directories are created and no message is delivered UNLESS I set the perms
to 777 from /home on down. THEN, procmail can deliver a message to
whichever directory I tell it to (in other words, I have to explicitly
specify '/home/user/Maildir/new', which results in a message file using a
non-Dovecot naming style, of course, and which is not indexed by Dovecot,
of course, because it hasn't been processed through Dovecot.)

Are you using DROPPRIVS before you try to deliver?

Without DROPPRIVS, new destination files are created (by procmail) as
root:USERGROUP

(root's normal GROUP is 'root', so, for example, with a message addressed
to 'lawyer1(_at_)example(_dot_)com', 'root:USERGROUP' might be something like
'root:Attorneys' where 'Attorneys' is the GROUP assignment for the user
'lawyer1'.)

With DROPPRIVS, new destination files are created as user:USERGROUP

(For example, 'user:USERGROUP' might be something like 'lawyer1:Attorneys'.)

I have DROPPRIVS currently enabled in /etc/procmailrc. Delivery of a
matched message fails, regardless of the DROPPRIVS setting.

Then there is something very wrong with your compile of procmail as
procmail requires no such thing.

I can get behind that. I did not modify anything in config.h or in
authenticate.c (or autoconf.h, after 'make') except for those changes
dictated by the procmail docs that described setting
MAILDIR=$HOME/Maildir.

I have also tried installing from an RPM, but that was borked from the
start because I couldn't change anything in the way the program compiled,
so it compiled for Sendmail/mbox delivery.

I have also tried installing from a SRC RPM, which, of course, just gave
me the same files as any tarball would.

I have also tried installing from tarballs obtained from locations other
than the procmail repository.

This installation has never had procmail working with the Maildir-style
mailboxes.

I have used procmail for many years on Sendmail/mbox boxes. This is my
first Postfix/Maildir box.

I'd like to take this opportunity to ask whether any of you who are using
Maildir delivery can duplicate the results of my 'procmail -v' output? Is
your "Your system mailbox:" displayed as "$HOME/Maildir/user", like mine
is? This seems to be a fundamental difference in my output from any other
output I have seen online.

That is why I originally chose that simple test to illustrate my primary
question about this installation of procmail, which is:

Can anyone think of any reason why the default '#define DEFmaildir
"$HOME"' in config.h would result in "Your system mailbox:
/var/spool/mail/user"

and

'#define DEFmaildir "$HOME/Maildir"' would result in "Your system mailbox:
$HOME/Maildir/user"?

If nobody but me is seeing an unresolved $HOME variable when procmail uses
that variable to display "Your system mailbox:" output, then it raises
much larger questions.

======
If you don't mind, I want to move away from the 'deliver' issue that is
sidetracking us a bit, and focus on my procmail issue.

I started trying to use 'deliver' because procmail's delivery into a
Dovecot IMAP structure was simply not to Dovecot's taste, with non-Dovecot
file naming structures and with procmail delivering that mail without
updating Dovecot's index, which is not the way Dovecot needs it to be
done.

I posted info about the 'deliver' issue, after posting my long, detailed
report on procmail symptoms and settings, because I hoped it would shed
some light on the procmail issue, which I believe is related, simply
because everything else on the system is functioning quite well, and as
long as procmail doesn't need to do anything except pass the message
through without a match, the mail system works just fine.

If you need information that is missing from this note, please see if I
have not already posted it in the 'long note', which is the third one in
this thread. That note may contain useful information that I have not
duplicated, here. If not, I am happy to post whatever might be useful.

Oh, I executed the 'procdiag.sh' script Mr. Straw wrote, but it seems to
be designed only for systems running Sendmail, as Mr. Straw's is, and so
it provides very little information, and does not recognize that procmail
is being called by my Postfix config file (mailbox_command). I can post a
[redacted] copy of its output, if anyone thinks it might be useful.

I apologize for the length of this note. I am trying to find the most
simple way to explain this.

Thanks.

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