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@xxxxxxxxxxxx