Just completed a transition of birdhouse hosting to a new machine (in the same data center) with a greatly increased monthly bandwidth ceiling, and have been able to raise bandwidth caps for all customer account levels.
Also took the opportunity to upgrade SpamAssassin to version 3, which, among other enhancements, supports SURBLs — Spam URI Realtime Blocklists. SURBLs essentially use the same logic as Movable Type’s blacklisting system – rather than trying to analyze content or block sender addresses or IPs (which are moving targets), SURBLs hit spammers where it hurts by blocking messages that include blacklisted URLs.
The downside of using SURBLs alone is that messages containing URLs that are not yet blacklisted slip through the net. But by combining SURBL scanning with content analysis, and by using distributed/collaborative blacklisting systems, you end up way ahead of the game.
Had to modify some of my customer’s SpamAssassin rulesets to work with the new syntax in SA3, but now that we’re dialed in, spam blocking seems to be more effective than ever – we’re catching about 98-99% of unwanted mail prior to delivery. w00t!
I send you this comment in order to have your advice.
I am Mister Ngolo Sutu Thala, son of Nigerian herbal Viagra merchant. If you want largers penising, please of trying my online Texas Hold ‘Em Poker site.
We exchange links, you are affiliate.
Clouded vanilla discus propensity foreground quail pyjamas silent sheep abrading toasters.
See, if only that comment had included a dangerous-looking URI, we could have nabbed it!
mnep – you’re now on deck for this year’s Comment of the Year award.
Ha ha ha! That was a great!
By the way Scot, how hard do you rate the setup of SpamAssassin? Fairly easy? Also, you you allow people to opt out of e-mail filtering?
Jeff –
Initial setup is not difficult. I usually use RPMs (urpmi) but in this case wanted the latest, as well as the accompanying libs and devtools, so built from source. No problems there.
Once installed, configuration was a bit more involved because I’m running a plugin (CGPSA) for the CommuniGate Pro MTA, so I had both its config files and SpamAssassin’s to deal with, and things are spread around in a number of directories. There are also things like setting the locations for the bayes and whitelist databases, making sure permissions in CGP were appropriate so that SpamAssassin can access the right places, etc. The important thing is to run
spamassassin –lint -D to test your rule sets. The output is hairy but interesting. It will tell you if it’s choking on any rules. I also had to remember to unload and reload the plugin after making changes or the changes wouldn’t be seen.
Creating custom rulesets that are not standard issue can be tricky if you haven’t done it. For example, some blog comment spam can trigger SA as it rolls in and get deleted without the blog owner seeing it, so I had to build rules to detect those and give them an extremely low score so they wouldn’t be deleted by the customer’s spam threshold rules.
birdhouse has a high threshold over which all spam is deleted, and that is not user configurable, but below that threshold, customers can set any level of tolerance they like, and can also opt to have junk dropped in a server-side spam box rather than deleted.