The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / cud / cud1024.txt < prev next >

Wrap

Text File | 2003-06-11 | 43.5 KB | 845 lines

Computer underground Digest Sun Apr 19, 1998 Volume 10 : Issue 24 ISSN 1004-042X Editor: Jim Thomas (cudigest@sun.soci.niu.edu) News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu) Archivist: Brendan Kehoe Shadow Master: Stanton McCandlish Shadow-Archivists: Dan Carosone / Paul Southworth Ralph Sims / Jyrki Kuoppala Ian Dickinson Field Agent Extraordinaire: David Smith Cu Digest Homepage: http://www.soci.niu.edu/~cudigest CONTENTS, #10.24 (Sun, Apr 19, 1998) File 1--proposal of technical solutions to spam problem File 2--Cu Digest Header Info (unchanged since 13 April, 1998) CuD ADMINISTRATIVE, EDITORIAL, AND SUBSCRIPTION INFORMATION ApPEARS IN THE CONCLUDING FILE AT THE END OF EACH ISSUE. --------------------------------------------------------------------- Date: Tue, 31 Mar 98 21:35:02 -0800 From: "Vladimir Z. Nuri" <vznuri@netcom.com> Subject: File 1--proposal of technical solutions to spam problem This essay is archived under the "cybernetics" section at www8.pair.com/mnajtiv/ see bottom for other links SRN, Self Regulated Network a proposal of technical solutions to the spam problem * intro * what is spam? * history of spam * is spam worsening? * the software problem * economic approaches * identification systems * proposal for a self-regulating network (SRN) * observations on example informal SRNs * the connected SRN complaint system * node statistics databases * complaint types * analysis of the mail SRN in operation * other approaches * economics of databases and servers * free speech, privacy, censorship * conclusion intro This paper examines the internet "spam" problem and seeks to find technical solutions. By technical I am referring to solutions that do not require social conventions, legislative, or litigatory approaches. It is an open problem as to whether a technical solution exists, however I consider the following to outline many excellent possibilities that haven't been seriously explored (and I wouldn't agree that a technical solution does not exist until variations on the following have been exhausted). I have been using the internet since 1989 and have subscribed to many mailing lists and newsgroups. IMHO the spam problem has become progressively worse and I see no reason why this downward spiral will not continue without proactive action by concerned users. In the past I have advocated some ideas only to meet various degrees of resistance and hostility. Maybe the current climate will prove to be more amenable to a rational discussion of these crucial issues (or perhaps the opposite). The good news is that many technical solutions may be available to minimize the problem. I suspect all easy, localized approaches toward solutions may have been exhausted by now. I believe a collaborative solution is necessary. Personally, I believe that spam legislation has the potential to actually mar the internet. Even if a law existed, enforcement may be impossible, or draconian. IMHO legislative solutions should be avoided at all costs. It could lead to another new government bureacracy that fails to fulfill its function, not because of ineptitude, but because of a fundamental impossibility. what is spam? It is difficult to define "spam". If a definition precise enough to be specified in computer code was possible, the problem would probably not exist, as users could simply run some kind of automated filter to delete it. Is it "unsolicited commercial email"? This is one definition that seems clear and reasonable. But it is subject to similar ambiguity. Suppose I post to a newsgroup and request information on "fly fishing". I receive a few helpful replies. However, I continue to receive replies several months later, from fly fishing companies, long after I am interested in the subject. When did the email become spam? Another situation may occur in which I receive lots of "unsolicited commercial email", but then suddenly receive an offer that I find extremely valuable. Would I have wished it to be rejected by a filter? The definition of spam that I will use in this paper will tend to adhere to two basic ideas around which an automated system can be developed: * spam is email that leads to subjective complaints * spam is email that fits certain objective statistical properties history of spam Unfortunately spam is a problem that has existed long before cyberspace, which the particular economic dynamics of cyberspace has exacerbated. Spam has existed with postal mail and telephone calls. In the case of postal mail, at least a cost is involved in the distribution that may make it economically unviable in a variety of situations. The phone is similar, although automated systems that could deliver messages unattended changed the picture somewhat. The low cost of sending a message in cyberspace means spam is much more economically viable on the internet. (The "true" cost of email is subject to debate, but it seems clear that cyberspace message transmission is inherently inexpensive-- it is much of its reason for existence.) If someone could come up with an elegant solution to spam in cyberspace, there is reason to suppose that it might be implemented in these other realms as well. Fame, glory, and perhaps riches await whoever can pull it off. Unfortunately it seems to tend to require collaborative solutions, something that is eminently feasible and ubiquitious in cyberspace but difficult to initiate due to a characteristic independent attitude of internet users. I believe there is a bias among internet designers and programmers that virtually all problems can be solved locally, and that the nagging persistence of spam is a disproof. is spam worsening? Spam appears to exhibit an interesting property. In small networks, apparently social taboo and stigma seems enough to keep people from spamming. However, as network sizes and degrees of anonymity seem to increase, the irresponsibility seems to increase as well. In other words, it's a problem that gets worse as network sizes increase. The spam situation seems to be a serious challenge to the fundamental scalability that the internet supposely embodies. This is often referred to as the "tragedy of the commons" quagmire of social systems, apparently referring to the tendency of farmers to overgraze an area with their livestock to society-as-a-whole's detriment (and even to their own). No studies exist about the percent of spam in small networks relative to large ones, but anecdotal experience of users seems to confirm the basic "the bigger it gets, the greater the proportion of spam" rule. An obvious reason for this is that a small audience does not make spamming useful enough to attract the element that perpetrates it. The internet was started in the mid-1970's as a system that could theoretically survive a nuclear attack by its seamless and invisible means of rerouting messages around failure points in the network. However, an interesting assumption in this configuration is now coming into focus in hindsight. Original designers assumed all "nodes" on the network would function according to specification. They did not consider the possibility that parts of the network might become "infected" in the sense of not behaving according to standard. Let us call this a "rogue site". Herein, a site that specializes in spam will be considered a rogue site. The problem becomes more serious when there is no overseeing policing entity. Some people will point to the beauty of the internet as its freedom from an overseeing agency, but in fact the lack of one may make it unstable in some ways. It is a hacker's paradise. Consider an internet site that does nothing but spam or mount denial-of-service attacks against other sites. There is currently no technical mechanism by which such a rogue site can be officially "removed" from the community. Each site must deal with these kinds of attacks independently. The system as a whole has persisted in spite of this apparent flaw, but this means of dealing with rogue sites seems inherently inelegant. IMHO A good, robust new network system should address the "denial of service" problem at many layers all the way down to lower level protocols. However, IMHO the internet community is wise to be wary (at some times, it seems, almost to the point of paranoia) of centralized controlling entities of the internet. One of the great values of the internet is the way in which it has been able to grow organically with a minimum of overseeing or centralized tracking/intervention. An ideal solution to the spam problem would be completely distributed and not require any "spam agency" or similarly unpalatable invention. The question that arises is, can a community self-police itself? Is there an equivalent of a "community watch" program for cyberspace? I think the answer is "yes" with a lot of ingenuity and will elaborate on this point. One problem of the internet is that increasing bandwidth has tended to disguise and exacerbate the spam problem. If more bandwidth is available, providers can pass increasing amounts of spam messages without it having any major economic cost. A secret of the internet's success is a curve of decreasing bandwidth costs. This means that spam, like all other activities on the net, becomes cheaper and cheaper. Generally in Usenet software, improved efficiency in mechanisms for transferring messages have been pursued instead of approaches for dealing with spam. the software problem Currently the large mass of internet sites use a mail program called Sendmail developed chiefly by Eric Allman. Will all due respect to the author and maintainers, IMHO the program is an embodiment in awkward and monolithic legacy software. It features many extremely arcane syntax rules and inscrutable conventions. Some users take pride in the system but I currently see it as an obstacle to more sophisticated email transfer systems. It has not proven agile and able to deal with new developments and demands. IMHO new email systems with entirely different approaches embodying flexibility and modularity must be developed if the spam problem is to be solved in an elegant way. Ideally market forces could be unleashed to pursue a flexible mail package with good spam solution. One of the deficiencies in sendmail is the inability to reject email based on header information alone. An elegant email delivery system might involve a sort of handshake going on between a receiver and sender in which varying degrees of information (such as digital signatures, passwords, etc.) are exchanged before the receiver agrees to "accept" the message. The current standards do not really support this. This allows the practice of "mailbombing" in which a massive set of email can inundate a mail server. In some cases, mail servers are configured to "drop on the floor" without notification of the sender mail messages that are considered to be possible spam. This seems very extreme-- in a robust system the sender always ought to know at least if the mail is rejected or not being delivered. Many of the limiting aspects of Sendmail are intertwined with the RFC822 standard for exchanging email. IMHO the RFC822 standard is just as venerable and limited as Sendmail. Some of the ideas I am proposing here are equivalent to a enhanced RFC822 standard, which would involve new headers and new mail exchange protocols. Increased functionality has a price, but IMHO in this case it's worth it. economic approaches Some people propose a "user pays" system in which people who sent the email would pay for the cost. But in fact the beauty of cyberspace is the low actual cost associated with merely moving electrons through a wire. IMHO it is unlikely that the true economic cost of sending email is actually larger than what spammers are now paying (typically an internet account). In other words, it is inherently very cheap to move bits around in cyberspace, and even if spammers were being charged the "true amount" that it costs to send huge batches of email, I assume it would only be marginally larger than the cost of their internet account. In fact, decreases in the cost of network transmission (i.e. higher bandwidth for less cost) will tend to make spam even more cost-effective and thereby annoyingly pervasive in time. Another interesting proposal involves microcurrency. In this idea a receiver could implement a charge on email. The sender would have to "enclose" the money required in an email or the email would be rejected. (This is an example where it makes sense to have a protocol that can exchange information, such as the microcurrency, before the message is accepted.) When the respondent might reply to the earlier sender, he could return the microcharge in his own envelope, reimbursing the sender. If he feels the person has wasted his time, he can withhold a return. In this system, email users can put any price on the scarce commodity involved: their attention. I consider this a very attractive approach, but unfortunately current mail protocols do not support this system. Moreover, despite that microcurrency might involve extremely non-costly economic transactions, thereby overcoming the major hurdle of implementing it (resistance to anything costly by users), microcurrency development and integration into internet protocols has been proceeding extremely slowly. It seems likely that spam will continue to persist for a long time before a good universal microcurrency system that is integrated into internet protocols is developed. identification systems One problem associated with mail delivery is the lack of a universal identity verification system on the internet. Such a system need not have any Orwellian implications, it might not do anything except ensure that mail cannot be forged (while still permitting unlimited pseudonymity by anyone on the internet). Complex issues such as cryptographic algorithm patents are involved here. It seems likely that, like microcurrency, such a system will not be implemented in a semi-universal way for some time. In the meantime, the spam problem demands an immediate solution. Once a semi-universal identification system is in place, a good mail standard would easily support it. If the mail server allowed a conversation between source and reciever before the message was actually transmitted, that interaction could easily (and would presumably by design) contain verification information. proposal for a self-regulating network (SRN) The sophisticated technical idea I have been experimenting conceptually with for several years that may solve the spam problem and a host of related problems (such as denial-of-service) is what I call a "self-regulating network" (SRN for short). It is an idea that avoids the deficiencies of the potential approaches suggested above, and was designed very specifically to fit into the current distributed, decentralized nature of the internet. It will tend to require authentication systems to verify identity but they could be password-based. Cryptographic systems may improve the security of the system but hopefully are not entirely necessary. A SRN is a network that does not assume full future connectivity of all nodes. It presumes that some nodes currently within the network may have to be detached at the "discretion" of people running other nodes. The entire entity is seen as a sort of organism in which nodes are analogous to cells, and some cells may be cancerous (i.e. those that participate in acti here, an FCN is a network that has no such formal regulating mechanism (it may have informal mechanisms that for purposes here won't be considered part of the "system"). Indeed, multiple SRN topologies can exist on top of a FCN in the way that virtual networks exist on top of the internet. When I describe the operations of the SRN, it should not be taken to be a proposal for regulating the current internet connectivity. It is a proposal for creating virtual SRNs on top of the internet FCN under the discretion and voluntary cooperation of participants. In particular it will focus on internet providers creating a SRN, a sort of self-policing electronic guild system. observations on example informal SRNs Examples of "informal" SRNs that exist today on the internet are: * individual site administrators routinely filter packets from certain rogue sites * in Usenet, administrators may disconnect rogue sites from the network * mail server administrators may bar messages transferred from unknown sites (or perhaps kick off an existing user) in an attempt to deal with the spam problem The characteristic that virtually all these situations have in common is that they are informal SRNs, and that connectivity is related to informal judgement. The community, in a sense, measures rogue sites by observations of the behavior, blocking, and complaints about these sites. Is there some way to formalize this? The proposal I am focusing on would create a system in which observations, blocking, and complaints are not isolated or passed around informally around a network "out-of-band", but instead considered an inherent part of the network connectivity system and transmitted/shared in standard protocols. The difficulty is that one probably cannot have a centralized complaint registration server. The potential for abuse is high, and scalability, the key requirement of network connectivity, is lacking with this approach. Hence I have been working on a system for a distributed complaint system in which there is no centralized complaint server, but complaints are still recorded in a systematic way. Consider an application of this to mail servers in which people can complain about mail emanating from a site to the originating site. The general idea is that an automated complaint address would exist for each mail originating site, to which receivers can register complaints in machine-readable form. In the current internet, there is a definite "food chain" of providers connecting to "adjacent" providers. Informally, people may sometimes complain to an "upstream provider" if they fail to obtain reasonable results from a complaint to a particular provider. The goal of a SRN is to encode this informal network in a protocol. A major problem with informal, localized "blocking" of sites implemented today is that, inherently, rogue sites are a global problem. If denial-of-service or other kinds of rogue behavior (e.g. spamming) are mounted from a site, that's a problem for all sites, and ideally detection would not have to be inefficiently repeated all over the internet by each site subject to the attack. Arguably, the failure of the existing system to deal with this problem robustly, in a global fashion, is the key to its increasing pervasiveness. Spammers have odds in their favor when thousands of sites do not cooperate in detecting or blocking them. The SRN attempts to support global detection in a fashion resistant to flaws. the connected SRN complaint system The SRN would work as follows. A provider is responsible for archiving complaints sent to itself. A remote site can register a complaint about mail emanating from a site with that site. The site is responsible for the accuracy of its own complaint database and allowing any internet sites to peruse its own complaint database. Also, a site will keep a database of complaints against its "adjacent sites", or sites that feed into it. If a remote site can show evidence that a site failed to record properly a complaint, it can send the complaint to the "upstream provider" and that provider will register the complaint. This process can continue until an upstream provider eventually registers the complaint. One way to handle the "upstream complaint escalation" described above is to have a site give a "receipt" of a complaint. The site that registered this complaint can keep a random number of complaints around to verify they have stayed archived after a given amount of time, "pinging" the old complaints. If a complaint is not registered, the complainee can send the receipt to an upstream site, and the upstream site can verify the receipt is genuine and that the downstream site failed to record the complaint. The complaint databases are accessable to mail delivery servers that could query the complaint database of an originating site or its adjacent neighbors in deciding whether to accept a message from it. A distributed domain-name-server-like system (or member-name-server, MNS) could be created that records whether various sites are currently "accepted" as members in the SRN, suitable for fast lookups. Some kind of system whereby nodes are pushed out of the name database automatically depending on complaints can be implemented. It would be possible to have multiple, competing MNS systems that have different standards with receivers able to customize their choice. One can create a system of multiple layers of SRNs. One layer ensures that all the sites are correctly archiving complaints sent to each other, and sites that do not are kicked out (rogue sites). Another SRN layer on top of this basic layer can kick out spamming users (rogue users on sites). Note that a lower level layer failure will tend to make a higher level impossible. The system cannot succeed unless lower-level layers are stable. Higher-level problems should not be confused with lower-level ones. The SRN protocols should make explicit this layering characteristic. The general idea is that a failure at a high-level layer results in a new action at a lower-level layer. node statistics databases Another very useful invention is a "node statistics database" in which a server keeps track of statistics associated with nodes that it connects to, and keeps it open for queries by other servers. In the case of mail, a providers' server could keep track of statistics such as: * how long a user has been on their system (AGE) * how many messages they have sent (MS) * total number of bytes sent (BS) * total number of different users emailed, or "to: count" (TC), etc. The node statistics database could easily be combined with the complaint database to allow additional information to receiving sites. As many statistics as possible should be archived. Note the above statistics do not require much processing time or disk space to archive. The statistics would tend to exist in layers, with some at the user level, some at the site level, etc. complaint types Note that complaints may be in several categories, and some not currently envisaged. The complaint databases should try to record the different types of complaints rather than the mere presence of complaints. The complaints also refer to different SRN layers; a complaint could be against a user on a site or a site on the network. * email harassment * unsolicited commercial email * spurious complaints * mailbombing * user forgery * provider forgery * denial-of-service * etc. The overall combination of statistics and complaint databases, as well as and Member Name Servers, comprises a sophisticated reputation system for supporting the SRN. analysis of the mail SRN in operation Consider a few basic scenarios, and how the mail SRN (MSRN) handles them. The MSRN would be built on top of a site SRN that ensures sites behave legitimately. 1. A user gets a new internet provider, and begins spamming. The receiving mail servers are all querying his site's database as he attempts to deliver each message. + The originating site may notice that certain statistics suggest the user is spamming (notice no operator intervention is necessary, a completely automated system is possible with the database). Maybe the messages will be archived with an increasing delay in delivery of each one, they will be bounced, the account will be turned off temporarily, etc. + Destination sites may query the database and discover the user has sent mail to a huge number of different addresses in a short amount of time (TC/AGE), that he has sent a lot of messages in a short amount of time (MS/AGE), etc. Presumably these variable threshholds could be easily customized by the receiver to values he considers optimal. + They may reject the message prior to it even being transferred, in such a way that denial-of-service attacks are minimized. + Or, the receiving site is a member of a certain kind of group, which is updated based on all these statistics, and that Member Name Server is queried rapidly to see if the sender is contained, and the mail is rejected if not. + To address the problem of spammers hopping between sites, the sending site could put all users on "probation" in which they can't send more than a certain number or size of messages in a given amount of time when they are first signed up. As their AGE increases, they have more leeway. Such restrictions could hopefully be tailored so that they are never encountered by legitimate users. 2. A rogue site creates a fake statistics database in which bogus statistics are contained, and allows people to spam from the site. + Complaints will accrue to the rogue site. It will either refuse to register them or will throw away complaints. Complainees can escalate the complaint to a higher site using the site SRN that duly either replicates the inability to archive the complaint, or is again rogue, in which case the complaints continue to escalate to a higher level (the complaints escalate until satisfactory response is achieved, i.e. at least an archival of the complaint in some place). + The Member Name Servers (MNS) routinely query the complaint databases and may exclude sites or chains of sites based on too many complaints at upstream providers. 3. User "forges" email address on a message. A good system would not permit forgeries. A system superior to that currently installed would allow email to be submitted only through the provider, and individual users could not create headers on messages. In any case, the complaint system could also support a framework that rejects sites that permit too many forgers. Based on the header of the email message, the mail servers could follow a procedure of finding the earliest verified originating source address in a dialogue with various servers who track mail in statistics databases and register a complaint. If users could arbitarily create their own aliases (see below), the "legitimate" needs for From: line modification would diminish. 4. A bunch of users gang up and try to knock a particular user off of the system under a vendetta. The system could support a verification scheme where someone can make a complaint about a given node only if they were involved in some interaction with that node, i.e. receiving mail from it. So for example an internet provider with the statistics database can verify that a complaint is coming from a party that a user actually sent mail to, and reject spurious complaints (perhaps even complaining about the spurious complaints to that site). Sites can "scroll off" information on old transactions. 5. Internet provider forges header information. The receiving mail servers are postulated to have a lot of logic that can respond dynamically, and query remote sites. Presumably enough information would be available in the headers of messages and intermediate servers such that rogue intermediaries could be detected and the complaint system invoked without human intervention. other approaches A few other approaches deserve mention. Currently a user cannot create his own email addresses arbitrarily. Software could easily support this feature. Site providers probably do not support it due to the potential for abuse. But if outgoing email always had an effective "complaint address" irrespective of its originator, site administrators may not have a problem if the abuses can be taken care of automatically. Consider this scenario: a user posts to Usenet under a self-created email address. He keep this alias open for about 2 weeks after his post, and after he is no longer interested, closes that alias. Or, if he finds an alias is receiving too much spam, he could close it off. As long as the complaint address on the posted message is accurate (to which spam can't be sent to), this practice is not susceptible to abuse. If the user begins to spam under an alias, the complaints will accrue. Different providers may handle the alias situation in various ways. Some may permit anonymity, others pseudonymity (in which outsiders can link an alias to an existing account), etc. Note however that an automated complaint system can still support anonymity. Also, consider a system in which messages are not stored on a destination site, only requests. A sender puts a request in the receiver's mail queue, storing the message on the sender's site. The receiver looks at the header (which may include the subject line, or whatever) and decides arbitrarily whether or not to fetch the message. Also, systems which store mail, wait some period of time, and forward it only if the originating site stays "clean" of complaints or inciminating statistics, otherwise bouncing or deleting it, are possible. A system of "round robin moderation" used in Usenet may be useful for aspects of the SRN, like a sort of rotating Neighborhood Watch program. Another possibility is user configurable blocking options. Servers could compile statistics about sites blocked by individual users. However, this approach may have the "redundancy" flaw in that spam sites have to be repeatedly identified by diverse users. economics of databases and servers Hopefully all the mechanisms described above are economically self-sufficient, and users (either end users or internet providers) would pay for the value-added services. The current internet supports a Domain Name Server system without serious economic problems (although it is currently subject to some controversy over its administration). Hence similar Member Name Servers could probably be created without scaling or architecture problems. In some ways they would be similar to the web search engines that continually query sites to update their searchable databases. Hopefully internet providers will see the statistics databases and complaint databases as useful cost-saving automations of services that they already have to perform anyway in currently time-consuming human interactions. Internet providers already presumably do not wish to deal with rogue sites, and the system might be a more automated means of identifying and unplugging them. Upstream sites are motivated to keep accurate statistics on downstream sites, and downstream sites are motivated to keep accurate statistics so they aren't unplugged by upstream ones. Also, note that users that require the most database processing time are likely to be spammers and are likely to be kicked off the system. There may be economic incentives such that user demand can be leveraged into building it. I.e. certain providers who make the development investment (time, code, meetings, etc.) might advertise as being part of the "spam free network" and charge a small premium. A provider may even find "spamfree" service not only covers the cost of overhead, but is lucrative in the face of high demand. In some cases, the data that is used for an SRN is already available and being archived. For example, most sites already log information about past mail transactions, just not in a way that is accessable to some kind of protocol or query. Also, informal databases of spammer IP addresses are available. As noted, the informal approach of "complaint escalations" to upstream providers is already considered a basic aspect of Internet culture. This SRN proposal in many ways merely suggests ways of rearranging and formalizing procedures and protocols that are already in place. Obviously, all of the above will require more processing time and storage than the current system. IMHO I don't see this as a liability, because the current system is proving to be increasingly dysfunctional at larger scales, and cycles and disk space are in relative abundance. Moreover, the processing time currently associated with mail is negligible. There's a lot of room for additional processing while still perserving the near-instantaneous-transmission of email. Delays of a few seconds are certainly tolerable if the new system really provides improved "signal-to-noise" features it is designed to support. The above ideas vary significantly in terms of difficulty of implementation; some can be readily implemented in existing software (such as local statistics tracking), others would require significant additional independent development efforts. (The system does not require every feature be implemented simultaneously to provide benefits.) I do not expect any to be implemented quickly; my experience suggests that people will tend to resist modifying internet software or cooperate to create and implement new software and approaches to deal with what is now regarded chiefly as a "social problem", doing so only when all other alternatives have been exhausted. Current mail and Usenet programs currently have very strong degrees of inertia due to their widespread use, justifiably so. Changes should not be considered lightly. But on the other hand, I think their current architecture is revealing itself increasingly at times to be a "weak reed to stand on". Billions of email messages are transmitted over the Internet with increasingly important contents, and I wonder if the informality of current systems continues to be appropriate or the best that can be achieved. free speech, privacy, censorship Issues of free speech, privacy, and censorship, barely resolved in the government arena, are probably the reason for the dramatic angst that typically accompanies any proposal for modification of a communication or identification system, particularly related to the internet, which contains a very politically active and charged community. Hopefully users will not see the statistics databases as Orwellian. Statistics such as total bytes sent, total number of addresses sent to (not the particular addresses themselves) etc. do not seem at all like privacy violations. This proposal is offered with the idea that nothing in it interferes with free speech or privacy. The right of free speech does not apply to anyone who wishes to be heard against the preferences of a particular audience. However, a SRN system could be manipulated to negative ends. The design I have arrived at has been specifically, painstakingly sculpted and crafted to be resistant to "single points of failure" or individual tyrannies. However, there are always certain hypothetical pathological situations in which virtually any technology would fail. This system does not seek to solve all problems, but instead only to be more appealing to users than the current system is. That is, it can only be fairly judged against the existing system and not some hypothetical, possibly impossible idealization. conclusion The SRN system creates a sort of Caller ID mechanism by which recipients of mail have more flexibility in rejecting messages according to their own criteria, and invents a dynamic network connectivity based on potentially "rogue" sites. It will be opposed by spammers but I hope the larger internet community can see it as enhancing, and organize and cooperate enough to implement it or something similar. The system as proposed has been designed with the current idiosyncracies of the internet in mind. It does not require significant new technologies such as microcurrency, universal identification, etc. although those could be integrated within it with positive results. It is a highly distributed system that might scale better than even existing technologies. It may become more necessary if the current system continues to scale poorly relative to spam. The system permits a sort of global information system on rogue users. Instead of every victim independently, inefficiently attempting to deal with the same problem, the system collects complaints, and ideally users could leverage off of each other's knowledge about rogue users. Ideally the SRN system described above would not be overly difficult to implement, and if done so, would significantly change the dynamics of the mail network to make spam far less viable. Obviously the overall system will fail if there are too many rogue sites that behave in pernicious ways (one can ask the question whether anything would function in such a scenario), but the expectation is that if the majority of sites are not corrupt, the SRN will be effectively self-policing in a dynamic, proactive, and responsive manner. I propose these ideas only because I suspect they have the potential to ultimately save time and effort after setup costs have been overcome. If aspects of the SRN prove in practice to be too complex, they should be discarded. However, some internet providers, especially large ones, have found that spam prevention is a costly, time-consuming, and attention-intensive process. No study exists about the actual magnitude of the expense, but possibly even a complex system could be superior. If the network eventually became free of spam, administrators might be tempted to turn off the SRN features. However, to my mind this would be like taking down a dike because the water is contained. The SRN is analogous to an immune system that must be engaged and active to prevent infections. If effective, by its intentionally general-purpose design, the SRN may be useful for areas other than mail such as Usenet, or perhaps in the best case, if proven to the satisfaction of the overall internet community, even low-level internet connectivity, maybe eliminating most denial-of-service attacks. See also: Usenet2 - new spamfree form of Usenet www.usenet2.org Qmail - new replacement for sendmail by Dan Bernstein www.qmail.org CAUCE - Coalition against unsolicited commercial email www.cauce.org Boycott SPAM - software, rogue site lists, etc. spam.abuse.net/spam ------------------------------ Date: Thu, 7 May 1997 22:51:01 CST From: CuD Moderators <cudigest@sun.soci.niu.edu> Subject: File 2--Cu Digest Header Info (unchanged since 13 April, 1998) Cu-Digest is a weekly electronic journal/newsletter. Subscriptions are available at no cost electronically. CuD is available as a Usenet newsgroup: comp.society.cu-digest Or, to subscribe, send post with this in the "Subject:: line: SUBSCRIBE CU-DIGEST Send the message to: cu-digest-request@weber.ucsd.edu DO NOT SEND SUBSCRIPTIONS TO THE MODERATORS. The editors may be contacted by voice (815-753-6436), fax (815-753-6302) or U.S. mail at: Jim Thomas, Department of Sociology, NIU, DeKalb, IL 60115, USA. To UNSUB, send a one-line message: UNSUB CU-DIGEST Send it to CU-DIGEST-REQUEST@WEBER.UCSD.EDU (NOTE: The address you unsub must correspond to your From: line) Issues of CuD can also be found in the Usenet comp.society.cu-digest news group; on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of LAWSIG, and DL1 of TELECOM; on GEnie in the PF*NPC RT libraries and in the VIRUS/SECURITY library; from America Online in the PC Telecom forum under "computing newsletters;" On Delphi in the General Discussion database of the Internet SIG; on RIPCO BBS (312) 528-5020 (and via Ripco on internet); CuD is also available via Fidonet File Request from 1:11/70; unlisted nodes and points welcome. In ITALY: ZERO! BBS: +39-11-6507540 UNITED STATES: ftp.etext.org (206.252.8.100) in /pub/CuD/CuD Web-accessible from: http://www.etext.org/CuD/CuD/ ftp.eff.org (192.88.144.4) in /pub/Publications/CuD/ aql.gatech.edu (128.61.10.53) in /pub/eff/cud/ world.std.com in /src/wuarchive/doc/EFF/Publications/CuD/ wuarchive.wustl.edu in /doc/EFF/Publications/CuD/ EUROPE: nic.funet.fi in pub/doc/CuD/CuD/ (Finland) ftp.warwick.ac.uk in pub/cud/ (United Kingdom) The most recent issues of CuD can be obtained from the Cu Digest WWW site at: URL: http://www.soci.niu.edu/~cudigest/ COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing information among computerists and to the presentation and debate of diverse views. CuD material may be reprinted for non-profit as long as the source is cited. Authors hold a presumptive copyright, and they should be contacted for reprint permission. It is assumed that non-personal mail to the moderators may be reprinted unless otherwise specified. Readers are encouraged to submit reasoned articles relating to computer culture and communication. Articles are preferred to short responses. Please avoid quoting previous posts unless absolutely necessary. DISCLAIMER: The views represented herein do not necessarily represent the views of the moderators. Digest contributors assume all responsibility for ensuring that articles submitted do not violate copyright protections. ------------------------------ End of Computer Underground Digest #10.24 ************************************