Re: [Asrg] 7. Best Practices - DNSBLs - Article

["Chris Lewis" <[e-mail]>]

Brad Knowles wrote:

> At 9:21 PM -0400 2003/09/07, Chris Lewis wrote:
> 
>>  For example, I can tell you that 2.5% of the email that got through
>>  would have been caught except for latency delays in our BLs... ;-)

>     Do you know what the latency delays are?  For example, if you 
> implemented greylisting and enforced a minimum 30 minute delay before 
> you allowed them to get through the greylist, for what percentage of 
> these messages would that 30 minute delay have been enough for them to 
> show up on the BLs?

We're considering greylisting as an adjunct to our filters.  However, 
since we have 8 inbound gateways, it could get rather messy.  A 
simple-minded implementation with a half hour delay would have a four 
hour worst-case delay...  Not acceptable.

Due to how our DNSBL system works (we do our own zone downloads), and 
with a eye to not bashing the DNSBL originating servers too much, the 
latency (for 3rd party DNSBLs) averages around 12 hours.  So, 
greylisting-delay-for-DNSBL-catchup isn't going to help (us).

Most of the third party DNSBLs have an average latency on the order of 
an hour or two (or considerably longer) when querying them directly[1]. 
  So, even by switching to real-time queries, it still wouldn't help 
greylisting (unless you were willing to deal with that much longer 
latencies). Only spamcop is any faster.  And SpamCop we won't use, 
because its FP level is too high (for a organization like us).

That being said - I don't think it's necessary to tune your greylisting 
timeout w.r.t. DNSBL latencies.

The simple fact of the matter is that open proxy/socks code will _not_ 
queue - so they won't try a second time[2].  I would strongly suspect 
that if you made your greylisting timeout _zero_, and simply 400'd the 
first appearance of a given sender/IP/recipient tuple and accept the 
next appearance, no matter how quickly, you'd still be getting 90% of 
what greylisting with a very long timeout would give you.

Of course, spamming tools will evolve, so then you consider increasing 
the timeouts.  Too far, tho, and it's worse than where you started.  And 
I don't think you'd ever get to where you'll be able to take into 
account DNSBL latency.

>     Have you incorporated tools like DCC or Razor into your 
> methodology?  Do you know how greylisting with a minimum delay time 
> (e.g., 30 minutes) would effect DCC and/or Razor, in terms of their 
> efficiency?

[1] Do also consider that our 2.58% number is based over a 14 _day_ 
interval.  There's no way of telling the distribution of that DNSBL 
"catchup" over the 14 days.  I don't think the DNSBL latencies on 
individual IPs is anywhere near close to the latency of update. Ie: 
there's no particular reason why a given IP hits the third party DNSBL 
detector at the same time it first hits you.  It takes time (as much as 
hours) for decent/"polite" open relay/proxy testing.

So, short of perhaps the CBL (and SpamCop of course) which doesn't do 
server testing, it's not possible to get latency down _that_ short even 
for direct query.

[2] That's not _entirely_ true, I've seen some spammers that retry 550's 
after DATA several times very quickly (within minutes).  Not sure 
whether that's proxy or relay behaviour.


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg