Re: [Asrg] Too Big to Block?
John Leslie <john@jlc.net> Thu, 09 July 2009 15:27 UTC
Return-Path: <john@jlc.net>
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 A8D743A6B66 for <asrg@core3.amsl.com>; Thu, 9 Jul 2009 08:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.324
X-Spam-Level:
X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 gwAXk2ftDfiV for <asrg@core3.amsl.com>; Thu, 9 Jul 2009 08:27:01 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 755253A684E for <asrg@irtf.org>; Thu, 9 Jul 2009 08:27:01 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 7FC6033C67; Thu, 9 Jul 2009 11:27:17 -0400 (EDT)
Date: Thu, 09 Jul 2009 11:27:17 -0400
From: John Leslie <john@jlc.net>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <20090709152717.GO15652@verdi>
References: <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <20090708141747.GA2822@gsp.org> <20090708155704.GN15652@verdi> <20090709120305.GC26436@gsp.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20090709120305.GC26436@gsp.org>
User-Agent: Mutt/1.4.1i
Subject: Re: [Asrg] Too Big to Block?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 15:27:03 -0000
Rich Kulawiec <rsk@gsp.org> wrote: > On Wed, Jul 08, 2009 at 11:57:04AM -0400, John Leslie wrote: > >> The introduction of reputation services creates options for getting >> the attention of the folks who maintain the MTAs of the large email >> services. > > We already have blacklists, Blacklists are, at most, one-bit reputiation services (which nobody would pay "two-bits" for). When I say "reputation service," I mean something with customers that pay for or otherwise subsidize the service. > which when appropriately used, do that without the need for more > elaborate mechanisms. Services naturally evolve, or to use your word, become more elaborate. > The trick is in the word "appropriate", which has little to do with the > criteria used for listing and a lot to do with who uses them and how. Which is why I ask for a "customer" relationship between service and users. >> If we insist on a world without reputation services (or ePostage), >> Rich is correct that only "large" email receivers will be able to >> make a dent in the practices of "large" email senders. > > Epostage is dead-on-arrival for a number of reasons, including "a > hundred million zombies". The reports of its death are highly exaggerated. A hundred million zombies aren't enough to guess strong password encryption (least of all one-time-pad encryption). And the mere fact of trying puts it into a different criminal classification than spamming. Presenting fraudulent ePostage tokens is, well, fraud. Blacklisting an MTA (zombied or otherwise) "during the investigation of fraud" is an unassailable practice. ("It's not _my_ fault that investigation is taking six months!") Making ePostage work is clearly possible in an environment of short token lifetime, encryption of paths it travels, and sufficient logging of failure-to-redeem to support (automated) investigations of fraud. > And any "reputation services", no matter how elaborately constructed, > will not make any difference unless they're used "appropriately", in > the same way that blacklists are/could be. "Appropriate" is in the eye of the beholder -- in this case the persons running the service, who will have customer agreements to limit "inappropriate" use. > In other words: we do not need any new mechanisms. Maybe you don't, but many of us do. > We do not need reputation services, or vouching services, Vouching services are needed to solve scaling problems. They also provide a "reporting" mechanism that can work -- where recipients report abuse to their reputation service, which accumulates enough to justify restrictive actions, and offers to summarize abuse reports to vouching services under contract terms. > or any of the other interesting ideas that have been put forth. We > need to use the mechanisms we already have, and have had for some time. We do use them (or at least the subset individual MTA operators trust, which amounts to pretty much all of them being used for some traffic). > The days when we could expect network and system administrators to > care about the abuse emanating from their operations because it was > clearly their highest responsibility and ethical obligation have been > gone for a long time. Expecting large corporations to "care about" such things is irrational. > (Some still do, of course -- and good for them.) _Many_ individuals running smaller ISPs do care! > The priority now is profit, profit, profit, and thus it is necessary > to speak to them in a language they understand. Aha! You do see the beauty of ePostage... > (That is: we need to revoke some of their privileges and thus provide > them motivation to do what they're not doing.) This has been tried. The result nearly always is that they assign "help-desk-personnel" to explain to their customers that the small ISP is failing to follow the "clearly-explained procedures" laid out on their web page; and that the problem needs to be solved by the small ISP. (Granted, they do "care" about the cost of those help-desk-personnal, but that cost can be controlled by ensuring that customers _never_ get anything more useful than that spiel and increasing the time-on-hold to even get that.) > We've spent the last 15 years sidestepping that, and we're still doing so. We've spent the last 15 years posturing why ePostage can't work and why none of the reputation services are worth the money their customers are (already) paying them. > What it comes down to, no matter what the mechanism, is "are you willing > to refuse privileges to X even though there may be consequences from > your own user community?". That's a balancing act. Small ISPs are willing do deal with "some" amount of consequences. > If "yes", and if there are a sufficient number of others who feel the > same, then it may be possible to affect X's behavior. Unfortunately, in the US at least, it's nearly impossible to reach a "sufficent" percentage without enlisting the cable/telco providers, all of which suffer the "care-less" characteristics of corporations. > If "no", then there's no reason for X to expend the time and money > required to address the issue. Alas, there _is_ one reason -- we'll go out of business if we don't. > And in the case of some egregious spam sources (e.g. Hotmail), the > answer given by many of us is "no" because they're TBTB: the outcry > from local users would be too great. Consider Hotmail: they have _many_ users who direct-marketers would love to reach, and would be happy to pay some ePostage amount to reach -- perhaps as much as ten cents per missive. Now suppose there were a critical-mass of ePostage banks: would Hotmail refuse to take the money? Now suppose that a few of us started asking Hotmail for one-cent ePostage to accept their email during a heavy-Hotmail-spamming period: is it worth it for them to refuse? (They're already running all the software needed to do it; they already have the ePostage account set up; the account is accumulating payments far greater that the "nuisance" amount we're asking; and they have no help-desk-personnel trained to explain why paying out 1% of the ePostage they receive would bankrupt them. > I'm certain Hotmail is well aware of this. They know full well they're > spewing, and they know equally well that they can get away with it. > I'm equally certain they're not the only ones who've made this > calculation. They're certainly not. Are we willing to consider how to tilt the "almighty-dollar" balance to encourage a better behavior? -- John Leslie <john@jlc.net>
- [Asrg] request for review for a non FUSSP proposal Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Paul Russell
- Re: [Asrg] request for review for a non FUSSP pro… Steve Atkins
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Lyndon Nerenberg
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Douglas Otis
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Douglas Otis
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… John Levine
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- [Asrg] VPNs (was: request for review for a non FU… Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] VPNs (was: request for review for a no… Claudio Telmon
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Danny Angus
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] VPNs vs consent Rich Kulawiec
- Re: [Asrg] VPNs (was: request for review for a no… Rich Kulawiec
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Rich Kulawiec
- Re: [Asrg] VPNs Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- [Asrg] Shared addresses (was: Re: VPNs vs consent) Claudio Telmon
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Alessandro Vesely
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs der Mouse
- [Asrg] A Vouch By Feedback proposal (was: VPNs) Alessandro Vesely
- Re: [Asrg] VPNs Daniel Feenberg
- [Asrg] gmail as source of spam (was VPN) David Wilson
- Re: [Asrg] A Vouch By Feedback proposal J.D. Falk
- Re: [Asrg] A Vouch By Feedback proposal Alessandro Vesely
- Re: [Asrg] A Vouch By Feedback proposal Claudio Telmon
- Re: [Asrg] A Vouch By Feedback proposal der Mouse
- Re: [Asrg] VPNs Rich Kulawiec
- Re: [Asrg] VPNs Bill Cole
- [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? Chris Lewis
- Re: [Asrg] Too Big to Block? Dotzero
- Re: [Asrg] Too Big to Block? Chris Lewis
- Re: [Asrg] A Vouch By Feedback proposal Ian Eiloart
- Re: [Asrg] Too Big to Block? Ian Eiloart
- Re: [Asrg] A Vouch By Feedback proposal Rich Kulawiec
- Re: [Asrg] Too Big to Block? Rich Kulawiec
- Re: [Asrg] A Vouch By Feedback proposal Ian Eiloart
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? Alessandro Vesely
- Re: [Asrg] Too Big to Block? der Mouse
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? der Mouse
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] EPOSTAGE Too Big to Block? John Levine
- Re: [Asrg] EPOSTAGE Too Big to Block? John Leslie
- [Asrg] archives Tom Petch
- Re: [Asrg] archives Bill Cole
- Re: [Asrg] archives Claudio Telmon
- Re: [Asrg] archives Tom Petch