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.
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.
Oh, as a FYI, relatively few connections failed to wait for the banner.
Can you confirm the max-daemons limit wasn't hit? A deadly slow TCP
backlog could cause clients to timeout. In that case, banner delay
would work similar to random connection dropping as done, e.g. by
stockade (see http://en.wikipedia.org/wiki/Stockade_%28software%29.)
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...
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg