Re: The right to refuse, was: Re: Principles of Spam-abatement

On Sun, 14 Mar 2004, Yakov Shafranovich wrote:

> In any case, it seems IMHO that there exists a percentage of ISPs that 
> either ignore or mishandle abuse reports. On the other hand there exists 
> a percentage of ISPs that respond to abuse reports in a timely fashion. 
> We seem to be in disagreement as to what those percentages are, but it 
> seems to me that we all agree that both types of ISPs are present on the 
> Internet today.
>
> Given that, should the IETF pursue development of standards to make 
> abuse reporting easier to facilitate the work of those ISPs that 
> actually do handle abuse reports properly? This is an example of 
> something that we have been asking at the ASRG 
> (http://asrg.sp.am/subgroups/abuse_reports.shtml). It is something 
> within the scope of the IETF's charter, can possibly be useful for 
> reducing spam by making it cheaper for some ISPs to handle abuse 
> reports, and is not something that claims to solve the entire spam 
> problem as a silver bullet. But clearly it is only a technical tool that 
> facilitates the human solution to spam - handling abusers. The key 
> question is whether the benefits provided by such standards justify the 
> cost of implementing and developing them. This is of course something we 
> can and probably should argue about.
>
> This is one of the many examples of things that the IETF can do that do 
> not solve the overall problem, but are very well within the IETF's 
> charter to make standards and can help with some aspects of the spam 
> problem. Of course, we can argue about how much impact it will make vs. 
> the cost of the solution, but that's something we should be doing anyway 
> as part of sketching out such solutions in order to evaluate them properly.
This is I think a very sane and appropriately limited thing for the IETF
to tackle.  As you note, it won't solve the spam problem, but then,
nothing will as long as it is marginally profitable except possibly
legislation and vigorous enforcement.  Paper advertising junk mail
(which costs roughly $1/piece or even more yet fills my mailbox daily)
indicates that we aren't likely to be able to prevent spam by
manipulating the profit margin side.  Legislation is being advanced and
test cases are appearing for existing legislation that might help, but
spam is international and in some cases virus driven and hence difficult
for real police to deal with.  Filtering abates the problem for many if
not most of us, and filtering doesn't require any action from the IETF
but filter-based solutions are a constant war and a constant cost and
bringing additional pressure to bear further upstream would be lovely if
it were workable.

I think that any sort of upstream attack on spam has to have several
features to be successful:

  a) It has to have a uniform standard and basis.  I think (if I
understand Dean's earlier responses correctly) that having a uniform
standard for taking various actions would provide valuable legal cover
for SP-level enforcement while protecting them from antitrust
accusations and the like.  This the IETF can help with; indeed, there is
nobody else that can, because although IETF recommendations and
standards have no force in law they ARE the engineering basis for the
internet and hence might be a bit more powerful than mere law in this
particular context.

  b) It has to have buy-in from the SPs that will do the actual
enforcement on the basis of standardized reports.

  c) Which in turn means that it has to be economical for them to
enforce rather than ignore.

  d) Which requires tools that permit them to manage the work with a
minimal investment in their time and resources and maximal automation.

  e) And very likely will require clearly spelled out SANCTIONS to be
applied in the event that they refuse to enforce anyway.

You'll have to draw a clear map of the road.  You'll have to pave the
road, put wheels on the cart, grease the axles, and show the donkey the
map.  You'll have to offer the donkey a carrot, and be prepared to beat
the donkey with a stick and even make a drum out of its skin if it
doesn't mosey down the road.  And the donkey still might not move.

This is the essence of Jeff Race's proposal (mentioned several times
over the last few days) and seems like a very reasonable starting point
for what you are proposing that the IETF do.  Vernon suggested (IIRC)
that similar proposals had been considered before, but hit the wall with
SPs unwilling to invest the resources required for enforcement.

I'm pretty skeptical.  Vernon and Dean together have a good argument
that doing nothing is preferrable to doing nearly anything that has been
proposed so far in this discussion and that in time the problem may
(like so many internet problems) prove to be fundamentally self-limiting
even if "we" (the IETF) sit on our hands the entire time.  Vernon has
also pointed out in fairly acid tones that talk is cheap -- what is
needed are specifications and software -- people doing actual
constructive work on real tools where the "protocols" required (if any)
are developed right along with the tools.  At this point there is lots
of energy going into good filters, little energy going into SP-level
tools for automated detection and enforcment.

I completely agree. 

SP enforcement is rare because enforcement is expensive, enforcement is
expensive because it requires human energy expended by smart people and
SPs have other uses for its often (very!)  limited supply of expensive,
technically smart humans.  Besides, they often make money from spammers
by turning a blind eye to them and accepting their money just like
everybody else's although they might be willing to give up the latter
pittance if that were the only issue as most SP admins probably hate
spam as much as you or I; they just don't have the time to deal with it.

Software COULD automate part of this process and reduce the cost to the
SPs, especially in the work burden required from skilled techs.  Write
software that a trained monkey could operate to identify spam/virus spew
from INSIDE an SP's network even before it is reported from outside and
that makes pulling the plug on the source a fully automated and
ritualized process (especially one that could be marketed as a FEATURE
of the SP -- both companies and individuals would, I suspect, actually
love it if their SP would "immediately" identify and isolate a virus
problem or other abuse of their resources) and you might get the
economics of enforcement to be less unfavorable.

Rules for reporting and so forth are good but without the tools AND the
will, SPs will continue to loudly ignore calls for them to enforce AUPs
and claim that they "can't" track down viruses and spammers originating
from within their boundaries. Which from their point of view is true --
in their own minds at least they can't afford the cost of doing so and
remain profitable.  Enforcement will always cost something, but the more
it costs the bigger the barrier.  Get the barrier down and sanctions of
almost any sort might then tip the balance; "sell" the notion of it
being a service or feature that SELLS the SP to the customer and it
might not even need sanctions to be adopted in some cases.

So who's going to write this needed software, and what will they write?
He asks, loudly not volunteering...(for good reason -- too far from my
area of expertise and I've already got a goodly set of projects along
with my day job ;-)

    rgb

-- 
Robert G. Brown                        http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     
email:rgb(_at_)phy(_dot_)duke(_dot_)edu