On Wed, 17 Mar 2004, Eric A. Hall wrote: > A better analogy is with new checking accounts. Many places won't accept > checks numbered below 1000, since they indicate that the account has not > established a track record. Other places will accept the checks after > verification, other places will accept them with thumbprint or some other > identifier. In all these cases, the organization is able to determine its > risk limits and act accordingly. Which is really pretty silly, right? Since anybody will print you checks that start with any number you like, completely legally. In fact, you can print your own checks with any number(s) you like, completely legally, as long as the bank information at the bottom is there and is correct and you actually own the account in question and don't commit fraud or pass bad checks. This kind of silly response is no obstacle to a criminal or spammer; it is merely an inconvenience (a pain in the ass) to the innocent. It also leaves one with all sorts of catch-22 problems -- one cannot get a "track record" until one is let onto the track, and one cannot get onto the track without a track record. Besides, this is all talking about >>IP numbers<<, right, since we all AGREED that user "identies" were transient artifacts and impossible to regulate. In the checking account metaphor above, on the internet I can print a new check with whatever numbers you like for each and every transaction, and back it up with a shiny new driver's license and any other "identification" tokens you require unless and until you create a huge government bureaucracy to regulate it and harsh laws to punish abuse. Sort of like the ones we have for real driver's licenses and checking accounts and human identities. Banking (and other human metaphors) are not correct for addressing IP number trust. It's more like can you trust the current residents of this neighborhood or that house down the street...when you never get to see them, only their masks. And IF we're talking about IP addresses, we can pretty much stop talking. As Vernon has repeatedly pointed out, "trust"-like facilities at the IP level are either ALREADY THERE and proving to be moderately ineffective against spam or run square against the economics and realities of the SP business. We cannot do anything silly like "not trust" a new IP number assigned by an SP to a new customer "until they have a track record". Trusted has to be the default or the Internet and a variety of business become impossible and incredibly burdensome on the innocent (far more so than spam). But I don't care if you agree -- as you note, you can "not trust" any parts of IP space you choose according to any criterion you select, within your own hosts or networks. Just don't blame anybody else when things stop working because you've punched a hole through a path to a critical service or human. > > Note that this is nothing new. We already do this with IP numbers. > > If you send me a packet with a non-verifiable source IP there > > will be no communication possible. Why should it be different > > with email addresses? > > Verification is different from trust. My position is that you need to be > able to validate and verify before you can successfully apply any kind of > trust (otherwise the trust is meaningless). Paul's message that I replied > to was specifically describing a minimum threshold of trust (it was akin > to the "no checks below #1000" position). You have to be able to quantify "trust" as well, in order to be able to use it as a filtering criterion. I fear that your metaphor is exact -- it is NO more difficult for a spammer to achieve whatever level of "trust" is required for acceptance for long enough to spew than it is for me to ask the bank to start the checks for my brand new checking account at #2000 "since of course some merchants won't take them otherwise". Or going home and printing some new ones. Somebody (Dean?) pointed out that if you can really solve the problem of "trust" at the electronic level, scalably and more or less for zero marginal cost, you're missing the real point. These are the SAME problems that are incredibly difficult to solve in the financial industry where the penalties are large and expensive, laws that severely punish identity theft artists and check forgers are vigorously enforced, and where instruments for reasonably reliably affirming identity (photo drivers' licenses, passports, birth certificates all abound and are tightly constrained by law and expensive government agencies and services. It's hard to trust even paper money, let alone that some stranger is who they assert themselves to be. In that sense it is an excellent milieu to look for metaphors to the network/spam/identity problems, just as paper spam and phone spam are also good places. If you can solve one, you can solve the other IF you are willing to pay similar costs. So next time anyone wants to advance a human-scale metaphor for a trust model, please a) ensure that it actually is relevant and WORKS (check numbering obviously is less than useless); b) discuss the costs. Human identification mechanisms are awesomely expensive and still don't prevent identity theft, forgery, and all sorts of abuse. And they don't apply to IP number trust. Don't get me wrong -- I do think that there is something to be said for focussing on IP numbers (NOT humans) and "trust" (if that's what you want to call blacklisting). I jut think Vernon, and Dean, and Jeff are all correct. The IETF will not fix spam in protocol. Spammers will work around and through any holes left available. SPs leave holes. Until they stop doing so spam will continue. This isn't QUITE an impasse -- but suggestions need to focus on this particular kernel and become concrete and less metaphorical. I think we are all agreed that IF SPs really tried to police their IP spaces the spam problem would be ameliorated to some degree. Even Vernon said as much, and Vernon seems to be both insanely realistic and perhaps a touch, shall we say, cynical? So: A) Let's stop talking about trust models as if they extend to humans. We aren't talking about trusting the "sender" of any message; we are talking about trusting the IP number of the originating host of that message, or alternatively the DNS owner of the subnet blocks where that IP number resides (the SP). B) Trust is going to be the default. This is OK because network addresses have sufficient persistence in time and are sufficiently difficult to change and are hierarchically organized. Besides, the network will rapidly break if trust isn't the default. C) No solution will work until the SPs buy in. D) SPs >>might<< buy in if spam reporting is streamlined, spam reporting is independently tallied, blacklist decisions were made on the basis of an open and clearly defined process and on the basis of publically available data (e.g. the number of spam reports made back to a given subnet in a given time window). Jeff thinks this is a place to start work and I agree. E) We're really talking about all forms of local-origin mail-based network abuse, not just spam. Virus reporting and response is in the same category -- done haphazardly in an expert-friendly fashion (if done at all). As Dean has pointed out, many spam agents are architecturally identical to viruses and sometimes appear to BE viruses, long out of control of their creators and hawking products that no longer exist with links to dead webspaces. I personally think that "trust" is the wrong metaphor for a trusted-default network. D) is the meaty one above. If there is anything that the IETF CAN do to help cut this particular knot, it is to create a relatively simple extension to mail that facilitates reporting mail abuse, and collection of abuse reports by multiple parties for tallying and blacklist decisions. This puts real pressure on the SPs to clean up their nets. I'm not even sure that this pressure would be necessary if spam were reported agressively and in a timely way and with the data required to actually RESOLVE the complaint included IN the complaint (note that Dean, obviously an expert, has to work to extract it from certain bounces -- what hope does an ordinary user have?). Most SP admins I've met or talked to are decent humans and take managing their networks seriously. Give them the tools to police their networks and I think they'd prove responsive. 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