Having thoroughly overdosed on fireworks, and trying to focus on the
substantial issues, and being surprised how many there are...
Perhaps the most basic issue is that the specification
is standardized syntax, without any standardized
semantics.
The specification says that each MTA can do whatever it
feels like with the message.
How can we possibly expect any sort of Internet-wide useful service out of
this?
This may well be true. But getting such an outcome is not a requirement for
IETF standards work, your opinions to the contrary notwithstanding.
I apologize for misunderstanding the examples you were citing. Worse, I am
astonished to hear that Internet mail has been functioning with a mechanism
-- even a non-standard one -- that would permit me to specify increased
handling priority.
The Internet is a very big place. I suspect that there are all sorts of
mechanisms in wide use in email and other protocols that all of us
participating in this discussion are unaware of. I know I find out about
various things that have deployed without my knowledge on a regular basis, and
I suspect my job connects me with a wide range of operational situations far
more than yours does.
The fact of that ignorance prompts me to suggest that the reason we do not
have a track record of abuse for this feature is because the general
population of users does not know about it. I am, of course, stating that
explanation vastly more tentatively than I believe it.
First, I think the term "general population" is largely meaningless when
talking about the Internet.
> One more time: Past experience directly contradicts this (IMO overly
> simplistic) assessment.
Alas, I wish that this were simplistic or, at least, just a matter of my
own opinion. And since it has been 25 years since I made a habit or
reading the relevant research literature, I can't counter your disbelief
with a mass of citation. Somehow I suspect that assuring you the citations
are there won't be convincing either...
Just for fun, I did a single sample query of a Cognitive Psych PhD and they
could not quite believe that anyone would assert that this sort of
mechanism (zero cost to the requester) would not be abused.
It surely is tempting to dig into the generally dismal track record of
predictions made by such "experts", but in this case it would be unfair to do
so because your query grossly misrepresented the situation. Nobody is saying
that the cost will be zero. Indeed, in my previous response I argued that in
one case exactly the opposite is true -- the cost to spammers is effectively
quite high.
And that was only one, and far from the only, example. Here's another: I cannot
speak to other implementations of priority mechanisms in MTAs, but the ones
I've done have various theshholds and therefore costs associated with them.
I'm not going to bother responding to the remainder of this section since
it all proceeds from the incorrect assumption that priority has no cost
associated with it.
III. TRANSPORT PRIORITY AS SMTP OPTION
> However, this discussion does lead me to conclude that priority is best
> done as an SMTP extension.
Given that the goal is transport handling I entirely agree.
(In case it has been looking as if I am against having any mechanism, let
me try to be clear that I think having one is essential. The rest of the
communications world has priority mechanisms, so we need them in email
too. Business use demands it. My concern is that we specify something
that will work.)
And to be equally clear, I am neither for nor against having such a mechanism.
But additionally, I have no desire to force what is being proposed here into
something that tries to meet from the outset what you believe the requirements
of business to be.
> > Do you really expect that relaying across the
> > open Internet will require use of SMTP Auth? In which century?
> Nobody said anything about requiring it for relaying across the open Internet.
> Using it as means of facilitating the use of extensions like priority
> is another matter.
This is getting confusing. You don't like my use of the word "require" yet
you accept that use of Auth for "facilitating" a priority extension.
No, what I'm saying is that one possible basis for transfer of priority
indicators is the SMTP AUTH parameter. This doesn't mean end users would
have to use SMTP AUTH (although in fact it is fairly widely deployed). Nor
does such usage require a network-wide authentication scheme. The credentials
passed around by SMTP AUTH may be derived from a service level arrangement,
not from the end-user's creditentials.
If the priority extension is to be seriously useful -- and for Internet
mail to satisfy business requirements, it does need to be -- you claim that
the Auth mechanism will enable, facilitate or otherwise be relevant to
creating that utility, then I claim it will need to be Internet-wide.
You are conflating end-user use of authentication with relay use of the AUTH
parameter. The two can be intertwined or disjoint. And even when they are
intertwined it doesn't mean that different administrative domains have to share
or cross-validate all their end-user's authentication credentials.
(Can you only send FedEx to places with which you have made a prior
arrangement?
Actually, yes. You can only send FedEx to places where they have service.
Bi-lateral agreements are a good way to start, but they don't
scale, of course.)
Hierarchical ones do.
My point, therefore, is that wide-scale, inter-organization use of security
has been essentially non-existent for anything except SSL, and then only
for privacy, not authentication. That makes it highly problematic to
specify a facility that relies on inter-group authentication. (The current
proposal does not do that; but your argument seems to rely on it.)
And this is entirely irrelevant since even if priority came to depend on SMTP
AUTH (which I don't claim will necessarily be the outcome) that would not in
turn require sharing of all authentication credentials.
> Well, one of the things that happens all the time is private bilateral
> agreements between service providers to provide improved QoS
In fact, bilateral agreements are the essence of the public international
phone service and have always been the essence of the public, commercial
Internet. No ISP is ever forced to peer with another. And peering is a
bilateral action.
In other words, bilateral agreements between service providers have scaled
sufficiently well to get us the Interent we have today. Doesn't this
argue that bilateral agreements about transfer of simple labels will
scale as well? Such an agreement would be FAR simpler than an existing
peering arrangement.
But your point is, of course, about TAILORING the service on a bilateral
basis. And it's just fine that a) it happens, and b) the terms are kept
private.
However, note that we still do not have a way to specify QoS at the lower
layers and that all efforts to provide that capability over the last 30
years have failed.
And what makes you think that exactly the same thing won't happen here if we
turn a simple priority label into a full-featured QoS scheme with tightly
specified semantics?
I believe that a less nailed down mechanism is potentially quite useful as a
tool that MTA implementors and service providers can use to build various
services. It is NOT a service in and of itself, and if you succeed in turning
it into one at the outset I predict you will find that it will either fail to
match up to what customers want, what service providers can provide, or what
enough MTAs can implement to actually deploy.
Tools first. Then services. Priority labelling is a tool that could prove
useful in providing an SMTP QoS service. But we need to have it specified and
play around with it before we'll ever be able to define the service. (And while
I've used past ad-hoc forays into this area in arguing that various dire
predictions are far from certain outcomes, I'll be the first to admit that
there's a world of difference between a standardized, fine-grained, SMTP-level
facility and nonstandard, coarse-grained, header-level facilities.)
And it should be understood that such tools in and of themselves aren't going
to make your business users happy. But given the number of so-called
"business-quality" email services springing up out there I will be very
surprised if they don't take any tool we provide and run with it. They
certainly have done so with DELIVERBY.
Divide and conquer, Dave. Divide and conquer.
Ned