At 02:28 PM 6/27/2001, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
The statement was that it would go unused.
That's demonstrably false.
The bottom line is that I think this is one of those things that the world
wants. (Needs is another matter.) So if we specify a priority mechanism that
's
reasonable and implementable it will deploy rapidly and widely.
1. As stated, the option leaves senders with an incentive to always
set high priority. It costs them nothing to do this. As we have seen with
spammers, some substantial portion of the community will in fact abuse the
option, thereby rendering useless. Some of you believe that human behavior
will be different from this projection; please explain.
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
so obviously the need is out there. I doubt any MTA, except maybe
Microsofts will act on this particular field. If it used a standard
mechanism I think it would have a better chance. There is already a standard
priority field defined by MIXER actually, but priority is really an
envelope thing.
This is why I think it is best considered per hop. As you then don't
get the users view of priority, but the view of an MTA that you may trust.
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.
I think SMTP AUTH is a small part of general auth. You might use it on
submission to allow priority setting, but in general an MTA would use
whatever mechanisms it wished to decide to honor the request. Other
things, like IP address, SSL/TLS etc would also likely factor into the
equation.
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, by
priority, is an appropriate queuing model for global Internet mail
relays. To the extent that the proposal attempts less than that -- for
example, simply trying to provide an advisory that each relay will use in
whatever way that it feels appropriate -- then it does little more than
substantiate the send-and-pray view of Internet mail. 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.
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. If you
mandate processing of priority, implementations will ignore it based
on your arguments in 1), so it seemed prudent to allow them that
latitude. You can currently do the send-and-pray technique by setting
various header fields that may or may not be recognised. I think this
mechanism is a step forward from that. My setting in Outlook Express
is exactly this (though I think in that case it is probably better
considered importance than priority).
I doubt there is any way I could convince your MTA to give my messages
high priority processing without some agreement before hand. But I might
convince it to do low priority from distribution list messages.
4. The IETF does not do intranet standards. This option looks quite
reasonable for use within a single administrative domain, where system-wide
handling policies can be established AND enforced. For the global
Internet, the Force is very much against successful operation.
This is starting to get into shades of grey. Isn't AUTH an intranet
solution? For that matter POP and IMAP too? They only work if there is
an agreement already in place amongst a closed community.
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).
Julian.