In my view, while it might be useful in a controlled environment,
creating this 'tool' without defining how it is used is likely to
decrease interoperability between MTAs, and thus, decrease the
reliability of Internet mail.
well there are certainly some inventive people out there, but I don't
see how it will decrease reliability.
Senario 1: client request priority of 99, server replies 5XX. Message
is bounced.
Senario 2: client request priority of 99, server silently downgrades
to normal.
Senario 3: client request priority of 99, server replies 4XX. Message
queued for retry.
Results:
Senario 1: message is not lost, but is returned to sender, possibly with
an appropriate message. OK, an ISP or hub might field an MTA which rejects
all messages with priority > 1, so building a road block, but they could make
a much better road block responding to the MAIL FROM field!
Senario 2: message delivered as normal.
Senario 3: this is the only potential problem case. If the client
continues to retry for ever, and the server always replies 4XX, then
it will get stuck. However this can already happen with MAIL FROM or
any of the other verbs. Intelligent clients time out the message.
Furthermore, you can simulate the behaviour right now by scanning for the
priority: field, its just more intensive, less reliable, doesn't work
per recipient and does not support the possible dynamic nature of
priority.
Like the SIZE extension, it has drawbacks if you wait until
you have the whole message before you make a decision.
Julian.