North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Economics of SPAM [Was: Micorsoft's Sender ID Authentication......?]

  • From: Michael.Dillon
  • Date: Mon Jun 13 05:11:49 2005

> You have to manage to lower the reputation
> of that host within a very short amount of time to increase the
> transaction costs sufficiently for the spammer to make the effort
> worthwhile. 

Or you have to ensure that the sending ISP can react quickly
and stop the flow of spam so that only a trickle of messages
actually enters the system

> In all likelyhood it can only be achieved
> by a combination of simple systems/mechanisms each tailored to deal with
> a specific part of the problem.

Here's a simple mechanism which has not yet been tried
seriously. Email server peering. This means that an SMTP
server operator only accepts incoming mail from operators 
with whom they have a bilateral email peering agreement.
Bilateral agreements have been shown to scale quite well
whether you look at BGP peering or the world of business
contracts. In any case, the fundamental need here is that
for somebody to notify the email administrator that is
sending spam and for that administrator to act immediately
to cut the flow.

Today, notifications arrive in a flood that smells a lot
like SPAM itself. They come from millions of unknown and
unvalidated and often confused sources. No email admin can
afford to act without careful investigation first. But if
the notifications only come from email peers who only report
problems that involve the bilateral relationship, i.e. source
of spam flow to destination of spam flow, then the source
email administrator can afford to act immediately without
any investigation. After all, this is all covered in the peering
agreement. The two parties have already agreed to do this,
have already agreed on notification mechanisms and have already
agreed on responsibility (and penalties) for bad notifications.

Because all of this is codified in a set of bilateral email
peering agreements, it becomes easy to incorporate any implications
in the email service level agreements with customers. In other 
words, if an email operator agrees to shut down IP access to
an 0wn3d workstation immediately upon request of their peer, 
then they can put that in the customer contract so that the
customer knows that SMTP is strictly forbidden without prior
arrangement with their operator.

SPAM is not a technical problem and there are no technical
solutions. It is a social problem and the solutions are to
be found in social arrangements like contracts, laws,
email services associations, etc.

A lot of this dubious technical garbage can be swept aside
if we simply recognize that the flat structure of a completely
open SMTP service is not scalable. But if we manage the structure
through agreements and contracts, we can organize the exact same
technology and protocols into a relatively thin hierarchy, no more
than 3 or 4 levels, with a global mesh of bilateral peering agreements
forming the top level. This top level could easily scale to thousands
of members if it is based on a standard bilateral email peering 
agreement that is administered by a consortium of the top level 
peers. In this way, a new operator can join the consortium and 
simultaneously sign the bilateral agreement with all current members.

I envisage the top level of this hierarchy to actually be composed
of several international consortia, probably 5 of them, building on
the work that has been done by the Regional Internet Registries in
building up international cooperation amongst ISPs. I'm not suggesting
that the RIRs would become these email consortia, simply that the
RIRs are proof that ISPs can cooperate on an international level
to manage Internet resources in an orderly fashion. And associated
with the 5 RIRs are 5 regional gatherings of ISPs where this
type of cooperation could be hammered out.

What we really need to get this off the ground is for some of the
large email operators to get together in public at a NANOG meeting
and discuss this openly in some type of round table discussion.
Who will take the first step? Perhaps the NANOG program committee?

--Michael Dillon