Appreciate any comments,
Basically I think a mechanism such as this is useless w/o requiring
authentication of the sender (which could be done by SMTP AUTH) and
verification of the sender's privilege to set that priority.
And that only works for the first hop. I think we would also need some
sort of model for determining priority of messages on subsequent hops -
based on either the sender's authenticated identity or on the identity
of the MTA that relayed the message.
Also, there is a potential problem with the negotiation - the fact
that an SMTP server asserts that it supports the priority extension
does not imply that the client/sender has the right credentials to
request priority handling from that server. If the client doesn't
have the right credentials, the worst that the servers should do is
to assign a priority equal to that of a message that does not assert
a priority. So a message should not be refused or delayed relative
to an unprioritized message simply because the client attempted to
assert a priority.
The draft doesn't say anything about what happens to priority when
a message is relayed. I guess that the priority should also be
relayed (if possible) but the draft should say so explicity.
Keith