On 07 March 2002, Bart Schaefer said:
> Got this reply from the procmail list. Are you (Greg and/or Daniel) sure
> that you're using the proper procmailrc lockfile syntax on recipes that
> deliver to mailboxes?
I don't think locks are relevant in my case, since the bogus message was
forwarded to another address, not saved locally. Here's my setup:
* mail to [EMAIL PROTECTED] (the address that was affected)
is received by qmail on starship.python.net; my .qmail file
consists solely of
| preline /usr/bin/procmail
* my .procmailrc exists mainly to run each message through SA;
spam is saved to a local Maildir, and real mail is forwarded
to my ISP address. procmail never writes to an mbox file.
Here's the start of my .procmailrc:
DEFAULT=/home/crew/gward/Maildir/
SPAM=/home/crew/gward/Maildir.spam/
LOGFILE=$HOME/procmail.log
PERL5LIB=/usr/local/lib/site_perl
[EMAIL PROTECTED] (censoring my ISP address)
And here's the stuff for running SA:
# Filter through SpamAsssassin
:0fw
| spamassassin -P
# Make procmail exit with spamassassin's exit code
:0e
{
EXITCODE=$?
}
# Flagged as spam?
:0:
* ^X-Spam-Status: Yes
$SPAM
# And send everything else home
:0
! $FORWARD
What happened yesterday is that I screwed up editing
/etc/spamassassin/local.cf, causing spamassassin to crash on startup.
So presumably my pipe-through-SA rule failed, causing the next rule to
set EXITCODE to SA's exit code (70, as it happens -- I just reproduced
my error to check).
I surmise that what happened next is procmail forwarded the input
message, minus that leading "F", to my $FORWARD address. Presumably,
qmail-inject assumed it was being fed a bare message body, so it tacked
on headers for me. The message that ultimately landed in my inbox (also
a Maildir, but on a different machine) looks like this:
Return-path: <[EMAIL PROTECTED]>
[...skipping Received headers...]
Date: 8 Mar 2002 18:33:04 -0000
Message-ID: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
Cc: recipient list not shown: ;
rom [EMAIL PROTECTED] Fri Mar 08 18:33:03 2002
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
[...rest of the test message I just sent to myself with a
broken /etc/spamassassin/local.cf ...]
Anyways, since the only options are write to a Maildir or forward to
another address, I don't see how locking is relevant. The other
possibility...
> b) that some other program is accessing the mailbox without using a
> locking method in common with procmail.
... doesn't seem relevant either, since there is no mailbox to speak of.
procmail is just forwarding to another address, ie. ultimately piping
the message through qmail-inject. (Well, probably qmail's sendmail
substitute.)
Note that yesterday, the exact same thing happened to five messages in
succession. As soon as I fixed local.cf, my mail was fine again. So
it's not some random, timing-sensitive lock-related race condition.
Greg
--
Greg Ward - software developer [EMAIL PROTECTED]
MEMS Exchange http://www.mems-exchange.org
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
