Alan,
AD> Which new services have achieved widespread deployment in less than
AD> 3-5 years? What properties do they have?
None that I know of.
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.
In any event, this working group is not about a new service. It is
about changing an existing one.
It requires end-users to pre-register the MTAs that they will use.
AD> SPF says nothing about end-users registering MTA's.
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> It talks about
AD> domains listing MTA's in DNS. The two statements are very, very,
AD> different.
Actually, no they aren't. This is one of the serious impacts that MTA
registration schemes tend to carry and discussion tends to miss, for the
reason I cite above.
AD> And if end-users wish to use an MTA not listed in DNS for a domain,
AD> they can talk to the domain owner.
That is the same as saying that the end-user carries the burden. This
is about end-user impact, not the act of text editing domain records.
AD> That owner can either include
AD> their domain (end-user registration of MTA with the domain), or the
AD> owner can tell them to use one of umpteen existing protocols to send
AD> mail through a system controlled by the domain owner.
As I said. This is visible to users.
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.
AD> A domain can publish a record saying
AD> "permitted from 0/0", which means no registration is required for
AD> anyone.
That disables the protection mechanism, which is exactly what I hope no
one wants for a mobile user (or anyone else).
Otherwise, it breaks third-party MUA usage, and quite a bit of mailing
list usage, and otherwise-legitimate mobility scenarios.
AD> I guess that means SUBMIT isn't part of the solution.
First, I listed 3 problems and you responded to one. 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> 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. Some assertions are made. Some concerns and
clarifications are raised. 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.
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.
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.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>