"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?
Exactly. I see priority as an attribute of the message. Whether or not a given
MTA choses to honor it doesn't affect the attribute itself.
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.
I agree. There should be an effective priority computed by an MTA, possibly
based on the priority suggested by the sender and possibly not, but this isn't
something that gets propogated as part of the message.
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.
Exactly. Downgrading the priority internally is fine, but it doesn't
change the value of the priority attribute of the message.
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.
Agreed.
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.
Hmm. Doesn't this argue that an SMTP extension is the wrong mechanism?
A priority specification can be propogated in a header field end to end
even if intermediate MTAs don't support it. If you use an extension for
this all the intermediaries have to support it.
The counter is that in order for this to be recipient-specific it has to
be an SMTP extension. So that's the tradeoff -- a recipient-specific
mechanism that requires upgrading intermediaries to work, or a
message-specific mechanism that requires no upgrading.
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.
Additionally, given that MTAs try to avoid splitting messages, it isn't at all
clear how to handle the case of two recipients with different priorities that
are travelling together. At a minimum some guidelines need to be given for this
case.
Ned