ietf
[Top] [All Lists]

Re: Apology Re: Principles of Spam-abatement

2004-03-15 10:33:43
Nathaniel,

NB> What this suggests to me is that until the larger society -- i.e. the
NB> courts and international institutions -- reach a determination of the 
NB> "right" paradigm for dealing with spam, the IETF is going to spin its 
NB> wheels on these issues.

Not necessarily.

As long as we debate the larger issues of spam, yes, we will probably
spin our wheels.

However as you note, there are smaller, user opportunities that do not
require gaining consensus on higher-level concepts or needs.

The recent burst of activity to produce some level of authentication is
an example.  Depending upon the particular mechanism chosen,
authentication mechanisms can be an "inherent" good, independent of
spam. That is, it generally raises the quality/utility of email.  Spam
therefore is a motivator to do something we should do anyhow.

Efforts to protect against compromised machines would be another
example, although perhaps not one the IETF can do much about.


NB> But most of us recognize that spam needs to be attacked on several
NB> fronts.  We can and should focus IETF efforts on getting as many 
NB> not-overly-controversial approaches to spam control to work together

Exactly.

If we view spam as a cluster of behaviors, rather than a single
phenomenon, then there also are some spamming behaviors against which we can
readily gain sufficient, general consensus.  This sort of narrow focus
on particular genres of spam takes careful management of the discussion
process, but might well lead to our taking useful steps.

The one danger -- which I believe is unfortunately demonstrated often in
spam discussions -- is that the narrow focus will fail to consider
larger implications of proposed changes.

A favorite current example is the extent to which an apparently useful
protection effectively destroys a number of reasonable and useful user mobility 
scenarios.


NB> but also, I suspect, a whole lot of other things (e.g., standardized
NB> headers to let challenge/response work better with mailing lists, 
NB> protocols for sharing data for collaborative spam filtering, 
NB> standardized SMTP extensions for cryptographic challenge/response 
NB> (which this morning's BBC broadcast described as a new Microsoft 
NB> invention!), and perhaps even improved tracing/accountability tools for 
NB> law enforcement.)

right.

NB> Anyway, in closing I apologize to the entire IETF community for taking 
NB> so long to realize that some of my technical arguments have been 
NB> founded upon basic philosophical assumptions which are not universally 
NB> shared.

This is in such marked contrast with the usual IETF discussions that
involve technical discussions founded on clear, compelling engineering
directives with which no reasonable person could argue...

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>