Richard Laager wrote: > On Tue, 2006-01-17 at 17:30 +0000, Paul Murphy wrote: > >>For more background, search the mailing list archives for "Blocking spam >>senders using IPTables?". > > > Before I spend a lot of time searching... Did you post the script, or > just notes on the idea? > > Thanks, > Richard >
I did something similar to this to reduce the spam (and load). Whenever I get a message I put the remote smtp server IP address in a sql table along with a timestamp, SA score, and counter. This lets me know what the SA average is for any host connecting. Now that I know what the averages are, I query this information during the filter_recipient function and bounce messages where we have at least 5 messages to average on, and where that average is higher than the spam threshold that is read out of our ldap directory for that user. So lets say that a user has the spam sensitivity set to high (5) and we have a zombie connect and pass 5 messages that average 7 points. On the 6th message the zombie will pass the mail from and rcpt to, then mimedefang finds that the average is higher than the users threshold and bounces the message. To keep the database cleaned up I delete all records that have not been updated for 24 hours every hour. This change basically limits zombies to 5 messages before they are rejected, which saves the system from running SA on messages that are almost certainly spam. I don't have exact numbers but the mail load on the system dropped significantly. I need to update my graphdefang config so that I know the exact statistics, but haven't got to it yet. The only drawback that I have found to this solution is users that forward all of their mail to our mail system. After the change several called and complained that the forwarding broke because the forwarded mail was mostly spam which caused the remote mta to get rejected. I told the users that the forwarded mail is mostly spam and that the provider forwarding the mail was indeed relaying spam. Every user had their issues resolved by either asking us to remove spam filtering from their account or asking the forwarding provider to filter messages for spam before they forward. The reason why I did it this way instead of iptables was because we need to be able to adjust the spam filtering on a per user bases. This is why we don't make any decisions on the message until after the rcpt to and ldap lookup. I also wanted to make sure that the support address always works because all of our bounce messages say to email support for help. This has worked very well for us since someone will run into a problem, then email support, which has spam filtering disabled (100 point threshold). When the helpdesk gets the message they simply look at the header which tells them exactly why the message was rejected and allows them to walk the user though how to fix it. If we had gone with iptables we wouldn't be able to leave our abuse, postmaster, and support addresses open, and users would be rejected without an error message explaining exactly what happened. Since rejected email only costs us one ldap and one sql lookup we will live with that since those things are really cheap compared to mimedefang and SA. Hope this helps someone. schu _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang