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

Bill Cole <bill@scconsult.com> Wed, 19 May 2004 03:07 UTC

Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08063 for <asrg-archive@odin.ietf.org>; Tue, 18 May 2004 23:07:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHOM-0001uU-1j for asrg-archive@odin.ietf.org; Tue, 18 May 2004 23:05:14 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J35DTa007338 for asrg-archive@odin.ietf.org; Tue, 18 May 2004 23:05:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHGp-0000tA-PV for asrg-web-archive@optimus.ietf.org; Tue, 18 May 2004 22:57:27 -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 WAA07627 for <asrg-web-archive@ietf.org>; Tue, 18 May 2004 22:57:24 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQHGm-0000oT-Ag for asrg-web-archive@ietf.org; Tue, 18 May 2004 22:57:24 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQHFj-0000js-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 22:56:19 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQHF8-0000fu-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 22:55:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQH9d-0008Fk-0j; Tue, 18 May 2004 22:50:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ4pE-0005wf-Pk for asrg@optimus.ietf.org; Tue, 18 May 2004 09:40:08 -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 JAA14578 for <asrg@ietf.org>; Tue, 18 May 2004 09:40:06 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ4pC-0000Sy-Ov for asrg@ietf.org; Tue, 18 May 2004 09:40:06 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ4o9-00000a-00 for asrg@ietf.org; Tue, 18 May 2004 09:39:02 -0400
Received: from sc1.scconsult.com ([66.73.230.190] helo=toaster.scconsult.com) by ietf-mx with esmtp (Exim 4.12) id 1BQ4n9-00077m-00 for asrg@ietf.org; Tue, 18 May 2004 09:38:00 -0400
Received: from [192.168.254.12] (localhost [127.0.0.1]) by toaster.scconsult.com (Postfix) with ESMTP id B57D6113849 for <asrg@ietf.org>; Tue, 18 May 2004 09:37:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: bill@fireproof.scconsult.com
Message-Id: <p06100597bccfa63615a9@[192.168.254.12]>
In-Reply-To: <C6DDA43B91BFDA49AA2F1E473732113E5DBC9C@mou1wnexm05.vcorp.ad.vrsn.com>
References: <C6DDA43B91BFDA49AA2F1E473732113E5DBC9C@mou1wnexm05.vcorp.ad.vrsn.com>
To: asrg@ietf.org
From: Bill Cole <bill@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 09:37:45 -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.0 required=5.0 tests=none 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