Re: [Asrg] An Anti-Spam Heuristic

Chris Lewis <clewis+ietf@mustelids.ca> Fri, 14 December 2012 01:05 UTC

Return-Path: <clewis+ietf@mustelids.ca>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9626921F8AE2 for <asrg@ietfa.amsl.com>; Thu, 13 Dec 2012 17:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.717
X-Spam-Level:
X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCttGw+9W-gu for <asrg@ietfa.amsl.com>; Thu, 13 Dec 2012 17:05:08 -0800 (PST)
Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 864D521F8B1A for <asrg@irtf.org>; Thu, 13 Dec 2012 17:05:07 -0800 (PST)
Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.4/8.14.4/Debian-2ubuntu2) with ESMTP id qBE150xn023361 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <asrg@irtf.org>; Thu, 13 Dec 2012 20:05:00 -0500
Message-ID: <50CA7B3C.70104@mustelids.ca>
Date: Thu, 13 Dec 2012 20:05:00 -0500
From: Chris Lewis <clewis+ietf@mustelids.ca>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: asrg@irtf.org
References: <SNT002-W143FB9A867C92FA80D90E04C54E0@phx.gbl> <DA14FA4D-13CB-4C61-90C4-4E690F0EC745@blighty.com> <SNT002-W1393526B62C0940EF697B2C54E0@phx.gbl> <20682.3413.665708.640636@world.std.com> <20121213205940.735FE24248@panix5.panix.com> <B03B6262-E7B0-499D-A744-8F4796CC761A@blighty.com>
In-Reply-To: <B03B6262-E7B0-499D-A744-8F4796CC761A@blighty.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] An Anti-Spam Heuristic
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 01:05:08 -0000

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.