1. a set of rules which ensure that MTAs that implement this proposal
do no harm to the handling of messages for which they're not willing
to trust the sender's assertion of priority. e.g. either they
trust the sender's assertion of priority or they simply ignore it.
I think this is a special case of your point 2.
2. a rule which asserts that when the claimed priority is accepted,
higher priority messages are treated no worse than lower priority
ones. (as opposed to priority being interpreted however the MTA
wants to)
OK - this sounds good, with the caveat that this is client
specific. Priority of high from one MTA might be taken as higher than
priority of HIGH from another MTA that is less trusted. A sentence
like
"An MTA that accepts the priority property, will ensure that messages
marked with higher priority received from the same MTA are treated
with the same, or higher, priority for scheduling purposes"
no, I don't think this is a good idea.
in fact, I think the whole idea of having the queuing priority affected
by preceding MTAs is severely flawed. for instance, the choke point
might be closer to the receiver than the sender - and yet the sender
might have privileges to set priority on the MTAs close to the receiver.
why should the earlier MTAs dilute the sender's priority?
I think you are mixing a couple of concepts here. I see priority as a
dynamic quantity, therefore it is really only useful from one MTA to
another. It should not be tied to the user, other than at submission time.
I think it's just the opposite. Other than in a completely closed system,
there will inherently be some users who have permission to set message
priority and some who do not.
A user might start out requesting high priority, it hits the
submission MTA(A). Based on local knowledge and rule processing, it
asserts that in reality, this user is only allowed to request priority
level 25 or below, so it downgrades it internally, sorts
its queues appropriately.
the problem is, MTA A doesn't know what permissions the user has with
MTA B, or with the MTAs nearer to the recipient.
I dont see a chain of trust being useful either
well, that's pretty much what you were describing. but I've since
convinced myself that it's not the way to go.
Message submitted to MTA(A) with priority HIGH,
passed to MTA(B) which doesn't trust MTA(A). It ignores the parameter,
and passes the message onwards to MTA(C) with no priority
parameter. MTA(C) using local rules, determines that the recipient of
the message has payed extra for priority processing, so assigns the
message a given priority (say, 33). It can then pass this on to
another MTA saying effectively I would like you to treat this message
with priority 33, if you trust my judgement.
that's silly. if MTA C can decide the message's priority in the absence
of any input from the sender, then we don't need the priority extension
at all. if priority is to be very useful, it needs to be preserved
end-to-end. intermediate MTAs can ignore it, but they shouldn't try to
change it, because that's misrepresenting the sender's request.
that doesn't preclude an MTA giving better service to some recipients
over others, but recipient-derived priority should be independent from
the sender-requested priority.
and if the purpose of priority is to make better use of limited resources
then you want to be able to set it on a per-message basis, not have it
derived from the sender or recipient address and MTA-local rules.
Keith