ietf-asrg
[Top] [All Lists]

Re: [Asrg] An Anti-Spam Heuristic

2012-12-13 19:05:14
On 12-12-13 04:08 PM, Steve Atkins wrote:

And a lot of spamware doesn't flunk.

The vast majority of spamware _still_ flunks.

It's the sort of thing that people tend to do because it makes them feel
like they're sticking one to spammers - which isn't a bad reason, by any
means, but doesn't lead towards optimal solutions.

Tarpitting/teergrubing et. al. are normally what people try in a
mistaken attempt to punish spammers.

Supposedly you don't do that if it isn't spam, the problem being is that
if you pick wrong, some legitimate email gets broken and some bad mail
gets through.  And there's no way you can punish a botnet enough to make
any difference.

Banner delay, MX tricks (ie: "no listing") aren't "punishment" methods,
they're highly effective filtering techniques in their own right.  They
don't require that you guess right as to whether the email is spam or not.

While dumb banner delay mechanisms can push damage and slow-downs back
on the sender, intelligently designed ones don't have to.  After all, if
it passes a banner delay, you _know_ that the next time it connects it
probably won't flunk either.  So only the first connection (over however
long you decide to "remember" it) suffers the delay.

Secondly, in this day and age, increasing the average delivery time,
say, by a factor of two, does NOT imply that the thruput per unit time
goes down by a factor of two.  Hint: multi-thread mail servers[+].
Bandwidth requirements don't change.

[+] Relatively modest SMTP receivers _might_ have hundreds or even
thousands of simultaneous live connections at any given moment (my traps
do).  So can senders.

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg