Two comments for section 10, Security Considerations:
First, the phrase
Message Submission Agents can
implement a policy that only allows authenticated users (or only
certain authenticated users) to specify message priorities
seems redundant. Since the message priority can only be specified
during transactions and authentication is implied at such stage, the
parenthesized "only certain" is the working case.
Second, protecting MT-Priority by DKIM-signing it results in broken
signatures in case the priority is altered by a conforming server
before relaying to a non-conforming one. If it has to be signed, I'd
suggest to revise Section 4.4 so as to never formally alter the field
after it has been signed (presumably by the MSA). Further MTAs may
treat the message as if it had a lower priority even without altering
I'd also put a question about section 4.5, Mailing lists and Aliases.
Requiring that the existing priority is retained across expansions
apparently discourages the use of low/negative priority for running
large lists. Would it make sense, instead, to have a process that
collects a message with, say, priority -3 and 1000 recipients and
re-queues it as 10 conveniently staggered messages with priority -2
and 100 recipients each?