[Dshield] Blocking Country Access

Tony Earnshaw tonni at hetnet.nl
Thu Feb 22 02:54:41 GMT 2007

Tomas L. Byrnes wrote, on 21. feb 2007 19:16:

> It depends on what you are blocking, and why. The DShield lists are of
> port scanners, which is more akin to the coyotes coming into your yard
> and trying to get in the cat door to get at your cat. threatSTOP
> provides those, and the TQM lists, in a form that your firewall can
> block on.
> If you're blocking SPAM @ the MTA level, and you are using RBLs, then I
> don't see the difference in security effect or probability of collateral
> damage of having a rule that blocks the first SYN @ the firewall, where
> it costs you a 64 byte TCP SYN, as opposed to using an MTA block, where
> you have to accept the connection, do a DNS lookup, and then send the
> 500 message. It costs you a lot less CPU and BW, and the spammer doesn't
> typically try more than one connection, because they don't see port 25
> as open at all.

We do use RBLs when all other blocks (including greylisting) have been 
passed. See my answer to Dave Hatz for one of these. We only use cidr 
subnet blocks on networks we're pretty sure will never send us bona fide 
mail and we *analyze each and very refused connection (including cidr 
blocks)*, every day and several times per day, so that we get the chance 
of unblocking/whitelisting clients that on reconsideration don't merit 
blocking. We get to see the whole smtp conversation, namely.

If we were blocking at firewall level, we'd never get to see all this. 
Hence my remark on "cutting the cat's throat".

> IOW: Dropping a connection that you are going to drop @ the MTA @ the
> firewall saves you bandwidth, and CPU on the MTA, for the exact same
> effect that you get with an MTA RBL.

The point of our using RBLs at all, is that they are dynamic. We are 
relying on 4 carefully chosen authorities to judge for us; anyone on 
their block lists can get off them again by repenting without us having 
to lift a finger. We also use other, empiric blocks relating to client 
behavior, specifically conformance to rfc2821.



Tony Earnshaw
Email: tonni at hetnet dot nl

More information about the list mailing list