At 03:54 AM 6/29/2001, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
Would you favor/suggest that this be re-cast as an option for message
The current proposal is for SMTP. The way that a posting user gets to
specify an SMTP option is a human factors issue that outside the scope of
the IETF (unless we also decide that the information should be encoded in
RFC 2822 headers.)
At 04:16 AM 6/29/2001, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
1. As stated, the option leaves senders with an incentive to always
set high priority. It costs them nothing to do this.
Even if you assume this is true (past experience with priority facilities
indicates it is not),
The past experience you have been citing pertains to LOWER priority. That
is quite different from one which includes HIGHER priority.
One more time: For a service that imposes no costs on the requester, the
incentive is to always ask for higher priority. As I noted, we have well
seen that the Internet is now under the strong influence of selfish
actors. They do not participate as good neighbors. That is the reason we
needed a major generational upgrade to router queuing and it is the reason
that the proposed mechanism, here, suffers scaling limitations for the open
this ignores the need to lower as well as raise priority.
If the proposal were only for requesting lower priority, I'd say fine,
though I would expect only marginal benefit.
2. References to usage of SMTP Auth with this option are confusing,
since it is used for posting, not relaying. I'd appreciate clarification
to this point.
Read the spec. SMTP AUTH not only provides facility for posting, it also
provides facilities for relaying authentication credentials.
As with most security topics, the difference between specification and
practise are significant. Do you really expect that relaying across the
open Internet will require use of SMTP Auth? In which century?
What will be the incentives that will cause people to adopt such a
(There is an argument that opt-in volume mailers, and ISPs receiving their
bulk postings, might like to use a certified channel. This would permit
distinguish the Good Bulk mail from the Bad Bulk Mail. That argument has
so far proved unpersuasive to ISPs.)
Users will have no
basis for knowing what to expect from the relay path. The purpose of QoS
mechanisms is to increase predictability. This will not achieve that.
I have no clear idea what "increase predictability" means, but I'm pretty
sure that nobody views priority as a means to achieve that end.
If my request for special handling (priority) carries no expectation of
what actual handling will take place, then the option is entirely
useless. If it does correlate with actual handling, then I had better have
better knowledge about the delivery behavior of my message than I had
without the option. That constitutes increased predictability. That is
what quality of service work is about.
In other words, Dan Chaney's interpretation is accurate.
4. The IETF does not do intranet standards.
Actually, the IETF does intranet standards all the time. This is especially
true if you equate administrative domains with intranets. By this rule POP3,
IMAP4 and SMTP submit are all intranet protocols that don't scale to the
All of those protocols work quite well over the open Internet just
fine. There is nothing about them that requires constraints on the
(I suppose one might claim that a login identification technique is the
contradiction but then we would have to claim that all web mechanisms that
require identification are intranet-limited.)
My point about being limited to an intranet is not about constraints on an
end-point. It is about being limited to an operational infrastructure that
has significant dependence on a single, coherent administrative
control. POP, IMAP and Submit have not such dependence. The proposed
priority mechanism does, unless and until the rest of the system
specification is provided, and controls are provided to distinguish
authorized high priority users from unauthorized.
At 04:50 AM 6/29/2001, Julian Onions wrote:
It will only be any use if the MTA acts on it. I can already set these
sorts of things using UA's. Outlook Express allows me to flag messages
I post as High Priority. It does this by inserting its own header
field X-MSMail-Priority: High
This thread has gotten confused a few times between communicating priority
between the originator and recipient, versus between originator and the
So let me suggest that any citations of existing mechanisms make explicit
which is which.
As I keep reiterating, whilst an MTA is unlikely to take notice of a
request to do priority=high processing from joe-average-mta, it may
well take note of priority=low processing. There seems little to lose
in doing this.
> 3. The proposal presumes that a simple rank-ordering approach,
It provides a mechanism for one MTA to tell another what it thinks the
priority of this message is in comparison to others it has.
I am trying to imagine a relay that does something useful with such
entirely source-relative prioritization information. The algorithm escapes
me. Or overwhelms me.
I doubt there is any way I could convince your MTA to give my messages
high priority processing without some agreement before hand.
I see two ways of passing priority information. As a hint (as in this
draft) which given communities may respect; or passing it, together with
sufficient other information, that an MTA can independantly validate to
its satisfaction that this message was and is suitable to be processed
at the given priority. The second strikes me as so heavy weight no
one will implement it much, even if it can be specified in a
The military people would be happy with the first, they would just
have a policy that you MUST take the hint. Some internet MTAs will be
happy to demote low priority requests too. In certain circumstances
they may honor high priority too (consider two large companies that
exchange mail and want to allow priority processing to occur between
I think you have summarized things quite well in these two paragraphs.
My only point of disagreement is to note that the global business community
clearly does want and need differential handling and that individual
express delivery companies, as well as the formal, international
aggregation of postal services, have a long and successful history of
Hence there is some basis for believing that Internet-wide mechanisms for
differential handling are entirely appropriate. The challenge is designing
the mechanism to work for the global system.
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.273.6464