ietf-mxcomp
[Top] [All Lists]

Re: Choice of SMTP headers

2004-03-24 10:03:55

Alan,


AD> Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
AD>   I can think of a number of new protocols deployed at the edge, and
AD> in wide use, in significantly less than 3 years.
AD>   Napster, for one:  http://grammy.aol.com/features/0130_naptimeline.html

ok. central registration and a centralized query service. initially a
single implementation.

yes, those do facilitate rapid deployment.

IETF work is typically about multiple implementations of services that
are truly distributed. Certainly email falls into that category, as do
changes to it.


The end-user carries the ultimate burden imposed by SPF.  Only the
end-user can possibly know the variety of access venues they will have.
And many require registration.

AD>   The end user is already carrying the burden of dealing with spam.

Both true and irrelevant.

You claimed that SPF imposes no user burden. The truth of that statement
does not hinge on whether other things impose a burden.


AD> The only question then, is: Is the additional burden of
AD> RMX acceptable?  I believe the answer is "yes".

That question is entirely different from claiming there is no user
visible impact.


AD>   If the cost of spam email becomes too high, many users will simply
AD> give up.  Many users are *already* giving up on email.  I simply don't
AD> believe that giving up on email is a better choice than using RMX.

Again: we all know spam is a problem.  Constantly citing its seriousness
does nothing to further the technical discussion.

Characterizing adoption of an RMX scheme, versus giving up on email as
the only two choices is simply wrong.  There are more choices than that.


AD>   Exactly.  People who think the cost of registration or SUBMIT is
AD> unacceptable can publish 0/0 records, and change none of their other
AD> behaviour in an RMX-aware world.
AD>   Once again, it's their choice.  RMX allows them to make that
AD> choice.  I don't see this as a problem.

Once again, a scheme that requires disabling the scheme, to support
significant, valid scenarios, is a very problematic scheme.


First, I listed 3 problems and you responded to one.
AD>   I'm not perfect, and I don't have all the answers.

damn.  please stop destroying my illusions...


Second, I was citing end-user impacts. Submit has very low adoption
so far, it involves quite a bit of end-user visibility to change
that.

AD>   So... we can work on end-user visibility.  People don't use SUBMIT
AD> because there's no reason to: They just run an SMTP client
AD> themselves.  RMX gives people incentive to use SUBMIT.

Perhaps.  But you claimed all of this was not user visible.  Changing to
Submit is user visible.


AD>   It's a little odd to push back on deploying RMX because SUBMIT isn't
AD> widely deployed.

It is a little odd to claim something is not user visible when in fact
it is highly user visible.


AD>  The deployment of the two protocols can feed off
AD> each other.

Adoption plans that have dependencies on other adoption plans take much
longer and often fail.


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


<Prev in Thread] Current Thread [Next in Thread>