Simple Mail Transfer Protocol Extension for Message Transfer Priorities
Extracted elements (28)
Priority applies per message rather than per recipient to keep the protocol simpler, based on the expectation that different priorities per recipient on the same message will be uncommon. When needed, senders can send separate messages with the same content segregated by priority.
The priority range -9 to 9 (19 levels) was chosen to: accommodate existing 3-level MTA implementations and the 6-level military use case as a minimum, provide extensibility for future use cases without further specification changes, and use zero as the intuitive 'normal' default so negatives are below-normal and positives are above-normal.
Senders using the MT-PRIORITY SMTP extension will not be subject to greylisting (RFC 6647) because the extension requires some form of trust/authentication. However, connection-level or EHLO/HELO greylisting may occur before SMTP AUTH or TLS are available.
The MT-PRIORITY extension can be combined with the DELIVERBY SMTP extension (RFC 2852), and clients using both can specify smaller DELIVERBY timeouts for higher-priority messages. However, use of DELIVERBY alone does not guarantee priority processing.
When multiple DNS MX records are used for a domain, all of them should support the MT-PRIORITY extension and handle priorities identically. If any server behaves differently, it is strongly suggested that none support the extension, to avoid unexpected delivery speed differences or rejections.
A compliant MTA/MSA SHOULD include the 'PRIORITY' clause (with value equal to the received MT-PRIORITY parameter) when inserting a Received header field.
A Mediator node handling mailing lists or aliases SHOULD retain the MT-PRIORITY parameter value for all expanded and/or translated addresses.
An MTA generating a delivery report (DSN) for a message it is processing SHOULD use the priority value of the original message as the priority of the generated delivery report.
If an SMTP server rejects a message because it exceeds the maximum size for the determined priority, it SHOULD use reply code 552 with Enhanced Status Code X.7.16.
If any associated esmtp-value for MT-PRIORITY is syntactically invalid, or if more than one MT-PRIORITY parameter appears in a MAIL FROM command, the server MUST return an error such as '501 syntax error in parameter' with Enhanced Status Code 5.5.2.
If the SMTP server changes the priority of a message, it SHOULD use the X.3.6 Enhanced Status Code in its response; the human-readable text contains the new priority followed by a space and explanatory text.
Irrespective of how many distinct priority levels an SMTP server supports internally, when relaying or delivering via LMTP it MUST communicate the original priority value as determined in Section 4.1, not the internally rounded value.
SMTP servers MUST implement all distinct priority levels specified in their Priority Assignment Policy. Unsupported priority values are rounded up to the next higher supported level (or to the highest supported priority if above all supported values).
The SMTP server MUST NOT allow upgraded (positive) priorities from untrusted or unauthorized sources. The server MAY allow untrusted sources to lower their own message priorities.
When an MSA rejects a message because the determined priority is below the lowest acceptable level, it MUST use Enhanced Status Code X.7.15 with a 450 or 550 reply code.
When relaying a message to an MTA/MDA that also supports MT-PRIORITY, an MT-PRIORITY parameter with the value determined per Section 4.1 MUST appear in the MAIL FROM command.
When relaying to a non-conforming SMTP/LMTP server, the MTA relays the message without including the MT-PRIORITY parameter in the MAIL FROM command.
The default message priority is 0 when no MT-PRIORITY parameter is specified. An SMTP client sends higher-priority messages before lower-priority ones when multiple messages are queued. Within a priority level, normal MTA ordering algorithms apply.
The MIXER Priority Assignment Policy (the default policy) maps three MT-PRIORITY values to MIXER priorities: -4=non-urgent, 0=normal, 4=urgent. This is the policy assumed when no policy name is advertised in the MT-PRIORITY EHLO response.
The MT-PRIORITY SMTP extension adds an optional MT-PRIORITY parameter to the MAIL FROM command, taking a decimal integer value from -9 to 9 inclusive, where higher numbers mean higher priority. The EHLO keyword is 'MT-PRIORITY' with an optional Priority Assignment Policy name parameter.
The Priority Service Extension supports a single priority for all recipients of the same message; different priorities for different recipients of the same message require sending separate messages.
The STANAG4406 Priority Assignment Policy maps 6 MT-PRIORITY values to military precedence names: -4=Deferred, -2=Routine, 0=Priority, 2=Immediate, 4=Flash, 6=Override. Internally, servers may round to the next supported level but must relay the original value.
IANA added 'MT-PRIORITY' to the SMTP Service Extensions registry and registered the 'PRIORITY' clause in the Additional-registered-clauses sub-registry for Received header fields, recording the MT-PRIORITY parameter value from MAIL FROM.
IANA created the 'SMTP PRIORITY Extension Priority Assignment Policy' registry governed by 'Specification Required' policy, with initial entries: MIXER (Appendix B, default policy), STANAG4406 (Appendix A, military messaging), and NSEP (Appendix C, national security/emergency preparedness).
IANA registered three new SMTP Enhanced Status Codes: X.7.15 (Priority Level is too low, with 450/550), X.7.16 (Message is too big for the specified priority, with 552), and X.3.6 (Requested priority was changed, with 250/251).
Elevating DSN (delivery status notification) priorities based on detection of DSN content creates exposure to fake DSN attacks, since untrusted systems could inject high-priority messages disguised as DSNs. DSN processing should follow normal Section 4.1 rules.
Without proper policy enforcement, an SMTP server implementing this extension is susceptible to denial-of-service attacks where malicious clients always request priority 9 to obtain preferential treatment. MSAs and MTAs must authenticate and authorize senders before accepting elevated priority values.
The priority-value ABNF is `(['-'] NZDIGIT) / '0'`, allowing values -9 to 9. The MT-PRIORITY EHLO response may include a priority-profile of 1-20 characters (ALPHA / DIGIT / '-' / '_' / '.'). The MAIL FROM command line maximum length increases by 15 octets to accommodate the parameter.