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