From prussell@nd.edu Thu Feb 5 16:22:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886133A688D for ; Thu, 5 Feb 2009 16:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF4RAfudC3Xf for ; Thu, 5 Feb 2009 16:22:54 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id 3B6963A6969 for ; Thu, 5 Feb 2009 16:22:54 -0800 (PST) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n160MfAl019930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Feb 2009 19:22:41 -0500 Received: from [172.19.226.30] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n160MoYP009942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Feb 2009 19:22:53 -0500 (EST) Message-ID: <498B82D8.7090907@nd.edu> Date: Thu, 05 Feb 2009 19:22:48 -0500 From: Paul Russell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <6E93F2D47C53A44AE5C2BBE9@paine.local> <1232036000.32316.296.camel@tardis.isode.net> <20090119122842.GA22164@gsp.org> <20090119144404.GA16377@gsp.org> <56C10DAAFEBDD2383409FD09@lewes.staff.uscs.susx.ac.uk> <20090120120617.GB11455@gsp.org> <2BBED7835CA593C6027ED96E@lewes.staff.uscs.susx.ac.uk> <497D2A17.60101@nd.edu> <1233003260.16735.6.camel@ernie.internal.graemef.net> In-Reply-To: <1233003260.16735.6.camel@ernie.internal.graemef.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Thu, 05 Feb 2009 19:22:42 EST Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 00:22:55 -0000 On 1/26/2009 3:54 PM, Graeme Fowler wrote: > On Sun, 2009-01-25 at 22:12 -0500, Paul Russell wrote: >> Exchange parses an inbound DSN to identify every address for which delivery >> status information is provided, then pre-pends the entire DSN with boilerplate >> text for every address in the DSN, regardless of the specific status code and >> text for that address. > > In my current experience, it's *Outlook* which does the > mangling/prepending/call-it-what-you-will. I access my Exchange mailbox using Thunderbird; Outlook is not in the picture. Appended below is the DSN I received when I sent a test message to a known bogus address in a domain I control. Everything above the original message headers was added by Exchange. We see the same boilerplate in every DSN handled by the Exchange servers, regardless of the actual delivery status information returned by the MTA that generated the DSN. This is particularly problematic when the a message is sent by an Outlook, Entourage, or OWA user to multiple recipients, and at least one recipient address is invalid, because the resulting DSN will include delivery status information for every recipient, including those for whom delivery was successful. Unfortunately, the first thing the recipient of the DSN sees is the boilerplate stating that delivery failed for every recipient. ==== begin ===== > Delivery has failed to these recipients or distribution lists: > > bogus@russellbend.com > The recipient's e-mail address was not found in the recipient's e-mail > system. Microsoft Exchange will not try to redeliver this message for you. > Please check the e-mail address and try resending this message, or provide > the following diagnostic text to your system administrator. > > The following organization rejected your message: smtp.easydns.com. > > Diagnostic information for administrators: > > Generating server: mx-p1.cc.nd.edu > > bogus@russellbend.com > smtp.easydns.com # : Recipient address rejected: User unknown in local > recipient table> #SMTP# > > Original message headers: > > Return-Path: > Received: from osgood.cc.nd.edu (osgood.cc.nd.edu [129.74.250.227]) > by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id > n15NlrkU014403 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) > for ; Thu, 5 Feb 2009 18:47:53 -0500 > Received: from [172.19.226.30] (nat20.cc.nd.edu [129.74.4.120]) > (authenticated bits=0) > by osgood.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id > n15Nls7M008205 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) > for ; Thu, 5 Feb 2009 18:48:06 -0500 (EST) > Message-ID: <498B7AA9.9030806@nd.edu> > Date: Thu, 5 Feb 2009 18:47:53 -0500 > From: Paul Russell > User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) > MIME-Version: 1.0 > To: bogus@russellbend.com > Subject: test msg to known invalid address > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > Content-Transfer-Encoding: 7bit > X-Source-IP: 129.74.250.227 > X-ND-MTA-Date: Thu, 05 Feb 2009 18:47:54 EST > > ------------------------------------------------------------------------ > > Reporting-MTA: dns; mx-p1.cc.nd.edu > > Final-recipient: RFC822; bogus@russellbend.com > Action: failed > Status: 5.1.1 > Remote-MTA: dns; smtp.easydns.com > X-Supplementary-Info: : Recipient address rejected: User unknown in local > recipient table> > ===== end ===== From davidnicol@gmail.com Tue Feb 10 09:03:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786EF28C171 for ; Tue, 10 Feb 2009 09:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeOS0G2Zs56V for ; Tue, 10 Feb 2009 09:03:34 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id A689C3A6BEF for ; Tue, 10 Feb 2009 09:03:34 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so271027yxg.37 for ; Tue, 10 Feb 2009 09:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=GEvuxuDBqrTZZeToSl2UrkmeNa5dIAS2rczCNoPrlmo=; b=L2BkeuCM5td0iWnRoPBsB8XwhlpMdzK9b3MCptnIjJOA95r4vpJ7yRsQB5Z1KaoS35 w0LkcAjt/BClzrR9HwvfL/h73X8QIiFELYtYu/qavPdSOKqPf8QPkt/OI6BZZKI+yzK5 7xJuLwypA/mmS1gzyPTV6OPUXLb7teGqiTDwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=gcpIOc9T4zO/9wtQHSLxcbIbebT5dwuqWNY01gc3mIf96yhFJcRyEL8O3JiFMcBA+v HxMTndRnJseDDr8h31l4B5qiGKOJTnSIlwXZlAjDn9JSLxZBEZ5W5RWfRnWOd/rO0y0N bn+65zwiHzG6at+vXhFQgWZ4ZsuNo9+kYbHPc= MIME-Version: 1.0 Received: by 10.151.157.1 with SMTP id j1mr704303ybo.145.1234285417618; Tue, 10 Feb 2009 09:03:37 -0800 (PST) In-Reply-To: <20090123003512.13970.qmail@simone.iecc.com> References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> Date: Tue, 10 Feb 2009 11:03:37 -0600 Message-ID: <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 17:03:35 -0000 This has been sitting in my drafts folder for a three weeks so here it is: i believe that the mechanisms for e-postage should be completely orthogonal to e-commerce; merging them should be left to competitive marketplace. From davidnicol@gmail.com Tue Feb 10 14:25:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A054D3A6CE4 for ; Tue, 10 Feb 2009 14:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RW4AQKspvNm for ; Tue, 10 Feb 2009 14:24:59 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id C371F3A6CB3 for ; Tue, 10 Feb 2009 14:24:59 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so49012yxg.37 for ; Tue, 10 Feb 2009 14:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=PHnDJkQsE3iSloetBSISl5tsexlYuC+P6+AIsDcb2tQ=; b=PabBo5zdYsDCDaRxS8kXOH/u5xiQOc5vwz/zUbjDdcF7ZzeP3Rj+mIF3qSutSyGLg8 YyzAzYBUNNsI/Fwuw6ARGOPIwsRfnszlVnY+A/VpJs1377WHPhTmT4N5EBqzYF6I6Kr5 k8L5jwtaU8OZI7Aq7HVsmMY5Dsh/WDyQBj/+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=E0rjZpKMnssCdrTLRE9TXEgS94pzt+ysz66GiqhZGRAVT6h3kHCzeoXnSQj4D+POQi Y84zWN9oVrIvMTcVXVsTf9zSVdxnmcc0IYq87kpdbzuPWMf0PS3fwIxXq8d9x79f9gsH T/5m/VzpyTtx3Q9pa99CFTqLv/LyZRKzp5iP0= MIME-Version: 1.0 Received: by 10.150.91.4 with SMTP id o4mr1467164ybb.172.1234304702589; Tue, 10 Feb 2009 14:25:02 -0800 (PST) In-Reply-To: <0507125E60293720FB528395@lewes.staff.uscs.susx.ac.uk> References: <4969650A.7010006@terabites.com> <5D7BDFBEE6628AAB358DB641@lewes.staff.uscs.susx.ac.uk> <20090112122833.GA30972@gsp.org> <0507125E60293720FB528395@lewes.staff.uscs.susx.ac.uk> Date: Tue, 10 Feb 2009 16:25:02 -0600 Message-ID: <934f64a20902101425h5b60ddby5683ad681239f944@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM) X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 22:25:00 -0000 On Mon, Jan 12, 2009 at 6:51 AM, Ian Eiloart wrote: > > In a world where you *can* prevent abuse of your domain, what's wrong with > bouncing email? > > -- > Ian Eiloart > IT Services, University of Sussex > x3148 Nothing, provided that by "bounce" you really mean "reject" From john@jlc.net Tue Feb 10 19:09:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3625A3A6C9D for ; Tue, 10 Feb 2009 19:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwEr3M9pdaGv for ; Tue, 10 Feb 2009 19:09:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 62B343A6A51 for ; Tue, 10 Feb 2009 19:09:17 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id CA9CA33C23; Tue, 10 Feb 2009 22:09:21 -0500 (EST) Date: Tue, 10 Feb 2009 22:09:21 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090211030921.GQ52653@verdi> References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 03:09:18 -0000 David Nicol wrote: > > i believe that the mechanisms for e-postage should be completely > orthogonal to e-commerce; merging them should be left to competitive > marketplace. My sentiments exactly! John Levine earlier wrote: ] ] We're a research group -- if you want to do standards track, the IETF ] is right down the hall. I think it would be quite useful to have ] something that describes a well thought out e-postage system, and all ] the reasons it failed. (I was tempted to reply, "It ain't dead yet!" ;^) I am willing to write up _a_ usage case, _if_ that will encourage folks to actually _do_ research on this. But I don't believe it should be part of an ePostage extension spec. There clearly are multiple possible usage cases. As far as "deployment" plans, that seems premature; but I could respond to specific questions about how it might deploy. (Keep in mind that mass-email isn't all spam, and there are quite a few mass-emailers that currently pay "vouching" services to improve their delivery rates.) From dotis@mail-abuse.org Wed Feb 11 11:58:34 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F1F3A6CB9 for ; Wed, 11 Feb 2009 11:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJyxk3I7mrs9 for ; Wed, 11 Feb 2009 11:58:32 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id CA0F33A6C38 for ; Wed, 11 Feb 2009 11:58:32 -0800 (PST) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4B96CA94439 for ; Wed, 11 Feb 2009 19:58:35 +0000 (UTC) Message-Id: <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> From: Douglas Otis To: Anti-Spam Research Group - IRTF In-Reply-To: <20090211030921.GQ52653@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 11:58:35 -0800 References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> <20090211030921.GQ52653@verdi> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 19:58:34 -0000 On Feb 10, 2009, at 7:09 PM, John Leslie wrote: > As far as "deployment" plans, that seems premature; but I could > respond to specific questions about how it might deploy. (Keep in > mind that mass-email isn't all spam, and there are quite a few mass- > emailers that currently pay "vouching" services to improve their > delivery rates.) It would seem any e-postage system requires international arrangements similar to what now accommodates the exchange of physical mail. Perhaps some type of random number exchange and cancelation process may involve the IETF. Making random numbers the size of IPv6 might allow routers to sort validations and cancelations for a new type of postal router. The next question might be how would countries be compensated for the dispersal of e-postage tokens, and their collection of fees? The token itself should encode the country of origin. Perhaps e-postage could be priced at one-tenth the price of international first-class stamps. How can discount e-postage be prevented, since there would be a profit motive to cheat? Perhaps this could be seen as a charity for third-world countries that have the cheapest stamps. -Doug From mouse@Sparkle.Rodents-Montreal.ORG Wed Feb 11 12:44:48 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4168D28C123 for ; Wed, 11 Feb 2009 12:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FD4S6OEOUHV for ; Wed, 11 Feb 2009 12:44:47 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 9A09B28C1F5 for ; Wed, 11 Feb 2009 12:44:46 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id PAA05201; Wed, 11 Feb 2009 15:44:30 -0500 (EST) From: der Mouse Message-Id: <200902112044.PAA05201@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 11 Feb 2009 15:37:17 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> <20090211030921.GQ52653@verdi> <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:44:48 -0000 > It would seem any e-postage system requires international > arrangements similar to what now accommodates the exchange of > physical mail. I'm actually inclined to disagree with that. There would be international agreements required, because email crosses national boundaries, but I think drawing the analogy to the agreements involved for paper mail places the emphasis in the wrong place. It makes it sound as though the agreements would be between countries, when I think the actually would need to be between providers, making them international only when, and because, the providers involved are in different countries. > The next question might be how would countries be compensated for the > dispersal of e-postage tokens, and their collection of fees? Would they? That works for postal mail, but (I believe) only because postal mail is a governmental monopoly. I doubt email will ever be a national monopoly for more than a tiny fraction of the world's email users, or mailservers. (Postage-bearing email might, but my guess, for what it's worth, is that that would kill postage-bearing email.) s/countries/providers/ and the question is still reasonable, though it requires thinking about in a rather different way because the entities involved are so different. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From john@jlc.net Wed Feb 11 14:45:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6737C3A696A for ; Wed, 11 Feb 2009 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGw0w4t3fV-t for ; Wed, 11 Feb 2009 14:45:43 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5A2BF3A69B7 for ; Wed, 11 Feb 2009 14:45:43 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5203633C5A; Wed, 11 Feb 2009 17:45:47 -0500 (EST) Date: Wed, 11 Feb 2009 17:45:47 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090211224547.GR52653@verdi> References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> <20090211030921.GQ52653@verdi> <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:45:44 -0000 Douglas Otis wrote: > On Feb 10, 2009, at 7:09 PM, John Leslie wrote: > >> As far as "deployment" plans, that seems premature; but I could >> respond to specific questions about how it might deploy. (Keep in >> mind that mass-email isn't all spam, and there are quite a few mass- >> emailers that currently pay "vouching" services to improve their >> delivery rates.) > > It would seem any e-postage system requires international arrangements > similar to what now accommodates the exchange of physical mail. Actually, no: the arrangements are "inter-bank" not international. (There is the question of currency exchange rates, but banks do that today.) Also, "bank" deserves to be in quotation marks, since there's no essential advantage to having postage-issuing "banks" regulated by national governments. (Only settlements between banks would be visible, and presumably regulated.) > Perhaps some type of random number exchange and cancelation process > may involve the IETF. Making random numbers the size of IPv6 might > allow routers to sort validations and cancelations for a new type of > postal router. Not sure I see your point... ePostage-Banks issue postage, and the same bank redeems it unless there's an agreement between "banks". I see no role for IETF in designing such "inter-bank" agreements. > The next question might be how would countries be compensated for the > dispersal of e-postage tokens, and their collection of fees? "Banks" would be compensated by debiting a customer account more than the amount of ePostage issued and/or crediting a customer account less than the amount redeemed. Or, perhaps there would be a per-transaction fee (in the thousandths of cents, presumably). I see no role for IETF in saying which model a "bank" uses. (It's even conceivable that each major email receiver might issue its own ePostage instead of going through a "bank", and hide the "banking" charges entirely.) > The token itself should encode the country of origin. Encode the _issuer_, yes. There might be an IETF role in saying how to encode it. > Perhaps e-postage could be priced at one-tenth the price of > international first-class stamps. Clearly there are some mass-emailers that would pay that; but I expect the actual amount to settle on a much smaller number. That's a research issue. ;^) > How can discount e-postage be prevented, since there would be > a profit motive to cheat? What do you mean, "cheat"? The receiver says what's acceptable, and cries "TILT" if s/he doesn't get it. I do expect _any_ "standard" ePostage amount to be undercut by some receivers: left to myself I'd skip the step of setting a "standard" amount. > Perhaps this could be seen as a charity for third-world countries > that have the cheapest stamps. I do expect some receivers to choose to accept charity-issued stamps. It will appeal to some folks' sensibilities. :^) -- John Leslie From steve@blighty.com Wed Feb 11 15:23:31 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF393A6C20 for ; Wed, 11 Feb 2009 15:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMupVIXx31h4 for ; Wed, 11 Feb 2009 15:23:31 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 08F843A6A6F for ; Wed, 11 Feb 2009 15:23:31 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 36B4480B8E for ; Wed, 11 Feb 2009 15:23:31 -0800 (PST) Message-Id: <98222097-9451-4FEA-997D-63192624F087@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <20090211224547.GR52653@verdi> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 15:23:35 -0800 References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> <20090211030921.GQ52653@verdi> <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> <20090211224547.GR52653@verdi> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:23:31 -0000 On Feb 11, 2009, at 2:45 PM, John Leslie wrote: > > "Banks" would be compensated by debiting a customer account more > than the amount of ePostage issued and/or crediting a customer > account less than the amount redeemed. Or, perhaps there would be a > per-transaction fee (in the thousandths of cents, presumably). I > see no role for IETF in saying which model a "bank" uses. Just to throw some arithmetic onto this. A large consumer ISP might send 50 million emails a day externally. Assuming that there isn't "one bank to rule them all" it seems reasonable to assume that any given "bank" wouldn't handle much more than that. A thousandth of a cent banking charge would be about $500 / day or $182,500 / year. That's not a plausible budget for running any organization with the level of reliability and backing that would be needed, not by at least one order of magnitude. So "thousandths of cents" doesn't seem realistic language when discussing a per-transaction fee. Cheers, Steve From john@jlc.net Wed Feb 11 16:17:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3433A68E5 for ; Wed, 11 Feb 2009 16:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPiCqc4nF2bY for ; Wed, 11 Feb 2009 16:17:08 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 8954E3A6839 for ; Wed, 11 Feb 2009 16:17:08 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7CAC433C26; Wed, 11 Feb 2009 19:17:12 -0500 (EST) Date: Wed, 11 Feb 2009 19:17:12 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090212001712.GS52653@verdi> References: <20090122144402.GN24908@verdi> <20090123003512.13970.qmail@simone.iecc.com> <934f64a20902100903x11ba5cb4y2dc82f12ced84a14@mail.gmail.com> <20090211030921.GQ52653@verdi> <441988AF-06D4-4FA7-8F81-CC80E3345E3E@mail-abuse.org> <20090211224547.GR52653@verdi> <98222097-9451-4FEA-997D-63192624F087@blighty.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98222097-9451-4FEA-997D-63192624F087@blighty.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 00:17:09 -0000 Steve Atkins wrote: > On Feb 11, 2009, at 2:45 PM, John Leslie wrote: >> >> "Banks" would be compensated by debiting a customer account more >> than the amount of ePostage issued and/or crediting a customer >> account less than the amount redeemed. Or, perhaps there would be a >> per-transaction fee (in the thousandths of cents, presumably). I >> see no role for IETF in saying which model a "bank" uses. > > Just to throw some arithmetic onto this. Very welcome! > A large consumer ISP might send 50 million emails a day externally. That sounds low to me. > Assuming that there isn't "one bank to rule them all" it seems > reasonable to assume that any given "bank" wouldn't handle much more > than that. I'd agree that depending on more than 100 million per day in drafting a business plan would be risky. > A thousandth of a cent banking charge would be about $500 / day or > $182,500 / year. I did say "thousandths" (plural). Will you allow me two? And IMHO, there are two transactions per email. We've passed $500,000 per year, anyway. > That's not a plausible budget for running any organization with the > level of reliability and backing that would be needed, What level of reliability _is_ needed? I figure five-nines on losing track of a token is marketable. Tokens outstanding needn't exceed, say, a billion. Guessing one cent tokens, we've got perhaps $10 million "outstanding", but in fact only settlements ever need to change hands. > not by at least one order of magnitude. That's "close enough" -- I was a physics major. ;^) > So "thousandths of cents" doesn't seem realistic language when > discussing a per-transaction fee. If so, the market will support a higher fee. (I don't mind!) -- John Leslie From johnl@iecc.com Wed Feb 11 18:44:51 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F383A6969 for ; Wed, 11 Feb 2009 18:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsA0xWoqLapM for ; Wed, 11 Feb 2009 18:44:50 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 72BEC3A6916 for ; Wed, 11 Feb 2009 18:44:50 -0800 (PST) Received: (qmail 6605 invoked from network); 12 Feb 2009 02:44:53 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 12 Feb 2009 02:44:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=ibXoH0LlS3i/6AWybmKZRZfNtwxs74q66M5HjwLAPBs=; b=THYQZkuIdwYIr8W0tAFb9VYZj0N7B01ysvNv+cRTDt9COwykGEFQ49rQuiDaB0nuuPz3JHfLlAPrME0VoQGI7xbtb9szAMDv6BooWaP/mxKIal3D4g3RA4mG4tBmzH6DmI7Wth/+DM+O+PT7S7RXd2JJN/cEZ94TPVzTEkfhqgY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=ibXoH0LlS3i/6AWybmKZRZfNtwxs74q66M5HjwLAPBs=; b=haWMBIv8HT8Qhrb00YDiiPQ+JMvnVM5xMf2n1pBmHRZ8DlQpFUX4F9AlotHKTvipO/Lxo7Bu/ww1zYtp+Z+e9KIXwrtYIV1l0YTdKmO3AJLhtuz0piXHTgv9g5vi5vGAuiuCDbTt8lfZ9OIvldwlvQDUIjpqcDNv4Hmro8V6Sqw= Date: 12 Feb 2009 02:44:51 -0000 Message-ID: <20090212024451.49775.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <98222097-9451-4FEA-997D-63192624F087@blighty.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 02:44:51 -0000 >> "Banks" would be compensated by debiting a customer account more >> than the amount of ePostage issued and/or crediting a customer >> account less than the amount redeemed. Or, perhaps there would be a >> per-transaction fee (in the thousandths of cents, presumably). I >> see no role for IETF in saying which model a "bank" uses. >So "thousandths of cents" doesn't seem realistic language when >discussing a per-transaction fee. I did a similar calculation for my white paper, and even a penny a message isn't enough, particularly if you have to budget for large numbers of spams with fake or duplicate postage that will require most of the work of verifying a real stamp, but provide no revenue. I hear that a lot of research involves models. Perhaps a model of where the money will have to go would be useful. R's, John From john@jlc.net Thu Feb 12 06:21:30 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEC728C1DA for ; Thu, 12 Feb 2009 06:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36Pru5aGQi9F for ; Thu, 12 Feb 2009 06:21:29 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 58A2F28C14E for ; Thu, 12 Feb 2009 06:21:29 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 610E833C61; Thu, 12 Feb 2009 09:21:34 -0500 (EST) Date: Thu, 12 Feb 2009 09:21:34 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090212142133.GV52653@verdi> References: <98222097-9451-4FEA-997D-63192624F087@blighty.com> <20090212024451.49775.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090212024451.49775.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:21:30 -0000 John Levine wrote: > Date: 12 Feb 2009 02:44:51 -0000 > From: John Levine > To: asrg@irtf.org > Cc: > Subject: Re: [Asrg] About that e-postage draft [POSTAGE] > >>> "Banks" would be compensated by debiting a customer account more >>> than the amount of ePostage issued and/or crediting a customer >>> account less than the amount redeemed. Or, perhaps there would be a >>> per-transaction fee (in the thousandths of cents, presumably). I >>> see no role for IETF in saying which model a "bank" uses. > >> So "thousandths of cents" doesn't seem realistic language when >> discussing a per-transaction fee. > > I did a similar calculation for my white paper, and even a penny a > message isn't enough, particularly if you have to budget for large > numbers of spams with fake or duplicate postage that will require most > of the work of verifying a real stamp, but provide no revenue. By "per transaction", I meant per _transaction_, not per _email_. (Is it possible we're not discussing the POSTAGE draft? It doesn't contain "stamps" that are carried in message headers, but a "token" passed between MTAs.) A receiving MTA asking its "bank" to redeem a token is a transaction whether or not the token is forged, and the "bank" needs to recover that transaction cost. I suspect sending MTAs that deliver bad tokens will get blacklisted quickly; but I can imagine ways to reduce the need for a "transaction" with the bank to verify that a token is plausible. (Need I remind our readers that receiving email _already_ provides no revenue?) > I hear that a lot of research involves models. Perhaps a model of > where the money will have to go would be useful. Hmm... I can imagine many models. Clearly, in almost any model, "banks" will have to cover transaction costs, and receiving MTAs will want to recover costs of transmission (including support costs). I expect most receiving MTAs will also want to cover POSTAGE for their normal volume of outgoing email. (Charging end-users for POSTAGE will only be practical for users with a large volume of outgoing email.) But I wouldn't preclude some portion of the POSTAGE being credited to the end-users -- I just don't expect that to be workable. -- John Leslie From johnl@iecc.com Thu Feb 12 13:58:38 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8174528C280 for ; Thu, 12 Feb 2009 13:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv49CVYt4gAn for ; Thu, 12 Feb 2009 13:58:37 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 0F84628C21F for ; Thu, 12 Feb 2009 13:58:36 -0800 (PST) Received: (qmail 24732 invoked from network); 12 Feb 2009 21:58:41 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 12 Feb 2009 21:58:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=1ZL18XiBSpvc2MFA3P+tzzPanOoPCy2pb56N7jZADi4=; b=RF9g9m23sowz1NNaleIw1NRAqLe0FBLERzaTaZ5MWprXGr6F67tLhV6ZdX42sBDZX43zirOS8vWd4j24t5ZzA6HJR+vwfCTo7LAzCc00a6iwiVofGFrMeeCHodPvCSOLosJHFN8PlKgvwyVm0mfntiksPUr58rCC7dP6Cj4KuLg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=1ZL18XiBSpvc2MFA3P+tzzPanOoPCy2pb56N7jZADi4=; b=ASrCRGtnUhHYUXoSjjDh+DtJWdaRicU0Nlup7P57kXIRRHFGJCoafcb/rWHl9c1Mzs1SdW06M9vxfkSdyAZyKL/INdRlxkrHTky3cVLCXVdmR/yrhaklFi0CQ6YfWETJApQYlOfluT1U1w946X2LaAscnIz1AnI40d1IMqdFI7k= Date: 12 Feb 2009 21:58:41 -0000 Message-ID: <20090212215841.11637.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090212142133.GV52653@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 21:58:38 -0000 > A receiving MTA asking its "bank" to redeem a token is a > transaction whether or not the token is forged, and the "bank" needs > to recover that transaction cost. I suspect sending MTAs that > deliver bad tokens will get blacklisted quickly; but I can imagine > ways to reduce the need for a "transaction" with the bank to verify > that a token is plausible. My standard spam model is that the bad guy buys one stamp and uses that one genuine stamp on a thousand messages (transactions, whatever) at the same time. It's really easy to verify that a stamp is real using digital signatures, but there's no way to tell if it's already been used other than asking the issuer. It is possible to defend against this threat, but not cheaply, since the defense requires a robust transaction system that can serialize the thousand requests, approve one, and reject the other 999, while still providing service to the rest of their customers. Through the magic of botnets, the thousand messages come from a thousand different MTAs, of course. > (Need I remind our readers that receiving email _already_ provides > no revenue?) Indeed, but banks don't work for free. (Well, not deliberately.) You want someone to provide stamps, you've got to make it worth his while. > I can imagine many models. ... Indeed. Now beef some of them up with some realistic estimates of transactions costs, and the costs of dealing with screwed up and fraudulent transactions. R's, John From john@jlc.net Thu Feb 12 16:12:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E56943A6B20 for ; Thu, 12 Feb 2009 16:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.656 X-Spam-Level: X-Spam-Status: No, score=-6.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuMouEoHq-ks for ; Thu, 12 Feb 2009 16:12:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 13A513A6AD5 for ; Thu, 12 Feb 2009 16:12:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id CA91F33C21; Thu, 12 Feb 2009 19:12:10 -0500 (EST) Date: Thu, 12 Feb 2009 19:12:10 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090213001210.GC52653@verdi> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090212215841.11637.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 00:12:06 -0000 John Levine wrote: > >> A receiving MTA asking its "bank" to redeem a token is a >> transaction whether or not the token is forged, and the "bank" needs >> to recover that transaction cost. I suspect sending MTAs that >> deliver bad tokens will get blacklisted quickly; but I can imagine >> ways to reduce the need for a "transaction" with the bank to verify >> that a token is plausible. > > My standard spam model is that the bad guy buys one stamp and uses > that one genuine stamp on a thousand messages (transactions, whatever) > at the same time. It's really easy to verify that a stamp is real > using digital signatures, but there's no way to tell if it's already > been used other than asking the issuer. Agreed. > It is possible to defend against this threat, but not cheaply, since > the defense requires a robust transaction system that can serialize > the thousand requests, approve one, and reject the other 999, while > still providing service to the rest of their customers. I'm not clear which party you're talking about here. The "bank" takes redemption requests serially and acts on them serially. The list of valid tokens can be kept in RAM. That amounts to no measurable delay. The receiving MTA takes email transactions, possibly in overlappping threads, and as each token is decoded, queries the agreed "bank". We have all the transmission time of the DATA to get a reply. Short of the "bank" suffering a DoS attack it's hard to imagine that not being long enough. If there are multiple copies of the same token provided to a single MTA, I suspect they'll get around to blacklisting the sending MTA, but that's an economic decision: the "bank" will accept no more than one of them. > Through the magic of botnets, the thousand messages come from a > thousand different MTAs, of course. Of course. Will the economic incentive cause all 1,000 to be blacklisted? Possibly... >> (Need I remind our readers that receiving email _already_ provides >> no revenue?) > > Indeed, but banks don't work for free. (Well, not deliberately.) You > want someone to provide stamps, you've got to make it worth his while. One way or another, I expect banks to cover these transaction costs. >> I can imagine many models. ... > > Indeed. Now beef some of them up with some realistic estimates of > transactions costs, and the costs of dealing with screwed up and > fraudulent transactions. I believe I have done so. It will take more than calling my estimates "unreasonable" to make me abandon them. Some numbers, please... -- John Leslie From johnl@iecc.com Thu Feb 12 16:47:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6AE3A6A90 for ; Thu, 12 Feb 2009 16:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUwX536+cKVJ for ; Thu, 12 Feb 2009 16:47:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id B75303A6B58 for ; Thu, 12 Feb 2009 16:47:52 -0800 (PST) Received: (qmail 51589 invoked from network); 13 Feb 2009 00:47:57 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Feb 2009 00:47:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=g+fYcYERktkvo7Qzq2g9l+Oj7euI8LY/PpZwtf0Nh9o=; b=S++UzCHge3Kk29YGuK75Md4gt+n1qrm8n3Sh7vD2jYcKJfd1hqh1NIgLMCWj/+bHTNn0a7ociIs9f0oFL47PugwXzzNRlNMJ9yqPpPoE5vfTSS+40CWIIdDGNEX+jfj52BIjcOCe2inFx4+cLxN7RG5kkh1TCOUyBP6v9j3WRUk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=g+fYcYERktkvo7Qzq2g9l+Oj7euI8LY/PpZwtf0Nh9o=; b=VnkG0dugXL5i0suJi+XHUzxwkq8DkuS6XF5hHl6vsDustUTfngKQ/P97PS4puY66ZfwxBs8OEAhnQwaex2HOXgn8jtWK2qoBYhQwaoevwAzfb8QHT8SSR3+k9ExVUPAALnPxe0XcRKf4Rplgb1588lz8t78M80hmDiNojL/3rz8= Date: 13 Feb 2009 00:47:48 -0000 Message-ID: <20090213004748.15601.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090213001210.GC52653@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 00:47:54 -0000 >> It is possible to defend against this threat, but not cheaply, since >> the defense requires a robust transaction system that can serialize >> the thousand requests, approve one, and reject the other 999, while >> still providing service to the rest of their customers. > > I'm not clear which party you're talking about here. The "bank" takes >redemption requests serially and acts on them serially. The list of >valid tokens can be kept in RAM. That amounts to no measurable delay. Um, you might be surprised. Locking systems that just serialize everything into one queue are unlikely to be fast enough to be interesting, particularly if you hope to handle an interesting fraction of Internet mail, which by my back of the thumb estimate is about two million messages/second. Also, unless the bank is planning to keep all the money for itself, it needs to have some way for the client presenting the tokens to collect the money eventually. That means either a book entry system where each client has an account and the bank has to mark the token as having been paid into that account, or a bearer system where the bank creates and sends the client a reissued token that it can cash in later. People have been thinking about micropayments for 15 years, and transaction systems for 50 years (really), and you are assuming a cheap solution to a long-term unsolved problem. That's why I think it would be a good idea to at least develop the model to the point where we can evaluate whether a putative solution is good enough. R's, John From john@jlc.net Thu Feb 12 18:08:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A73E3A6D21 for ; Thu, 12 Feb 2009 18:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tacp3eu7vUL for ; Thu, 12 Feb 2009 18:08:25 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 30E233A6A94 for ; Thu, 12 Feb 2009 18:08:25 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A1B6033C2A; Thu, 12 Feb 2009 21:08:29 -0500 (EST) Date: Thu, 12 Feb 2009 21:08:28 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090213020828.GD52653@verdi> References: <20090213001210.GC52653@verdi> <20090213004748.15601.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213004748.15601.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:08:26 -0000 John Levine wrote: >> >> I'm not clear which party you're talking about here. The "bank" takes >> redemption requests serially and acts on them serially. The list of >> valid tokens can be kept in RAM. That amounts to no measurable delay. > > Um, you might be surprised. Locking systems that just serialize > everything into one queue are unlikely to be fast enough to be > interesting, particularly if you hope to handle an interesting fraction > of Internet mail, which by my back of the thumb estimate is about two > million messages/second. I see no problem handling one million queries per second in a RAM-based system. Locking is likely overkill -- the tokens in RAM are known-good (or already deleted): the debit/credit need not be real-time. > Also, unless the bank is planning to keep all the money for itself, it > needs to have some way for the client presenting the tokens to collect > the money eventually. That means either a book entry system where > each client has an account and the bank has to mark the token as > having been paid into that account, or a bearer system where the bank > creates and sends the client a reissued token that it can cash in > later. That choice should be up to the bank. I was thinking book-entry with credit/debit lagging token redemption by perhaps a few seconds. (Locking for the book-entry part is worth doing.) > People have been thinking about micropayments for 15 years, and > transaction systems for 50 years (really), and you are assuming a > cheap solution to a long-term unsolved problem. I'm assuming the problem is defined wrong if it takes 50 years to solve. Once you separate token creation/redemption from _all_ other accounting (by journaling the creation/redemption) it becomes much simpler. And once you move the token database into RAM, timing problems pretty much disappear. > That's why I think it would be a good idea to at least develop the > model to the point where we can evaluate whether a putative solution > is good enough. Ben is working on that. -- John Leslie From johnl@iecc.com Fri Feb 13 02:09:07 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3DC3A6C49 for ; Fri, 13 Feb 2009 02:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W01RfG1AVuqM for ; Fri, 13 Feb 2009 02:09:06 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 38FCC3A67FF for ; Fri, 13 Feb 2009 02:09:06 -0800 (PST) Received: (qmail 42458 invoked from network); 13 Feb 2009 10:09:11 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 13 Feb 2009 10:09:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=77XcnojVPYg7SP6FUYoqkeRTuNDaNEqBr/xdl8sQHCk=; b=SthMSg434kIvA6xMg2g08uVKMAWfeBoQhSx0QpEi2fY1yjy+Vl4WsVBRHkuPmjQFY4o79vhHrZemVtiLpckcKVu55SpjaHQGC9bifdS7KdSnERtZmS8HcFdFP5vSuJwqKXmyLWUjSgNvALEuvf7z91gGDS+9upFn+XwrCIL2HFk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=77XcnojVPYg7SP6FUYoqkeRTuNDaNEqBr/xdl8sQHCk=; b=E1Vy9HDE8oz7gyrFLoEB/buN3sNgwejtxiXrq8lP4GDpy+IrONpjtTSHhOmmD62yx0ZGbiQd5dOuUdi7pgKynkinGhReKQ2+OLeMiPYtOMbMK+cH7lPeau1PlyE+LU9CpH/OZKC+jqnY7KlM4VyG9Jl8MTpwtxu1p9J50n0DrcM= Date: 13 Feb 2009 10:09:11 -0000 Message-ID: <20090213100911.14927.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090213020828.GD52653@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 10:09:07 -0000 >> People have been thinking about micropayments for 15 years, and >> transaction systems for 50 years (really), and you are assuming a >> cheap solution to a long-term unsolved problem. > > I'm assuming the problem is defined wrong if it takes 50 years >to solve. Once you separate token creation/redemption from _all_ >other accounting (by journaling the creation/redemption) it becomes >much simpler. And once you move the token database into RAM, timing >problems pretty much disappear. Sigh. There are lots of transaction systems that work well, and have been since about 1964. But there are no transaction systems that handle a very high transaction rate, most of which are rejected and provide no revenue, at a cost of a tiny fraction of a cent per transaction. We haven't even started to consider how the transactions get in and out of the systems with the RAM, and I don't think it would be productive to do so at this point. That's why I really think it would be a good idea to figure out what sort of performance and what sort of cost an e-postage system would need, as a prototype or as a production system, so in the even that someone came up with a concrete design, we could tell whether it's within an order of magnitude of being workable. R's, John From john@jlc.net Fri Feb 13 05:38:43 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB433A6AF8 for ; Fri, 13 Feb 2009 05:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.643 X-Spam-Level: X-Spam-Status: No, score=-6.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEni4cpsUEn5 for ; Fri, 13 Feb 2009 05:38:42 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id A304E3A67B0 for ; Fri, 13 Feb 2009 05:38:42 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6F4BE33C22; Fri, 13 Feb 2009 08:38:49 -0500 (EST) Date: Fri, 13 Feb 2009 08:38:49 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090213133849.GA94816@verdi> References: <20090213020828.GD52653@verdi> <20090213100911.14927.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213100911.14927.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:38:43 -0000 John Levine wrote: > >>> People have been thinking about micropayments for 15 years, and >>> transaction systems for 50 years (really), and you are assuming a >>> cheap solution to a long-term unsolved problem. >> >> I'm assuming the problem is defined wrong if it takes 50 years >> to solve. Once you separate token creation/redemption from _all_ >> other accounting (by journaling the creation/redemption) it becomes >> much simpler. And once you move the token database into RAM, timing >> problems pretty much disappear. > > Sigh. ... psi-star dV > There are lots of transaction systems that work well, and have > been since about 1964. OK, the problem still might be defined wrong if it takes fifteen years to solve... > But there are no transaction systems that handle a very high > transaction rate, most of which are rejected and provide no revenue, > at a cost of a tiny fraction of a cent per transaction. Then, let's stop trying to do all that at once. We need the high transaction rate. We need to be able to reject, say, 99% of the requests. We don't need to charge nothing at all for a rejection. Being a bear-of-small-brain, I prefer to have the "bank" charge for rejected transactions. This allows the receiving MTA a wide choice of strategies for deciding how quickly (or even whether) to present tokens for redemption. (Tarpitting is still a useful tactic.) > We haven't even started to consider how the transactions get in and > out of the systems with the RAM, Quite true -- and that's a more serious bottleneck, IMHO... > and I don't think it would be productive to do so at this point. Nor do I -- it's an unrelated problem with standard solutions. > That's why I really think it would be a good idea to figure out what > sort of performance and what sort of cost an e-postage system would > need, as a prototype or as a production system, I believe we could do useful research with a million-per-day volume, but it seems pointless to me not to design the "transaction" portion to handle a million-per-second (leaving network I/O as the bottleneck). By "transaction" I mean: - a customer with sufficient credit balance asks for a token; or - a customer with an existing account asks to redeem a token. In neither case does the "transaction" need to debit or credit the appropriate account at the microsecond of the "transaction" -- these could be batched for processing an hour later if necessary. The "transaction" involves only the creation and redemtion of tokens issued by the "bank" and redeemed by the same "bank". The actual per-transaction pricing is an open issue -- I'd guess an upper limit is around a tenth of a cent per "transaction", but I expect competition to drive that well below a hundredth of a cent. (For research, a goal of a tenth of a cent seems fine.) > so in the even that someone came up with a concrete design, we could > tell whether it's within an order of magnitude of being workable. Be my guest... -- John Leslie From rsk@gsp.org Fri Feb 13 05:40:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C4C73A67B0 for ; Fri, 13 Feb 2009 05:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RugSyXBaw555 for ; Fri, 13 Feb 2009 05:40:25 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 2DA763A69BB for ; Fri, 13 Feb 2009 05:40:25 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.90.dsl.charm.net [207.114.25.90]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n1DDeVUx029747 for ; Fri, 13 Feb 2009 08:40:31 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n1DDeWjv023442 for ; Fri, 13 Feb 2009 08:40:32 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n1DDeP6g012056 for ; Fri, 13 Feb 2009 08:40:25 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n1DDePmB012053 for asrg@irtf.org; Fri, 13 Feb 2009 08:40:25 -0500 Date: Fri, 13 Feb 2009 08:40:25 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090213134025.GB10598@gsp.org> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090212215841.11637.qmail@simone.iecc.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:40:26 -0000 On Thu, Feb 12, 2009 at 09:58:41PM -0000, John Levine wrote: > Indeed. Now beef some of them up with some realistic estimates of > transactions costs, and the costs of dealing with screwed up and > fraudulent transactions. Along those same lines, such an estimate must take into account a minimum of 100M botted hosts, and correspondingly, a minimum of 100M compromised sets of email credentials. [1] Thus, such an estimate must be able to cope gracefully with the case where (say) 1M systems simultaneously (or nearly so) present the same token to (say) 100K mail systems -- and must do so without permitting on an effective DoS on the transaction processor. (And note that, modulo the token, this is a routine occurence. It could reasonably be expected to become more so if abusers found it effective.) ---Rsk [1] These estimates may be much too small to reflect reality; for example, a compromise of my system would eventually expose over 30 sets of such credentials, each picked up in turn as it was used. Personally, I think "250m" and "1.5B" are probably more realistic numbers. From john@jlc.net Fri Feb 13 06:21:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF2E3A6BBC for ; Fri, 13 Feb 2009 06:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.639 X-Spam-Level: X-Spam-Status: No, score=-6.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Poll3ywWaDYr for ; Fri, 13 Feb 2009 06:21:17 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 44F463A67F7 for ; Fri, 13 Feb 2009 06:21:17 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A35F733C27; Fri, 13 Feb 2009 09:21:21 -0500 (EST) Date: Fri, 13 Feb 2009 09:21:21 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090213142121.GB94816@verdi> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <20090213134025.GB10598@gsp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213134025.GB10598@gsp.org> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 14:21:18 -0000 Rich Kulawiec wrote: > On Thu, Feb 12, 2009 at 09:58:41PM -0000, John Levine wrote: > >> Indeed. Now beef some of them up with some realistic estimates of >> transactions costs, and the costs of dealing with screwed up and >> fraudulent transactions. > > Along those same lines, such an estimate must take into account a > minimum of 100M botted hosts, and correspondingly, a minimum of 100M > compromised sets of email credentials. [1] Reasonable numbers... > [1] These estimates may be much too small to reflect reality; for > example, a compromise of my system would eventually expose over > 30 sets of such credentials, each picked up in turn as it was > used. Personally, I think "250m" and "1.5B" are probably more > realistic numbers. Can I deal with those estimates separately? > Thus, such an estimate must be able to cope gracefully with the case > where (say) 1M systems simultaneously (or nearly so) present the same > token to (say) 100K mail systems -- and must do so without permitting on > an effective DoS on the transaction processor. I take "simultaneously" to mean "within one second". First, from the "bank's" viewpoint: it receives 100K requests to redeem, at worst; credits one and refuses the rest. All 100K get charged a transaction fee. From the receiving MTAs' viewpoint: each starts an SMTP session, requests postage (probably in differing amounts) and gets a token. Since the sending MTA is on a suspected-bot blocklist, it either presents the token as quickly as possible (in hopes of being the first to present), or tarpits long enough to see whether the IP address shows up on a confirmed-evil-bot blocklist. Remember, presentation of a bad token is a much clearer indication of evil intent: a few dozen should suffice for blocklisting. It's quite practical to blocklist 100 million IPs, at which point the problem will start to disappear. Computers blocklisted this way will pretty much be forced into going through a relay MTA with which they have a contractual relationship -- which removes the problem from the "botted-MTA" territory. > (And note that, modulo the token, this is a routine occurence. It > could reasonably be expected to become more so if abusers found it > effective.) Agreed. -- John Leslie From meta404@gmail.com Sun Feb 15 07:14:12 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34C83A6988 for ; Sun, 15 Feb 2009 07:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyjpdRWpcQbw for ; Sun, 15 Feb 2009 07:14:11 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id 119E43A67D2 for ; Sun, 15 Feb 2009 07:14:10 -0800 (PST) Received: by qyk14 with SMTP id 14so3231057qyk.7 for ; Sun, 15 Feb 2009 07:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=ZV3QXu9jUXh8GlbQq8kRZWCUP0h2H+JJh05A2URtOmA=; b=ucs+8GfOHfK4pCnJn2AhW6xk4WpLxvzWqf+kEv8/d4TPYEDyCv4yFqM28/MUFxuMt6 Kh7SH10HfRPd4lBMYgo0v40pSvzc2bnf7meDsyZmuc+/Sq3zp3LkI+fB5/uG8rff+MrH FwmNQC165mlqja/+lyWIMSZBNBsvg3qcgFoKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=X3gCfLr7hMJPB73mLaVn1b5cbqxyXR2toyaK7dOWh0jsWjlBoRnyJXnPxBlLU/lOHH 4sKrgP7fT5JtwaWB77tMKCFLYGILcFOp9c3X2ci3mhRr0ci19WXEiNS6HNRL0MvBLtGF xfEMV8im75m571bMRoQsSp7w4rJWEm86/9rFQ= MIME-Version: 1.0 Sender: meta404@gmail.com Received: by 10.229.85.17 with SMTP id m17mr1081629qcl.43.1234710855988; Sun, 15 Feb 2009 07:14:15 -0800 (PST) In-Reply-To: <20090212215841.11637.qmail@simone.iecc.com> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> Date: Sun, 15 Feb 2009 09:14:15 -0600 X-Google-Sender-Auth: 4e5667a238e5f3c1 Message-ID: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> From: mathew To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=0016364edf6ef8b4490462f685f6 Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 15:14:12 -0000 --0016364edf6ef8b4490462f685f6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 12, 2009 at 15:58, John Levine wrote: > My standard spam model is that the bad guy buys one stamp and uses > that one genuine stamp on a thousand messages (transactions, whatever) > at the same time. It's really easy to verify that a stamp is real > using digital signatures, but there's no way to tell if it's already > been used other than asking the issuer. > > It is possible to defend against this threat, but not cheaply, since > the defense requires a robust transaction system that can serialize > the thousand requests, approve one, and reject the other 999, while > still providing service to the rest of their customers. Nonsense. You just make the purchased stamp dependent upon the address of the recipient, for example by hashing the To: address inside the cryptographic stamp when it's minted. You know, like SSL certificates include the hostname so you can't use the same one on multiple sites. Sure, the spammer can then send 1000 copies of the stamp with 1000 spam messages, but 999 of them will be rejected when the stamp is decoded, without any network transaction being required. mathew --0016364edf6ef8b4490462f685f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2009 at 15:58, John Levine <johnl@taugh.com> wrote:
My standard spam model is that the bad guy buys one s= tamp and uses
that one genuine stamp on a thousand messages (transactions, whatever)
at the same time.  It's really easy to verify that a stamp is real=
using digital signatures, but there's no way to tell if it's alread= y
been used other than asking the issuer.

It is possible to defend against this threat, but not cheaply, since
the defense requires a robust transaction system that can serialize
the thousand requests, approve one, and reject the other 999, while
still providing service to the rest of their customers.
<= br>Nonsense. You just make the purchased stamp dependent upon the address o= f the recipient, for example by hashing the To: address inside the cryptogr= aphic stamp when it's minted.

You know, like SSL certificates include the hostname so you can't u= se the same one on multiple sites.

Sure, the spammer can then send 1= 000 copies of the stamp with 1000 spam messages, but 999 of them will be re= jected when the stamp is decoded, without any network transaction being req= uired.


mathew
--0016364edf6ef8b4490462f685f6-- From john@jlc.net Sun Feb 15 10:55:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AED53A6915 for ; Sun, 15 Feb 2009 10:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.635 X-Spam-Level: X-Spam-Status: No, score=-6.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wxwFK4glyR7 for ; Sun, 15 Feb 2009 10:55:56 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id CDE5A3A6824 for ; Sun, 15 Feb 2009 10:55:56 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 74D7333C31; Sun, 15 Feb 2009 13:56:04 -0500 (EST) Date: Sun, 15 Feb 2009 13:56:04 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090215185604.GC94816@verdi> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:55:57 -0000 mathew wrote: > On Thu, Feb 12, 2009 at 15:58, John Levine wrote: > >> My standard spam model is that the bad guy buys one stamp and uses >> that one genuine stamp on a thousand messages (transactions, whatever) >> at the same time. It's really easy to verify that a stamp is real >> using digital signatures, but there's no way to tell if it's already >> been used other than asking the issuer. >> >> It is possible to defend against this threat, but not cheaply, since >> the defense requires a robust transaction system that can serialize >> the thousand requests, approve one, and reject the other 999, while >> still providing service to the rest of their customers. > > Nonsense. You just make the purchased stamp dependent upon the address > of the recipient, for example by hashing the To: address inside the > cryptographic stamp when it's minted. Minor correction: for the POSTAGE draft, the token may cover multiple To: addresses; thus it should be tagged with the receiving MTA, not the To: address. > You know, like SSL certificates include the hostname so you can't use > the same one on multiple sites. > > Sure, the spammer can then send 1000 copies of the stamp with 1000 spam > messages, but 999 of them will be rejected when the stamp is decoded, > without any network transaction being required. This might be worth adding to the POSTAGE draft -- not that it isn't already possible, just that for this to catch multiple use of the same token it would need to be mandatory. What do folks think? -- John Leslie From johnl@iecc.com Sun Feb 15 15:12:04 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4FF3A6A8B for ; Sun, 15 Feb 2009 15:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjLPwfnsY0St for ; Sun, 15 Feb 2009 15:12:03 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id DB0A93A67D4 for ; Sun, 15 Feb 2009 15:12:02 -0800 (PST) Received: (qmail 42724 invoked from network); 15 Feb 2009 23:12:09 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 15 Feb 2009 23:12:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=y2whwKxWPPGf6k77VgtHz5BxvT58r2Wr1ghSOq96yB8=; b=gr9w2g7ACuBISrDumeJqK5we915+JgO/kv8WC0M7TKJbk0z9mbwKpNMzw5egyScBfv68Djujfqa4q8995lssPBJRF2MwVyXA3qSPWV6NftxMsZBLY9PTyjPHxyIc3yO5vL7JDSoQB4CsXd8k4dKUnC/l205UKDQ/8i+LFM3EzRE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=y2whwKxWPPGf6k77VgtHz5BxvT58r2Wr1ghSOq96yB8=; b=IEfiunjOewX2AFN4IBVgcvsOYphA3Zq9TcJpTYT9tWBiVvH274BFeHXoX171L+7Ba9BvJh4kiJz9Lm7wY0TM9Od9KhnYiEHKaK1QNYPZof5v5fiZzGHj8KwI8BZbxO0Th/pvX4PhnL26Kz/PvsxQHLVnCUt09n3gMgfmwFqnQz4= Date: 15 Feb 2009 23:12:09 -0000 Message-ID: <20090215231209.66745.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 23:12:04 -0000 >> It is possible to defend against this threat, but not cheaply, since >> the defense requires a robust transaction system that can serialize >> the thousand requests, approve one, and reject the other 999, while >> still providing service to the rest of their customers. >Nonsense. You just make the purchased stamp dependent upon the address of >the recipient, for example by hashing the To: address inside the >cryptographic stamp when it's minted. Aw, come on. Please don't tell me I have to explain why this model has the exact same problem. Really, if you're the least bit serious about doing this, you need a performance model to help analyze proposals, many of which are likely to have much more subtle problems than this one. R's, John From schaefer@closedmail.com Sun Feb 15 15:50:27 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0EE93A6A65 for ; Sun, 15 Feb 2009 15:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgjsgNNW8M5k for ; Sun, 15 Feb 2009 15:50:27 -0800 (PST) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by core3.amsl.com (Postfix) with ESMTP id 277C43A696C for ; Sun, 15 Feb 2009 15:50:26 -0800 (PST) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KF4004G6SVWZZN6@vms173007.mailsrvcs.net> for asrg@irtf.org; Sun, 15 Feb 2009 17:50:25 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n1FNoJu6007979 for ; Sun, 15 Feb 2009 15:50:20 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n1FNoIdT007978 for asrg@irtf.org; Sun, 15 Feb 2009 15:50:18 -0800 From: Bart Schaefer Message-id: <090215155018.ZM7977@torch.brasslantern.com> Date: Sun, 15 Feb 2009 15:50:18 -0800 In-reply-to: <20090215185604.GC94816@verdi> Comments: In reply to John Leslie "Re: [Asrg] About that e-postage draft [POSTAGE]" (Feb 15, 1:56pm) References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215185604.GC94816@verdi> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Anti-Spam Research Group - IRTF MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 23:50:28 -0000 On Feb 15, 1:56pm, John Leslie wrote: } Subject: Re: [Asrg] About that e-postage draft [POSTAGE] } } mathew wrote: } > } > Nonsense. You just make the purchased stamp dependent upon the address } > of the recipient, for example by hashing the To: address inside the } > cryptographic stamp when it's minted. } } Minor correction: for the POSTAGE draft, the token may cover multiple } To: addresses; thus it should be tagged with the receiving MTA, not the } To: address. } } This might be worth adding to the POSTAGE draft -- not that it isn't } already possible, just that for this to catch multiple use of the same } token it would need to be mandatory. What do folks think? John might recall that during our off-list discussion of the POSTAGE draft, I suggested using a per-transaction token such as DSN ENVID for this sort of tagging, but we chose to avoid becoming entangled with the DSN extension. Tagging per MTA isn't nearly as effective as per recipient or per transaction, because for some MTAs (a Yahoo MX, for example) the number of possible recipients becomes large enough that using the same stamp on thousands of transactions is still a viable attack. However, I'd like to remind everyone of one important aspect of the POSTAGE draft: It doesn't rely on the notion of "buying a stamp". The transaction is structured such that the token presented by the sender is more like a credit card authorization. The token allows the recipient MTA to make a charge of a specified amount against an account maintained by (a bank on behalf of) the sender. The sender does not obtain the "stamp" from the recipient, he gets it from his bank. If that sender chooses to present the same stamp a million times, it's up to the sender and his bank to resolve the dispute; if the bank has no way to detect and refuse duplicates, it can simply tally them all up and bill the sender after the fact. This doesn't in any way address problems of a pwned machine grabbing tokens from a compromised bank account, but it does mean that the recipient MTA can ignore the problem and expect to be paid no matter what shenanigans are going on at the other end of the wire. From meta404@gmail.com Mon Feb 16 07:06:52 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890DB3A6A9F for ; Mon, 16 Feb 2009 07:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5d8O0l5ilvp for ; Mon, 16 Feb 2009 07:06:51 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 91CDB3A6A8C for ; Mon, 16 Feb 2009 07:06:51 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so584599qwe.7 for ; Mon, 16 Feb 2009 07:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=wFSsm7AtthQt2lccoGVzjM66ZK28fhnmZBOrcc2nAhU=; b=D7tyoViS+kKkvYmF5eYziIQNMvMMXw04neU9SCoYrmhQ3/iq/mJKnoxifAA+LdMG2U OTvnWkf8PGhWEQTyiu535/9u0fv6dxU+dCrjqTwq1TGKx/pCK6Bjw5bGyfRD6PuY4JuL Dutf6WugEfbosER4usKMr3SyFIs/UIkHAoWYg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=igHgvcVio/75/MU7ZR8EacAcDJ6vnadrbTH/C5YFfa/cYWVthtcfe7F9g5H6WokzLO s8hSN4HlJflaEIu+vkorAyFxpUFt0dSkBCexEkcfHu5pvNpts6+1YGPPl/UKzXmgD4k8 JUgVQrTskDgkXs6JMAhVEg3HqeghnQ3Y5XIsI= MIME-Version: 1.0 Sender: meta404@gmail.com Received: by 10.229.89.146 with SMTP id e18mr1177240qcm.23.1234796820411; Mon, 16 Feb 2009 07:07:00 -0800 (PST) In-Reply-To: <20090215231209.66745.qmail@simone.iecc.com> References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> Date: Mon, 16 Feb 2009 09:07:00 -0600 X-Google-Sender-Auth: 6a68bbfca91be2af Message-ID: <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> From: mathew To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=0016364ee4e6d9b3d204630a8925 Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 15:06:52 -0000 --0016364ee4e6d9b3d204630a8925 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 15, 2009 at 17:12, John Levine wrote: > >> It is possible to defend against this threat, but not cheaply, since > >> the defense requires a robust transaction system that can serialize > >> the thousand requests, approve one, and reject the other 999, while > >> still providing service to the rest of their customers. > > >Nonsense. You just make the purchased stamp dependent upon the address of > >the recipient, for example by hashing the To: address inside the > >cryptographic stamp when it's minted. > > Aw, come on. Please don't tell me I have to explain why this model has > the exact same problem. Go on, indulge us. Explain why stamps that are hashed to the recipient can still be spent on multiple spams unless a network transaction is carried out for every one. Let's go ahead and assume that the stamp also has an expiry date encoded into it, mmkay? mathew --0016364ee4e6d9b3d204630a8925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Feb 15, 2009 at 17:12, John Levine <johnl@taugh.com> wrote:
>> It is possible to defend against this threat= , but not cheaply, since
>> the defense requires a robust transaction system that can serializ= e
>> the thousand requests, approve one, and reject the other 999, whil= e
>> still providing service to the rest of their customers.

>Nonsense. You just make the purchased stamp dependent upon the address = of
>the recipient, for example by hashing the To: address inside the
>cryptographic stamp when it's minted.

Aw, come on.  Please don't tell me I have to explain why thi= s model has
the exact same problem.

Go on, indulge us. Explain why= stamps that are hashed to the recipient can still be spent on multiple spa= ms unless a network transaction is carried out for every one.

Let= 9;s go ahead and assume that the stamp also has an expiry date encoded into= it, mmkay?
 

mathew
--0016364ee4e6d9b3d204630a8925-- From ben@stagecraft.net Mon Feb 16 08:25:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E913A6CB8 for ; Mon, 16 Feb 2009 08:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfnvHVRJk2KA for ; Mon, 16 Feb 2009 08:25:35 -0800 (PST) Received: from lercnetworks.com (unknown [140.99.13.90]) by core3.amsl.com (Postfix) with ESMTP id BBC1F3A6C2C for ; Mon, 16 Feb 2009 08:25:35 -0800 (PST) Received: (qmail 30621 invoked from network); 16 Feb 2009 09:39:17 -0700 Received: from c-24-61-74-219.hsd1.nh.comcast.net (HELO benjamin-aprils-macbook-pro.local) (24.61.74.219) by 91.lercnetworks.com with SMTP; 16 Feb 2009 09:39:17 -0700 Message-ID: <49999388.5040306@stagecraft.net> Date: Mon, 16 Feb 2009 11:25:44 -0500 From: Benjamin April User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> In-Reply-To: <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 16:25:37 -0000 mathew wrote: > On Sun, Feb 15, 2009 at 17:12, John Levine > wrote: > > >> It is possible to defend against this threat, but not cheaply, > since > >> the defense requires a robust transaction system that can serialize > >> the thousand requests, approve one, and reject the other 999, while > >> still providing service to the rest of their customers. > > >Nonsense. You just make the purchased stamp dependent upon the > address of > >the recipient, for example by hashing the To: address inside the > >cryptographic stamp when it's minted. > > Aw, come on. Please don't tell me I have to explain why this > model has > the exact same problem. > > > Go on, indulge us. Explain why stamps that are hashed to the recipient > can still be spent on multiple spams unless a network transaction is > carried out for every one. > > Let's go ahead and assume that the stamp also has an expiry date > encoded into it, mmkay? > > > mathew I think we need to go the other way. Stop assuming the token contains *anything* useful. It is intended to be an opaque meaningless value. This removes the possibility of anything but brute-force forgery. If we have lots of complex encoding of values we open the door for people to forge those values. We also extend the time to clear a token through the receiving "bank" considerably and enter a world of crypto-library incompatibility, varying format versions etc. Before I get flamed I should say that a well designed DHT lookup for an opaque token would certainly be faster than verifying a signature then doing a DHT lookup for the serial number. I will also go out on a limb and say that doing a DHT insert of random block of pre-existing random data and monitoring the result for duplication will be faster than marshaling and signing a new token based on a series of values. This is not to say that the "BANK" can't encode something they find useful in a token, but I would urge them not to. "BANKS" are also welcome to declare number-space limitations if the like e.g. mod 7 or prime but again this severely limits the search-space for a brute-force attack. The beauty of a simple token like this is that you can keep a cache of token's you have seen recently. Recently being defined by the amount of disk space you wish to dedicate to this. If you have seen the token in the last "X" consider it invalid. MTA implementations need to be vigilant in looking for brute-force attacks (as should "BANKS") to prevent cache-poisoning attacks. Thanks Ben > ------------------------------------------------------------------------ > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > From john@jlc.net Mon Feb 16 09:06:00 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483AA3A6CDF for ; Mon, 16 Feb 2009 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnoKDoj1VoqH for ; Mon, 16 Feb 2009 09:05:59 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 4ACEB3A6CD4 for ; Mon, 16 Feb 2009 09:04:27 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5CCA233C2D; Mon, 16 Feb 2009 12:04:36 -0500 (EST) Date: Mon, 16 Feb 2009 12:04:36 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090216170436.GD94816@verdi> References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090215231209.66745.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:06:00 -0000 John Levine wrote: > >> Nonsense. You just make the purchased stamp dependent upon the address of >> the recipient, for example by hashing the To: address inside the >> cryptographic stamp when it's minted. > > Aw, come on. Please don't tell me I have to explain why this model has > the exact same problem. Actually, it's not "exactly" the same: though the "bank" has a very similar problem, encoding the recipient MTA would mean that there's a test the recipient MTA could do before submitting to the "bank". I'm a bit open on this issue, but I'm disinclined to change the spec before we get some research experience. I do think it wise for the "bank" to ask what receiving MTA the token is destined for, but it seems to me that - whether it actually encodes that in the token, and - whether it tells the receiving MTA how to decode it are issues we shouldn't specify yet. -- John Leslie From john@jlc.net Mon Feb 16 09:17:28 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA19D3A694F for ; Mon, 16 Feb 2009 09:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.63 X-Spam-Level: X-Spam-Status: No, score=-6.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b9hmoPUHVSY for ; Mon, 16 Feb 2009 09:17:28 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id E21263A691D for ; Mon, 16 Feb 2009 09:17:27 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 62C2033C2B; Mon, 16 Feb 2009 12:17:38 -0500 (EST) Date: Mon, 16 Feb 2009 12:17:38 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090216171738.GE94816@verdi> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215185604.GC94816@verdi> <090215155018.ZM7977@torch.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <090215155018.ZM7977@torch.brasslantern.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:17:28 -0000 Bart Schaefer wrote: > > However, I'd like to remind everyone of one important aspect of the > POSTAGE draft: It doesn't rely on the notion of "buying a stamp". > > The transaction is structured such that the token presented by the > sender is more like a credit card authorization. The token allows the > recipient MTA to make a charge of a specified amount against an account > maintained by (a bank on behalf of) the sender. The sender does not > obtain the "stamp" from the recipient, he gets it from his bank. Ideally, the token is issued by a "bank" where both sending MTA and receiving MTA have accounts. Whether those accounts are like "credit" or "debit" cards or some other model entirely is orthogonal to the spec. (We envision agreements between "banks" that enable sending MTAs to request a token from a different "bank" than the one the receiving MTA will redeem it at; but that is out of scope at the moment, and we hope for research where both use the same "bank".) > If that sender chooses to present the same stamp a million times, it's > up to the sender and his bank to resolve the dispute; if the bank has > no way to detect and refuse duplicates, it can simply tally them all > up and bill the sender after the fact. Obviously this would make for an unhappy customer! But Bart is correct to say that this is an issue between customer and "bank" -- the spec is, and IMHO should be, silent on what happens if a "bank" redeems the same token more than once. -- John Leslie From steve@blighty.com Mon Feb 16 09:33:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6B53A6A7E for ; Mon, 16 Feb 2009 09:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo5mr3nZ7BtT for ; Mon, 16 Feb 2009 09:32:58 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id B40103A691D for ; Mon, 16 Feb 2009 09:32:58 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id EE15B805E7 for ; Mon, 16 Feb 2009 09:33:03 -0800 (PST) Message-Id: <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 09:33:07 -0800 References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:33:03 -0000 On Feb 16, 2009, at 7:07 AM, mathew wrote: > On Sun, Feb 15, 2009 at 17:12, John Levine wrote: > >> It is possible to defend against this threat, but not cheaply, > since > >> the defense requires a robust transaction system that can serialize > >> the thousand requests, approve one, and reject the other 999, while > >> still providing service to the rest of their customers. > > >Nonsense. You just make the purchased stamp dependent upon the > address of > >the recipient, for example by hashing the To: address inside the > >cryptographic stamp when it's minted. > > Aw, come on. Please don't tell me I have to explain why this model > has > the exact same problem. > > Go on, indulge us. Explain why stamps that are hashed to the > recipient can still be spent on multiple spams unless a network > transaction is carried out for every one. > > Let's go ahead and assume that the stamp also has an expiry date > encoded into it, mmkay? > If it's simply hashed then anyone can create them. That means it's possible to send a large number of messages using stamps that look entirely plausible prior to them being looked up at the central broker. There are obvious reasons why people would do this. So, the next step is to use some crypto such that it's possible for anyone to validate that the stamp may be plausible for the recipient, but not for anyone to generate it. Maybe you use public key signatures - presumably with the private key held solely by the bank. But that means that stamps are not interchangeable. You can't buy them or generate them in advance, or at least not in bulk, in advance. Instead you have to purchase them (from one of a small number of "banks") at the time you send the mail as well as redeem them (from that very same bank) later. (Given that the sending machine has to contact a central server and the receiving machine also has to contact the same central server during the transmission of the message there are a lot of other things you could do with it that are simpler than epostage). Cheers, Steve From prussell@nd.edu Mon Feb 16 09:45:55 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EA73A6BB7 for ; Mon, 16 Feb 2009 09:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQWnRrbMqMd5 for ; Mon, 16 Feb 2009 09:45:55 -0800 (PST) Received: from mx-p1.cc.nd.edu (mx-p1.cc.nd.edu [129.74.250.57]) by core3.amsl.com (Postfix) with ESMTP id D7BB53A6B43 for ; Mon, 16 Feb 2009 09:45:54 -0800 (PST) Received: from mta-2.cc.nd.edu (mta-2.cc.nd.edu [129.74.250.37]) by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n1GHjTxg023411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Feb 2009 12:45:32 -0500 Received: from [172.19.226.104] (nat20.cc.nd.edu [129.74.4.120]) (authenticated bits=0) by mta-2.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id n1GHjvRR025081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Feb 2009 12:45:58 -0500 (EST) Message-ID: <4999A653.6000008@nd.edu> Date: Mon, 16 Feb 2009 12:45:55 -0500 From: Paul Russell User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <20090216170436.GD94816@verdi> In-Reply-To: <20090216170436.GD94816@verdi> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Source-IP: 129.74.250.37 X-ND-MTA-Date: Mon, 16 Feb 2009 12:45:32 EST Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:45:55 -0000 On 2/16/2009 12:04 PM, John Leslie wrote: > I do think it wise for the "bank" to ask what receiving MTA the token is > destined for, but it seems to me that > > - whether it actually encodes that in the token, and > - whether it tells the receiving MTA how to decode it > > are issues we shouldn't specify yet. In other words, the sender must buy a seperate "stamp" for each message sent, at the time the message is sent. This precludes "buying a book of stamps" or "filling the postage meter", and using the postage, as needed, over time. The suggestion from Benjamin April that an e-postage token should have an opaque value makes sense to me. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame prussell@nd.edu From johnl@iecc.com Mon Feb 16 11:27:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFF93A6A0D for ; Mon, 16 Feb 2009 11:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZuRbKKX7DRQ for ; Mon, 16 Feb 2009 11:27:28 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 483693A69F6 for ; Mon, 16 Feb 2009 11:27:28 -0800 (PST) Received: (qmail 76824 invoked from network); 16 Feb 2009 19:27:36 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 16 Feb 2009 19:27:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=djOi/LjUyLMTKLaMJ1DiFAOAEI1Nlt3TE9xhJU3ewp0=; b=nPIvy5+i7Z1+iVAqQt6j7+nfvSwoyjFp7wT2/sLpUWywfPVFL+qY0T1soPIBJxk02Ygf8xVRviTsHW2JA0mVT27aqc8C5svV4DIYGniC6Ej0BI+0EbjwVB8k3YaPFc6Cr3YLnELlzTllP1Bp5BHBR0IKnW0sd0piM9qnQLu0PCw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=djOi/LjUyLMTKLaMJ1DiFAOAEI1Nlt3TE9xhJU3ewp0=; b=JDd/8znENi1Hl5S6FUcZuY8sdmPKJRz+yf8RekEUn1xFwsUNbRujVsxKzhoYn2JNanXzBAQ7FRWl41V7oB4IMqDEv9Kr9j0GbzBGAjsaIae7Lg4eDuNHtOX3+EnM7M+mzluBcNa7jGC8l6Igdau0bEZ/qeDPNkGcSX0RYMR7TMY= Date: 16 Feb 2009 19:27:36 -0000 Message-ID: <20090216192736.94339.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 19:27:29 -0000 >But that means that stamps are not interchangeable. You can't buy >them or generate them in advance, or at least not in bulk, in >advance. Instead you have to purchase them (from one of a small >number of "banks") at the time you send the mail as well as redeem >them (from that very same bank) later. Right -- we've just moved the bottleneck from cashing the stamps to generating the stamps. But actually, we haven't moved it, since the bad guy can use the same stamp to send multiple spams to the same victim unless the bank also cancels the stamps. The idea of an expiration time is not terrible, but now it means that we're putting a hard limit on how slow a recipient system can be and not lose valid mail due to expiring stamps. There's a tradeoff between replay prevention and lost mail that I doubt has a satisfactory resolution, since it's not hard to send dozens or hundreds of messages a second, but an unavailable system is often unavailable for minutes or hours. If you allow senders to redeem unused expired stamps, now you have yet another race condition of trying to use a stamp and redeem it within a small interval around the expiration time. It would be really nice if anyone suggesting a postage scheme do at least a rudimentary threat analysis like this, what are likely ways that bad guys will try to defraud it, what are the countermeasures, and how expensive are they. R's, John From ben@stagecraft.net Mon Feb 16 12:07:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025563A6838 for ; Mon, 16 Feb 2009 12:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS2ycn1IgWO5 for ; Mon, 16 Feb 2009 12:07:09 -0800 (PST) Received: from lercnetworks.com (unknown [140.99.13.90]) by core3.amsl.com (Postfix) with ESMTP id 1F6293A67C1 for ; Mon, 16 Feb 2009 12:07:09 -0800 (PST) Received: (qmail 32076 invoked from network); 16 Feb 2009 13:20:52 -0700 Received: from c-24-61-74-219.hsd1.nh.comcast.net (HELO benjamin-aprils-macbook-pro.local) (24.61.74.219) by 91.lercnetworks.com with SMTP; 16 Feb 2009 13:20:51 -0700 Message-ID: <4999C764.6060409@stagecraft.net> Date: Mon, 16 Feb 2009 15:07:00 -0500 From: Benjamin April User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> In-Reply-To: <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:07:10 -0000 Steve Atkins wrote: > > On Feb 16, 2009, at 7:07 AM, mathew wrote: > >> On Sun, Feb 15, 2009 at 17:12, John Levine wrote: >> >> It is possible to defend against this threat, but not cheaply, since >> >> the defense requires a robust transaction system that can serialize >> >> the thousand requests, approve one, and reject the other 999, while >> >> still providing service to the rest of their customers. >> >> >Nonsense. You just make the purchased stamp dependent upon the >> address of >> >the recipient, for example by hashing the To: address inside the >> >cryptographic stamp when it's minted. >> >> Aw, come on. Please don't tell me I have to explain why this model has >> the exact same problem. >> >> Go on, indulge us. Explain why stamps that are hashed to the >> recipient can still be spent on multiple spams unless a network >> transaction is carried out for every one. >> >> Let's go ahead and assume that the stamp also has an expiry date >> encoded into it, mmkay? >> > > If it's simply hashed then anyone can create them. That means it's > possible to send a large number > of messages using stamps that look entirely plausible prior to them > being looked up at the central > broker. There are obvious reasons why people would do this. KISS, A simple back-off solves this. After your third bogus token my MTA won't accept a postage-due e-mail for 1 minute from your MTA. IMO something like this should be done regardless of weather the token has any encoded meaning. (insert your own values) > So, the next step is to use some crypto such that it's possible for > anyone to validate that the stamp > may be plausible for the recipient, but not for anyone to generate it. > Maybe you use public key > signatures - presumably with the private key held solely by the bank. My main concern here is that allowing the receiving MTA to validate the token offers a false sense of authority. We now know it is far easier than originally expected to create a "fake" signing cert. While some will argue that using appropriately modern hashing etc will mitigate that, I say it only delays the inevitable. On the other had the only known valid attack against a truly random (and secret) opaque token is brute-force. We have plenty of history to look at for reducing the effectiveness of this kind of attack. > But that means that stamps are not interchangeable. You can't buy them > or generate them in > advance, or at least not in bulk, in advance. Instead you have to > purchase them (from one of a > small number of "banks") at the time you send the mail as well as > redeem them (from that very > same bank) later. I see this as a big issue. I would find having to go to the post office every time I needed a stamp insane. By using opaque tokens you could buy a selection of tokens in advance and dispense them on demand. > > (Given that the sending machine has to contact a central server and > the receiving machine > also has to contact the same central server during the transmission of > the message there are a lot > of other things you could do with it that are simpler than epostage). In the opaque token model I do not see this as a required state. You would be able to pre-buy tokens and only the recipient would have to have ongoing connection with the "BANK". Maybe some banks will offer discounted fees to MTAs who provide advance notice before placing a big order for tokens. Thanks Ben > > Cheers, > Steve > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg From steve@blighty.com Mon Feb 16 12:40:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B513A6D0A for ; Mon, 16 Feb 2009 12:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7GNJdTXZ8LN for ; Mon, 16 Feb 2009 12:40:09 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id A4E2B3A6BCB for ; Mon, 16 Feb 2009 12:40:09 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 16789805C3 for ; Mon, 16 Feb 2009 12:40:14 -0800 (PST) Message-Id: <769AD13D-0817-44C6-BF9D-5B764FBA2785@blighty.com> From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <4999C764.6060409@stagecraft.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 12:40:17 -0800 References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> <4999C764.6060409@stagecraft.net> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:40:16 -0000 On Feb 16, 2009, at 12:07 PM, Benjamin April wrote: > Steve Atkins wrote: >> >> If it's simply hashed then anyone can create them. That means it's >> possible to send a large number >> of messages using stamps that look entirely plausible prior to them >> being looked up at the central >> broker. There are obvious reasons why people would do this. > KISS, A simple back-off solves this. After your third bogus token my > MTA > won't accept a postage-due e-mail for 1 minute from your MTA. IMO > something like this should be done regardless of weather the token has > any encoded meaning. (insert your own values) OK. I have 100,000 MTAs. Now what are you going to do? >> So, the next step is to use some crypto such that it's possible for >> anyone to validate that the stamp >> may be plausible for the recipient, but not for anyone to generate >> it. >> Maybe you use public key >> signatures - presumably with the private key held solely by the bank. > My main concern here is that allowing the receiving MTA to validate > the > token offers a false sense of authority. We now know it is far easier > than originally expected to create a "fake" signing cert. While some > will argue that using appropriately modern hashing etc will mitigate > that, I say it only delays the inevitable. Yup. > On the other had the only known valid attack against a truly random > (and > secret) opaque token is brute-force. We have plenty of history to > look > at for reducing the effectiveness of this kind of attack. Well, no. There are many, many other types of attack against a system that uses opaque cookies. But the two obvious choices are either something involving cryptographic authentication or an opaque cookie. They're different enough that they should probably be considered separately, if at all. >> But that means that stamps are not interchangeable. You can't buy >> them >> or generate them in >> advance, or at least not in bulk, in advance. Instead you have to >> purchase them (from one of a >> small number of "banks") at the time you send the mail as well as >> redeem them (from that very >> same bank) later. > I see this as a big issue. I would find having to go to the post > office > every time I needed a stamp insane. By using opaque tokens you could > buy > a selection of tokens in advance and dispense them on demand. Yes. (Or, with some limits, reuse them, but that's a different aspect). >> (Given that the sending machine has to contact a central server and >> the receiving machine >> also has to contact the same central server during the transmission >> of >> the message there are a lot >> of other things you could do with it that are simpler than epostage). > In the opaque token model I do not see this as a required state. You > would be able to pre-buy tokens and only the recipient would have to > have ongoing connection with the "BANK". Maybe some banks will offer > discounted fees to MTAs who provide advance notice before placing a > big > order for tokens. My statement was in the context of epostage stamps which are purchased for a specific recipient. Obviously if that's not the case you can buy stamps in bulk (or reuse stamps you receive) rather than having to buy them specifically for each recipient. Cheers, Steve From johnl@iecc.com Mon Feb 16 13:22:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8433A6D19 for ; Mon, 16 Feb 2009 13:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.899 X-Spam-Level: X-Spam-Status: No, score=-14.899 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2HjxqAgjfv1 for ; Mon, 16 Feb 2009 13:22:43 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 4D5373A6844 for ; Mon, 16 Feb 2009 13:22:43 -0800 (PST) Received: (qmail 77127 invoked from network); 16 Feb 2009 21:22:52 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 16 Feb 2009 21:22:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=oHJF3syjPZD4rG8I1A8sUQdNMGdWOBLwlaqlTj6UxYA=; b=OidLYxoyRNb56r5Egej0dEuzi8C0/xR28Zp8Huw/YL3+5gsHFowBwY7n3Z5KzGtmhu8y8zNBiVxRSCqRJ1slPUsE0vfk9hGohh0HbItu7dx9ZtEFkzhw7tNP1H4qIrsVACAJ+biwEAfuEBKMl1moVvpHhPycsWvBZEzEeZwz3nA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=oHJF3syjPZD4rG8I1A8sUQdNMGdWOBLwlaqlTj6UxYA=; b=jc8sem/ozU4Ux90CuAK0ixByF3RCugdXR4NQ60jzhiesCDfIvJqjbiOmlvJTKBVno+j7DvG1PG48uPRCVogr371TGHFJZbCZqrkb7mb4pgwCrHNvCzcfpOsxRqp/ldEG2jYAwjqZyMygyP6S8E1RCuUdo2dtDmSKKeMo/RDR0Vw= Date: 16 Feb 2009 21:22:51 -0000 Message-ID: <20090216212251.24646.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090216171738.GE94816@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:22:44 -0000 > Ideally, the token is issued by a "bank" where both sending MTA and >receiving MTA have accounts. You probably don't want to do that, since the performance of book entry transactions is worse than for bearer ones. If you're doing book entry, you need at least a journalling system to log the entries to be added to each account, if not locks on each account to maintain the balance. Here's the least awful way I know to do small value online payments: Sender goes to his bank and buys a bunch of bearer stamps. There are two things one can do with a bearer stamp, cancel/reissue, and redeem it. Cancel/reissue simply creates a new stamp worth the same as the old stamp (or maybe a little less if the bank keeps its cut) but promises that the new stamp is good. If the old stamp has already been cancelled, this fails. This transaction is supposed to be fast, since it needs only check the one bit to see if it's been used and generate the new stamp or maybe take one from a precomputed list of them. Redeeming is a batch process, collect a whole bunch of stamps, send them in to the bank, and in a while you get a credit for all of them, maybe in an account in that bank, maybe sent to your real bank. The point of bearer stamps is that the bank doesn't try to track who's got them, they're like cash and whoever presents a stamp first wins. So when you get those reissued stamps for incoming postage, you have to keep those private, since if someone else finds out what they are and sends them to the bank first, he wins and you lose. None of this is new, this was all worked out a decade ago. But it's all still way too slow to keep up with an interesting amount of e-mail. R's, John From ajv-zieddleurt@vsta.org Tue Feb 17 08:02:03 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C85E3A6870 for ; Tue, 17 Feb 2009 08:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vb6gF83VzKG for ; Tue, 17 Feb 2009 08:01:59 -0800 (PST) Received: from vsta.org (vsta.org [208.70.148.177]) by core3.amsl.com (Postfix) with ESMTP id 970113A6A14 for ; Tue, 17 Feb 2009 08:01:59 -0800 (PST) Received: from deepthought.vsta.org (localhost [127.0.0.1]) by vsta.org (Postfix) with ESMTP id 5FCFEABBE7 for ; Tue, 17 Feb 2009 07:52:33 -0800 (PST) To: asrg@irtf.org From: Andy Valencia Cc: Message-Id: <20090217155233.5FCFEABBE7@vsta.org> Date: Tue, 17 Feb 2009 07:52:33 -0800 (PST) Subject: Re: [Asrg] About that e-postage draft X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:02:03 -0000 --------------- > From: John Levine > ... > It would be really nice if anyone suggesting a postage scheme do at > least a rudimentary threat analysis like this, what are likely ways > that bad guys will try to defraud it, what are the countermeasures, > and how expensive are they. I believe "defraud" does not cover the range of analysis needed, because "fraud" implies using the system to benefit the bad guy. Because the spammers are SO happy with the current system, the analysis has to include any abuse of the system which will make it undesirable to the general population, even if there's no (immediate) benefit to the spammer. Thus not only must it address hijacked and spoofed postage, but also attacks which cause slow downs, dropped messages, false positives/negatives, and all the scenarios which spring from hijacked PC's. Banks have to deal with sob stories about grandmothers losing their life savings, and this new system will have to deal with it, too. Personally, I lump these systems into the same bin of pipe dreams as the UN-sanctioned anti-spam strike team, sweeping in on the spammers in a Blackhawk and bursting through the window in their kevlar suits. Except the latter would be cooler. :-> But neither one would work well, and neither one is going to happen. "In my very humble opinion" Andy Valencia From meta404@gmail.com Wed Feb 18 09:27:36 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16893A69E0 for ; Wed, 18 Feb 2009 09:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLXIbEceSiy5 for ; Wed, 18 Feb 2009 09:27:36 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id EE6703A63D2 for ; Wed, 18 Feb 2009 09:27:35 -0800 (PST) Received: by qyk14 with SMTP id 14so1290qyk.7 for ; Wed, 18 Feb 2009 09:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bAl6hSsgtQcoBUp2b7gLriI+YlwUEOVwRdQAfdVo2Ac=; b=TI+c/wCQ4HGpY1JwYUzFY07J0cb1WbMsRurDS8Lr4Ir77l/nSH6pC/6vcDRp1A828g zBsYqCj3DMYHr601D5R3ena/0A+jmXo5F3iylfjrxHmLdq/cNO+WbKnIBza/Nf7q7iS9 9aVeguv/gKQ2I2+Z2TgzBhXqtKE+HJ9iU9AR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sibKkMSHqhv+MvmSehClTgTo65eqt3Fw/q3Uc7AouZgShMOSkwXQxLCAA+SGhawL8/ Z7wA089RrkRSFjFJcU3NMAqQEHp9IzXPCjPePSl+knROQ+E3Z93nyPYz/yr7p74lUspA K+HUKPk1ilCMGWeh2/sORNz8dWKWh83+Kcaqk= Received: by 10.224.37.139 with SMTP id x11mr1681730qad.146.1234978067711; Wed, 18 Feb 2009 09:27:47 -0800 (PST) Received: from ?10.0.1.199? (cpe-66-25-161-48.austin.res.rr.com [66.25.161.48]) by mx.google.com with ESMTPS id 6sm91974qwd.43.2009.02.18.09.27.46 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 09:27:46 -0800 (PST) Sender: mathew murphy Message-ID: <499C4511.1050003@pobox.com> Date: Wed, 18 Feb 2009 11:27:45 -0600 From: mathew User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090216192736.94339.qmail@simone.iecc.com> In-Reply-To: <20090216192736.94339.qmail@simone.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 17:27:36 -0000 John Levine wrote: > But actually, we haven't moved it, since the bad guy can use the same > stamp to send multiple spams to the same victim unless the bank also > cancels the stamps. > Or unless the receiving system does elementary checks for the same stamp being used multiple times. But obviously, since your main interest is convincing everyone that e-postage is impossible, you're going to assume that the receiving system is implemented without even the most blatantly obvious checks. mathew From meta404@gmail.com Wed Feb 18 09:37:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8B33A6A17 for ; Wed, 18 Feb 2009 09:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKXJKuA027ei for ; Wed, 18 Feb 2009 09:37:35 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id B1A053A69F4 for ; Wed, 18 Feb 2009 09:37:35 -0800 (PST) Received: by qyk14 with SMTP id 14so10382qyk.7 for ; Wed, 18 Feb 2009 09:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=H4K5rVY9+++rSl5I3tMMDkfZuViO0j1DXUWjLKvHc4c=; b=Uu/M33wrp2iJJga0FC0MEkIQvcryWZNMTZZFBNOyfLcs4LGCx68Eh/gFC+HxfrIHFa 3FM4AZBrfV3PPu88gTgk7ZqmxxL6z1rItZi6EXxWYA4OOyxaRLEOCXpC7pyFwnkuTwvI 5C+6DYBiXWRqzSXCu2Sa79RG4vC6X1+gxpKBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=A5zD76FC8Pqa8dW/tiEkWv9Co4iUdwyUHQTt+6FlZOlP9pNAc5T+CKwDipSmcndRte 0SlnhNi8VivTqhOoXp35/BKboKZzndRVLdQ568+MWbBtU0pR0G7ix2i/6UR77Uw8OzJB cdC1VMkgmqGOEg8oP0lafLQw+a5ug+nU+RKT8= Received: by 10.224.67.10 with SMTP id p10mr10215470qai.267.1234978667229; Wed, 18 Feb 2009 09:37:47 -0800 (PST) Received: from ?10.0.1.199? (cpe-66-25-161-48.austin.res.rr.com [66.25.161.48]) by mx.google.com with ESMTPS id 2sm104577qwi.48.2009.02.18.09.37.46 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 09:37:46 -0800 (PST) Sender: mathew murphy Message-ID: <499C4769.3030106@pobox.com> Date: Wed, 18 Feb 2009 11:37:45 -0600 From: mathew User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> <4999C764.6060409@stagecraft.net> In-Reply-To: <4999C764.6060409@stagecraft.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 17:37:37 -0000 Benjamin April wrote: > My main concern here is that allowing the receiving MTA to validate the > token offers a false sense of authority. We now know it is far easier > than originally expected to create a "fake" signing cert. It was never intended to be anything other than trivial to create a signing cert. But just because I can create a signing cert, doesn't mean that anyone else is going to recognize it. With SSL, the fact that you create a signing cert doesn't mean any browser software is going to accept it as valid. With e-postage, sensible recipients will have a policy of not accepting unknown postage vendors by default. Just as browsers have lists of signing certs they accept, so e-mail MTAs and/or client software will have lists of signing certs they accept. I would imagine that to get your cert onto the standard list for a common MTA, you'd need to demonstrate that you actually paid out the postage and weren't just committing fraud. Much as you won't get added to the default cert list for Firefox if you irresponsibly sign any SSL key presented to you. > I see this as a big issue. I would find having to go to the post office > every time I needed a stamp insane. By using opaque tokens you could buy > a selection of tokens in advance and dispense them on demand. > The only reason having to go to the post office every time you need to buy a stamp is insane, is that the post office is a physical entity you have to travel to. Millions of people buy e-postage from the USPS every day, in order to ship stuff they sell on eBay. They go to the online post office every time they need to obtain and print a stamp. So there's a real world example showing that it's not an unworkable way of doing things. I don't know if the USPS makes their e-postage codes dependent on the address you're sending to, but clearly they *could* without breaking the way ordinary people use the service or making it unworkable. It would actually be an interesting experiment to try cutting up two USPS e-postage labels, switching the bar codes around, and seeing if the items still got delivered properly... mathew From meta404@gmail.com Wed Feb 18 09:41:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD07F3A6A79 for ; Wed, 18 Feb 2009 09:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I3t1m3CTj8l for ; Wed, 18 Feb 2009 09:41:15 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id 031203A6A15 for ; Wed, 18 Feb 2009 09:41:14 -0800 (PST) Received: by qyk14 with SMTP id 14so13647qyk.7 for ; Wed, 18 Feb 2009 09:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Eub99t5lDP7St+GijJ/8l1spCy6348iDipxM3TalG3w=; b=jE1bTVQ1Ogy6c4dKoqlGMssStECI8DS1b+pZ8Qufeoe8yvaxU0ZsO4Ez774kzQ/lZV D83erAY4b5A2DVyt2y82HZCeP79+yFS4vOYJNVTrxPX3mI3oA8nvSEpAmPgIjnkKcYnN xzJlxDqhXte213zxuzBNkWueJn6lflFLb6MUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CLJR16WkGrPD0+pKE5H6aA+xHDnbAOf/8gEqA4GHOBmhUk+37PMXJo+Z/28UDC8Zns D8b3iMk5qfej9TZu75G4Jk9ygDda/jiZFX0M+V0x98josNK/pd+ajoWvdnqOhs6wtfZU e+xaCPqhXyNWf9FUVG9oafzO4YE0agnNgOVW8= Received: by 10.224.28.207 with SMTP id n15mr1051687qac.91.1234978886117; Wed, 18 Feb 2009 09:41:26 -0800 (PST) Received: from ?10.0.1.199? (cpe-66-25-161-48.austin.res.rr.com [66.25.161.48]) by mx.google.com with ESMTPS id 5sm156735qwg.54.2009.02.18.09.41.25 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 09:41:25 -0800 (PST) Sender: mathew murphy Message-ID: <499C4843.4040004@pobox.com> Date: Wed, 18 Feb 2009 11:41:23 -0600 From: mathew User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090217155233.5FCFEABBE7@vsta.org> In-Reply-To: <20090217155233.5FCFEABBE7@vsta.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 17:41:15 -0000 Andy Valencia wrote: > Thus not only must it address hijacked and spoofed postage, but also > attacks which cause slow downs, dropped messages, false > positives/negatives, and all the scenarios which spring from hijacked > PC's. Banks have to deal with sob stories about grandmothers losing > their life savings, and this new system will have to deal with it, too. > Any system can be slowed down by a DoS attack. Therefore no system can ever meet your requirements. Therefore you might as well unsubscribe, as nothing anyone discusses here will satisfy you. mathew From rsk@gsp.org Wed Feb 18 10:00:59 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0C63A6767 for ; Wed, 18 Feb 2009 10:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7MrDpoMYuQl for ; Wed, 18 Feb 2009 10:00:58 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 2FE073A685F for ; Wed, 18 Feb 2009 10:00:58 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.90.dsl.charm.net [207.114.25.90]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n1II17Gk001730 for ; Wed, 18 Feb 2009 13:01:10 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n1II0pPc019964 for ; Wed, 18 Feb 2009 13:00:51 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n1II11ot016017 for ; Wed, 18 Feb 2009 13:01:01 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n1II0xrX016016 for asrg@irtf.org; Wed, 18 Feb 2009 13:00:59 -0500 Date: Wed, 18 Feb 2009 13:00:59 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090218180059.GA15257@gsp.org> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215185604.GC94816@verdi> <090215155018.ZM7977@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <090215155018.ZM7977@torch.brasslantern.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:00:59 -0000 I don't see how this has any possibility of working. Economic systems analogous to the mechanism you describe work, and are financially viable, because the overwhelming majority of transactions that they process are legitimate, and the transaction charges levied are sufficient to cover the overhead of detecting and dealing with the bogus ones. But the exact opposite is true w.r.t. email: the overwhelming majority of transactions are bogus. (And the adversary can easily push "overwhelming majority" to as many 9's as necessary or desirable at will.) Are there any real-world examples of systems where (say) 99% of the attempted transactions are fraudulent, yet the system remains viable? ---Rsk From rsk@gsp.org Wed Feb 18 10:03:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0633C3A6929 for ; Wed, 18 Feb 2009 10:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biotmiomjLys for ; Wed, 18 Feb 2009 10:03:52 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 1B17F3A677D for ; Wed, 18 Feb 2009 10:03:52 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.90.dsl.charm.net [207.114.25.90]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n1II43kM025330 for ; Wed, 18 Feb 2009 13:04:04 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n1II3l0l029732 for ; Wed, 18 Feb 2009 13:03:47 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n1II3wtc016072 for ; Wed, 18 Feb 2009 13:03:58 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n1II3wwZ016071 for asrg@irtf.org; Wed, 18 Feb 2009 13:03:58 -0500 Date: Wed, 18 Feb 2009 13:03:58 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090218180357.GB15257@gsp.org> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <20090213134025.GB10598@gsp.org> <20090213142121.GB94816@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090213142121.GB94816@verdi> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:03:53 -0000 On Fri, Feb 13, 2009 at 09:21:21AM -0500, John Leslie wrote: > Remember, presentation of a bad token is a much clearer indication > of evil intent: a few dozen should suffice for blocklisting. It's > quite practical to blocklist 100 million IPs, at which point the > problem will start to disappear. Computers blocklisted this way will > pretty much be forced into going through a relay MTA with which they > have a contractual relationship -- which removes the problem from > the "botted-MTA" territory. Blacklisting those 100 million IPs -- which most sensible folks did years ago, either by subdomain, regexp, IP, DNSBL or some mechanism -- has not forced them to go through relay MTAs. The only thing that will force them to through relay MTAs are router/firewall rulesets on the networks within which they reside. However, suppose -- against all experience -- that actually happens. (And that'd be a good thing, so I'm not arguing against; it's just that if it were going to happen, I think it would have happened within a few months of the rise of the zombies.) In that case, every relay MTA you see will present "a few dozen" bogus tokens very shortly thereafter, because some/most/all of those 100 million IPs will now be sending through them. Do you plan to blacklist all those relay MTAs? If so, then you could just do that now and skip the exercise. If not, then you're going to have to still do it the hard way. ---Rsk From rsk@gsp.org Wed Feb 18 10:06:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0993A687C for ; Wed, 18 Feb 2009 10:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlIKobUuEePp for ; Wed, 18 Feb 2009 10:06:09 -0800 (PST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by core3.amsl.com (Postfix) with ESMTP id 8595C3A6813 for ; Wed, 18 Feb 2009 10:06:09 -0800 (PST) Received: from squonk.gsp.org (bltmd-207.114.25.90.dsl.charm.net [207.114.25.90]) by taos.firemountain.net (8.14.1/8.14.1) with ESMTP id n1II6KYZ009209 for ; Wed, 18 Feb 2009 13:06:21 -0500 (EST) Received: from avatar.gsp.org (avatar.gsp.org [192.168.0.11]) by squonk.gsp.org (8.14.1/8.14.1) with ESMTP id n1II647P022763 for ; Wed, 18 Feb 2009 13:06:04 -0500 (EST) Received: from avatar.gsp.org (localhost [127.0.0.1]) by avatar.gsp.org (8.14.3/8.14.3/Debian-4) with ESMTP id n1II6Fue016156 for ; Wed, 18 Feb 2009 13:06:15 -0500 Received: (from rsk@localhost) by avatar.gsp.org (8.14.3/8.14.3/Submit) id n1II6FM4016155 for asrg@irtf.org; Wed, 18 Feb 2009 13:06:15 -0500 Date: Wed, 18 Feb 2009 13:06:15 -0500 From: Rich Kulawiec To: Anti-Spam Research Group - IRTF Message-ID: <20090218180615.GC15257@gsp.org> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:06:10 -0000 On Sun, Feb 15, 2009 at 09:14:15AM -0600, mathew wrote: > Nonsense. You just make the purchased stamp dependent upon the address of > the recipient, for example by hashing the To: address inside the > cryptographic stamp when it's minted. How's that going to work with forwarding, virtual user tables, and alias expansions? And how will it avoid leaking information when someone is BCC'd? ---Rsk From schaefer@closedmail.com Wed Feb 18 10:48:02 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930593A6A28 for ; Wed, 18 Feb 2009 10:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ8W7XmEvv6B for ; Wed, 18 Feb 2009 10:48:01 -0800 (PST) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id 337ED3A6A17 for ; Wed, 18 Feb 2009 10:48:01 -0800 (PST) Received: from torch.brasslantern.com ([96.238.220.215]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KF9007R0YVB0UVG@vms173019.mailsrvcs.net> for asrg@irtf.org; Wed, 18 Feb 2009 12:47:41 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n1IIlYUA017475 for ; Wed, 18 Feb 2009 10:47:34 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n1IIlW22017474 for asrg@irtf.org; Wed, 18 Feb 2009 10:47:32 -0800 From: Bart Schaefer Message-id: <090218104732.ZM17473@torch.brasslantern.com> Date: Wed, 18 Feb 2009 10:47:32 -0800 In-reply-to: <20090218180615.GC15257@gsp.org> Comments: In reply to Rich Kulawiec "Re: [Asrg] About that e-postage draft [POSTAGE]" (Feb 18, 1:06pm) References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090218180615.GC15257@gsp.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Anti-Spam Research Group - IRTF MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:48:02 -0000 On Feb 18, 1:06pm, Rich Kulawiec wrote: } Subject: Re: [Asrg] About that e-postage draft [POSTAGE] } } On Sun, Feb 15, 2009 at 09:14:15AM -0600, mathew wrote: } > Nonsense. You just make the purchased stamp dependent upon the address } > of the recipient, for example by hashing the To: address inside the } > cryptographic stamp when it's minted. } } How's that going to work with forwarding, virtual user tables, and } alias expansions? It doesn't, by fiat. The POSTAGE draft applies to an SMTP transaction, not to an end-to-end transmission through all possible store-and-forwards of a message from a sender to a recipient. Maybe this oversimplifies it into uselessness, but that's how it's structured. It's an SMTP extension, not a format-of-internet-messages extension. } And how will it avoid leaking information when someone is BCC'd? The crytpographic stamp doesn't need to survive the transaction any more than the Bcc header itself does. From ben@stagecraft.net Wed Feb 18 10:56:44 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB5E3A6909 for ; Wed, 18 Feb 2009 10:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IGHrqdMYGxi for ; Wed, 18 Feb 2009 10:56:44 -0800 (PST) Received: from lercnetworks.com (unknown [140.99.13.90]) by core3.amsl.com (Postfix) with ESMTP id 0709E3A677D for ; Wed, 18 Feb 2009 10:56:43 -0800 (PST) Received: (qmail 12063 invoked from network); 18 Feb 2009 12:10:43 -0700 Received: from c-24-61-74-219.hsd1.nh.comcast.net (HELO benjamin-aprils-macbook-pro.local) (24.61.74.219) by 91.lercnetworks.com with SMTP; 18 Feb 2009 12:10:43 -0700 Message-ID: <499C59F7.2030908@stagecraft.net> Date: Wed, 18 Feb 2009 13:56:55 -0500 From: Benjamin April User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090215231209.66745.qmail@simone.iecc.com> <7eeceb440902160707r3054f493o33576f1b9a35e4ef@mail.gmail.com> <042C0029-F3C2-47A7-B9D6-672DB0D91C26@blighty.com> <4999C764.6060409@stagecraft.net> <499C4769.3030106@pobox.com> In-Reply-To: <499C4769.3030106@pobox.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:56:44 -0000 mathew wrote: > Benjamin April wrote: >> My main concern here is that allowing the receiving MTA to validate the >> token offers a false sense of authority. We now know it is far easier >> than originally expected to create a "fake" signing cert. > > It was never intended to be anything other than trivial to create a > signing cert. But just because I can create a signing cert, doesn't > mean that anyone else is going to recognize it. > > With SSL, the fact that you create a signing cert doesn't mean any > browser software is going to accept it as valid. With e-postage, > sensible recipients will have a policy of not accepting unknown > postage vendors by default. Just as browsers have lists of signing > certs they accept, so e-mail MTAs and/or client software will have > lists of signing certs they accept. > > I would imagine that to get your cert onto the standard list for a > common MTA, you'd need to demonstrate that you actually paid out the > postage and weren't just committing fraud. Much as you won't get added > to the default cert list for Firefox if you irresponsibly sign any SSL > key presented to you. While that is accurate it misses the point. There is a verified attack methodology whereby I can create my own key-pair to replace the key-pair blessed by a trusted CA(e.g. Verisign). I can then use my key-pair as if it were signed by the CA, and it would be trusted as such. When the CA signs a key they only sign a digest. There are still CA's that use MD5 as their digest algorithm. Known weaknesses in MD5 make this possible. Most CAs that were on the ball moved to a form of SHA, but that is nothing but a delay tactic. >> I see this as a big issue. I would find having to go to the post office >> every time I needed a stamp insane. By using opaque tokens you could buy >> a selection of tokens in advance and dispense them on demand. >> > The only reason having to go to the post office every time you need to > buy a stamp is insane, is that the post office is a physical entity > you have to travel to. You've got me there. I still do not see a good reason to mandate send-time transactions. > Millions of people buy e-postage from the USPS every day, in order to > ship stuff they sell on eBay. They go to the online post office every > time they need to obtain and print a stamp. So there's a real world > example showing that it's not an unworkable way of doing things. > There are also models where you buy a quantity of e-postage and generate your own stamps without (mint-time) contact with USPS. I don't think it is un-workable however I don't yet see a compelling reason mandate the linking a token to a recipient. > I don't know if the USPS makes their e-postage codes dependent on the > address you're sending to, but clearly they *could* without breaking > the way ordinary people use the service or making it unworkable. It > would actually be an interesting experiment to try cutting up two USPS > e-postage labels, switching the bar codes around, and seeing if the > items still got delivered properly... > Thanks Ben > > mathew > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg From johnl@iecc.com Wed Feb 18 14:32:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1668A28C148 for ; Wed, 18 Feb 2009 14:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.692 X-Spam-Level: X-Spam-Status: No, score=-13.692 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgSO5eeqI6z8 for ; Wed, 18 Feb 2009 14:32:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 878C428C0FA for ; Wed, 18 Feb 2009 14:32:37 -0800 (PST) Received: (qmail 54462 invoked from network); 18 Feb 2009 22:32:49 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Feb 2009 22:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=uGY3bRZ6Z6XDESAX5wYtIMcjvHbG6ym7+zKYY+8mz/U=; b=nDHTpfQKaQAHqekW7um7wnalPsv20NvhUn5RB+Af0pWtGe2Pry/usW5vwNjni/4wwob5Fx1LvhETdgynqW/QDb3rACJjHBThyDKcS7Ttp6Tv37ph3cL8nW7z9+DypUMSYfCcXRvEzpqqiPvsdGwuVYsF7dP6eyxXndgs9rVpQbM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=uGY3bRZ6Z6XDESAX5wYtIMcjvHbG6ym7+zKYY+8mz/U=; b=XV+80tNfuuF/n3RLSWce1whdrY5BwNtK1CazWvgUhFAPwQgtJ3RgS76+gg7b9mQR7odGzZK0YdvghAOA47asU9jyyw7V4jkBArLfMS+8AwPHpI7yhzR/uFBZEi4/5UqhkenPa0sqYwyJu9baE08n52/NxPgTLe4pMAOxEIg5ano= Date: 18 Feb 2009 22:32:48 -0000 Message-ID: <20090218223248.18937.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <499C4511.1050003@pobox.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:32:39 -0000 >> But actually, we haven't moved it, since the bad guy can use the same >> stamp to send multiple spams to the same victim unless the bank also >> cancels the stamps. >> > >Or unless the receiving system does elementary checks for the same stamp >being used multiple times. [snark] A large mail system like AOL or Comcast has somewhere between dozens and hundreds of MTAs handling something like two billion delivery attempts per day. If you know a way to do cheap fast duplicate detection in such an environment, I know a lot of people who'll be interested to hear about it, and not just for e-postage. R's, John From johnl@iecc.com Wed Feb 18 14:41:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497563A67E9 for ; Wed, 18 Feb 2009 14:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.846 X-Spam-Level: X-Spam-Status: No, score=-13.846 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_05=-1.11, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZpSMyHsDtII for ; Wed, 18 Feb 2009 14:41:31 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 1DD7A3A67AD for ; Wed, 18 Feb 2009 14:41:31 -0800 (PST) Received: (qmail 62011 invoked from network); 18 Feb 2009 22:41:41 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Feb 2009 22:41:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=sLPEwu+n4in5ehKE8srzj4yS5kycNNf5P0oyGNp+P8Y=; b=kqpTUYt6OJZdXFmnbP+sCm0nGyto9FAzEKehHiiu2tvdaZjhY++Ay5NuLE83WncOXkDlzxPRHIU1dB+q3nUc+u2vVgvrwFaHjXvjaWxqf4xPIyE74U+RfxBD++NTk2XzkfWYfRj+9HbZfBFoBNxBDYom8wxci694mFu/f9Wg9tQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=sLPEwu+n4in5ehKE8srzj4yS5kycNNf5P0oyGNp+P8Y=; b=kpxcJNoV2UfqU34xTnkTkXHRwcYvHzqZaR51S/4Cp5A4jgkHfX8Q7fI5SzsVCTsKbBvAcApfDNtsB3jdZnLWlIZsLwC7GR3YTrCh0z5hi4sh29zoGs5115xKBOTG0M01mnHgLUWIes3Jn8eidBEtnnEuNCBN883G+xiAZ1CE6fQ= Date: 18 Feb 2009 22:41:40 -0000 Message-ID: <20090218224140.21340.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <499C4769.3030106@pobox.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:41:32 -0000 >Millions of people buy e-postage from the USPS every day, in order to >ship stuff they sell on eBay. They go to the online post office every >time they need to obtain and print a stamp. So there's a real world >example showing that it's not an unworkable way of doing things. A few moments' online research reveals that Paypal did 214.5 million transactions last year, of which a little under half were from eBay. A hundred million transactions a year is under 300K per day, and I'd be surprised if as many as half of them bought online USPS postage to ship the order. It's easy to believe that the USPS has a system that can handle 150K or 200K transactions a day, but that's four orders of magnitude lower than what an e-postage system would need to handle, and their average transaction is probably three orders of magnitude more expensive than an e-stamp. It would save us all a lot of time if people proposing a design would make at least a small attempt to get the numbers right. R's, John From johnl@iecc.com Wed Feb 18 14:46:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318623A68E4 for ; Wed, 18 Feb 2009 14:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.665 X-Spam-Level: X-Spam-Status: No, score=-14.665 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OOYV2AjpBsg for ; Wed, 18 Feb 2009 14:46:12 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 0726F3A6866 for ; Wed, 18 Feb 2009 14:46:11 -0800 (PST) Received: (qmail 64912 invoked from network); 18 Feb 2009 22:46:24 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 18 Feb 2009 22:46:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=UtIjuMUYg/+vUtV0t/bM9XT3NgKeJTuUkwHOfwuMS1s=; b=B54ub+Q1w88aoko5KCUDSBAa3gVPbsJEPNPXV6gQTd2ylPOvZWuYHTlVfGrV/AhZ7Sd4MO45K+USdzAxRlE75LSIhEkdNhrS88gLX2v0P2Cm/3thktXRaBinQRwwUa651PVLtfHSk5RhP4nYec2TScOT8QzxOrUq7fgXdwCIcVM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=UtIjuMUYg/+vUtV0t/bM9XT3NgKeJTuUkwHOfwuMS1s=; b=k49fIbkIYJHJkrIX+KY3qnjUvXtIkYSL0r3LmDLax1gTGYA8uZreKY4LxzcDBRyngF3fVwG5oG921AxrTUPqOKYQMmy3B2pMn6FAVegkjJqZuwaQf2G8M+P+bWV+X03eS2cT3brjP9sNZNVU6OeKD02arNqZl0wcRCUVgiH51FU= Date: 18 Feb 2009 22:46:23 -0000 Message-ID: <20090218224623.22631.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090218180059.GA15257@gsp.org> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:46:13 -0000 >Are there any real-world examples of systems where (say) 99% of the >attempted transactions are fraudulent, yet the system remains viable? One possible model is the .COM registrar-registry database. Nearly all of the registration attempts are domain sniping, attempts to grab a domain the moment it expires, and nearly all of them fail, either because the domain isn't free yet or someone grabbed it a millisecond before. On the other hand, the failing transactions aren't fraudulent, just failures. Every registrar trying to do a transaction is known to the registry and there's under 1000 of them. A successful transaction is worth $6 which can support quite a lot of unsuccessful ones. R's, John From john@jlc.net Wed Feb 18 14:59:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975AF3A689A for ; Wed, 18 Feb 2009 14:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.627 X-Spam-Level: X-Spam-Status: No, score=-6.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83AoIpP5Hz06 for ; Wed, 18 Feb 2009 14:59:04 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 6CBAF3A687A for ; Wed, 18 Feb 2009 14:59:04 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id B125433C57; Wed, 18 Feb 2009 17:59:16 -0500 (EST) Date: Wed, 18 Feb 2009 17:59:16 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090218225916.GF94816@verdi> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090216212251.24646.qmail@simone.iecc.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:59:05 -0000 John Levine wrote: > >> Ideally, the token is issued by a "bank" where both sending MTA and >> receiving MTA have accounts. > > You probably don't want to do that, For the sake of keeping research simple, I do. > since the performance of book entry transactions is worse than for > bearer ones. You can think of this as a bearer system if that helps. Tokens created are very like bearer tokens (except that the "bank" might limit which customers are eligible to redeem them. They sit unrelated to any existing account until "presented" for redemption, or until they expire. The amount redeemed eventually works its way into the receiving MTA's account. Or, of course, someone could invent a totally different "banking" system -- the POSTAGE spec is (intentionally) quite silent on how "banking" transactions are performed. (I'm sure the three authors have three different ideas of many details of the "banking" system: we merely satisfied ourselves that there existed at least one way to accomplish the function.) > If you're doing book entry, you need at least a journalling system to > log the entries to be added to each account, if not locks on each > account to maintain the balance. I prefer journaling. IMHO, the actual balance _can_ never be stable for receiving MTAs -- they'll just decide what's a comfortable cushion in the account. There's really no good reason why senders shouldn't do likewise. > Here's the least awful way I know to do small value online payments: > > Sender goes to his bank and buys a bunch of bearer stamps. There are > two things one can do with a bearer stamp, cancel/reissue, and redeem > it. Sounds good. > Cancel/reissue simply creates a new stamp worth the same as the old > stamp (or maybe a little less if the bank keeps its cut) but promises > that the new stamp is good. If the old stamp has already been > cancelled, this fails. This transaction is supposed to be fast, since > it needs only check the one bit to see if it's been used and generate > the new stamp or maybe take one from a precomputed list of them. I'm not sure how much call there will be for this... > Redeeming is a batch process, collect a whole bunch of stamps, send > them in to the bank, and in a while you get a credit for all of them, > maybe in an account in that bank, maybe sent to your real bank. There's no particular reason to collect a "whole bunch" unless the "bank" makes a charging system to encourage that. Any such financial benefit needs to be weighed against the possibility that someone else will redeem it first. (Regardless, you should expect a lag before the credit shows up in your account: this is not a problem so long as you know whether the token was honored.) > The point of bearer stamps is that the bank doesn't try to track who's > got them, they're like cash and whoever presents a stamp first wins. Exactly. For example, a bad sender might buy a good stamp, then race to the bank to redeem it before he finishes sending the DATA. > So when you get those reissued stamps for incoming postage, you have > to keep those private, since if someone else finds out what they are > and sends them to the bank first, he wins and you lose. (You may have noticed the spec mentions "The SMTP client and server may wish to use TLS to secure the amounts involved.") > None of this is new, this was all worked out a decade ago. But it's > all still way too slow to keep up with an interesting amount of e-mail. Have you perhaps not noticed Moore's Law at work these last ten years? -- John Leslie From john@jlc.net Wed Feb 18 15:26:06 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27FD28C155 for ; Wed, 18 Feb 2009 15:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.626 X-Spam-Level: X-Spam-Status: No, score=-6.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El+fuHWwDPAn for ; Wed, 18 Feb 2009 15:26:05 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 952D728C153 for ; Wed, 18 Feb 2009 15:26:05 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id B008833C2A; Wed, 18 Feb 2009 18:26:18 -0500 (EST) Date: Wed, 18 Feb 2009 18:26:18 -0500 From: John Leslie To: Anti-Spam Research Group - IRTF Message-ID: <20090218232618.GG94816@verdi> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <20090213134025.GB10598@gsp.org> <20090213142121.GB94816@verdi> <20090218180357.GB15257@gsp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218180357.GB15257@gsp.org> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 23:26:06 -0000 Rich Kulawiec wrote: > On Fri, Feb 13, 2009 at 09:21:21AM -0500, John Leslie wrote: > >> Remember, presentation of a bad token is a much clearer indication >> of evil intent: a few dozen should suffice for blocklisting. It's >> quite practical to blocklist 100 million IPs, at which point the >> problem will start to disappear. Computers blocklisted this way will >> pretty much be forced into going through a relay MTA with which they >> have a contractual relationship -- which removes the problem from >> the "botted-MTA" territory. > > Blacklisting those 100 million IPs -- which most sensible folks did > years ago, either by subdomain, regexp, IP, DNSBL or some mechanism -- > has not forced them to go through relay MTAs. Nonetheless, we receive a significant amount of spam through some ISP's mailservers... I think you're glossing over the difference between something merely "unsolicited" vs. something _fraudulent_. > The only thing that will force them to through relay MTAs are > router/firewall rulesets on the networks within which they reside. Granted, reaching no recipients doesn't technically "force" them to do anything -- that's why I said "pretty much be forced". > However, suppose -- against all experience -- that actually happens. > (And that'd be a good thing, so I'm not arguing against; it's just > that if it were going to happen, I think it would have happened within > a few months of the rise of the zombies.) Blacklists are pretty blunt weapons. We field many complaints when a blacklist blocks email the sender considers legitimate. The balance between a "small inconvenience" and a total failure to pass "essential" information keeps todays blacklists on the timid side. If OTOH, we can point to a plainly _fraudulent_ act, the balance becomes easier. And if we can point to a currency value, perhaps including "treble damages", to resolve the problem, reasonable folks would have to agree that trusting "postage" from someone who already defrauded you is too much to ask. > In that case, every relay MTA you see will present "a few dozen" > bogus tokens very shortly thereafter, because some/most/all of those > 100 million IPs will now be sending through them. The relay MTAs are responsible for their own postage tokens. There is no reason for them to "trust" tokens from their users. > Do you plan to blacklist all those relay MTAs? If they ship fraudulent tokens, yes. > If so, then you could just do that now and skip the exercise. No I can't, because there is nothing fraudulent about what they've done. > If not, then you're going to have to still do it the hard way. Understand, we'll have to accept email without postage from some ISPs and enterprises that don't implement the POSTAGE extension. That's not a fault of the POSTAGE extension. Only if they imlement it and send fraudulent tokens can we take a strong blacklisting position. -- John Leslie From davidnicol@gmail.com Thu Feb 19 14:12:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572123A6BF6 for ; Thu, 19 Feb 2009 14:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chJT-+L09WfT for ; Thu, 19 Feb 2009 14:12:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id A9ED23A6B6C for ; Thu, 19 Feb 2009 14:12:44 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so663549rvf.7 for ; Thu, 19 Feb 2009 14:12:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=FPxYweeDdVAJ/+k4Ryl79nasNAYm18Vat+6W4/cdGPE=; b=NZ+AO5XdlYmzyqYOvwco3e2AuIwLPSf/fRWlwDiJY+GTJwHbEIPJOXNY1D9SIJeZa9 QhJ5sX8tJFfh7Te/t/wwyHlt1iuC9SKg2O+qK3dR9p6TcWlCm9jYK/IjU0cYt9s5PQrL ltMKBf7E6bG4s/NdH7geBma7ArAs8AKmINisg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=C+etIV5TzCHcUQws5oeMw9WLERBDg/xXLpv+vm/n20kV8Fp5ijKSkoijoDWxEgBqrh +nyT8EOmNTzTGb5TkR2u4xyICsv/obN8JcuLOEzI2EkSeU4pn/LK86RaiOlEb8QBTfZf ZXmuynHm3VnCoiun+biJ8LVUI/fI7ewHuftcY= MIME-Version: 1.0 Received: by 10.142.103.2 with SMTP id a2mr25593wfc.164.1235081577910; Thu, 19 Feb 2009 14:12:57 -0800 (PST) Date: Thu, 19 Feb 2009 16:12:57 -0600 Message-ID: <934f64a20902191412x3ba60f12v5bbd3c46f9eceff0@mail.gmail.com> From: David Nicol To: ASRG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Asrg] e-postage scaling X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:12:45 -0000 I was reading about SIP and telephone switching network theory, a phrase seemed relevant: scalability can be obtained by "pushing the intelligence to the edges of the network" From asrg3@billmail.scconsult.com Thu Feb 19 14:37:56 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA19628C0D8 for ; Thu, 19 Feb 2009 14:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWKTYZ9e2rm1 for ; Thu, 19 Feb 2009 14:37:55 -0800 (PST) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 3321728C138 for ; Thu, 19 Feb 2009 14:37:55 -0800 (PST) Received: from bigsky-scconsult-com.local (unknown [66.73.230.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 43719851676 for ; Thu, 19 Feb 2009 17:38:08 -0500 (EST) Message-ID: <499DDF4F.8010305@billmail.scconsult.com> Date: Thu, 19 Feb 2009 17:38:07 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> In-Reply-To: <20090218225916.GF94816@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:37:56 -0000 John Leslie wrote, On 2/18/09 5:59 PM: > John Levine wrote: [...] >> None of this is new, this was all worked out a decade ago. But it's >> all still way too slow to keep up with an interesting amount of e-mail. > > Have you perhaps not noticed Moore's Law at work these last ten years? CPU power is not likely to be the critical bottleneck for a system that has to do large numbers of transactions across the Internet. Network latency is particularly resistant to Moore's law or anything like it. From johnl@iecc.com Thu Feb 19 14:40:22 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB24E3A69DD for ; Thu, 19 Feb 2009 14:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.688 X-Spam-Level: X-Spam-Status: No, score=-14.688 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHgts1dWOid7 for ; Thu, 19 Feb 2009 14:40:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id DAD573A67C1 for ; Thu, 19 Feb 2009 14:40:21 -0800 (PST) Received: (qmail 41549 invoked from network); 19 Feb 2009 22:40:34 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 19 Feb 2009 22:40:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=lopqc4QufUnEmfeXtMSLj3zBUCzs1pkkBhZhqTtfPWk=; b=SCsl3H+QUyGB/dvE/XmrapOgYMq7sB0Z+wmMaSHLpPcZN+4b+xHpWtHnT4AkjOnmquuOWHZWDlF81VSNvaU6g9hh6+6kuaXLsIS0QtrtQLGFprGuG5XfJkuE04CIZjTBO9SrdwOj5eT141sRAywL9zKqfbosLLAy+v435N+UwPA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=lopqc4QufUnEmfeXtMSLj3zBUCzs1pkkBhZhqTtfPWk=; b=FUEXHF6qByLog7chXHwfEV4L9Gw9Koza7cEqddN6Lv0wEegfHt8njj8nHHQG3aqZ6fnKNCx1M0zvpHNfM+xrFVvpVjUvK0rhlbbhSeQ96vtUl7czP2abEGNlluHrT5C1lcoQsCm1uHruCabG3ECg0LUMAaIij+2Aw8vb96edO3M= Date: 19 Feb 2009 22:40:34 -0000 Message-ID: <20090219224034.9571.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <934f64a20902191412x3ba60f12v5bbd3c46f9eceff0@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] e-postage scaling X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:40:22 -0000 >I was reading about SIP and telephone switching network theory, a >phrase seemed relevant: > >scalability can be obtained by "pushing the intelligence to the edges >of the network" I don't see how this is relevant. Is anyone trying to meter the number of calls each SIP phone can make? R's, John From mouse@Sparkle.Rodents-Montreal.ORG Thu Feb 19 15:34:10 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47BB3A6B40 for ; Thu, 19 Feb 2009 15:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.733 X-Spam-Level: X-Spam-Status: No, score=-6.733 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_50=0.001, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdHfaNgv1WP1 for ; Thu, 19 Feb 2009 15:34:10 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id C591F3A6AEA for ; Thu, 19 Feb 2009 15:34:09 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id SAA03465; Thu, 19 Feb 2009 18:34:05 -0500 (EST) From: der Mouse Message-Id: <200902192334.SAA03465@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 19 Feb 2009 18:21:53 -0500 (EST) To: asrg@irtf.org In-Reply-To: <499DDF4F.8010305@billmail.scconsult.com> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 23:34:11 -0000 > Network latency is particularly resistant to Moore's law or anything > like it. Well, sure; we're up to the point where speed-of-light is a substantial fraction of the latency of long-haul links. I suspect - admittedly without evidence - that if you subtract off the speed-of-light delay, something rather like Moore's law will turn up. When $DAYJOB opened an office in Thailand and people were complaining about the network latency, I had to point out that something like half the latency we were seeing was compelled by a combination of lightspeed and going around (versus through) the planet. Our planet is something like 140 light-milliseconds around, and we were seeing quarter-second RTTs - and I don't for a moment think packets were taking great-circle paths to get there. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From meta404@gmail.com Thu Feb 19 17:01:32 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55233A6ABF for ; Thu, 19 Feb 2009 17:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkzuYYjNG002 for ; Thu, 19 Feb 2009 17:01:32 -0800 (PST) Received: from mail-qy0-f21.google.com (mail-qy0-f21.google.com [209.85.221.21]) by core3.amsl.com (Postfix) with ESMTP id BD4CE3A6907 for ; Thu, 19 Feb 2009 17:01:31 -0800 (PST) Received: by qyk14 with SMTP id 14so1555104qyk.7 for ; Thu, 19 Feb 2009 17:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=XWA6JnAz5Dk+nqE5SwZ+EgHVloXN71npj7hAzx5M46s=; b=hN3txTWnDg3N2hmREmS5CBtmnKmybW0J5tU7SEjocxcaIfOeehWrIiyZgO74mNiL8G lYM3O1cV+vuAMx4JYD7naGGNZkKjGr8pjfryS6izFlylPkk839yF7sQXK7kZrEr9avCC RFq9GZz8PMRjIi9KcwyWQ5i1lBRdb/lySnCDg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=Vi0GQiOGirsHHcCyJbsfRFxUW7VLB/i1yT47ANdUo3dJxix52J01iTjEXiKltOOpzW N2kkclMAK2h8keMpFq1qBjU77TfgRGHLriwCM90bN9wH5pd1Q0dgC4vbU7f0G0GdROeT ekWVQevw7xlaiFKw0PbgpvZomg4CQfnRaiR14= MIME-Version: 1.0 Sender: meta404@gmail.com Received: by 10.229.89.138 with SMTP id e10mr129332qcm.13.1235091704906; Thu, 19 Feb 2009 17:01:44 -0800 (PST) In-Reply-To: <20090218180615.GC15257@gsp.org> References: <20090212142133.GV52653@verdi> <20090212215841.11637.qmail@simone.iecc.com> <7eeceb440902150714h597409f6hf1c4b7db53dea403@mail.gmail.com> <20090218180615.GC15257@gsp.org> Date: Thu, 19 Feb 2009 19:01:44 -0600 X-Google-Sender-Auth: 630c4d95af475856 Message-ID: <7eeceb440902191701h528c5fe9r8f110fb0b7b301f9@mail.gmail.com> From: mathew To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=0016364ef1cc5604fa04634f32a9 Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:01:32 -0000 --0016364ef1cc5604fa04634f32a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 18, 2009 at 12:06, Rich Kulawiec wrote: > How's that going to work with forwarding, virtual user tables, and > alias expansions? (a) recipient has to know (and tell the system) which addresses he expects forwarded e-mail from--just like with today's spam filters. (b), (c) receiving MTA has to take its aliases and virtual user tables into account when checking the signatures on e-postage. > And how will it avoid leaking information when > someone is BCC'd? Use a one-way hash. mathew --0016364ef1cc5604fa04634f32a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2009 at 12:06, Rich Kulawiec <rsk@gsp.org> wrote:
How's that going to work with forwarding, virtual= user tables, and
alias expansions?

(a) recipient has to know (and tell = the system) which addresses he expects forwarded e-mail from--just like wit= h today's spam filters.
(b), (c) receiving MTA has to take its alias= es and virtual user tables into account when checking the signatures on e-p= ostage.
 
&nbs= p; And how will it avoid leaking information when
someone is BCC'd?

Use a one-way hash.


m= athew

--0016364ef1cc5604fa04634f32a9-- From meta404@gmail.com Thu Feb 19 17:06:14 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9883A692F for ; Thu, 19 Feb 2009 17:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.074 X-Spam-Level: X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3HwSgjWpJpo for ; Thu, 19 Feb 2009 17:06:13 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 870093A6907 for ; Thu, 19 Feb 2009 17:06:13 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so228282qwe.7 for ; Thu, 19 Feb 2009 17:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=BA9mAXNdU8qSFjMv48fH+0H4NenibWf0p+y0TbOVWMY=; b=sh2mYOjf34B1zJWCIoPv+D2nieRbd6227vYvB+MBdZIiaMQ8HY8OupRrV829qSTRUF rubfIRIq53TN7Y7omv5GuG/++9GdBl/vqhhDk92iOVFaCn+uLN3MSBWsitpGbKLebPIq CCKiMay/CDwwFT4g3ZxO5MvP+vapRutFxXxws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=We+BPkZpX9Zr5KtKXkrAW9QOQoX1G9pgydvgrWDYeDqbfPOA1IVpwh5A/CaeELtj24 KILeups+CfaoMOqSXjEiQI9yEQztGu8jZSon4ge5HIFtmeHJZ7IM0l1CjTgDKAsDhRbw 5ziBt7XfK42KaiJJn0MMMNmiWIrjczgkHDxJc= MIME-Version: 1.0 Sender: meta404@gmail.com Received: by 10.229.84.72 with SMTP id i8mr69282qcl.63.1235091986775; Thu, 19 Feb 2009 17:06:26 -0800 (PST) In-Reply-To: <20090218224140.21340.qmail@simone.iecc.com> References: <499C4769.3030106@pobox.com> <20090218224140.21340.qmail@simone.iecc.com> Date: Thu, 19 Feb 2009 19:06:26 -0600 X-Google-Sender-Auth: 1956f783643f0887 Message-ID: <7eeceb440902191706r61b959b8yf43c73968414dad3@mail.gmail.com> From: mathew To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=00163642715422ff8a04634f4386 Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:06:14 -0000 --00163642715422ff8a04634f4386 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 18, 2009 at 16:41, John Levine wrote: > >Millions of people buy e-postage from the USPS every day, in order to > >ship stuff they sell on eBay. They go to the online post office every > >time they need to obtain and print a stamp. So there's a real world > >example showing that it's not an unworkable way of doing things. > > A few moments' online research reveals that Paypal did 214.5 million > transactions last year, of which a little under half were from eBay. > A hundred million transactions a year is under 300K per day, and I'd > be surprised if as many as half of them bought online USPS postage to > ship the order. I'd also be surprised if every USPS e-postage transaction was performed via PayPal. There are plenty of sellers who use third party services, go directly to USPS, use Pitney-Bowes machines, and so on. PayPal users are the minority, in my experience. > It's easy to believe that the USPS has a system that can handle 150K > or 200K transactions a day, but that's four orders of magnitude lower > than what an e-postage system would need to handle, and their average > transaction is probably three orders of magnitude more expensive than > an e-stamp. Thank goodness nobody's proposing a single central vendor for e-postage. And thank goodness nobody's insisting that any proposed system must be able to handle the entire e-mail volume of the Internet on day 1. mathew --00163642715422ff8a04634f4386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2009 at 16:41, John Levine <johnl@taugh.com> wrote:
>Millions of people buy e-postage from the USPS ev= ery day, in order to
>ship stuff they sell on eBay. They go to the online post office every >time they need to obtain and print a stamp. So there's a real world=
>example showing that it's not an unworkable way of doing things.
A few moments' online research reveals that Paypal did 214.5 mill= ion
transactions last year, of which a little under half were from eBay.
A hundred million transactions a year is under 300K per day, and I'd be surprised if as many as half of them bought online USPS postage to
ship the order.

I'd also be surprised if every USP= S e-postage transaction was performed via PayPal. There are plenty of selle= rs who use third party services, go directly to USPS, use Pitney-Bowes mach= ines, and so on. PayPal users are the minority, in my experience.
 
It= 9;s easy to believe that the USPS has a system that can handle 150K
or 200K transactions a day, but that's four orders of magnitude lower than what an e-postage system would need to handle, and their average
transaction is probably three orders of magnitude more expensive than
an e-stamp.

Thank goodness nobody's proposing a si= ngle central vendor for e-postage. And thank goodness nobody's insistin= g that any proposed system must be able to handle the entire e-mail volume = of the Internet on day 1.


mathew
--00163642715422ff8a04634f4386-- From john@jlc.net Thu Feb 19 17:53:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2488B3A6939 for ; Thu, 19 Feb 2009 17:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS5yVuBBYmei for ; Thu, 19 Feb 2009 17:53:38 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 5D8F73A6832 for ; Thu, 19 Feb 2009 17:53:38 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id ACCF133C2A; Thu, 19 Feb 2009 20:53:52 -0500 (EST) Date: Thu, 19 Feb 2009 20:53:52 -0500 From: John Leslie To: asrg@irtf.org Message-ID: <20090220015352.GB65762@verdi> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499DDF4F.8010305@billmail.scconsult.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:53:39 -0000 Bill Cole wrote: > John Leslie wrote, On 2/18/09 5:59 PM: >>John Levine wrote: > [...] >>> None of this is new, this was all worked out a decade ago. But it's >>> all still way too slow to keep up with an interesting amount of e-mail. >> >> Have you perhaps not noticed Moore's Law at work these last ten years? > > CPU power is not likely to be the critical bottleneck for a system that > has to do large numbers of transactions across the Internet. Actually, CPU power _can_ be a bottleneck, though seldom the critical one. Moores' law also applies to RAM. It has become somewhat practical to address a terabyte of RAM. This eliminates storage latency, for all practical purposes, which usually _is_ the critical bottleneck. > Network latency is particularly resistant to Moore's law or anything > like it. Agreed, but network _bandwidth_ has benefited substantially from Moore's law. The bottom line is, redeeming a million tokens per second is practical with processing delay not much greater than network latency. (This was not true ten years ago...) -- John Leslie From asrg3@billmail.scconsult.com Fri Feb 20 15:25:01 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008623A6B38 for ; Fri, 20 Feb 2009 15:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd4YGuv6pB77 for ; Fri, 20 Feb 2009 15:24:59 -0800 (PST) Received: from toaster.scconsult.com (toaster.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id 6ED553A6AE9 for ; Fri, 20 Feb 2009 15:24:57 -0800 (PST) Received: from bigsky-scconsult-com.local (unknown [66.73.230.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 17E33853BC2 for ; Fri, 20 Feb 2009 18:25:08 -0500 (EST) Message-ID: <499F3BD1.3020707@billmail.scconsult.com> Date: Fri, 20 Feb 2009 18:25:05 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> In-Reply-To: <20090220015352.GB65762@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:25:01 -0000 John Leslie wrote, On 2/19/09 8:53 PM: > Bill Cole wrote: >> John Leslie wrote, On 2/18/09 5:59 PM: >>> John Levine wrote: >> [...] >>>> None of this is new, this was all worked out a decade ago. But it's >>>> all still way too slow to keep up with an interesting amount of e-mail. >>> Have you perhaps not noticed Moore's Law at work these last ten years? >> CPU power is not likely to be the critical bottleneck for a system that >> has to do large numbers of transactions across the Internet. > > Actually, CPU power _can_ be a bottleneck, though seldom the critical > one. Any component *can* be a bottleneck. Maybe my point would be clearer put this way: throwing more processing power at a high-volume OLTP system that has to talk to clients across the Internet stops having returns long before it requires the deployment of 21st-century CPU technologies. > Moores' law also applies to RAM. It has become somewhat practical to > address a terabyte of RAM. This eliminates storage latency, for all > practical purposes, which usually _is_ the critical bottleneck. Storage latency can certainly be a problem and I'm convinced that it is the easiest bottleneck to create or eliminate by seemingly trivial details of logical design and implementation. That makes it a common criticality in deployed systems, where it is often cheaper/faster/easier to fix than design and/or coding, but it isn't rational for the hardware aspects of storage to be critical in a system that has to chat with clients halfway around the world. As Mouse noted, RTT's in hundreds of milliseconds are assured by physics for as long as the Internet operates with wires, fiber, and photons (rather than with spin-coupled antiparticle pairs or wormholes...) When many transactions will have one or more 100ms periods of dead time and essentially all will have 10ms waits, there's no fundamental reason for hard storage latency to be critical. >> Network latency is particularly resistant to Moore's law or anything >> like it. > > Agreed, but network _bandwidth_ has benefited substantially from > Moore's law. Which doesn't help much for a transactional system that ultimately has to serialize a lot of small transactions. The standard tactical responses to the fact that bandwidth has grown without proportional drop in latency have been aimed at utilizing bandwidth, i.e. transferring a lot of data. Email postage validation wouldn't seem to me to benefit from such tactics as parallelization of sliced-up tasks or deep acknowledgement queues, but maybe I'm just not seeing some insight. > The bottom line is, redeeming a million tokens per second is practical > with processing delay not much greater than network latency. (This was > not true ten years ago...) I think I'd quibble with details on that, but they really are not all that important. This is a problem that should be subject to a simplified thought experiment. If you make extremely unrealistic positive assumptions about processing, storage, and bandwidth but recognize that many RTT's between redemption clients and servers will be above 100ms, most above 10ms, and essentially all above 1ms, it is very hard to design a logical system (never mind a collection of hardware) that will handle a million redemption requests per second in a worthwhile manner (i.e. not repudiate valid tokens or validate bogus or redeemed ones by design) when the request stream is being engineered to break the system by parties with tens of thousands of hijacked machines at their disposal. I'm pretty sure that I'm not the best systems analyst/designer on this list. I certainly hope I'm not the best one to have thought about e-postage. I'd be happy to learn from a master how it is in fact possible to make an ideally simplified minimal system like this work as a starting point for how to assemble a more complex system that has more elements of reality in it. I think (but may be wrong!) that it isn't possible to design a system that will be theoretically capable of correctly handling a million redemption requests per second of which ~90% are the result of someone working to break the system. From davidnicol@gmail.com Fri Feb 20 15:31:15 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0C23A6BC1 for ; Fri, 20 Feb 2009 15:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWQS76yUD7eb for ; Fri, 20 Feb 2009 15:31:14 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 6EFE43A6BB5 for ; Fri, 20 Feb 2009 15:31:14 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1197716wfd.7 for ; Fri, 20 Feb 2009 15:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=930m7kevP4Zi9fMielEwpdF9ambiNbhk3tLDankG9q8=; b=hca/jt8oNgSBC3WtHgB8iKTqjqXsSIE/27M2cHoDjVEbKAKmc7Tt/OJsZIEpDJUN3u ML6DJmzDX2qNqr72SVcY51JSf3Jyjk/ITwElOITTQzVo2Jx/bmTJGxpUIl/ofgsk40t7 OzR4kkGAsK5vITDIucsfMHLTB1NcVo61d1kTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=bIm7/fRfDLWOTzRxzzwFc5QUuchlV1m+TY/5EXzLgIlmdrYziDDHaN2L/s/pFGMkNG 1QWR51pK1dCklZ9S8MtuvIPXpeNvYo6A5U6Wc3kwO4/uh6Ij4/Oty5M9A+MPlSWjZVm5 E7RkFqok+CeoDuEpFKOBFRO3E/Ew5FmFg1V3A= MIME-Version: 1.0 Received: by 10.143.28.8 with SMTP id f8mr646221wfj.204.1235172688283; Fri, 20 Feb 2009 15:31:28 -0800 (PST) In-Reply-To: <20090219224034.9571.qmail@simone.iecc.com> References: <934f64a20902191412x3ba60f12v5bbd3c46f9eceff0@mail.gmail.com> <20090219224034.9571.qmail@simone.iecc.com> Date: Fri, 20 Feb 2009 17:31:28 -0600 Message-ID: <934f64a20902201531n2edfe2fbw92e69fe1b7299af3@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] e-postage scaling X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:31:15 -0000 On Thu, Feb 19, 2009 at 4:40 PM, John Levine wrote: >>I was reading about SIP and telephone switching network theory, a >>phrase seemed relevant: >> >>scalability can be obtained by "pushing the intelligence to the edges >>of the network" > > I don't see how this is relevant. Is anyone trying to meter the number > of calls each SIP phone can make? > > R's, > John Actually, yes, CDR-based billing is available with VOIP telephony. -- Freedom's colors are red, white and black and blue. From steve@blighty.com Fri Feb 20 16:26:18 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9F328C217 for ; Fri, 20 Feb 2009 16:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W--vgswbdiel for ; Fri, 20 Feb 2009 16:26:18 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 0B57028C157 for ; Fri, 20 Feb 2009 16:26:18 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id EAA1F804C7 for ; Fri, 20 Feb 2009 16:26:27 -0800 (PST) Message-Id: <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> From: Steve Atkins To: asrg@irtf.org In-Reply-To: <499F3BD1.3020707@billmail.scconsult.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 16:26:32 -0800 References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:26:19 -0000 On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: > >> The bottom line is, redeeming a million tokens per second is >> practical >> with processing delay not much greater than network latency. (This >> was >> not true ten years ago...) > > I think I'd quibble with details on that, but they really are not > all that > important. > > This is a problem that should be subject to a simplified thought > experiment. If you make extremely unrealistic positive assumptions > about processing, storage, and bandwidth but recognize that many > RTT's between redemption clients and servers will be above 100ms, > most above 10ms, and essentially all above 1ms, it is very hard to > design a logical system (never mind a collection of hardware) that > will handle a million redemption requests per second in a worthwhile > manner (i.e. not repudiate valid tokens or validate bogus or > redeemed ones by design) when the request stream is being engineered > to break the system by parties with tens of thousands of hijacked > machines at their disposal. There are many problems with epostage - fundamentals, social problems and implementation - but this particular aspect isn't one, I don't think. It's a trivially parallelizable problem. The reliability (SPoF), economics, business and usability issues are likely to be much more of a problem. > I'm pretty sure that I'm not the best systems analyst/designer on > this list. > I certainly hope I'm not the best one to have thought about e- > postage. I'd > be happy to learn from a master how it is in fact possible to make > an ideally simplified minimal system like this work as a starting > point for how to assemble a more complex system that has more > elements of reality in it. I think (but may be wrong!) that it isn't > possible to design a system that will be theoretically capable of > correctly handling a million redemption requests per second of which > ~90% are the result of someone working to break the system. It's fun to consider, though. Using your numbers - one million redemption requests a second of which at least 90% are invalid, leads to 100,000 outstanding valid requests per second, which would give around 250 billion outstanding stamps at any one time, if we expire them after a month (expiring would likely involve voiding the unused stamps and issuing new ones in the same amount, but that's a business issue, and doesn't affect the redemption requirements). Use private-key cryptography to ensure that you reject any stamp you didn't create. This is easy to do in hardware, or to parallelize should you need to. Pick enough machines or asics to meet your throughput goal. (That might well be one). Hash the stamp to one of a number of redemption machines. This is "just" a network problem. At each redemption machine, look up the stamp an "I've seen this" associative array. If you've seen it, reject the stamp, otherwise accept it. This is arbitrarily scalable, just by adding enough redemption machines that the memory access time to look up the entry in the associative array is enough to meet your throughput goal, and the size of the number of outstanding stamps fits in the storage space of the machine. Assuming there's a serial number in each stamp, your associative array could simply be 250 gigabits of RAM, so again it's not going to be many machines, maybe one, to do in software. To me it feels like the hard bit of this is handling a million packets in and out per second reliably, along with the overhead of providing robustness and redundancy, rather than the redemption itself. Cheers, Steve From johnl@iecc.com Sat Feb 21 06:51:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C1F3A694E for ; Sat, 21 Feb 2009 06:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.707 X-Spam-Level: X-Spam-Status: No, score=-14.707 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiTkQvaRK5og for ; Sat, 21 Feb 2009 06:51:44 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 114A33A6843 for ; Sat, 21 Feb 2009 06:51:43 -0800 (PST) Received: (qmail 32176 invoked from network); 21 Feb 2009 14:51:57 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 21 Feb 2009 14:51:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=Ew4Dmdj4OvMhO3ZEan6ysTiGHZsS7o3JvRFt2SweF+w=; b=cp1nsi4hZlVy9Em+9cqHtZdy8Az/1w3FRcENZ7+F8yzFwPZSuymlHZGCCsM2wR1PgaFfPN7r0tFArvG4r0Dj2niv3jjGcqYHLkhwRAxqoDXjYPq7kmFTzyrVPOFHNXCRVd2JtWbk40nX5ODM+hd4XNDEiJzezgZ+HkPssPkNUr0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=Ew4Dmdj4OvMhO3ZEan6ysTiGHZsS7o3JvRFt2SweF+w=; b=aeHg6n+1ce0iGjgR4tPBEEOnsU0xXQaHloftedi8VR43nIDpd6eeDtR7/0NhUUs5xXCg+ovqfcpTMY3R8OfOvbrWPO2vv0bOAGhrBM2NS0z1UvvKlSBkjnQD0bgrKPr51k5aQDFvH5du+ANhrufOz3Zitq4LrDYHMJb2SssDHdM= Date: 21 Feb 2009 14:51:55 -0000 Message-ID: <20090221145155.33421.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <934f64a20902201531n2edfe2fbw92e69fe1b7299af3@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] e-postage scaling X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 14:51:45 -0000 >>>scalability can be obtained by "pushing the intelligence to the edges >>>of the network" >> >> I don't see how this is relevant. Is anyone trying to meter the number >> of calls each SIP phone can make? > >Actually, yes, CDR-based billing is available with VOIP telephony. Well, sure, that's how my phone works. But the billing is handled at my VoIP vendor's server not "to the edges of the network". R's, John From asrg3@billmail.scconsult.com Sat Feb 21 16:07:04 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16103A6966 for ; Sat, 21 Feb 2009 16:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBeAJHZI-bKV for ; Sat, 21 Feb 2009 16:06:59 -0800 (PST) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id A61423A677D for ; Sat, 21 Feb 2009 16:06:56 -0800 (PST) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id C9CF1854D7F for ; Sat, 21 Feb 2009 19:07:09 -0500 (EST) Message-ID: <49A0972D.2030103@billmail.scconsult.com> Date: Sat, 21 Feb 2009 19:07:09 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> In-Reply-To: <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:07:05 -0000 Steve Atkins wrote, On 2/20/09 7:26 PM: > > On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: [Quoting John Leslie] >>> The bottom line is, redeeming a million tokens per second is practical >>> with processing delay not much greater than network latency. (This was >>> not true ten years ago...) >> >> I think I'd quibble with details on that, but they really are not all >> that >> important. I guess maybe one detail is... If the processing delay for every redemption attempt is of the same order of magnitude as irreducible network latencies, i.e. tens to hundreds of milliseconds, handling a million one-use token redemption attempts per second is absolutely hopeless. I'm pretty sure that a large fraction of the attempts would be for already-redeemed tokens and that those could be handled extremely fast so that a validation server can handle such requests in sub-millisecond times. I would hope that the requests which succeed could be done in sub-millisecond time as well, but that's less critical. >> This is a problem that should be subject to a simplified thought >> experiment. If you make extremely unrealistic positive assumptions >> about processing, storage, and bandwidth but recognize that many RTT's >> between redemption clients and servers will be above 100ms, most above >> 10ms, and essentially all above 1ms, it is very hard to design a >> logical system (never mind a collection of hardware) that will handle >> a million redemption requests per second in a worthwhile manner (i.e. >> not repudiate valid tokens or validate bogus or redeemed ones by >> design) when the request stream is being engineered to break the >> system by parties with tens of thousands of hijacked machines at their >> disposal. > > There are many problems with epostage - fundamentals, social problems > and implementation - but this particular aspect isn't one, I don't > think. It's a trivially parallelizable problem. If it's trivial, I'd welcome the public humiliation of being shown how, with specific reference to the problem that (for example) 50k clients on the other end of 100ms RTT connections may present the same token almost simultaneously, and exactly one can be be allowed to redeem it. > The reliability (SPoF), economics, business and usability issues are > likely to be much more of a problem. Those are all problems. It seems to me that any attempt to seriously address the SPoF problem makes the race resolution problem harder. >> I'm pretty sure that I'm not the best systems analyst/designer on this >> list. >> I certainly hope I'm not the best one to have thought about e-postage. >> I'd >> be happy to learn from a master how it is in fact possible to make an >> ideally simplified minimal system like this work as a starting point >> for how to assemble a more complex system that has more elements of >> reality in it. I think (but may be wrong!) that it isn't possible to >> design a system that will be theoretically capable of correctly >> handling a million redemption requests per second of which ~90% are >> the result of someone working to break the system. > > > It's fun to consider, though. > > Using your numbers - one million redemption requests a second of which > at least 90% are invalid, leads to 100,000 outstanding valid requests > per second, which would give around 250 billion outstanding stamps at > any one time, if we expire them after a month (expiring would likely > involve voiding the unused stamps and issuing new ones in the same > amount, but that's a business issue, and doesn't affect the redemption > requirements). > > Use private-key cryptography to ensure that you reject any stamp you > didn't create. This is easy to do in hardware, or to parallelize should > you need to. Pick enough machines or asics to meet your throughput goal. > (That might well be one). > > Hash the stamp to one of a number of redemption machines. This is "just" > a network problem. I love the quotes... That network problem risks adding latency to every transaction, particularly because at first glance it looks like an obvious place to address the large-scale SPoF problem by giving physical location diversity to your subunits. Unfortunately, if you make the back end really robust by putting redundant parts in widely dispersed places, every transaction gets a multi-millisecond minimum lifetime, which is a problem. > At each redemption machine, look up the stamp an "I've seen this" > associative array. If you've seen it, reject the stamp, otherwise accept > it. This is arbitrarily scalable, just by adding enough redemption > machines that the memory access time to look up the entry in the > associative array is enough to meet your throughput goal, and the size > of the number of outstanding stamps fits in the storage space of the > machine. Assuming there's a serial number in each stamp, your > associative array could simply be 250 gigabits of RAM, so again it's not > going to be many machines, maybe one, to do in software. I think it is a bit of a hand-wave to call this arbitrarily scalable, but I'm happy to stipulate for the test of my hypothesis that the entire server-side decision process for any one redemption transaction can be reliably done correctly in uniform sub-millisecond time if the stamp is either available for redemption or already redeemed. The problem is that logically you need a third intermediate state that will last for the RTT of the network connection to the redeeming client, and that state will defer the decision for other attempts to redeem the stamp. > To me it feels like the hard bit of this is handling a million packets > in and out per second reliably, along with the overhead of providing > robustness and redundancy, rather than the redemption itself. That was my point, because it seems to me that a redemption cannot be done with just one packet in and one out, but really needs two in and one out. A legitimate stamp needs to have 3 possible states in the server's map: redeemed, unredeemed, and pending acknowledgment of redemption. If the server only has two states for a stamp, then it would end up with one of two flaws by design: 1. If the stamp is marked as redeemed when a successful redemption attempt completes on the server, it is possible that the success will not be successfully communicated to the client. If the client then retries the redemption, it will fail. 2. If the stamp is left as unredeemed while waiting for the client ack of success, stamp "reuse" becomes a question of how many redemption decisions can be made per client RTT. The server may have to defer many thousands of clients for scores of milliseconds while waiting for one to send an ack. Handling a few dozen such events per second seems to me to be a really hard problem to address, but maybe I'm missing something. If the average transaction lifetime is 100ms, then a million-TPS system needs to be able to handle an average of 100k concurrent pending transactions and spikes probably twice that. I think the ways to handle that all include dividing the front end between multiple machines, but that creates a tougher problem keeping the back end recordkeeping fast and coherent from the viewpoints all of the front ends. I suspect that the "solution" that will be chosen if anyone tries to create a real e-postage system instead of hand-waving about it will be to open it to lost packet damage as the cost of scalability. Network latency with clients becomes irrelevant if the server assumes that its redemption messages are always delivered. That allows for a lot of optimization. Once in a while a stamp that should work will fail to do so, and if such a system ever gets into the real world I'm sure its users will be shocked at how much higher the real-world failures are than in their tests... From steve@blighty.com Sat Feb 21 18:02:37 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C684028C125 for ; Sat, 21 Feb 2009 18:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcwE+WlDQC6E for ; Sat, 21 Feb 2009 18:02:36 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id CAD5828C104 for ; Sat, 21 Feb 2009 18:02:36 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id B1C9E4F8263 for ; Sat, 21 Feb 2009 18:02:46 -0800 (PST) Message-Id: <09DB0EC3-3607-43C0-9EDA-C21EEFFD4390@blighty.com> From: Steve Atkins To: asrg@irtf.org In-Reply-To: <49A0972D.2030103@billmail.scconsult.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 18:02:50 -0800 References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 02:02:37 -0000 On Feb 21, 2009, at 4:07 PM, Bill Cole wrote: > Steve Atkins wrote, On 2/20/09 7:26 PM: >> On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: > >> The reliability (SPoF), economics, business and usability issues >> are likely to be much more of a problem. > > Those are all problems. It seems to me that any attempt to seriously > address the SPoF problem makes the race resolution problem harder. Almost by definition. If your definition of which of two redemption attempts is valid is the one that arrives at a particular place first, then that place is a single point of failure. If that's not your definition, things get a lot more complex. >> At each redemption machine, look up the stamp an "I've seen this" >> associative array. If you've seen it, reject the stamp, otherwise >> accept it. This is arbitrarily scalable, just by adding enough >> redemption machines that the memory access time to look up the >> entry in the associative array is enough to meet your throughput >> goal, and the size of the number of outstanding stamps fits in the >> storage space of the machine. Assuming there's a serial number in >> each stamp, your associative array could simply be 250 gigabits of >> RAM, so again it's not going to be many machines, maybe one, to do >> in software. > > I think it is a bit of a hand-wave to call this arbitrarily > scalable, but I'm happy to stipulate for the test of my hypothesis > that the entire server-side decision process for any one redemption > transaction can be reliably done correctly in uniform sub- > millisecond time if the stamp is either available for redemption or > already redeemed. The problem is that logically you need a third > intermediate state that will last for the RTT of the network > connection to the redeeming client, and that state will defer the > decision for other attempts to redeem the stamp. > > >> To me it feels like the hard bit of this is handling a million >> packets in and out per second reliably, along with the overhead of >> providing robustness and redundancy, rather than the redemption >> itself. > > That was my point, because it seems to me that a redemption cannot > be done with just one packet in and one out, but really needs two in > and one out. One in and one out will do it. The client MTA can include a nonce or serial number in the request. The redemption machine can keep track of the nonce value of the request that was accepted as valid, at a cost of a few times the number of machines needed. We're already keeping that state for a month anyway. If any client doesn't receive a response (positive or negative) after a while, it can retry with the same nonce and it will still get a correct answer. (While the system may well need to deal with malicious clients, it only needs to give correct results to non-malicious clients). This eliminates any need to keep state for anything resembling packet RTT time. The similarities of this to DNS might just betray my background rather than being anything particularly meaningful. > A legitimate stamp needs to have 3 possible states in the server's > map: redeemed, unredeemed, and pending acknowledgment of redemption. > If the server only has two states for a stamp, then it would end up > with one of two flaws by design: Or "unredeemed" and "redeemed for nonce value X". > 1. If the stamp is marked as redeemed when a successful redemption > attempt completes on the server, it is possible that the success > will not be successfully communicated to the client. If the client > then retries the redemption, it will fail. > > 2. If the stamp is left as unredeemed while waiting for the client > ack of success, stamp "reuse" becomes a question of how many > redemption decisions can be made per client RTT. > > The server may have to defer many thousands of clients for scores of > milliseconds while waiting for one to send an ack. Handling a few > dozen such events per second seems to me to be a really hard problem > to address, but maybe I'm missing something. If the average > transaction lifetime is 100ms, then a million-TPS system needs to be > able to handle an average of 100k concurrent pending transactions > and spikes probably twice that. I think the ways to handle that all > include dividing the front end between multiple machines, but that > creates a tougher problem keeping the back end recordkeeping fast > and coherent from the viewpoints all of the front ends. > > I suspect that the "solution" that will be chosen if anyone tries to > create a real e-postage system instead of hand-waving about it will > be to open it to lost packet damage as the cost of scalability. > Network latency with clients becomes irrelevant if the server > assumes that its redemption messages are always delivered. That > allows for a lot of optimization. Once in a while a stamp that > should work will fail to do so, and if such a system ever gets into > the real world I'm sure its users will be shocked at how much higher > the real-world failures are than in their tests... Don't forget that there is no state that needs to be kept or transferred other than that keyed on the stamp value itself. You can spread the load needed across as many systems as you need to keep up with demand. At an extreme, you can have the client MTAs use the cookie in the stamp to decide where to check the stamp, and spread load across multiple networks and locations - I check this stamp by sending a packet to whatever IP address .stampcheck.foo resolves to. (That's what I mean when I describe it as embarrassingly parallelizable.) That might end up being expensive to operate, of course. Cheers, Steve From hjp-asrg@hjp.at Sun Feb 22 03:53:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F183A686A for ; Sun, 22 Feb 2009 03:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUqWoOIFYx9T for ; Sun, 22 Feb 2009 03:53:04 -0800 (PST) Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id DA3E93A6405 for ; Sun, 22 Feb 2009 03:53:03 -0800 (PST) Received: by zeno.hjp.at (Postfix, from userid 1000) id 7CAAA45151; Sun, 22 Feb 2009 12:53:18 +0100 (CET) Date: Sun, 22 Feb 2009 12:53:18 +0100 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20090222115318.GA28773@hjp.at> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <49A0972D.2030103@billmail.scconsult.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 11:53:05 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-02-21 19:07:09 -0500, Bill Cole wrote: > Steve Atkins wrote, On 2/20/09 7:26 PM: > >On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: > [Quoting John Leslie] > >>> The bottom line is, redeeming a million tokens per second is practic= al > >>>with processing delay not much greater than network latency. (This was > >>>not true ten years ago...) > >> > >>I think I'd quibble with details on that, but they really are not all= =20 > >>that > >>important. >=20 > I guess maybe one detail is... >=20 > If the processing delay for every redemption attempt is of the same order= =20 > of magnitude as irreducible network latencies, i.e. tens to hundreds of= =20 > milliseconds, handling a million one-use token redemption attempts per=20 > second is absolutely hopeless. I think John meant "processing delay" as seen from the client. So this includes a) the time to send the request (tens to hundreds of milliseconds), b) the time it takes the server to process the request (sub-milliseconds?) and c) the time for the response to get back to the client (again tens to hundreds of milliseconds).=20 The number of requests a server can process per second is mostly determined by b). The communication delays only increase the number of open but idle connections (which may also be a problem). So if checking a single token takes 1 millisecond (rather conservative, IMHO), one server can check roughly 1000 tokens per second, so a server farm of 1000 servers can check 1 million tokens per second. That doesn't seem "absolutely hopeless" to me. It's certainly technically possible, although I'm sceptical whether it's economically feasible. > >>I'm pretty sure that I'm not the best systems analyst/designer on this= =20 > >>list. > >>I certainly hope I'm not the best one to have thought about e-postage.= =20 > >>I'd > >>be happy to learn from a master how it is in fact possible to make an= =20 > >>ideally simplified minimal system like this work as a starting point=20 > >>for how to assemble a more complex system that has more elements of=20 > >>reality in it. I think (but may be wrong!) that it isn't possible to=20 > >>design a system that will be theoretically capable of correctly=20 > >>handling a million redemption requests per second of which ~90% are=20 > >>the result of someone working to break the system. > > > > > >It's fun to consider, though. > > > >Using your numbers - one million redemption requests a second of which= =20 > >at least 90% are invalid, leads to 100,000 outstanding valid requests=20 > >per second, which would give around 250 billion outstanding stamps at=20 > >any one time, if we expire them after a month (expiring would likely=20 > >involve voiding the unused stamps and issuing new ones in the same=20 > >amount, but that's a business issue, and doesn't affect the redemption= =20 > >requirements). I expect most tokens would be redeemed pretty soon, so you won't have to keep them around for a month, at least not for real-time checking. > >To me it feels like the hard bit of this is handling a million packets= =20 > >in and out per second reliably, along with the overhead of providing=20 > >robustness and redundancy, rather than the redemption itself. >=20 > That was my point, because it seems to me that a redemption cannot be don= e=20 > with just one packet in and one out, but really needs two in and one out. > A legitimate stamp needs to have 3 possible states in the server's map:= =20 > redeemed, unredeemed, and pending acknowledgment of redemption. If the=20 > server only has two states for a stamp, then it would end up with one of= =20 > two flaws by design: >=20 > 1. If the stamp is marked as redeemed when a successful redemption attemp= t=20 > completes on the server, it is possible that the success will not be=20 > successfully communicated to the client. If the client then retries the= =20 > redemption, it will fail. Yes, but is this a problem which needs to be avoided at all cost? If the redemption fails, the client can simply buy another stamp and send the message again. Delivery of that particular message was now twice as expensive as that of an average message, but if that only happens infrequently it doesn't matter. If it does happen frequently for a particular bank, the affected client(s) will probably be reconfigured to prefer tokens from other banks.=20 So if your 50k clients try to redeem the same token at the same time, one of these 50k requests will be the first to be processed by the server. The server marks the token as redeemed and sends a positive reply to the client. The other 49999 requests will be denied. If (because of network congestion caused by the 50k nearly simultaneous requests) the reply never reaches the "lucky" client, the token will be lost.=20 Sending 50k requests with the same token is garantueed to yield at most one positive reply in this case. It isn't viable for someone who wants to send many messages, but it may be a viable DoS attack. > 2. If the stamp is left as unredeemed while waiting for the client ack of= =20 > success, stamp "reuse" becomes a question of how many redemption decision= s=20 > can be made per client RTT. >=20 > The server may have to defer many thousands of clients for scores of=20 > milliseconds while waiting for one to send an ack. Yes, but it only needs to defer those clients which sent a request with the same token. It can process lots of other tokens in the meantime.=20 Also the server doesn't have to keep the connection open. If the token it wants to check is currently in the "pending" state, it can reply with a temporary error and leave it to the client to retry at a later time. > I think the ways to handle that all include dividing the front end > between multiple machines, but that creates a tougher problem keeping > the back end recordkeeping fast and coherent from the viewpoints all > of the front ends. I think it is possible to solve the coherency problem by using the token to choose the server. Then there is always exactly one server responsible for a specific token and no coherency problem does occur. The draft doesn't specify the protocol used to buy or redeem tokens, so this could be done in the client: A token might consist of two parts, the first one identifies the server to connect to, the second is unique within that server. > I suspect that the "solution" that will be chosen if anyone tries to crea= te=20 > a real e-postage system instead of hand-waving about it will be to open i= t=20 > to lost packet damage as the cost of scalability. Yes, that's what I'd probably do. > Network latency with clients becomes irrelevant if the server assumes > that its redemption messages are always delivered. That allows for a > lot of optimization. Once in a while a stamp that should work will > fail to do so, and if such a system ever gets into the real world I'm > sure its users will be shocked at how much higher the real-world > failures are than in their tests... If you are still cheaper than the competition, that doesn't matter. If you aren't, but already have sufficient market share (because you were one of the first), it might not matter, either. Otherwise you're out of business. hp --=20 _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJoTyufZ+RkG8quy0RAocoAJ9yBw69h0gazcdkFMcdjth2WLNoMQCgtbIX KfFuW+JNR7QGQ8uSdBXcPJ0= =hkfv -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From asrg3@billmail.scconsult.com Sun Feb 22 21:58:59 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC613A67F2 for ; Sun, 22 Feb 2009 21:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvm+j3VcHDQM for ; Sun, 22 Feb 2009 21:58:57 -0800 (PST) Received: from toaster.scconsult.com (www.scconsult.com [66.73.230.185]) by core3.amsl.com (Postfix) with ESMTP id E39B83A67A1 for ; Sun, 22 Feb 2009 21:58:54 -0800 (PST) Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id 3904E856333 for ; Mon, 23 Feb 2009 00:59:09 -0500 (EST) Message-ID: <49A23B2E.2000402@billmail.scconsult.com> Date: Mon, 23 Feb 2009 00:59:10 -0500 From: Bill Cole User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> <20090222115318.GA28773@hjp.at> In-Reply-To: <20090222115318.GA28773@hjp.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: asrg@irtf.org List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 05:58:59 -0000 Peter J. Holzer wrote, On 2/22/09 6:53 AM: > On 2009-02-21 19:07:09 -0500, Bill Cole wrote: >> Steve Atkins wrote, On 2/20/09 7:26 PM: >>> On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: >> [Quoting John Leslie] >>>>> The bottom line is, redeeming a million tokens per second is practical >>>>> with processing delay not much greater than network latency. (This was >>>>> not true ten years ago...) >>>> I think I'd quibble with details on that, but they really are not all >>>> that >>>> important. >> I guess maybe one detail is... >> >> If the processing delay for every redemption attempt is of the same order >> of magnitude as irreducible network latencies, i.e. tens to hundreds of >> milliseconds, handling a million one-use token redemption attempts per >> second is absolutely hopeless. > > I think John meant "processing delay" as seen from the client. So this > includes a) the time to send the request (tens to hundreds of > milliseconds), b) the time it takes the server to process the request > (sub-milliseconds?) and c) the time for the response to get back to the > client (again tens to hundreds of milliseconds). > > The number of requests a server can process per second is mostly > determined by b). The communication delays only increase the number of > open but idle connections (which may also be a problem). Just in case anyone misconstrues your use of the term "connections": Using one TCP connection per transaction for a system that needs to complete a million transactions per second across the Internet would be a ridiculous design flaw. I therefore assume that you mean "connection" in a more generic sense, and indeed that was the core of my argument: if the server has to retain state on transactions for typical Internet RTT's for a common class of transaction, concurrency is likely to become a problem in and of itself. > So if checking a single token takes 1 millisecond (rather conservative, > IMHO), one server can check roughly 1000 tokens per second, so a server > farm of 1000 servers can check 1 million tokens per second. That doesn't > seem "absolutely hopeless" to me. It's certainly technically possible, > although I'm sceptical whether it's economically feasible. Your hand waves so elegantly when forming the phrase "server farm of 1000 servers." I believe that dividing the workload between multiple front-end machines will either create unworkable latencies in the back end to assure that all of the front ends see a coherent state database for tokens or else will create vulnerabilities that will allow any significant botnet operator to effectively eliminate chunks of the system at will. Hand-waving a 1000-node server farm doesn't persuade me that I'm wrong. >>>> I'm pretty sure that I'm not the best systems analyst/designer on this >>>> list. >>>> I certainly hope I'm not the best one to have thought about e-postage. >>>> I'd >>>> be happy to learn from a master how it is in fact possible to make an >>>> ideally simplified minimal system like this work as a starting point >>>> for how to assemble a more complex system that has more elements of >>>> reality in it. I think (but may be wrong!) that it isn't possible to >>>> design a system that will be theoretically capable of correctly >>>> handling a million redemption requests per second of which ~90% are >>>> the result of someone working to break the system. >>> >>> It's fun to consider, though. >>> >>> Using your numbers - one million redemption requests a second of which >>> at least 90% are invalid, leads to 100,000 outstanding valid requests >>> per second, which would give around 250 billion outstanding stamps at >>> any one time, if we expire them after a month (expiring would likely >>> involve voiding the unused stamps and issuing new ones in the same >>> amount, but that's a business issue, and doesn't affect the redemption >>> requirements). > > I expect most tokens would be redeemed pretty soon, so you won't have > to keep them around for a month, at least not for real-time checking. Someone who thinks e-postage is workable should make a real specification that defines "pretty soon" in concrete terms that would support an actual protocol design that expires tokens. That "someone" won't be me, and I expect that it won't be anyone else who has been asking for such a specification. E-postage has been at the hand-waving idea stage for over a decade, and it's becoming a bit comical. >>> To me it feels like the hard bit of this is handling a million packets >>> in and out per second reliably, along with the overhead of providing >>> robustness and redundancy, rather than the redemption itself. >> That was my point, because it seems to me that a redemption cannot be done >> with just one packet in and one out, but really needs two in and one out. >> A legitimate stamp needs to have 3 possible states in the server's map: >> redeemed, unredeemed, and pending acknowledgment of redemption. If the >> server only has two states for a stamp, then it would end up with one of >> two flaws by design: >> >> 1. If the stamp is marked as redeemed when a successful redemption attempt >> completes on the server, it is possible that the success will not be >> successfully communicated to the client. If the client then retries the >> redemption, it will fail. > > Yes, but is this a problem which needs to be avoided at all cost? I think so, but then I think the whole e-postage concept is a misguided fantasy in multiple aspects. If you think it could actually survive having random stamps made worthless and indicative of fraud by dropped packets, I urge you to implement it and demonstrate that people will tolerate such a system. > If the > redemption fails, the client can simply buy another stamp and send the > message again. Delivery of that particular message was now twice as > expensive as that of an average message, but if that only happens > infrequently it doesn't matter. If it does happen frequently for a > particular bank, the affected client(s) will probably be reconfigured to > prefer tokens from other banks. There's not any strong reason for such a problem to be bank-specific. It could just as easily be tied to where the redemption attempt is coming from. > So if your 50k clients try to redeem the same token at the same time, > one of these 50k requests will be the first to be processed by the > server. The server marks the token as redeemed and sends a positive > reply to the client. The other 49999 requests will be denied. If > (because of network congestion caused by the 50k nearly simultaneous > requests) the reply never reaches the "lucky" client, the token will be > lost. > > Sending 50k requests with the same token is garantueed to yield at most > one positive reply in this case. It isn't viable for someone who wants > to send many messages, but it may be a viable DoS attack. Botnet spammers have a history of attacking anti-spam systems. Any mailing tactic capable of crippling an e-postage system, even temporarily, will be tried. > >> 2. If the stamp is left as unredeemed while waiting for the client ack of >> success, stamp "reuse" becomes a question of how many redemption decisions >> can be made per client RTT. >> >> The server may have to defer many thousands of clients for scores of >> milliseconds while waiting for one to send an ack. > > Yes, but it only needs to defer those clients which sent a request with > the same token. It can process lots of other tokens in the meantime. If designed correctly, that might be the case. What is that design again? Spammers will work to break any e-postage system. They will be the indirect sources of most of the redemption requests, so whatever inconvenient cases are possible can be expected to make up almost all of the request traffic. > Also the server doesn't have to keep the connection open. If the token > it wants to check is currently in the "pending" state, it can reply with > a temporary error and leave it to the client to retry at a later time. Then the system is NOT handling that redemption attempt. The million-TPS scaling is based on the number of redemptions that have to be completed, not tried. If trying a redemption once doesn't dispose of that token, you need to scale up to handle the retries. This is a problem that is familiar to many MTA admins: if you defer clients, you increase how many client connections you get. >> I think the ways to handle that all include dividing the front end >> between multiple machines, but that creates a tougher problem keeping >> the back end recordkeeping fast and coherent from the viewpoints all >> of the front ends. > > I think it is possible to solve the coherency problem by using the token > to choose the server. Then there is always exactly one server > responsible for a specific token and no coherency problem does occur. > The draft doesn't specify the protocol used to buy or redeem tokens, so > this could be done in the client: A token might consist of two parts, > the first one identifies the server to connect to, the second is unique > within that server. So, you have something embedded in the token that tells the MTA trying to redeem it which one of 1000 servers to contact for redemption, each one of which is capable of handling 1000 redemptions per second? With spammers controlling botnets of 100k machines? Is there a punch line? If e-postage is ever going to be more than hand-waving about a concept, someone who is able to put in disciplined, serious system design work is going to need to be convinced that there's enough potential in e-postage to put together a redemption protocol that doesn't generate derisive giggling. >> I suspect that the "solution" that will be chosen if anyone tries to create >> a real e-postage system instead of hand-waving about it will be to open it >> to lost packet damage as the cost of scalability. > > Yes, that's what I'd probably do. Why not actually do it? >> Network latency with clients becomes irrelevant if the server assumes >> that its redemption messages are always delivered. That allows for a >> lot of optimization. Once in a while a stamp that should work will >> fail to do so, and if such a system ever gets into the real world I'm >> sure its users will be shocked at how much higher the real-world >> failures are than in their tests... > > If you are still cheaper than the competition, that doesn't matter. If > you aren't, but already have sufficient market share (because you were > one of the first), it might not matter, either. Otherwise you're out of > business. Demonstrate that *anyone* will accept a new sort of currency designed to randomly be worthless based on the vagaries of Internet packet reception before making up stories about competitive providers of such magic scrip. From john@jlc.net Mon Feb 23 04:18:26 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52BA3A6934 for ; Mon, 23 Feb 2009 04:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.622 X-Spam-Level: X-Spam-Status: No, score=-6.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2fTAYzHedX for ; Mon, 23 Feb 2009 04:18:26 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id D8C343A6916 for ; Mon, 23 Feb 2009 04:18:25 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8C61033C53; Mon, 23 Feb 2009 07:18:43 -0500 (EST) Date: Mon, 23 Feb 2009 07:18:43 -0500 From: John Leslie To: asrg@irtf.org Message-ID: <20090223121843.GD65762@verdi> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49A0972D.2030103@billmail.scconsult.com> User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:18:26 -0000 Bill Cole wrote: > > ... The problem is that logically you need a third intermediate state > that will last for the RTT of the network connection to the redeeming > client, and that state will defer the decision for other attempts to > redeem the stamp. We're getting a fair ways from the POSTAGE spec into the BANKING spec (not yet written), or actually beyond it, since it deals with customer interface, not internals. However, while you're welcome to implement your "bank" that way, I'd pretty strongly advise against even trying to maintain distributed state. The state of the token can be simply "redeemed" whether the presenting customer _ever_ learns about it. The customer really doesn't care about the state of the token. They care whether their account has been credited the appropriate amount. And they don't care about which microsecond that credit happens in -- they'd be happy waiting tens of seconds. > A legitimate stamp needs to have 3 possible states in the server's map: > redeemed, unredeemed, and pending acknowledgment of redemption. If the > server only has two states for a stamp, then it would end up with one > of two flaws by design: > > 1. If the stamp is marked as redeemed when a successful redemption > attempt completes on the server, it is possible that the success > will not be successfully communicated to the client. If the client > then retries the redemption, it will fail. As it should, IMHO. It's just as abusive for the receiving SMTP server to multiply redeem tokens as for the sending SMTP client to send multiple copies of the same token. (Obviously, the customer interface with the bank should consider how to work around communications failures; but a simple retry is a particularly bad way to do so.) > 2. If the stamp is left as unredeemed while waiting for the client > ack of success, stamp "reuse" becomes a question of how many > redemption decisions can be made per client RTT. RTT, alas, is a variable. :^( An abusive customer could draw it out way beyond reason. > I suspect that the "solution" that will be chosen if anyone tries to > create a real e-postage system instead of hand-waving about it will > be to open it to lost packet damage as the cost of scalability. That is a business decision. (More exactly, to what extent the "bank" tries to adjust for packet loss is a business decision.) > Network latency with clients becomes irrelevant if the server assumes > that its redemption messages are always delivered. Yes, and it may be the case for many "banks" that standard TCP is considered sufficiently "reliable". > That allows for a lot of optimization. Once in a while a stamp that > should work will fail to do so, and if such a system ever gets into > the real world I'm sure its users will be shocked at how much higher > the real-world failures are than in their tests... No doubt some will be... -- John Leslie From johnl@iecc.com Mon Feb 23 05:58:08 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B723A69F1 for ; Mon, 23 Feb 2009 05:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.723 X-Spam-Level: X-Spam-Status: No, score=-14.723 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZNjH6R+AlPv for ; Mon, 23 Feb 2009 05:58:07 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id C8E533A6968 for ; Mon, 23 Feb 2009 05:58:05 -0800 (PST) Received: (qmail 60871 invoked from network); 23 Feb 2009 13:58:21 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 23 Feb 2009 13:58:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=79KgS4O0pPZtVc3HjeVRbaArHpi5pmTDWJAYzRgi9N4=; b=TOWfPSvSe7ohNt3ARcii/77ROh0k1V2DjdNwxL0PtpQqbW/1gqIn676RbWb2iZ9HZo7xC8VUvT73BgWaFrQmbQVbL/fKKVTmIeBqxzV7Xa2+qZa26sxTgH1GKD951oQx27Sq8qxwuvYlrfSoZaOAvgwonOa2EFoXT/mt1pnvaNw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=79KgS4O0pPZtVc3HjeVRbaArHpi5pmTDWJAYzRgi9N4=; b=L8MaNzWsA9Oy09mjPg07Ck9KPWS2kC4bS/9ySInT7YxhbvmAGGGYtTp5wEQJAbYO000o/Pk5Cj5a1rqqrIyvUn+j7qpqB0ExhgH6H1b0VPfjVnNFGIISYMfSmlVF3d4ZX39B2Fyq25Su1v/1Vxt+nUQE26pcnXefz2TZH65uA4c= Date: 23 Feb 2009 13:58:21 -0000 Message-ID: <20090223135821.5147.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <20090223121843.GD65762@verdi> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:58:08 -0000 > We're getting a fair ways from the POSTAGE spec into the BANKING >spec (not yet written), or actually beyond it, since it deals with >customer interface, not internals. A fair point. But I think it would be a good idea to write down what the banking requirements would be, e.g., what sorts of transactions it would have to handle, at what sorts of transaction rates, and what kinds of attacks it is likely to have to withstand. R's, John From davidnicol@gmail.com Mon Feb 23 14:38:17 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1913A6897 for ; Mon, 23 Feb 2009 14:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0oz4Vea6H1f for ; Mon, 23 Feb 2009 14:38:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 851593A63D3 for ; Mon, 23 Feb 2009 14:38:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2253140rvf.7 for ; Mon, 23 Feb 2009 14:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=T1oOjUx3rF4Gk2bO9+bgOrEDwXXQM2eyhJpcGtC4tNk=; b=KQyjVir7WFAI/bmYiN0rJlLFa4Cz9YhcTpSeaNtVEI3VXDf+Ax1jYK0DnYnohprtPf ng5wxpIWYficuAnoFPzFMtTKgYIxTOHGbdzDwnJSKJY59ffQOIMWika1v9vw7V2XKDqL ibnbIzh1V+AX6N3ZeJYYy2Ek/wds0ZWcxKfZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=L4pJYgFBUIzcFd8nsIph0ZbqXeB88uINHNoayQwbEIdPwAqYEZZ6ugCUhN/h7FnQiE Aht6rcPOfFdGrlwJdevJEqoAEWdEnnNfnkGkbCyxTDJRpNwcHSmEfcVeFAPLSBQF8pup h13lTzlKagz2R/jn9aP9Uk0oTeHM4NJXwE4hU= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr2171139wfe.265.1235428713835; Mon, 23 Feb 2009 14:38:33 -0800 (PST) In-Reply-To: <20090216212251.24646.qmail@simone.iecc.com> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> Date: Mon, 23 Feb 2009 16:38:33 -0600 Message-ID: <934f64a20902231438k350e7b31vc3fd8fc2ab379e4c@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:38:17 -0000 On Mon, Feb 16, 2009 at 3:22 PM, John Levine wrote: > You probably don't want to do that, since the performance of book > entry transactions is worse than for bearer ones. But bearer system cannot be done securely, implying book entry system anyway, so let us hear no more on bearer systems. > If you're doing > book entry, you need at least a journalling system to log the entries > to be added to each account, if not locks on each account to maintain > the balance. So what? Imagine a coin minting/redemption protocol in which central authorities issue book-entry tokens and associate them with value which is transferrable. The primitive operations available include mint here is some value from my account into a coin account and give me the coin. bite here is a coin code, what if anything is it worth? melt here is a coin code please transfer its value into my account knowing a coin code implies a capability to melt it, but it can only be melted once. Scalability happens by creating as wide an array of mint operations as is needed. Minting/melting takes fewer read/write operations than delivering an e-mail by several orders of magnitude, and even if a paid e-mail took ten free e-mails to implement that would not be a problem. The problems are political not technical. So anyway in SMTP terms, toward e-postage drafts, I see senders, spf-authenticated envelope return addresses (ERAs), so we can work this all out prior to the DATA phase, using mint/melt to deliver value in a form trusted by both the ERA and the recipient, to the receiving MX, along with a concise statement of their payment policy. There doesn't have to be any imposition or zero-day, just restriction of access by the receivers of paid e-mail until senders adapt. From johnl@iecc.com Mon Feb 23 15:43:35 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00B628C241 for ; Mon, 23 Feb 2009 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.737 X-Spam-Level: X-Spam-Status: No, score=-14.737 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTOXpJJO51DB for ; Mon, 23 Feb 2009 15:43:34 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 9C11B28C209 for ; Mon, 23 Feb 2009 15:43:34 -0800 (PST) Received: (qmail 78095 invoked from network); 23 Feb 2009 23:43:52 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 23 Feb 2009 23:43:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=czIpe/gDqYjBdpl9wsX9xdzSNASuQUi+pR7Ni0A1ERI=; b=kKlLzKAeD/PDyebTkBjUNI7fQbyqg5MLJuEWe2o9awR9mbqYtX9eQpEqe+uCC5NhjFcOg/sAa5KfpkagjFyTV6QoAnd7WQdb/bFbgJZo38Be7aKA3n40C41Zl/65l7pOX5SikIKUTeYoG4hAc03xVRfwzhF0myd4aCFNyMSaSvA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=czIpe/gDqYjBdpl9wsX9xdzSNASuQUi+pR7Ni0A1ERI=; b=FnztyzJWIulQDSBL9L9br+PdoIWFiMy6Q6QF5OpLmL8BuJd3/p8JMOtwlcKI27ympr67MTvlDWG7Vo6SadpY8Y5YhYkUovUgo5lWroA2GX3uShbs1wWvvbu1Nl9ifXLnRflVCdn1nWxtpJwmLbllNS4ajr5FiHrCCKk7vnuCYkQ= Date: 23 Feb 2009 23:43:51 -0000 Message-ID: <20090223234351.76381.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <934f64a20902231438k350e7b31vc3fd8fc2ab379e4c@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:43:35 -0000 >> You probably don't want to do that, since the performance of book >> entry transactions is worse than for bearer ones. > >But bearer system cannot be done securely, implying book entry system >anyway, so let us hear no more on bearer systems. Huh? Bearer systems are just as secure as book entry, but they have different performance characteristics. >> If you're doing book entry, you need at least a journalling system >> to log the entries to be added to each account, if not locks on >> each account to maintain the balance. >So what? locks -> bottlenecks -> slow. It's a basic problem of any concurrent system. >Minting/melting takes fewer read/write operations than delivering an >e-mail by several orders of magnitude, and even if a paid e-mail took >ten free e-mails to implement that would not be a problem. This is a non-sequitur. Delivering mail is inherently very parallel, postage operations are not. The whole point of postage is to apply global limits to the number of messages that someone can send, which means that all those parallel deliveries have to funnel requests to a limited number of banks/postoffices/whatever to find out whether the senders have any mail-fu left. >The problems are political not technical. They're political AND technical. R's, John From davidnicol@gmail.com Mon Feb 23 16:02:13 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618D43A67B4 for ; Mon, 23 Feb 2009 16:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1W+hXAyYTJt for ; Mon, 23 Feb 2009 16:02:12 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 76FE13A63D3 for ; Mon, 23 Feb 2009 16:02:12 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2305965wfd.7 for ; Mon, 23 Feb 2009 16:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=md3UrR3xXIPDi4rAS8mOHor0qNTdJNuUJPArlzWHE78=; b=iHjCGnLWVsuL62L/H/WOxoKa1mxYT7E6Q+uy4mvPTrtdN98gPTCoO/KsR/HUaIjzME 6J6XMAnszUBKQpVGQyieFIRfaBqZ1to/5iPf5pO2nQBkAAFrnNsTY3GH7BSlY51ZHvjT 1EolgqrohWmVt1OWMCQ+Ha3EFhqJNvLXXTU/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=o9RmQ+iqj2Wc6pyD8ujZbsFjSsf5SG1oYn5KaalqEDF20hGg98tV7JCLwE0RE9HfmJ +sBVxL7YfeAEkQHacm/CwgzdGt3OekSXMUcKdQ2Cx/8P/fGXVnQeBSMPQtEJrUAq1B5H hTD+DhSxAWx9GOcD+QSWA3Ea8b0WqYE2T5tXg= MIME-Version: 1.0 Received: by 10.143.15.14 with SMTP id s14mr43682wfi.284.1235433749115; Mon, 23 Feb 2009 16:02:29 -0800 (PST) In-Reply-To: <20090223234351.76381.qmail@simone.iecc.com> References: <934f64a20902231438k350e7b31vc3fd8fc2ab379e4c@mail.gmail.com> <20090223234351.76381.qmail@simone.iecc.com> Date: Mon, 23 Feb 2009 18:02:28 -0600 Message-ID: <934f64a20902231602k62b35c43vff62bcca7e8764de@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:02:13 -0000 On Mon, Feb 23, 2009 at 5:43 PM, John Levine wrote: > The whole point of postage is to apply > global limits to the number of messages that someone can send, which > means that all those parallel deliveries have to funnel requests to a > limited number of banks/postoffices/whatever to find out whether the > senders have any mail-fu left. Now we're getting somewhere. I see the whole point of postage as a mechanism for the recipient to monetize their attention. And since there is money involved, suddenly substantially complex machine loads can be afforded, as the transaction costs can be a small fraction of the cost of someone's restricted attention. The purchase of additional mail-fu as required will be a cost borne by the senders, who will aggregate it at various levels opportunisticly depending on reality. The first step is to have some recipients demand to be paid for delivery to them. An interesting proposal is http://wiki.qpsmtpd.org/plugins:spam:autowhitelist_captcha although it has the obvious problem of being a c/r system rather than issuing smtp rejection codes referring to an http address for the authen piece. From johnl@iecc.com Mon Feb 23 16:59:58 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC2473A67E6 for ; Mon, 23 Feb 2009 16:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.748 X-Spam-Level: X-Spam-Status: No, score=-14.748 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B35VikqAi1ry for ; Mon, 23 Feb 2009 16:59:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 875383A69FE for ; Mon, 23 Feb 2009 16:59:57 -0800 (PST) Received: (qmail 36196 invoked from network); 24 Feb 2009 01:00:15 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Feb 2009 01:00:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=gDlb+KaA/hYNt4OrREKCqAJS+wzPl3pGeRLo7cUg84E=; b=FgAB7ZIzqHoOWv/5sJf/ov/+RDjegGj3z8Gq8iVR4Sj8BvDHufGJfJvCMCHqCbe1qAVG9OQmacffdjEjC2l2PFh4RebO1ye3QSG3akeKZE/Nvq/UzDVNsHOHc64+kwtoqeVX0aeZu8qItgD1qFg1Iclmbnxwqbnj6lh9O/ryIks= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=gDlb+KaA/hYNt4OrREKCqAJS+wzPl3pGeRLo7cUg84E=; b=V4kzKa6KWh3YcCV6ykrRBTpsVj4gHtQCRTNOjFHEkVapbyzkYasGJqcwlC9TpzJtkCoCsB+EUVMI7cxg0jBilUDX28CXbSPCDHVEyu79fzHXZ+Kpil12JPs1T44gImg1bkKacCUMtXsxhuZWkeoyGN2Xc5ipqrB0ykyhuS0YuMo= Date: 24 Feb 2009 01:00:14 -0000 Message-ID: <20090224010014.98782.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <934f64a20902231602k62b35c43vff62bcca7e8764de@mail.gmail.com> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:59:58 -0000 >Now we're getting somewhere. I see the whole point of postage as a >mechanism for the recipient to monetize their attention. And since >there is money involved, suddenly substantially complex machine loads >can be afforded, as the transaction costs can be a small fraction of >the cost of someone's restricted attention. Well, OK. How do you see this relating to the current mail system? Do you expect a system where all mail is paid? If not, how do you decide what to accept for free? How much do you expect advertisers to pay for your attention? (See goodmail and e-rewards for some current examples.) A draft explaining what your model is would be nice. The existing draft (I think) is more intending to use e-postage to limit mail volume, not to pay end recipients. R's, John From mouse@Sparkle.Rodents-Montreal.ORG Mon Feb 23 21:15:05 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF4F3A6812 for ; Mon, 23 Feb 2009 21:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.627 X-Spam-Level: X-Spam-Status: No, score=-6.627 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_40=-0.185, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxo9wmr8FxNa for ; Mon, 23 Feb 2009 21:15:04 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id DFF163A69AA for ; Mon, 23 Feb 2009 21:15:03 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id AAA06862; Tue, 24 Feb 2009 00:15:04 -0500 (EST) From: der Mouse Message-Id: <200902240515.AAA06862@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 24 Feb 2009 00:13:38 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090224010014.98782.qmail@simone.iecc.com> References: <20090224010014.98782.qmail@simone.iecc.com> Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 05:15:05 -0000 > Do you expect a system where all mail is paid? If not, how do you > decide what to accept for free? Surely the answer to that will be "it's up to the recipient ('s postmaster)", just as most filtering decisions are now? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From franck@avonsys.com Tue Feb 24 01:47:16 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0407A3A6AE0 for ; Tue, 24 Feb 2009 01:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeCoH9HWPaa7 for ; Tue, 24 Feb 2009 01:47:15 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 1C63E3A6AD4 for ; Tue, 24 Feb 2009 01:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id C1C8D64F843C for ; Tue, 24 Feb 2009 21:47:49 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HM7Yli+54lb for ; Tue, 24 Feb 2009 21:47:48 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id ABDDF64F843B for ; Tue, 24 Feb 2009 21:47:48 +1200 (FJT) Date: Tue, 24 Feb 2009 21:47:48 +1200 (FJT) From: Franck Martin To: asrg@irtf.org Message-ID: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_11957754.1235468842433" X-Originating-IP: [113.20.67.75] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1482_Mac) Subject: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 09:47:16 -0000 ------=_Part_7_11957754.1235468842433 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I have been looking around, but it seems I cannot find a TXT record that has spf2.0 they are all v=spf1 This seems strange to me. I know that SPF is part of SenderID but then... So is SenderID really deployed or it is just SPF? ------=_Part_7_11957754.1235468842433 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I have been looking around, but it seems I cannot find a TXT record that has spf2.0 they are all v=spf1

This seems strange to me. I know that SPF is part of SenderID but then... So is SenderID really deployed or it is just SPF?
------=_Part_7_11957754.1235468842433-- From CLEWIS@nortel.com Tue Feb 24 05:47:57 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991D93A691D for ; Tue, 24 Feb 2009 05:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5XpwPsBQaCB for ; Tue, 24 Feb 2009 05:47:57 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B4ED73A67A2 for ; Tue, 24 Feb 2009 05:47:56 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1ODmD215559 for ; Tue, 24 Feb 2009 13:48:13 GMT Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 08:48:11 -0500 Received: from [47.9.16.49] (47.9.16.49) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Feb 2009 08:48:10 -0500 Message-ID: <49A3FA99.8040503@nortel.com> Date: Tue, 24 Feb 2009 08:48:09 -0500 From: "Chris Lewis" Organization: Nortel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2009 13:48:11.0478 (UTC) FILETIME=[88638F60:01C99686] Subject: Re: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:47:57 -0000 Franck Martin wrote: > I have been looking around, but it seems I cannot find a TXT record that > has spf2.0 they are all v=spf1 dig -t txt ebay.com From steve@blighty.com Tue Feb 24 08:11:45 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D000D3A6957 for ; Tue, 24 Feb 2009 08:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7fA9elqegwW for ; Tue, 24 Feb 2009 08:11:45 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 31D723A683E for ; Tue, 24 Feb 2009 08:11:45 -0800 (PST) Received: from [192.168.80.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 28A178054A for ; Tue, 24 Feb 2009 08:11:57 -0800 (PST) Message-Id: From: Steve Atkins To: Anti-Spam Research Group - IRTF In-Reply-To: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 08:12:01 -0800 References: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> X-Mailer: Apple Mail (2.930.3) Subject: Re: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:11:45 -0000 On Feb 24, 2009, at 1:47 AM, Franck Martin wrote: > I have been looking around, but it seems I cannot find a TXT record > that has spf2.0 they are all v=spf1 ebay.com and paypal.com are the two I can think of (though paypal.com seem to have broken their DNS a little right now). > > > This seems strange to me. I know that SPF is part of SenderID but > then... So is SenderID really deployed or it is just SPF? SenderID is dead. The only group that every liked it was Microsoft / Hotmail, and even they don't publish it. Any records you see are mostly just fossil relics of an earlier era. Cheers, Steve From rrognlie@gamerz.net Tue Feb 24 08:30:29 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917F63A697D for ; Tue, 24 Feb 2009 08:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u1KH8IAs0K3 for ; Tue, 24 Feb 2009 08:30:28 -0800 (PST) Received: from sentrion.gamerz.net (sentrion.gamerz.net [96.255.48.5]) by core3.amsl.com (Postfix) with ESMTP id 4076D3A683E for ; Tue, 24 Feb 2009 08:30:28 -0800 (PST) Received: from play.gamerz.net (www.gamerz.net [192.168.1.129]) by sentrion.gamerz.net (Sentrion-MP-4.0.0/Sentrion-MP-4.0.0) with ESMTP id n1OGUkjE006424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Feb 2009 16:30:46 GMT X-DKIM: Sendmail DKIM Filter v2.5.6 sentrion.gamerz.net n1OGUkjE006424 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gamerz.net; s=dk20081216a; t=1235493046; bh=x1g3+yOnOP43LuVomoVldUfSQQcNxxhhz1y 0jNgvT6w=; h=Date:From:To:Subject:Message-ID:References: Mime-Version:Content-Type:In-Reply-To; b=CIObvs+2Ermd1tTyaB4xNXTIL ESREulWV/j670ZYUeh4tP4NMSPkOHo1XzRQSVT54zMDSpmne5RjH+aZC9YoGyRfTKiw CdyZ9Jr4G+O+r+pc8CP9ka9orVcbojluK0zA2S1PopcsMYjqPFsS+2hR/4Goz1vgsD+ q2GDK9HDAIIg= Received: from play.gamerz.net (localhost.localdomain [127.0.0.1]) by play.gamerz.net (Sentrion-MP-4.0.0/Switch-3.3.0) with ESMTP id n1OGUkmf022701 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Tue, 24 Feb 2009 11:30:46 -0500 X-DKIM: Sendmail DKIM Filter v2.3.2 play.gamerz.net n1OGUkmf022701 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gamerz.net; s=dk20070703; t=1235493046; bh=x1g3+yOnOP43LuVomoVldUfSQQcNxxhhz1y0 jNgvT6w=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:Content-Disposition:In-Reply-To:User-Agent; b=K5NuUOP 9f28/lDTxCmEKkB9TDQ+BdGl0nCQOul7CEdEzSHgS6Zx5D70WFwgiI1WmIrs0UoG3Mn VhoH8/SYRgg6Hrqvn5lwZu2yd66tu0u6fKDT+E39tUhy+B+S2Uk0C3g8s80sPjbsUlZ BxvlwKb+pkTAeleMsReKD3w2igEgvw= Received: (from rrognlie@localhost) by play.gamerz.net (Sentrion-MP-4.0.0/Switch-3.3.0/Submit) id n1OGUkbK022700 for asrg@irtf.org; Tue, 24 Feb 2009 11:30:46 -0500 Date: Tue, 24 Feb 2009 11:30:46 -0500 From: Richard Rognlie To: Anti-Spam Research Group - IRTF Message-ID: <20090224163046.GM9807@gamerz.net> References: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:30:29 -0000 On Tue, Feb 24, 2009 at 08:12:01AM -0800, Steve Atkins wrote: > > SenderID is dead. The only group that every liked it was Microsoft / > Hotmail, and even they don't publish it. Any records you see are > mostly just fossil relics of an earlier era. And one SenderID/SPF issue that you *will* run into is that... The Sender ID spec tells you that if you see a v=spf1 record, you should treat it as though it were spf2.0/mfrom,pra when, in fact, if *should* be treated as though it were spf2.0/mfrom. any assumption of "pra" is not necessarily a valid read of the sending domains wishes. -- / \__ | Richard Rognlie / Sendmail Ninja / Gamerz.NET Lackey \__/ \ | http://www.gamerz.net/~rrognlie / \__/ | Creator of pbmserv@gamerz.net \__/ | Helping reduce world productivity since 1994 From franck@avonsys.com Tue Feb 24 10:42:02 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535503A6A16 for ; Tue, 24 Feb 2009 10:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cunVnn7VMjS for ; Tue, 24 Feb 2009 10:42:01 -0800 (PST) Received: from seine.avonsys.com (seine.avonsys.com [202.170.42.206]) by core3.amsl.com (Postfix) with ESMTP id 26EF53A6A11 for ; Tue, 24 Feb 2009 10:42:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 00BF264F843C for ; Wed, 25 Feb 2009 06:42:35 +1200 (FJT) X-Virus-Scanned: amavisd-new at avonsys.com Received: from seine.avonsys.com ([127.0.0.1]) by localhost (seine.avonsys.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-3cJoLWcSLS for ; Wed, 25 Feb 2009 06:42:29 +1200 (FJT) Received: from seine.avonsys.com (localhost [127.0.0.1]) by seine.avonsys.com (Postfix) with ESMTP id 8917464F843B for ; Wed, 25 Feb 2009 06:42:29 +1200 (FJT) Date: Wed, 25 Feb 2009 06:42:29 +1200 (FJT) From: Franck Martin To: Anti-Spam Research Group - IRTF Message-ID: <2053944.261235500922586.JavaMail.franck@franck-martins-macbook-pro.local> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [113.20.67.75] X-Mailer: Zimbra 5.0.11_GA_2695.UBUNTU6 (Yahoo! Zimbra Desktop/1.0_1482_Mac) Subject: Re: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:42:02 -0000 And you have to submit your SPF record to MS CIDF database otherwise MS does not even read it from the DNS. Is that a joke? Yes senderID is truly dead. ----- Original Message ----- From: "Steve Atkins" To: "Anti-Spam Research Group - IRTF" Sent: Wednesday, 25 February, 2009 4:12:01 AM (GMT+1200) Auto-Detected Subject: Re: [Asrg] spf2.0 On Feb 24, 2009, at 1:47 AM, Franck Martin wrote: > I have been looking around, but it seems I cannot find a TXT record > that has spf2.0 they are all v=spf1 ebay.com and paypal.com are the two I can think of (though paypal.com seem to have broken their DNS a little right now). > > > This seems strange to me. I know that SPF is part of SenderID but > then... So is SenderID really deployed or it is just SPF? SenderID is dead. The only group that every liked it was Microsoft / Hotmail, and even they don't publish it. Any records you see are mostly just fossil relics of an earlier era. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From johnl@iecc.com Tue Feb 24 11:11:39 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3173A6A1C for ; Tue, 24 Feb 2009 11:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.551 X-Spam-Level: X-Spam-Status: No, score=-13.551 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY2kE0RvDEj1 for ; Tue, 24 Feb 2009 11:11:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id CFE713A68A7 for ; Tue, 24 Feb 2009 11:11:37 -0800 (PST) Received: (qmail 4889 invoked from network); 24 Feb 2009 19:11:56 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Feb 2009 19:11:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; i=johnl@user.iecc.com; bh=XGKQPztwgbBGO3FdA0ifCcz94PNxJZPAD9GsDZYdhhg=; b=DiFhMOkFji1N9E7wZkG4ynqRODsWs5+gfx7trRrEwFL6fRWuyftN2rV4VikXoWmHrGH2reAL0Qczga1xiYSSMJgQTNJFJXNNZ6GlQ5xqhJmHSIf+wRdwCMqUV+A8qlAJoQTotJ2a5n2L4iVMk9Pkb+WnYxPP97CxHLvN6dN8VJg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k0902; bh=XGKQPztwgbBGO3FdA0ifCcz94PNxJZPAD9GsDZYdhhg=; b=iUYJQLLqJwPpf39cm7aT1HBUj4XCtUnwdcEZP8Hw86/JB5FYf2dNonZpc06znaxRL4JTGeDTgVEVnPGKgDIo+XzCA5BUr/9HO+gWvza0sJGuWzRmjXeTtSx7cRYYaRHlEe68213aF6zZc3CfBfl3NGf8qjuSTd/wVUFCHE6ERTo= Date: 24 Feb 2009 19:11:55 -0000 Message-ID: <20090224191155.50801.qmail@simone.iecc.com> From: John Levine To: asrg@irtf.org In-Reply-To: <200902240515.AAA06862@Sparkle.Rodents-Montreal.ORG> Organization: Cc: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:11:39 -0000 >> Do you expect a system where all mail is paid? If not, how do you >> decide what to accept for free? > >Surely the answer to that will be "it's up to the recipient ('s >postmaster)", just as most filtering decisions are now? Actually, I meant in a more technical sense. There's a flood of mail coming at you; how do you decide which ones to accept and which ones to do the postage thing? R's, John From mouse@Sparkle.Rodents-Montreal.ORG Tue Feb 24 11:41:42 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2473A68A6 for ; Tue, 24 Feb 2009 11:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.023 X-Spam-Level: X-Spam-Status: No, score=-8.023 tagged_above=-999 required=5 tests=[AWL=1.965, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7+V6Kp0Ik+Z for ; Tue, 24 Feb 2009 11:41:40 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id 47D873A67A2 for ; Tue, 24 Feb 2009 11:41:40 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA10962; Tue, 24 Feb 2009 14:41:58 -0500 (EST) From: der Mouse Message-Id: <200902241941.OAA10962@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Tue, 24 Feb 2009 14:37:04 -0500 (EST) To: Anti-Spam Research Group - IRTF In-Reply-To: <20090224191155.50801.qmail@simone.iecc.com> References: <20090224191155.50801.qmail@simone.iecc.com> Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:41:42 -0000 >>> [H]ow do you decide what to accept for free? >> Surely the answer to that will be "it's up to the recipient ('s >> postmaster)", just as most filtering decisions are now? > Actually, I meant in a more technical sense. There's a flood of mail > coming at you; how do you decide which ones to accept and which ones > to do the postage thing? That's what I meant too: it'll be "whatever the relevant mail admin decides to implement" - just like today's filtering. Ideally, this will bear at least some relation to what the end user wants, in most cases, but that's no more necessarily so here than it is in today's filtering decisions. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From JMacDonald@e-dialog.com Tue Feb 24 12:38:09 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030493A6874 for ; Tue, 24 Feb 2009 12:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-7i8SVsbjtH for ; Tue, 24 Feb 2009 12:38:08 -0800 (PST) Received: from corp-mail.e-dialog.com (corp-mail.e-dialog.com [64.28.75.202]) by core3.amsl.com (Postfix) with ESMTP id 2A3C33A6841 for ; Tue, 24 Feb 2009 12:38:07 -0800 (PST) Received: from jmac.e-dialog.com ([10.0.30.87]) by corp-mail.e-dialog.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 15:38:24 -0500 Date: Tue, 24 Feb 2009 15:38:24 -0500 From: Jeff Macdonald To: Anti-Spam Research Group - IRTF Message-ID: <20090224203824.GO18915@jmac.e-dialog.com> References: <1912616.101235468842435.JavaMail.franck@franck-martins-macbook-pro.local> <20090224163046.GM9807@gamerz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20090224163046.GM9807@gamerz.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 24 Feb 2009 20:38:24.0676 (UTC) FILETIME=[D6FF8640:01C996BF] Subject: Re: [Asrg] spf2.0 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:38:09 -0000 On Tue, Feb 24, 2009 at 11:30:46AM -0500, Richard Rognlie wrote: >On Tue, Feb 24, 2009 at 08:12:01AM -0800, Steve Atkins wrote: >> >> SenderID is dead. The only group that every liked it was Microsoft / >> Hotmail, and even they don't publish it. Any records you see are >> mostly just fossil relics of an earlier era. > >And one SenderID/SPF issue that you *will* run into is that... > >The Sender ID spec tells you that if you see a v=spf1 record, you should >treat it as though it were spf2.0/mfrom,pra when, in fact, if *should* >be treated as though it were spf2.0/mfrom. any assumption of "pra" is >not necessarily a valid read of the sending domains wishes. that is why we use spf2.0/pra records for our clients (in addition to v=spf1 records). So I think as long as MS abuses v=spf1 records, SenderID lives.... -- Jeff Macdonald jmacdonald@e-dialog.com From johnl@iecc.com Tue Feb 24 14:24:23 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199453A6862 for ; Tue, 24 Feb 2009 14:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S-H27I10NWJ for ; Tue, 24 Feb 2009 14:24:22 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id E9B833A6867 for ; Tue, 24 Feb 2009 14:24:21 -0800 (PST) Received: (qmail 79201 invoked from network); 24 Feb 2009 22:24:40 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 24 Feb 2009 22:24:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:subject:message-id:mime-version:content-type:user-agent:cleverness; s=k0902; i=johnl@user.iecc.com; bh=UsJuMj+r5Q2QjQLojujqBN3Xh0+SJ4ns4p/tVKQEsyM=; b=nbQlpAyTR1K5/nzvFIU2RlMrd/303F1PDrfP17MbVYZCAU3J4pAl3bqOXMvZuX3yB7tsYqPmyIFMngFjtCa/JUM//cLWqUBOKqKioa/wrvrWP1g9KplmaLNLYADq1OYbXTondEDva5FRx70hf6uR2GO52etLZhDHmqa23OI7j3I= Date: Tue, 24 Feb 2009 22:24:39 +0000 (GMT) From: "John R. Levine" To: Anti Spam Research Group Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [Asrg] ASRG list test X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:24:23 -0000 Please ignore this content-free message sent only to debug some mail problems. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From hjp-asrg@hjp.at Wed Feb 25 15:15:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 571C23A6B9C for ; Wed, 25 Feb 2009 15:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGzY+P5b9r7E for ; Wed, 25 Feb 2009 15:15:52 -0800 (PST) Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id 0DCBA3A6AE6 for ; Wed, 25 Feb 2009 15:15:50 -0800 (PST) Received: by zeno.hjp.at (Postfix, from userid 1000) id 6927B92AB; Thu, 26 Feb 2009 00:16:09 +0100 (CET) Date: Thu, 26 Feb 2009 00:16:09 +0100 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20090225231609.GA10639@hjp.at> References: <20090216171738.GE94816@verdi> <20090216212251.24646.qmail@simone.iecc.com> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> <20090222115318.GA28773@hjp.at> <49A23B2E.2000402@billmail.scconsult.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <49A23B2E.2000402@billmail.scconsult.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:15:53 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-02-23 00:59:10 -0500, Bill Cole wrote: > Peter J. Holzer wrote, On 2/22/09 6:53 AM: > >On 2009-02-21 19:07:09 -0500, Bill Cole wrote: > >>Steve Atkins wrote, On 2/20/09 7:26 PM: > >>>On Feb 20, 2009, at 3:25 PM, Bill Cole wrote: > >>[Quoting John Leslie] > >>>>> The bottom line is, redeeming a million tokens per second is practi= cal > >>>>>with processing delay not much greater than network latency. (This w= as > >>>>>not true ten years ago...) > >>>>I think I'd quibble with details on that, but they really are not all= =20 > >>>>that > >>>>important. > >>I guess maybe one detail is... > >> > >>If the processing delay for every redemption attempt is of the same ord= er=20 > >>of magnitude as irreducible network latencies, i.e. tens to hundreds of= =20 > >>milliseconds, handling a million one-use token redemption attempts per= =20 > >>second is absolutely hopeless. > > > >I think John meant "processing delay" as seen from the client. So this > >includes a) the time to send the request (tens to hundreds of > >milliseconds), b) the time it takes the server to process the request > >(sub-milliseconds?) and c) the time for the response to get back to the > >client (again tens to hundreds of milliseconds).=20 > > > >The number of requests a server can process per second is mostly > >determined by b). The communication delays only increase the number of > >open but idle connections (which may also be a problem). >=20 > Just in case anyone misconstrues your use of the term "connections": >=20 > Using one TCP connection per transaction for a system that needs to=20 > complete a million transactions per second across the Internet would be a= =20 > ridiculous design flaw. >=20 > I therefore assume that you mean "connection" in a more generic sense, I was generally deliberately vague, but in this paragraph I actually meant a TCP connection. I assume that many requests can be sent over the same TCP connection (just as you can send many emails over a TCP connection using SMTP, and many HTTP/1.1 requests can be sent over a TCP connection). But many clients won't need to do that. For an MX for a small personal domain it simply makes no sense to keep permanent TCP connections to all banks, just because it might need to redeem a token some time in the next hours. It would close the connection after a single request unless it needs to redeem another token within a very short time. For such single-request connections the minimum time is determined by the RTT. > and=20 > indeed that was the core of my argument: if the server has to retain stat= e=20 > on transactions for typical Internet RTT's It doesn't, except at the TCP level - naturally, the kernel needs to keep state for all open TCP connections. But the redeeming agent doesn't nee > for a common class of=20 > transaction, concurrency is likely to become a problem in and of itself. >=20 > >So if checking a single token takes 1 millisecond (rather conservative, > >IMHO), one server can check roughly 1000 tokens per second, so a server > >farm of 1000 servers can check 1 million tokens per second. That doesn't > >seem "absolutely hopeless" to me. It's certainly technically possible, > >although I'm sceptical whether it's economically feasible. >=20 > Your hand waves so elegantly when forming the phrase "server farm of 1000= =20 > servers." ;-) >=20 > I believe that dividing the workload between multiple front-end machines= =20 > will either create unworkable latencies in the back end to assure that al= l=20 > of the front ends see a coherent state database for tokens or else will= =20 > create vulnerabilities that will allow any significant botnet operator to= =20 > effectively eliminate chunks of the system at will. Hand-waving a 1000-no= de=20 > server farm doesn't persuade me that I'm wrong. >=20 >=20 > >>>>I'm pretty sure that I'm not the best systems analyst/designer on thi= s=20 > >>>>list. > >>>>I certainly hope I'm not the best one to have thought about e-postage= =2E=20 > >>>>I'd > >>>>be happy to learn from a master how it is in fact possible to make an= =20 > >>>>ideally simplified minimal system like this work as a starting point= =20 > >>>>for how to assemble a more complex system that has more elements of= =20 > >>>>reality in it. I think (but may be wrong!) that it isn't possible to= =20 > >>>>design a system that will be theoretically capable of correctly=20 > >>>>handling a million redemption requests per second of which ~90% are= =20 > >>>>the result of someone working to break the system. > >>> > >>>It's fun to consider, though. > >>> > >>>Using your numbers - one million redemption requests a second of which= =20 > >>>at least 90% are invalid, leads to 100,000 outstanding valid requests= =20 > >>>per second, which would give around 250 billion outstanding stamps at= =20 > >>>any one time, if we expire them after a month (expiring would likely= =20 > >>>involve voiding the unused stamps and issuing new ones in the same=20 > >>>amount, but that's a business issue, and doesn't affect the redemption= =20 > >>>requirements). > > > >I expect most tokens would be redeemed pretty soon, so you won't have > >to keep them around for a month, at least not for real-time checking. >=20 > Someone who thinks e-postage is workable I don't think e-postage is workable. AFAICS an early adopter has no advantages, but a lot of disadvantages. Therefore, e-postage won't happen in the SMTP world. > should make a real specification=20 > that defines "pretty soon" in concrete terms that would support an actual= =20 > protocol design that expires tokens. As a purely academic exercise, here's a sketch of a protocol and a server implementation. If anybody wants to run with it, feel free: Protocol: Based on TCP. Simple request/response structure, Server and Client can close the close the connection at any time. A token consists of two parts, the first is a domain name, the second is opaque. The server for redeeming a given token can be found via a SRV lookup. Requests: redeem token account the token is redeemed and the value is transferred to account. responses: redeemed (+ value) unknown token (possible reasons: forged or mangled token, token has already been redeemed, ...) temporary error (possibly with an estimate when a retry might make sense) mint account amount =09 Create a new token with given value and deduct the amount from the account. (This needs some kind of authentication, of course) There may be a variant which creates $n tokens at once. response new token insufficent funds account doesn't exist or client doesn't have access temporary error Implementation of redemption server: Keep all valid tokens in memory. Multithreaded to take advantage of multi-core systems (but almost certainly not 1 thread per connection - because there will be lots (hundreds of thousands?) simultaneous TCP connections). When a redemption request is received, the look up the token in memory. If it isn't there, send an "unknown token" reply. Otherwise attempt to lock the token. If this fails, send a "temporary error" reply to the client. Otherwise write a "this token has been disabled, transfer $value $currency to $account" record to a journal, invalidate the token in memory and unlock it, and finally send a "redeemed" response to the=20 client. I think current PC hardware can easily handle several tenthousand requests per second. I'm less sure about the number of concurrent TCP connections and connection requests a modern OS can handle. Redemption Client: If the client (=3DSMTP server) needs to redeem a token, it extracts the host name and does a SRV lookup to find the server. If it already has a TCP connection to that server, use that, otherwise open a new connection. A temporary failure can be passed on to the SMTP client. Minting: Each server only mints tokens which it will redeem itself - this eliminates the need to distribute knowledge about the tokens, but may create an uneven load. Load balancing is left as an exercise for the reader. > > If the > >redemption fails, the client can simply buy another stamp and send the > >message again. Delivery of that particular message was now twice as > >expensive as that of an average message, but if that only happens > >infrequently it doesn't matter. If it does happen frequently for a > >particular bank, the affected client(s) will probably be reconfigured to > >prefer tokens from other banks.=20 >=20 > There's not any strong reason for such a problem to be bank-specific. It= =20 > could just as easily be tied to where the redemption attempt is coming fr= om. If client C has a problem communicating with bank B1, but not with bank B2, it doesn't matter whether it is the fault of B1 or of C. C will prefer to use B2. > >So if your 50k clients try to redeem the same token at the same time, > >one of these 50k requests will be the first to be processed by the > >server. The server marks the token as redeemed and sends a positive > >reply to the client. The other 49999 requests will be denied. If > >(because of network congestion caused by the 50k nearly simultaneous > >requests) the reply never reaches the "lucky" client, the token will be > >lost.=20 > > > >Sending 50k requests with the same token is garantueed to yield at most > >one positive reply in this case. It isn't viable for someone who wants > >to send many messages, but it may be a viable DoS attack. >=20 > Botnet spammers have a history of attacking anti-spam systems. Any mailin= g=20 > tactic capable of crippling an e-postage system, even temporarily, will b= e=20 > tried. Of course. But there is no system which is immune to DoS attacks, and I think DoS attacks and double-spending are sufficiently different problems that they should be considered separately. > >>2. If the stamp is left as unredeemed while waiting for the client ack = of=20 > >>success, stamp "reuse" becomes a question of how many redemption=20 > >>decisions can be made per client RTT. > >> > >>The server may have to defer many thousands of clients for scores of=20 > >>milliseconds while waiting for one to send an ack. > > > >Yes, but it only needs to defer those clients which sent a request with > >the same token. It can process lots of other tokens in the meantime.=20 >=20 > If designed correctly, that might be the case. What is that design again? See above for a few ideas. I won't do a more detailed specification for two reasons: 1) As I mentioned above, I don't think e-postage has a market in the SMTP world, so I won't waste time to implement it, and I won't waste time thinking about details of something I don't plan to implement. 2) If I did change my mind and wanted to implement it, I wouldn't post=20 a detailed description to a public mailing list :-). hp --=20 _ | Peter J. Holzer | Openmoko has already embedded |_|_) | Sysadmin WSR | voting system. | | | hjp@hjp.at | Named "If you want it -- write it" __/ | http://www.hjp.at/ | -- Ilja O. on community@lists.openmoko.org --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJpdE5fZ+RkG8quy0RApRnAJ0SCN1dp5X8BXkWMDqnbn4slOkzGQCeNAPu FKGGQrN1B5AkphH0pDtfyS0= =7Tuj -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From davidnicol@gmail.com Thu Feb 26 17:48:53 2009 Return-Path: X-Original-To: asrg@core3.amsl.com Delivered-To: asrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE69E28C224 for ; Thu, 26 Feb 2009 17:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k69zIdSxdhl9 for ; Thu, 26 Feb 2009 17:48:53 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 0209F28C217 for ; Thu, 26 Feb 2009 17:48:52 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so849661wfd.7 for ; Thu, 26 Feb 2009 17:49:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iHdEHV1ho+361whwkWB9QCBN56fEnGMZ/WiScCmEUmg=; b=JPBlLrLzVYb9my83oobHL4rLKbMagei71qer5dOHJg0CqgTB8a09nTtZFAcVwbeu6g wAxHQKJNz4CD2oDv/6eMRd5Sl18X8zQUUNc8byfXBXZAV90JVTUQKYbtiYJXI7nTzt17 UEH24dmZ7c8T12bG/iIN1CBLdvjxpCElZe5h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=W9A6V5KAdMlXat7daXrtZ8b4Tz6QD5YW++nOZ+EO1Z4yGzgH7WsmD0MmdK+3HqJ8+b HlxMmYogFp5honAchKEyRkk6tytaUF+4JBJzwKeOMQOpHvOYKgOIn35WGFviQYRX9Fg7 5a17H+mrHFUSgV+dlJKtQ6OJ3+21wUGUP6DKA= MIME-Version: 1.0 Received: by 10.142.126.6 with SMTP id y6mr978962wfc.52.1235699355091; Thu, 26 Feb 2009 17:49:15 -0800 (PST) In-Reply-To: <20090225231609.GA10639@hjp.at> References: <20090216171738.GE94816@verdi> <20090218225916.GF94816@verdi> <499DDF4F.8010305@billmail.scconsult.com> <20090220015352.GB65762@verdi> <499F3BD1.3020707@billmail.scconsult.com> <456675FC-BA4F-414B-BB22-03264553D7D5@blighty.com> <49A0972D.2030103@billmail.scconsult.com> <20090222115318.GA28773@hjp.at> <49A23B2E.2000402@billmail.scconsult.com> <20090225231609.GA10639@hjp.at> Date: Thu, 26 Feb 2009 19:49:14 -0600 Message-ID: <934f64a20902261749tbe02a01q242eba2db958400a@mail.gmail.com> From: David Nicol To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Asrg] About that e-postage draft [POSTAGE] X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:48:53 -0000 On Wed, Feb 25, 2009 at 5:16 PM, Peter J. Holzer wrote: > > 2) If I did change my mind and wanted to implement it, I wouldn't post > =C2=A0 a detailed description to a public mailing list :-). yeah, that's had me discarding drafts a lot of late ;) --=20 The vents emit burning methane thought to be of metamorphic origin, which in ancient times were landmarks that sailors could navigate by, and which today the custodian uses to brew tea.