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
- [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] 3. Proof-of-work analysis Barry Shein
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- RE: [Asrg] 3. Proof-of-work analysis Hallam-Baker, Phillip
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- Re: [Asrg] 3. Proof-of-work analysis Alan DeKok
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] 3. Proof-of-work analysis Alan DeKok
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- RE: [Asrg] 3. Proof-of-work analysis grsa
- RE: [Asrg] 3. Proof-of-work analysis Bill Cole
- Don't blame the list, blame me (was RE: [Asrg] 3.… Bill Cole
- RE: [Asrg] 3. Proof-of-work analysis Bill Cole
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Tony Finch
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] Re: 3. Proof-of-work analysis Jonathan Morton
- Re: [Asrg] Re: 3. Proof-of-work analysis Barry Shein
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- [Asrg] Re: 3. Proof-of-work analysis Philip Miller
- Re: [Asrg] 3. Proof-of-work analysis Jon Kyme
- Re: [Asrg] Re: 3. Proof-of-work analysis Mark Baugher
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. About hashcash v1 (was: Proof-o… Jonathan Morton
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] Re: 3. Proof-of-work analysis william(at)elan.net
- Re: [Asrg] Re: 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. Proof-of-work analysis william(at)elan.net