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
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
"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"
This is regardless of whether it trusts the client or not. So from an
untrusted client, it might ignore the property, effectively saying all
messages are treated as normal priority. But with the effect that high
priority requests are treated no worse than low priority.
3. a story about authentication. I can see two ways to do this:
- "chain of trust" model
sender authenticates to original MTA using SMTP AUTH,
non-original MTAs can trust the priority of messages relayed from
other MTAs if those MTAs also use SMTP AUTH.
this implies that MTAs don't relay priority unless they receive
the message from a trusted source.
this is a weak model, as trust isn't really transitive.
but it could work in a limited scenario like a military organization.
- "capability model"
along with original message, client supplies (say in MAIL FROM)
a verifiable assertion of his ability to set priority this messages.
essentially this requires that the client sign the message
(modulo received headers) though you also could allow the originating
MTA to sign the message based on the sender's SMTP AUTH credentials.
note that this isn't intended for authenticating the message to the recipie
the signature would not be passed to the recipient.
this model would allow priorities to be relayed, but each MTA could
then decide (based on the signature) whether to accept the sender's
credentials. if the MTA did not accept them, it would ignore priority
(but it could still relay the priority and the signature to the next
MTA if it supported those extensions)
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.
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.
It passes the message onto another MTA (B), and using the priority
parameter, asserts to this MTA "I would like you to consider this
message at a priority of 25". If this MTA(B) is willing to trust
MTA(A) for the purposes of priority, then it will take this on
MTA(B) now determines the recipient is local, and is a distribution
list. It expands the list, and has a local policy that this list
members should be processed at low priority. So when the message is
passed on to MTA(C), it asserts "I would like you to treat this
message as low priority"
I dont see a chain of trust being useful either - it might happen, but
is not necesary. 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.