Tony and Steve, et al,
TH> In context, it is clearly the right of a mail server operator to refuse
TH> mail. My concern is more about the precedent where a large ISP decides
TH> that address ranges have particular application semantics.
...
TH> The IETF needs to recognize that the ISPs don't really have a good
TH> alternative, and work on providing one.
and
SMB> Yes. Normally, I'd worry a lot about backwards compatibility. In this
SMB> case, I think the problems for ISPs -- and users -- are so severe that
SMB> people will switch *rapidly* to a new protocol if it solved most of the
SMB> spam problem.
Most of this thread is really about legal and customer service issues.
I do not see how it is an IETF topic, no matter how much each of us
might (and do) feel strongly about it.
However I'll join the ranks of those heartily supporting your
conclusion about the absence of good alternatives...
However there is a catch:
With respect to spam, and many other content-related activities,
what does it mean to provide a good alternative?
To answer this means we need to understand the problem very well
and understand the technical underpinnings of the problem very
well.
It is easy to note features that are lacking from email, but dangerous
to assume that adding those features will result in their being adopted
or that their adoption will magically fix the problem at hand.
Worse is that, by and large, spam is a topic for which reasoned
discussion -- and especially careful analysis -- is so far proving
impossible in an open forum. Between the formal fuzziness of the topic,
the strong emotion it engenders, and the compulsive self-interest of
many constituencies, the reality is fragmented, heated exchanges, rather
than anything really productive.
Here are some realities that I think we must juggle:
1. We do not understand the full range of email (ie, electronic
mediated human exchanges) very well at all;
2. An installed base of 100 million users should be expected to adopt
changes very, very slowly
3. Each change will have large, unintended consequences, most of which
will be undesirable. (This statement is an absolute cliché in serious
discussions about organizational and social change.)
Note that the definition of spam largely depends upon the person making
the definition; unless and until we can develop of reasonably simple
definition that has a) broad acceptance, and b) a largely technical
basis, then it is pure folly for the IETF to think it can do anything
major in this arena. It might be useful for us to standardize some relatively
straight tools, like a client/filter-server exchange protocol, but we
are not going to achieve really strategic improvements.
I should also note that the last two years have seen at least two
efforts to consider a replacement email service -- or at least an
alternative one -- but that neither seems to have achieved a critical
mass of interest.
And before anyone claims that spam will be the flag around which
Email(ng) troops will rally, I'll ask what changes anyone thinks are
required. As soon as anyone tries to answer that, everyone else should
watch the style of responses they get...
(if you want to save time, just look at the discussion of spam on the
ietf over the last few days. has it been analytic? has it been systemic?
has it been productive? -- except for the thread that Tony just started,
of course.)
d/
--
Dave Crocker <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>