Since I was about to hit the send button on this one, here is a shorter
version of my original thoughts. Partially on-topic (yay!) again. ;)
> Fantastic! This worked perfectly "out of the box"! (just edited mydomain).
Good. :)
> 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.
Since the receipt did work during your testing -- assuming, you fed it
some of the numerical spams, too -- the problem CAN NOT be with the
receipt to catch the numerical To header spam early. The problem must be
somewhere else with your live procmailrc file.
Did you try commenting out that block?
> <PMRC EXTRACT>
> #Start processing section
> # Put a copy of ALL mail into a backup folder
> :0c:
> *
> /mnt/backup/mail/rawmail
Get rid of the superfluous, empty condition. I don't know if this might
trigger the issue, and frankly doubt it. However, it is useless and
irritating. ;)
> # Spam filter
>
> :0fw
> * < 256000
> | /usr/bin/spamc --username=mark
If there is even the slightest chance, your MTA might flood your MDA
with mail during a peek -- add some explicit locking here, even though
this is not a delivery receipt (explicit, because it is a filter, and
procmail can't lock the target file). IIRC the SA docs do have a lock
there, too.
:0 fw: spamassassin.lock
* < 512000
| spamc
If you don't lock, you might end up with more mail being piped to spamc
consecutively, than your spamd can generate children.
> 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:
I don't see why this should be limited to these particular messages.
> 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
The failing lock clearly is related to the backup copy receipt. However,
it should *not* be requesting the lock itself.
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
