Secondary benefit from greylisting's delay

[Adam Katz <an...@khopis.com>]

John Hardin wrote:
>>> Igor, you might also want to implement greylisting, to give the URIBLs a 
>>> chance to list URIs that appear in these messages.

Ned Slider responded:
>> Interesting concept - do you have any data to support the hypothesis?

John Hardin shrugged:
> Nope.

I have anecdotal evidence supporting it; after I train+report a spam, I
have SA parse it a second time.  On occasion, it has hit another
spamtrap or two (in addition to hits from the places I reported it to:
DCC, Pyzor, SpamCop, and my local Bayesian db), though perhaps it had
hit some of the places I was reporting to as well.

Here's a logical defense if you prefer:

Many MTAs now implement some sort of delay (mine uses 1.8s) before
anything can happen in an SMTP transaction.  This has the direct benefit
of stopping some spam bots from delivering mail (supporting data:
http://acme.com/mail_filtering/sendmail_config.html ), but it also has a
second benefit:  spam can't be sent out so quickly when so many of its
recipients force it to wait for delivery.

So if you're at the beginning of a blasting of spam and a spamtrap is
later on, or if somebody has reported the message after it was delivered
to you, it will appear in the online indexes (and not just URIBLs; don't
forget DNSBLs and all the hash-sharing systems).

Like the delay before the SMTP greeting, greylisting is a great way to
stop spam botnets.  The secondary benefit of delayed network tests in SA
is often overlooked as it is admittedly far less profound than the first
benefit.

Re: Secondary benefit from greylisting's delay

[Rik <hl...@buzzhost.co.uk>]

On Sun, 2009-04-26 at 15:06 -0400, Adam Katz wrote:
> John Hardin wrote:
> >>> Igor, you might also want to implement greylisting, to give the URIBLs a 
> >>> chance to list URIs that appear in these messages.
> 
> Ned Slider responded:
> >> Interesting concept - do you have any data to support the hypothesis?
> 
> John Hardin shrugged:
> > Nope.
> 
> I have anecdotal evidence supporting it; after I train+report a spam, I
> have SA parse it a second time.  On occasion, it has hit another
> spamtrap or two (in addition to hits from the places I reported it to:
> DCC, Pyzor, SpamCop, and my local Bayesian db), though perhaps it had
> hit some of the places I was reporting to as well.
> 
> Here's a logical defense if you prefer:
> 
> Many MTAs now implement some sort of delay (mine uses 1.8s) before
> anything can happen in an SMTP transaction.  This has the direct benefit
> of stopping some spam bots from delivering mail (supporting data:
> http://acme.com/mail_filtering/sendmail_config.html ), but it also has a
> second benefit:  spam can't be sent out so quickly when so many of its
> recipients force it to wait for delivery.
> 
> So if you're at the beginning of a blasting of spam and a spamtrap is
> later on, or if somebody has reported the message after it was delivered
> to you, it will appear in the online indexes (and not just URIBLs; don't
> forget DNSBLs and all the hash-sharing systems).
> 
> Like the delay before the SMTP greeting, greylisting is a great way to
> stop spam botnets.  The secondary benefit of delayed network tests in SA
> is often overlooked as it is admittedly far less profound than the first
> benefit.
> 
Sure, it may not be able to send it out as quick, but as it is usually
somebody Else's bandwidth I'm sure the average spammer is not sitting
back and pulling their hair out for a bit of tarpitting. 

You could also argue the delay has a detrimental effect. Certain systems
are looking to detect spambot IP's by 'x' connections seen in 30 minutes
on a detector gateway. If you delay a message by a few seconds it is not
totally inconceivably that the connection rate drops back adding a delay
to the detection. If everybody started to do it how much latency could
this add to spotting the trend of an IP?

Greylisting and tarpitting are amusing to watch from a telnet prompt,
but the average bot really does not care if you want to keep wasting
your own resources. It's a network cuckoo usually. I can see the logic,
but the coin has two sides.