MailScanner: September 2004 Archives

Spam Assassin 3 was released the other day, so I started rolling it out across as many servers as possible. We had already been testing it on a couple without encountering any issues, so putting the stable version should have been quite easy. In most cases it was, except for one Red Hat 9 server. It simply refused to go on properly. If I got it past the install, either via CPAN, tar.gz or Julian's RPMs it would not pass the spamassassin --lint test After struggling with it for over an hour I gave up and rolled it back to 2.64, which works fine. I've also ordered the book from Amazon, so I'm waiting to see if it covers anything I haven't thought of or come across:

A number of people reported severe problems with the bitdefender update scripts yesterday. Seemingly the processes were hanging and eating up CPU. Kevin Spicer found a good interim solution: vim /usr/lib/MailScanner/bitdefender-autoupdate Comment out the following two lines: LINE 190 system "$bitDCmd > $origFile "; LINE 253 system "$bitDCmd > $destFile "; You then need to kill any bitdefender update processes. Most of them are "bdc", so you can run: ps auxwww|grep bdc but I also found a few with "bitdefender" in the string. Thanks to Kevin for solving this! EDIT: This issue was resolved by the developers a few days later

Julian released a set of scripts to install Spam Assassin RC3 yesterday for both rpm and non-rpm based distros. You can get them here and maybe you'll have more luck with them than I did :mrgreen: I couldn't get it to work on the Whitebox machine I was trying to install it on, as it would not overwrite the contents of /usr/share/spamassassin After trying to rectify this in a number of ways I finally opted for a "clean" install using the tar.gz from the Spam Assassin site. Word of caution: If you are using custom rulesets you may need to remove them first, as a lot of them are now part of SA3's code. There are a number of new features in SA3 that should make it more interesting: - Mail::SpamAssassin::Plugin::URIDNSBL - SURBL - available via a plugin that ships with it. I must have a closer look at the scoring on this -Mail::SpamAssassin::Plugin::SPF - Checks for SPF content -Mail::SpamAssassin::Plugin::RelayCountry - fairly obvious, though I'm not sure what we can do with the output -Mail::SpamAssassin::Plugin::Hashcash - not 100% sure what that does :smile: Update: I did a bit more research into Hashcash. The concept is quite interesting. In essence you "earn" the right to send email by "spending" CPU cycles. As each email requires you to "spend" resources before you can send it a spammer would not be able to send the same volume of email, while a "normal", "legitimate" user would not even notice the slight delay. More information is available on the Hashcash site.

/usr/lib/MailScanner/MailScanner/CustomConfig.pm contains a number of handy little features that are not "on" by default. One which came up on the list today was IPBlock which allows you to control the maximum number of emails from a particular IP per hour. This might be useful for combatting infected machines spewing email at servers, but it still does not address the issue of the connection to the MTA. Vispan can also achieve this. It would be interesting to implement something like this that interfaced directly with IPTables instead of the MTA.