procmail
[Top] [All Lists]

Re: Incorrect Resolution of $HOME Variable

2009-03-30 16:43:46
On 30-Mar-2009, at 14:17, James Butler wrote:
On 30-Mar-2009, at 12:17, James Butler wrote:
On a related note, I have been trying to get Procmail to pipe over to
Dovecot's DELIVER application to get messages into the Dovecot IMAP
structure,

Why?

Dovecot uses Maildir

MAILDIR=$HOME/Maildir/

:0
.fred/


Please see my "long post", the third in this thread, for all the gory
details. Summing up: Procmail CAN deliver a message to a Maildir IF I set /home = chmod 777, /home/user2 = chmod 777 and /home/user2/Maildir = chmod 777, (chmod anything less fails) all of which are undesirable, however the
Procmail-delivered message is unusable to the Dovecot structure, which
uses a vastly different naming convention and chokes on the file names
generated by procmail ... if I ever decided to make all of those
directories world-executable, which I won't. I have detailed this in my
second, long, post.

Um... my $HOME is 755 and $HOME/Maildir is 700 and the actual maildirs inside are also 700. Why would dovecot require 777? Is your dovecot mail not owned by the user? Are you SURE you are delivering correctly? I know lots of people using procmail+dovecot.

<http://wiki.dovecot.org/MailboxFormat/Maildir>

Notice the last line:

The proper way to configure procmail to deliver to a Maildir is to use Maildir/ as the destination.


The terminal slash is *required*.

Also:
<http://wiki.dovecot.org/MailLocation/Maildir?highlight=%28%28MailboxFormat%7CMaildir%29%29 >
By default Dovecot usese Maildir++ directory layout. This means that all mailboxes are stored in a single directory and prefixed with a dot. For example:

        • Maildir/.folder
        • Maildir/.folder.subfolder


Which is exactly how my procmailrc is writing mailboxes. individual files are named

1234567890.88750_0.mail.covisp.net:2,

where 123456780 is epoch time, the 88750 are a random number seeded of the milliseconds, mail.covisp.net is the mailserver, and the whle name is designed to be unique. What do your names look like?

procmail IS failing to resolve that variable. So that probably
counts as a PROBLEM, Mr. Straw.

Logs showing this?

Which log would show this more plainly than my example output from
'procmail-v' that began this thread? I will gladly post its output.

procmail -v is NOT proof that procmail is not expanding the variable.

a .procmailrc that says

LOG=$HOME/test.log
VERBOSE=ON
COMSAT=YES

:0
$DEFAULT

Showing the mail being delivered somewhere other than $HOME/Maildir would show that procmail is not properly expanding the $HOME.

And I'd be interested in those logs, as would others on the list.

There's something very wrong with your machine, and I don't think it is procmail.

--
Of pleasures, those that occur most rarely give the
        most delight


____________________________________________________________
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