Re: [Asrg] An Anti-Spam Heuristic

[Chris Lewis <[e-mail]>]

On 12-12-16 06:50 AM, Alessandro Vesely wrote:
> On Fri 14/Dec/2012 05:39:21 +0100 Chris Lewis wrote:
>> Ooh, quantitative ;-)
>>
>> For grins, I took one of my smaller spamtraps and applied a 30 second
>> banner delay.  I wanted to quantify
>>
>> "And a lot of spamware doesn't flunk."
>>
>> In the timestamps below, the change happened at 04:52.
>>
>> Flow per minute:
>> [snip]
>>     156 2012/12/14-04:51
>>      30 2012/12/14-04:52
>>
>> A 3:1 spam reduction is nothing to sneeze at.

Small update: Kelihos and Lethic are stopped dead with a 30 second
delay.  Unlike previous reports, Festi actually appears unaffected.

These tests were very short duration and given the small size of the
trap, it's sometimes difficult to tell the difference between natural
flow variation and clear effect.  With Lethic and Kelihos it's
absolutely unmistakeable.  Festi looked at first, but it wasn't doing
much anyway and later showed it wasn't dead.

> You need at least 15 daemons accepting 2 msgs/minute each to get 30
> messages, while at, say, 60 msgs/minute 3 daemons can take 180.

The trap is 20 simultaneous daemons, _each_ multi-threaded (event driven).

When pushed, the traps can have several thousand SMTP sessions
simultaneously in progress.

We weren't anywhere near hitting a limit.

Obviously, this can be a consideration - I wouldn't want to set a
several minute delay on one of the traps currently doing 700 emails/second.

I've tried this on two of our smallest traps for this very reason - and
this is why I was only able to relate the effects on the very highest
volume bots.

[One of our traps is capable of and has _seen_ sustained thruput of 6-7
_thousand_ per second.]

> Can you confirm the max-daemons limit wasn't hit?

Yup, see above.

> On a real MX, rather than being fixed at 30 seconds, the banner delay
> should be made proportional to the spammitude reckoned for the sending
> IP.  Sort of tarpitting, perhaps not the FUSSP itself, but...

Right.  I did this as simply as I could.  In production, you'd want
something much smarter.

The idea isn't to "punish" (like tarpit), the idea is to distinguish as
simply and cheaply as possible what is highly non-RFC-compliant, and
ignore ignore them from then on.

Something like;

> if (this is the first time in t0 seconds you've seen a given IP)
>    then
> 	banner delay it for t1 seconds.
> elsif (this is the second time in t0 seconds you've seen a given IP)
>     then
>         if (it previously passed)
> 	      then
> 	     	  don't banner delay
> 	      else
> 		  banner delay for t1 seconds
> else
>     if (it previously passed)
>         then
>             don't banner delay
> 	  else
>             drop at connect

then twiddle the tn's.   The second "kick at the delay" is to allow for
a legitimate mail server or network hiccup - the banner delay will be
treated as a retry and you want the retry to work.