ietf
[Top] [All Lists]

Re: The utilitiy of IP is at stake here

2003-05-29 11:51:50
I tend to agree with Dave Crocker, getting 100+ millions users
to upgrade to SMTPng is not going to be any easier
than getting them to move to IPv6... It will also suffer from
the second design syndrome. I will not fool myself and believe
it can happen overnight....
... although, due to the volume of spam, there is little choice but doing it.

For this effort to be effective, I think it will have to be done
in a way that is at odds with the traditional IETF thinking:

1) Compatibility with SMTP is not desirable
   ==> if not, spam will be forward compatible!

2) Some form of privacy is not desirable
   ==> You cannot define Spam but you know this is spam when you see one.
           As you cannot put any reliable filters in place,  your only
solution is the legal route. For this to work, you want to be able
           to trace exactly who was sending the mail.

3) To much scalability is not desirable
==> There is (almost) no direct cost per mail, but a lot of indirect costs.
           This may actually very well be the root cause of the problem.
There is relatively little spam in regular snail mail or telephone,
           not only because of legislative regulations, but also
           because it cost money per message. This regulate the flow.
           One cannot sent millions of mail/phone calls for just $20...
Another way of saying this is that SMTP is a victim of the IETF credo,
           the protocol scales too well.


    - Alain.







Dave Crocker wrote:

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(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>