textfiles/magazines/CUD/cud1024.txt

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
************************************