[Top] [All Lists]


2001-07-01 10:07:55

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 Internet.

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 considerable mechanism?

(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 entire

All of those protocols work quite well over the open Internet just fine. There is nothing about them that requires constraints on the operational network.

(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 transport infrastructure.

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.

agreed.  completely.

> 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
reasonable way.

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
their management).

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 providing it.

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  <>
tel +1.408.246.8253;  fax +1.408.273.6464

<Prev in Thread] Current Thread [Next in Thread>