At 09:16 PM 9/8/2004 -0400, Andrew Newton wrote:
On Sep 8, 2004, at 8:32 PM, AccuSpam wrote:
Instead I support a single DNS record which can be used by either
proprietary (pra) or free software (mailfrom).
By this, I assume you mean a record that does not describe a scope
(since what I proposed did allow one record to describe both scopes).
Minimally yes.
IMO, the scope should be implicit from the specification.
I will elaborate below.
BTW, I appreciated your proposal to try to build concensus, and I hope you will
consider my reasoning below.
And if so, do you actually think it is better for the receiver to have
to guess the intended scope of the sender?
Yes because inherent in the design of the specification should be acknowledged
the *REALITY* that the sender can not control the receiver (verifier).
Even today without this standard, senders have no control over how their e-mail
is filtered by receivers. IMO, that will never change, because the market will
always decide that receiver has control over his/her Inbox and never give that
control to the sender. Would you give control of your Inbox to your senders?
A robust specification that will stand the test of time (e.g. SMTP) will
acknowledge that it only specifies what the syntax data means, it can not
reasonably specify all the ways that companies will try to "embrace and extend"
to their competitive advantage.
There is fundamental disconnect between what we think/want to happen and what
we can actually insure will happen. I urge people here to think about all the
ways a specification can be "misused" (...for example if only the original
writers of SMTP could have predicted "misuse"...). I do not think we correct
"misuse" by throwing everything we can think of into the specification.
Instead, a wiser approach is to analyze priorities of what is sufficiently
general and germane to the cause so as to both easily accepted into concensus
and also robust to stand the test of time.
For example, since we know that pra and mailfrom can still suffer from forged
From: (as explained in my previous post), i.e. we do not provide a final "end
all" solution, then verifiers are going to be adding value by interpreting the
data provided by the specification (e.g. incorporating when the From and PRA or
MAIL FROM: are different as another data in probability analysis).
I think it would be folly and brittle for us to attempt to specify *ALL* the
ways that the data in the DNS record can be used and interpreted, as the result
set will be numerous and continually changing (improving). We might never
reach concensus (even if get all tthe people here to agree but as you deploy
other needs will be discovered and specification will continually be under
revisement).
Using this same logic, I am against a brittle and complex specification that
attempts to cover too much. If we could start with something simple and core,
such as specifying the approved mail servers for sending from a domain, and
then we can later build new specifications on top of that basic core
specification.
I could ramble on about technical reasons. We need to keep this simple for the
millions of owners of domains, as most senders are not forged and thus have
very little incentive to deploy. Why complicate when we are not even sure what
benefits we will get from the additional complexity? Is it cost effective to
prioritize the needs of a few and pass the cost on to the many?
Instead I support letting others build experimental complexity on top of a core
unencumbered centralized standard, and then let them petition for their
extensions to become part of the standard, but always only if those extensions
can be used by free software also. For example, if Microsoft proposes some
extension to the syntax, then they should justify how that extension can be
used by all software, not just their licensees, else it should not be
incorporated into an endorsed standard. It would be different if Microsoft had
some proven technology that had no other alternative, but that is far from the
case today. In fact, I am arguing that choosing the winning technology from
unproven and incomplete set, is not the role of the standards body. And I
argue that instead standardizing fragmentation is worse (or same as) no
standard at all.
What is wrong with reaching concensus on a DNS record that specifies the
approved mail servers for sending email for a domain, then allow SPF and
SenderID (and others) to go forward as experimental uses of that specification?
Then we have more time to hash out real experience in the market.
Since issues such as SUBMITTER for forwarding are (minimally and I would argue
preferably) not part of the DNS record, then we can proceed with that
resolution as an experiment and debate such orthogonal issues forward.
Also we should try to form orthogonal approach to specification, so that we can
accomplish highest priority goals most efficiently and so that esoteric and/or
experimental features do not encumber the entire internet useage nor encumber
future improvements and experience we will learn.