On Thu, Jan 31, 2008 at 09:48:20PM +0100, Karsten Bräckelmann wrote: > 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. ;)
Oops - I was busy replying to your last message and didn't see this one come in... > > 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? Ahh.. Interesting! I commented out that block and my test message still caused the error message.... BUT... I think it's only the test message that causes the error (I'm testing with "procmail < tmp/testmail" where testmail is a made-up header + body with the right address. I've got a tail running on the logfile so I'll just have to wait for one of those spams to come in (there's never one when you need one!). > > > <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. ;) Opps - cut + paste error sorry. > > > > # 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. Ahhh that's very helpful! I have in the past had problems where SA has been overwhelmed by a sudden rush of spam and has literally locked up the PC. My solution was to limit my fetchmail (which runs every 3 minutes) to collecting only 20 mails at a time - which seems to be manageable. But your solution should be better. Thanks. > > > 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. No - nor me. But maybe it's just a problem with my test message (I'm still waiting... Perhaps I'll just try an old "real" one out of my corpus). > > > > 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 Your help is much appreciated. Mark
pgpH5OjGEj728.pgp
Description: PGP signature
