Are you using Cerb4’s anti-spam system efficiently?
Community, Tips & Tricks January 14th, 2009
posted by Jeff Standen
Configuring groups to quarantine probable spam.
Cerb4’s anti-spam system is a huge saver of both time and sanity, but it has the potential to be used inefficiently if it’s used “as is” once your helpdesk is running. Here is an overview of how Cerb4 deals with spam, along with tips based on our own workflow (at WebGroup Media) to get you started:
http://wiki.cerb4.com/wiki/Best_Practices:Dealing_with_Spam
Enjoy!
-Jeff@WGM
3 Comments to “Are you using Cerb4’s anti-spam system efficiently?”
Leave a Comment
You must be logged in to post a comment.
[...] best theory at the moment is that by freak coincidence a bunch of customers followed the instructions we sent out last night to purge their spam histories at exactly the same time (we’re happy people found the [...]
Hi,
Thanks for the write-up, helped me tweak things even further.
In recent days, in Cerb4 as well as GMail there’s an influx of Russian character spam. As per your write-up, Cerb4 removes non-standard characters so according to the Spam Analysis, it’s an empty e-mail. Without tokens, it’s hard for the system to judge whether it’s legit or not.
Is anyone else getting this and is there are way to have this spam-analysed? Is anything in the works to get these mails?
As an example (sorry if this mentions really bad stuff), I get this:
любые методы массажа ( лица и тела), косметические маски, пилинг,
Under the Spam Analysis tab, it results in no tokens and hence no spam score.
Any ideas?
@Jim
Hey there! Yeah, we tend to get a lot of Ukrainian/Russian spam that gets through too (koi8-r charset).
I’m planning on adding a quick ‘anti-spam’ config area to ‘helpdesk setup’ where you’ll be able to blacklist certain charsets. If there’s no way you’d read or receive Russian/Ukrainian/Japanese/Chinese/etc messages then the helpdesk could just always toss them based on their encoding. Right now you can set up a Pre-Parser rule to do that based on the “Content-Type” header, but it’s not 100% reliable since multipart message bodies can encode differently than the envelope. The new option I’d like to add will introspect the actual content and should get rid of most of it.
I’ll try to get that tweak into the next update. :)
-Jeff