On Wed, Jan 30, 2008 at 09:56:49PM +0100, Karsten Bräckelmann wrote: > On Wed, 2008-01-30 at 20:12 +0000, Arthur Dent wrote: > > On Wed, Jan 30, 2008 at 08:22:55PM +0100, Karsten Bräckelmann wrote:
Sorry Chaps, I had no idea this topic would grow so much.
>
>
> Do file-locking, when delivering to mbox files. Don't for Maildir.
I do use mbox not maildir.
>
> When delivering, let procmail figure out the appropriate lock. In cases
> where you don't deliver (filters, variable setting, pure nested logic,
> whatever), either don't lock, or give a specific lock file IFF you want
> it. For example, when filtering through SpamAssassin, you want a lock,
> to prevent too many consecutive SA running.
I still don't quite get it (see below).
> > This is what I have so far:
> > :0:
>
> Don't lock here. :)
>
> > * [EMAIL PROTECTED]
>
> It is useless to continue matching, if you don't care about the content.
> The trailing '.*' does nothing, but keep procmail busy.
>
> > {
> > :0 fhw
> > * ^Subject:\/.*
> > | formail -i "Subject: [SPAM (XXX)] $MATCH"
> > }
> >
> > :0:
> > * ^Subject:.*\[SPAM \(XXX\)\].*
> > IN-Spam
> >
> > I could not find a way to combine the matching, subject rewriting and moving
> > into one step (is this possible?).
>
> No. There may be exactly one action. Either a filter, or delivering.
> However, unconditional receipts pretty much do exactly that.
>
> > The above method works but give me the following error message in my
> > Procmail
> > log:
> >
> > procmail: Extraneous locallockfile ignored
> > From [EMAIL PROTECTED] Wed Jan 30 19:47:28 2008
> > Subject: [SPAM (XXX)] This is a test
> > Folder: IN-Spam
>
> procmail is right there. ;) No need for locking...
>
> Below is a receipt, that should do what you want. Again: This is NOT
> tested. The comments should be self-explanatory, as to when we want or
> need locking. Also, it should add the spam tag to the subject even if
> the original message does not have a Subject header.
>
> Basically, we don't need to check for anything inside the loop. The one
> condition exists only, to grab the existing Subject.
>
>
> # catch bad numerical To: headers
> # no locking here, since this block does not deliver
> :0
> * [EMAIL PROTECTED]
> {
> # grab the subject, if any
> :0
> * ^Subject: \/.*
> { SUBJECT = "${MATCH}" }
>
> # add the subject spam tag in either case
> :0 fhw
> | formail -i "Subject: [SPAM (XXX)] ${SUBJECT}"
>
> # deliver unconditionally (since we're here, we know we want to treat
> # it as spam), DO LOCK here
> :0 :
> spam
> }
Fantastic! This worked perfectly "out of the box"! (just edited mydomain).
Thank you Guenther!
When I moved it from my test rig to the live server however I ran into a
couple of problems. I still have a record locking problem (though not the same
as the one you fixed). I have put below a more complete extract of my
/etc/procmailrc file.
<PMRC EXTRACT>
#Start processing section
# Put a copy of ALL mail into a backup folder
:0c:
*
/mnt/backup/mail/rawmail
# First remove some known spam patterns
# catch bad numerical To: headers
# no locking here, since this block does not deliver
:0
* [EMAIL PROTECTED]
{
# grab the subject, if any
:0
* ^Subject: \/.*
{ SUBJECT = "${MATCH}" }
# add the subject spam tag in either case
:0 fhw
| formail -i "Subject: [SPAM (XXX)] ${SUBJECT}"
# deliver unconditionally (since we're here, we know we want to treat
# it as spam), DO LOCK here
:0 :
IN-Spam
}
# Virus filter
:0fw
| /usr/local/bin/clamassassin
:0:
* ^X-Virus-Status: Yes
IN-virus
# Spam filter
:0fw
* < 256000
| /usr/bin/spamc --username=mark
:0:
* ^X-Spam-Status: Yes
IN-Spam
### Sort Mail in various folders ###
...
</PMRC EXTRACT>
The key thing is that first element. I am so paranoid about losing mail that the
very first thing I do is make a copy of each and every raw-unprocessed mail
and store it in a backup partition (which I archive to disk every month).
This now seems to cause a lock problem on these number spams (and only these)
in a way that it never did before:
procmail: Lock failure on "/mnt/backup/mail/rawmail.lock"
From [EMAIL PROTECTED] Thu Jan 31 18:00:43 2008
Subject: [SPAM (XXX)] This is a test
Folder: IN-Spam
I know I something wrong but what. To me, the copy-to-backup should be locked
while it is delivering (no?) and then the normal processing should continue as
if that never happened... or am I missing something?
Sorry to to continue this OT thread and take it yet further OT, but I am soooo
nearly there...
Thanks again!
Mark
pgpOnNJLUmUsc.pgp
Description: PGP signature
