Re: An Anti-Spam Heuristic
Chris Lewis <[email protected]>
| Newsgroups | gmane.ietf.asrg |
|---|---|
| Message-ID | <[email protected]> |
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.