ietf-mxcomp
[Top] [All Lists]

Re: Choice of SMTP headers

2004-03-25 08:51:14

Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
requiring a central server is not an 'edge' deployment.

  <sigh> So I guess I'm mistaken in believing that millions of people
used a new protocol on their computers, at the network edge, in less
than a year.

  That was the whole point of the discussion.  RMX et. al. may require
changes at the edge.  You claimed nothing was deployed in less than
3-5 years.  I gave a factual example which countered your assertion.
But you now claim my example doesn't demonstrate what I think because
of the existence of a central server.  I fail to see how that's
relevant.

  Deploying a new protocol to millions of end-users in less than a
year is possible.  It's been done lots of times.  All that's required
is sufficient incentive for the end user, and a lack of participation
by the IETF.

  I think that's where I'm making my biggest mistake.

AD>   It's not "disabling" the scheme.  It's working within the scheme to
AD> acheive backwards compatibility with end-users who don't want to
AD> change their behaviour.

For the users with the problem, it renders the scheme useless, except
for creating hassles.

  I just don't understand.  The people publishing 0/0 records have
already decided not to use the scheme.  The only reason they're
publishing 0/0 records is to interact with people who ARE using the
scheme.  That makes it useless for the sender, but they've already
decided to not use it, so there's no problem.

  The only question then is what do the recipients think of people
publishing 0/0 records.  They have a few choices:

  a) whitelist domains they like, in which case RMX is not applicable
  b) use another scheme for verifying user identities, in which case
     RMX is not applicable
  c) blindly accept the messages from 0/0 domains.
  d) Notice 0/0, and treat them with suspicion.

  So (a) and (b) allow people to interact in an RMX world without ever
using RMX.

  In (c), the scheme doesn't help the recipient, as spammers will also
be publishing 0/0 records.

  So... it might make sense to require that the protocol design allow
for (d), and the recipient will have more information than they have
now.

  Rather than giving up on an idea because of flaws, it's more
productive to see if we can use the flaws to come up with an improved
design.  If the design ends up too complicated, we can toss it, and
start over.

  Alan DeKok.


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