Hi,

I'm trying to take all my messages flagged as spam and forward them to a local account that is spam@localhost, not a mail folder called spam. A completely separate email account called spam.

The code I was using below is:

This code seems to just get into an endless loop though reprocessing the mail for spam until it runs out of processes. This usually takes a few minutes and then the mail shows up in the spam@localhost account's mailbox. The headers on the email show it's been forwarded from the original incoming email to spam, then spam forwards it to spam, etc etc. Sendmail's logs also verify this is happening.

I'd like a solution that properly does what I asked above, and also an explaination of why my solution doesn't work. It seems that the first time a spam message comes into any email address, it will process it with spamc if it's less than 256000 bytes, no problems so far.

Then spamc is done with the message and the next rule checks if the X-Spam-Flag is "YES" and if X-Loop is NOT equal to "spam". Since this is the first time we've seen this message both these conditions are true. Formail does it's job and appends the X-Loop: spam header onto the email and sends it off to spam@localhost.

The problem happens at this point. The message is queued up again and examined by procmailrc as it's being sent to spam@localhost. The message is still less than 256000 bytes, let's process it for spam again (I could probably put another * !^X-Loop: spam statement here to prevent it checking the message for spam twice I think?) but then when it gets down to the second set of conditions it should not execute the formail statement because I set X-Loop: spam on the previous iteration.

Procmailrc should now get to the bottom of the file without doing anything and leave the message in spam@localhosts mailbox I would think. But it seems to just keep processing it over and over and over.

Any help? It would be greatly appreciated, I've been messing with this thing on and off for like a month!

Bump

If you just make a personalized .procmailrc file only for your user (or make it then copy it to all other users) rather than using a global one, that will fix your problem. Then it won't run the spam check on e-mail that goes to your spam address. Oh, and bumps really aren't necessary, and in fact they annoy most people who would help you.

I guess that's one solution, but I was looking for something that I could apply sitewide. I don't want to have to copy this custom procmailrc file to every user on the mail server. I just don't see what's causing the loop, it's baffling me.

I finally got it working without the infinite loop. Here's the new code:

Basically I added the !^FROM_DAEMON statement in there to prevent infinite loops. That's what the X-Loop:spam is supposed to do, but oh well. You may be able to remove the last 2 conditions from the first ruleset, but I don't want to mess around with it too much now that it's working.

This is working somewhat for me, but my users are still getting a ton of spam email that has been flagged. Is there a reason that using these rules isn't simply re-directing the message to the spam account? Is the formail rule forwarding a copy and still sending an original to the recipient? I am seeking a way to redirect the mail so the original intended recipient doesn't receive the spam.

Occasionally this happens to me too, basically my fix was to give spamd an additional number of threads to work with. What seems to happen is that at peak times, my spamd gets overwhelmed by the number of messages that it has to process, and while it SHOULD just queue them up, it doesn't. I know this because I'll get a blatantly spam email and I'll look at the headers to see why it wasn't marked as spam, and spamd won't even have processed it. At first I would just restart the server, and when it came back up, it processed spam fine. Then I realized "duh!" all I have to do is shut down and restart spamd to clear out all the threads. But then I just modified the startup script for spamd to give it a couple more threads and it doesn't seem to happen anymore. Please look at the header in your blatantly spam emails that are getting through and see if spamd is even processing them for spam. If it is, and the spam level is above your threshold, then my procmail script has a problem (which it doesn't seem to for me, but I'm sure we can work it out). If it is, and the spam level is below your threshold, well then you need to customize your rules or lower the spam threshold because procmailrc is doing what it's supposed to. If it's not being processed for spam at all, try my theory about increasing the number of threads dedicated to spamd and let me know if that seems to solve it.

I attempted to add an additional check, which seems to have helped but I still don't think it is quite right. Maybe my file isn't quite right:

:0 fw
* < 256000
| /usr/bin/spamc -f -u mail

:0
* !^FROM_DAEMON
* ^X-Spam-Flag: YES
* !^X-Loop: spam
| formail -A "X-Loop: spam" | /usr/sbin/sendmail -oi spam@company.com

:0
* !^FROM_DAEMON
* ^X-Spam-Status: YES
* !^X-Loop: spam
| formail -A "X-Loop: spam" | /usr/sbin/sendmail -oi spam@company.com


How do I increase the threads? My concern here is that right now I only have two users processing mail thru that server but it will be about 150 once we go live. If it is letting spam thru processing email to 2 users, I can't imagine what is going to get thru to 150. The subject line is being re-written with *****SPAM***** so I know it is being processed. But for some reason, messages are still being delivered.

I think it's so odd that SpamAssassin hasn't released any code on their site to solve this particular problem. All the code on their site assumes that you're using IMAP so it puts the spam into a particular folder. I know us two cannot be alone in wanting to filter all spam to a particular email address, it seems like it would be a popular solution to spam, but I haven't found any good code out there to do it.

That being said, an additional check shouldn't gain you anything, it should do it right the first time. Admittedly I tried that myself when debugging my script, but it doesn't seem to do anything but bounce it one more time. I was looking at your code again just as I typed this though to make sure you had everything the exact same as mine, and I noticed that I tweaked my code since my original posting, so disregard everything said previously!

The middle block of code creates a copy of the message for processing the rule, and cuts the spam score out of the header and puts it into /var/log/spam. This is just a cute little rule I put together so I can statistically keep track of my spam scores. Basically I watched 1,000 spam messages and put their scores into /var/log/spam and then did some analysis to determine what my spam threshold should be. Sort of a fun little experiment if you want to get a good threshold.

ANYWAY, the important part is that I basically added two lines to the first rule that tells spamc to process the message for spam, and all my problems went away. I asked it not to check the message for spam if it already has been checked on a previous iteration, (if X-Spam-Flag is NOT 'Yes', and if X-Loop is not 'spam').

Try out your spam filter for a couple days with those two additional lines of code and let me know how it does.

P.S. I don't know what flavor of Linux you're running, but to increase the number of children for spamd and the number of threads per child:

(or /etc/init.d/spamd, or wherever your init script for spamassassin is)

Find the SPAMOPTIONS variable, and do like -m 8 or -m 10 or something. That will increase the number of children. You can also add --max-conn-per-child=8 or 10 or whatever you need. Multiply the two together to figure out how many messages spamassassin can process at once. This will depend on your processing power and the demand on your server.

Whew! I'm glad my reply got posted, I hit the submit button but I must have taken too long to draft it because it like timed out, and when I entered my password in again it said I was replying to an invalid thread! Glad my reply got there though.

I have made the modifications. I will let you know what the results are. I created the spam file in /var/log as it didn't get created by default when hitting the first message. Not sure if it will track them or not, but I put it in for the sake of curiosity.