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>