RE: [Asrg] 3. Proof-of-work analysis

grsa@billmail.scconsult.com Wed, 19 May 2004 00:44 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01488 for <asrg-archive@odin.ietf.org>; Tue, 18 May 2004 20:44:49 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQF7l-00030c-Ok for asrg-archive@odin.ietf.org; Tue, 18 May 2004 20:39:59 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J0dv0a011562 for asrg-archive@odin.ietf.org; Tue, 18 May 2004 20:39:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQF7B-0002l5-5S for asrg-web-archive@optimus.ietf.org; Tue, 18 May 2004 20:39:21 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01290 for <asrg-web-archive@ietf.org>; Tue, 18 May 2004 20:39:19 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQF78-0004Ie-TO for asrg-web-archive@ietf.org; Tue, 18 May 2004 20:39:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQF6F-0004FN-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 20:38:24 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQF5e-0004C9-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 20:37:46 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEvP-0008VP-9K; Tue, 18 May 2004 20:27:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQEre-0007Aw-3O for asrg@optimus.ietf.org; Tue, 18 May 2004 20:23:20 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00394 for <asrg@ietf.org>; Tue, 18 May 2004 20:23:16 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQErc-00034h-33 for asrg@ietf.org; Tue, 18 May 2004 20:23:16 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQEqf-00030y-00 for asrg@ietf.org; Tue, 18 May 2004 20:22:18 -0400
Received: from sc1.scconsult.com ([66.73.230.190] helo=toaster.scconsult.com) by ietf-mx with esmtp (Exim 4.12) id 1BQEpo-0002xC-00 for asrg@ietf.org; Tue, 18 May 2004 20:21:24 -0400
Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id ED84F1138DC for <asrg@ietf.org>; Tue, 18 May 2004 20:21:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bill@fireproof.scconsult.com
Message-Id: <p0610059bbcd058b9ec93@[192.168.254.12]>
To: asrg@ietf.org
From: grsa@billmail.scconsult.com
Subject: RE: [Asrg] 3. Proof-of-work analysis
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Tue, 18 May 2004 20:21:20 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60

At 10:53 PM -0700 5/17/04, Hallam-Baker, Phillip wrote:
>>  Spamware could parallel connections to umpteen million recipients and
>>  send at full speed if all it had to do was wait.
>
>Absolutely, this code is not your standard mail client stuff.

That depends on what you mean by 'mail client.' There are common 
modern MTA's that will parallelize quite heavily by default, and for 
most of a decade there have been transport agents designed for 
mailing lists with tunable parallelization.

The class of spammers that seems to have the biggest problem with 
slow transaction times has a logically intrinsic problem there. These 
are the  compromised machine users, who are not free to tune systems 
for broad parallelization and for whom longer per-host connect times 
and/or broad parallelization per harnessed zombie mean greater 
likelihood of getting caught and evicted from the machines they 
trespass on sooner than if they simply fire off all of their outbound 
data for a single target as if assuming that all responses will be 
positive. There is at least one spammer/ratware combination in 
operation right now that is actually sending the entire client-side 
part of an SMTP session in a single TCP segment.

>>  > Or for that matter just don't respond with a 250 to their HELO for N
>>  > seconds and if they continue talking anyhow drop the connection
>>  > (something like this is in the current beta sendmail, 8.13.0beta.)
>>
>>  That works currently against spamware that pipelines illegally.  If it
>>  becomes more common, that spamware will become less common.
>
>Problem is that there are lots of people using these techniques for
>good reason. 'illegal' is a poor choice of language, SMTP is not an
>act of parliament, nor is it a particularly great design.

I'm not sure that you and Seth are understanding 'pipelines 
illegally' in the same way. There is a defined standard for when and 
how an SMTP client can pipeline which includes some carefully 
reasoned times when pipelining cannot be  correct behavior. Spamware 
today breaks the natural rules about what can be pipelined, not just 
the social rules about whether a sender should try pipelining when 
the EHLO response isn't there.

>If you
>need to send out a million mails to your customers as Ebay does every
>day you cannot wait around a minute while someone's idiot sendmail
>script runs.

1. Yes, you can. It's a parallelization  issue for the sender, and 
legitimate high-volume senders deal with 30-90 second delays per SMTP 
command all the time.  It is an issue of system design and tuning.

2. Using Ebay as an example of a legitimate mailer is a cute bit of 
humor. I understand that they are a very different operation from the 
zombie herders, but   it is of dubious value to look at the problem 
of spam technically only and reference chronically unethical 
high-volume mailers like Ebay, Verisign, Microsoft, Digital Impact, 
Topica, and Yahoo as a set that needs to fit within any technical 
approach.  (and yes, that's a very incomplete list) It may be that in 
order to address the behavior of the Alan Ralsky's and Scott 
Richter's of the world, the big guys who are not doing anything that 
is criminal (at least not in the US and/or not yet proven in a court 
of law) and have names everyone knows will have to rework or even 
abandon their use of email as a broadcast medium.

Spam is a problem in large part because of the non-uniform economies 
of scale that have existed for email and the unreasonable 
expectations of economies of scale extending into very large scales, 
i.e. that because there is not a tenfold difference in capital and 
operational cost between sending to one hundred and one thousand, 
that there should not be a tenfold increase in cost between a hundred 
thousand and a million. It is that sort of expectation which drives 
the 'legit' companies to cut corners on ethical list management and 
whine about being unable to handle delays (where 'handle' really 
means 'comfortably fund the needed resources to work with') and leads 
to the sort of behavior that the NYAG has documented: subcontracting 
layers leading from seemingly legitimate companies down to zombie 
rustlers.


-- 
Bill Cole
bill@scconsult.com


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg