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.
Please name them.
Napster, for one: http://grammy.aol.com/features/0130_naptimeline.html
It took a little over a year from the first version of software, to
having millions of people using it.
Other P2P protocols have similar deployment timescales.
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.
The end user is already carrying the burden of dealing with spam. I
don't see how any method of removing that burden from the user can be
cost-free. The only question then, is: Is the additional burden of
RMX acceptable? I believe the answer is "yes".
AD> That is, SPF allows end-users to register MTA's. It doesn't
AD> "require" that registration.
Right. And end-users are not "required" to send email.
Exactly. It's a choice. Choices often have costs.
If the cost of spam email becomes too high, many users will simply
give up. Many users are *already* giving up on email. I simply don't
believe that giving up on email is a better choice than using RMX.
[ 0/0 ]
That disables the protection mechanism, which is exactly what I hope no
one wants for a mobile user (or anyone else).
Exactly. People who think the cost of registration or SUBMIT is
unacceptable can publish 0/0 records, and change none of their other
behaviour in an RMX-aware world.
Once again, it's their choice. RMX allows them to make that
choice. I don't see this as a problem.
First, I listed 3 problems and you responded to one.
I'm not perfect, and I don't have all the answers.
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.
So... we can work on end-user visibility. People don't use SUBMIT
because there's no reason to: They just run an SMTP client
themselves. RMX gives people incentive to use SUBMIT.
It's a little odd to push back on deploying RMX because SUBMIT isn't
widely deployed. The deployment of the two protocols can feed off
each other. To me, that sounds like another reason to use RMX: It
will encourage people to use SUBMIT.
AD> And the alternative is worse. Do we really intend to permit
AD> end-users to use a domains name without the consent of the domain
AD> owner?
This is the stage of discussion that seems to occur quite predictably in
anti-spam discussions.
And we've been having this discussion for nearly a year now. I
still haven't gotten an answer to that question from anyone opposing
the deployment of RMX. Maybe the question is too controversial, but I
see it as one of the main sources of disagreement between the pro &
con camps.
RMX allows people to make choices, however bad (e.g. 0/0). People
who disagree with RMX don't want to permit others to use RMX. That
is, they're removing others ability to freely choose.
These are then denied or dismissed and ultimately things devolve
into a reference to the lack of any real choice in the matter,
because spam is serious and we must do something.
I have never demanded that anyone implement or deploy RMX (despite
Vernons claims to the contrary). Rather, I'm opposed to the people
who are opposed to others deploying RMX. The double negative seems a
bit much, but it's an accurate statement of my position.
If some people believe that deploying RMX will solve their spam
problem, or make them better in bed, I really couldn't care less. If
their deployment of RMX causes problems when I try to communicate with
them, I can either consent to their conditions for communication, or I
can stop talking to them.
To me, that's really what this argument is about. While discussion
of deployment costs is nice, those costs matter only to the people who
are deploying RMX, or interacting with people who deploy RMX. For
everyone else, it just doesn't matter. The real argument is that (so
far as I can tell), the people opposing RMX don't want to change their
behaviour in an RMX world. So rather than not communicating with
people implementing RMX, they try to prevent those people from
implementing RMX.
See, neither of our opinions about costs matter in the long run. If
people administering systems decide that RMX is benefical and has
sufficiently low cost, they're going to deploy it no matter what we
think of the costs.
I'd like to give them that choice. I don't see why that's a problem.
We are all here because we seek to get useful spam control mechanisms
created and deployed. However, this purpose is not severed if we create
mechanisms that have onerous impact on legitimate uses and/or high
administrative overhead.
More onerous than giving up on email entirely? That's the world
we're headed to. If you disagree, I'll point my MX at you.
And the only reason I'm supporting RMX is that there's nothing
better out there. RMX isn't perfect, but it stops one kind of spam.
This is not a panicked attempt to cobble together a "solution" to
the spam problem. It's a reasoned method to attack one part of the
spam problem, where people can choose to implement the protocol if
they believe the costs are managable
AD> RMX (SPF and variants) are about choice: permitting people to
AD> cooperatively and consensually communicate.
This is a bit like saying that current airport security mechanisms are
about choice. You can, after all, choose not to fly.
Exactly. It's an ugly world, but that's the reality. If you don't
like it, you can try to change the security requirements by talking to
your government...
In contrast, the arguments against RMX are like someone trying to
prevent airlines from implementing security, because they believe that
the security measures are too expensive for everyone else, even though
they have no intention of flying themselves...
Alan DeKok.