spam as DOS

[Kent Crispin <kent@songbird.com>]

On Fri, Aug 08, 1997 at 01:38:25PM +0200, Anonymous wrote:
> > > How about if it is an employee of yours, using your computer
> > > equipment, that sent the message, in explict contradition to your
> > > companies stated policy?
> > 
> > Use a retraction server (David's project)
> 
> I wonder if there is a problem of inconsistent levels in this debate...
> 
> At one level, many people on this list are in favour of infrastructure
> such as Usenet and the Web carrying all information without filtering with
> respect to content, to avoid censorship, oppression and so on.
> 
> At another level, almost everybody has personal preferences as to what
> they consider worthwhile information, what they want to read, what they
> want their children/employees to read, and what they want their
> privately-owned hardware to be used to carry.
> 
> At the content-free level, cancels are information just like anything
> else, merely a stream of octets.  By definition, they _can't_ be morally
> wrong at that amoral level where we talk only about whether
> store-and-forward works properly or not.  Cancels, "forged" or otherwise
> are just a tool, just bytes.
> 
> Within a particular value system, you might agree or disagree with a
> particular cancel, or with the idea in general.  It's easy to configure a
> news server or reader to conform to your preferences, just people who hate
> spam are free to ignore it.  At this level, you can make judgements as to
> which uses of that tool are justifiable.  (Cancels by sysadmins,
> anti-spammers, spammers, system owners, governments, parents, copyright
> lawyers or nobody at all.)

Very good point.

The problem exists at both levels, however.  At the "content-free" 
level the equivalent of spam is a flooding denial of service attack.  

But thinking about it at the "content free" level puts the issues in a
much better focus, for me.  You can note the following:

	1) at a "content-free" level filters, by definition simply
	don't work.  [They don't really work for spam, either, of 
	course.] 

	2) the issue is fundamentally bandwidth consumption [with spam
	the bandwidth is human attention bandwidth]

	3) it's a damn hard problem, and no good solution exists

	4) there is an analog to e-postage in QOS routing, but the
	problem of flooding is still not solved.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html