Page 1 of 1

Which RBL etc. - Spamdyke

Posted: Mon Jan 02, 2012 3:07 am
by jpkelly
I recently implemented Spamdyke with the following RBLs enabled:
zen.spamhaus.org
bl.spamcop.net
bogons.cymru.com

Soon after I got a call from a customer saying emails from RoadRunner and Gmail accounts were getting blocked.

I disabled all RBLs but zen.spamhaus.org
and added to DNSWL: list.dnswl.org

Not really sure how this will work though.

I appreciate any thoughts on the use of RBLs.

Re: Which RBL etc. - Spamdyke

Posted: Mon Jan 02, 2012 11:49 am
by scott
One option would be to move them out of the smtp layer, and into spamassassin. Then you'd just have a score based response rather than an allow/deny event.

Re: Which RBL etc. - Spamdyke

Posted: Mon Jan 02, 2012 1:02 pm
by faris
Been there and done that. I just LOVE this sort of thing.

The bottom line is that you need to balance performance, faslse positives and false negeatives.
Unfortunately the right balance will be different for each customer, but luckily SpamDyke can handle that for you without too much hassle.

The only blacklists which you can safely use at the smtp level is the spamhaus list (e.g. zen). Even then you might experience problems from time to time, but these are manageable.

Personally I don't want to waste cpu cycles on spammers. This means filtering as much at the smtp level as I can. This starts with blocking IPs with no rdns and blocking everything on the zen list, both via spamdyke. No exceptions, unless a customer has a problem receiving from a legitimate sender with misconfigured email server, in which case we're willing to whitelist that sender.

After this, I use customer-domain-level options. For my own domains, I block all sorts of things that might normally be prone to false positives. For example rdns that does not forward resolve to an IP, and email "from" domains with no MX records (this is quite false-positive prone - even email from big "names" fail this test when they use subdomains for outgoing email (e.g. newsletter@email.domain.tld) but no such subdomains for incoming (e.g. domain.tld).

Next I add the spamcop list, sorbs list* and barracuda list and for a complete block on my domains (not recommended for customers! * stopped using sorbs -- got fed up with it after it got sold).

Actual customers do have the option to use my "strong" options if they want basically no spam but plenty of false positives, or they can use the normal option which moves spamcop, barracuda, hostkarma, and several other blacklists to the Spamassassin scoring system, as well as disabling no MX, forward resolving, and a few other things.

We also whitelist certain things both in SpamAssassin and Spamdyke (different things usually). Such whitelisting woul normally be asking for trouble (e.g. if you were to whitelist all AOL or MSN addresses in SpamAssassin you'd be up to your eyeballs in various Nigerian 419s), but so far our combinations, which change from time to time, seem to be doing the trick.

Actually we've found the 419s to be the hardest to deal with because they are usually sent via legit senders, and can only be filtered by their content.

Re: Which RBL etc. - Spamdyke

Posted: Tue Jan 03, 2012 3:04 am
by jpkelly
Thanks faris!
That is a big help.
Now Spamdyke is working for me without a ton of false positives.

Can you give any thoughts on Spamdyke greylisting?

Or DNSWLs like list.dnswl.org?

Re: Which RBL etc. - Spamdyke

Posted: Tue Jan 03, 2012 9:28 am
by faris
Graylisting is generally 100% free of false positives as long as you get customers using your servers to send email via authenticated smtp to use port 587 (without spamdyke).

However, although I've not looked at my stats recently, I'm not sure how effective it actually is at reducing spam. It used to be very useful indeed. I suspect not so much now.

dnswl.org - not really looked into that on the spamdyke level. I do use it in SpamAssassin.

I did forget to mention one other things that we do, which reduces spam massively. We have our own dnsbl set up, and include all known IPs for as many "bad" countries as we can. South Korea springs to mind but I don't want to reveal to many details here.

Of course it might be better to do this at the firewall level, but by doing it via a dnsbl and spamdyke, we can adjust which countries are blocked on a customer to customer basis. For example we have one who needs to receive email from a normally blocked country, and we can allow this very easily (because we have various sub-lists on the dnsbls, so we can use some or all or none depending on the customer)