[Asrg] Spam Ecomomics

"Hannigan, Martin" <hannigan@verisign.com> Thu, 30 December 2004 23:13 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26262 for <asrg-web-archive@ietf.org>; Thu, 30 Dec 2004 18:13:55 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck9ft-0006xf-V4 for asrg-web-archive@ietf.org; Thu, 30 Dec 2004 18:25:46 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck9Qx-0003Fm-2A; Thu, 30 Dec 2004 18:10:19 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck9Nd-0001pz-V1 for asrg@megatron.ietf.org; Thu, 30 Dec 2004 18:06:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25511 for <asrg@ietf.org>; Thu, 30 Dec 2004 18:06:51 -0500 (EST)
Received: from falcon.verisign.com ([216.168.239.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck9Z4-0006of-0x for asrg@ietf.org; Thu, 30 Dec 2004 18:18:42 -0500
Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id iBUN1uop025222 for <asrg@ietf.org>; Thu, 30 Dec 2004 18:01:56 -0500 (EST)
Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <Y05Q5QQY>; Thu, 30 Dec 2004 18:06:17 -0500
Message-ID: <A206819EF47CBE4F84B5CB4A303CEB7A14A46A@dul1wnexmb01.vcorp.ad.vrsn.com>
From: "Hannigan, Martin" <hannigan@verisign.com>
To: "'asrg@ietf.org'" <asrg@ietf.org>
Date: Thu, 30 Dec 2004 18:04:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Subject: [Asrg] Spam Ecomomics
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3


I'm not sure how my thoughts earlier this/last week turned into
"pay per", but let me try one last annoying time to clarify.

End User (Ease of Use)

The end user sees no change in the operation of email services
on the Internet. They do see a chance in the service offering 
where they are now allowed to send and receive X number of emails
per month based on the service plan that they have subscribed to
with their provider.

The Provider (Email)

The provider email operations establishes a real cost based on 
the fractional sampling of settlement(IP)data they use to determine
payables or receivables on their peering contracts. They take this
cost, apply it to their product, and determine what the value of 
email is and apply it in the form of "the cap". 

The Provider (Billing)

A chance to the mail receipt and delivery mechanism must be made in
order to generate an acceptable accounting record so that a fair
determinatioin can be made when a user is in overage, and, what the
amount the user will owe. The mechanism for determination is up to 
the provider i.e. counts in SS7 reachable databases, CA dips, or
whatever mechanism is cost effective for them. 

The Provider (Network)

Provider will have to extrapolate the cost of SMTP traffic vs. other
traffic from their peering data. The cost is then in turn broken out
by customer. In the case of 'always connected' customers, they too are
alloted a specific amount of SMTP b/w and are charged for overage based
on normal usage patterns i.e. 95th percentile, etc. This is doable today.

The Spammer (Inclusive)

The spammer is now just an end user and they too will pay. Since they 
don't spam from their own connections, it has little impact on the,m.

The End User (cost)

End users incurs no additional cost unless they violate their
plan. In the case of "stolen" SMTP traffic, the end user pays
since  they didn't "do the right thing".

Rational: Does anyone mount a dialup line on the outside of their
          home and label it "DIALUP LINE"

          Does anyone leave their cell phone in a bar with a label that
          says "USE ME" on it?

If your kids pickup the phone and start calling 900 numbers, who's fault
is that? The telco? The CLEC? The government?
	

The End Result

Spammers incentive is rapidly decreased. It now becomes a hard job.
This drives up rental costs. This discourages some. The costs rise
as time goes on until the spammers start collapsing and "going out
of business" [ Remember, the spammers are now NOT the originator, 
someone else gets paid to do the spamming ]

Best case, the spammers return to their old methods of using their own
hosts and trying to find places to run them. Fine, but they are paying
or  driving up the ISP's cost and they are charged accordingly. It is
un-profitable.

The spammer dies a painful and noisy death, deprived of the income he was
once enjoying due to reversal of SPAM economics and the SPAM sponsors
(botnet
customers) have little recourse. 

The Big Picture

We can then move on to signing emails, authentication, etc. things that
are very important but because SPAM destroys all hope for the future of 
email, are not taken as a priority by the majority.

SPAM EcoNomIc Model "SPAMEMIM" (Like "Eminem")

  NSP       -- LAYER 4  IMPORTANT
  ISP       -- LAYER 3  
  SPAMMER   -- LAYER 2
  ENDUSER   -- LAYER 1  LESS IMPORTANT

At layer 3 and 4, economic attack. 
At layer 3 and 1, technology attack.

Relationship Matrix

Layer 3 and 4
Layer 3 and 1

There's never a relationship top Layer 2 i.e. noone spends
time on "getting" the spammer, the efforts are focusing on 
fixing the user.



-M<










--
Martin Hannigan                         (c) 617-388-2663
VeriSign, Inc.                          (w) 703-948-7018
Network Engineer IV                       Operations & Infrastructure
hannigan@verisign.com


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg