Copy Link
Add to Bookmark
Report
Computer Undergroud Digest Vol. 10 Issue 24
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
************************************
