Simple Mail Transfer Protocol Extension for Message Transfer Priorities
This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 7 must, 12 should, 7 may.
3 Definition of the Priority SMTP Extension
- OPTIONALThe EHLO keyword has an OPTIONAL parameter that conveys the name of the Priority Assignment Policy (see Section 9.2) used by the server.
4.1 Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server
- MUSTIf any of the associated <esmtp-value>s (as defined in Section 4.1.2 of [RFC5321]) are not syntactically valid, or if there is more than one MT-PRIORITY parameter in a particular MAIL FROM command, the server MUST return an error, for example "501 syntax error in parameter" (with the 5.5.2 Enhanced Status Code [RFC2034] [RFC5248]).
- SHOULDWhen inserting a Received header field as specified in Section 4.4 of [RFC5321], the compliant MTA/MSA (Mail Submission Agent) SHOULD include the "PRIORITY" clause whose syntax is specified in Section 7.
- SHOULDThe received MT-PRIORITY parameter value SHOULD be logged as part of any logging of message transactions.
- MUST NOTThe SMTP server MUST NOT allow "upgraded" (positive) priorities from untrusted (e.g., unauthenticated) or unauthorized sources.
- MAYof MTA-to-MTA transfer, such authorization will usually be done as a bilateral agreement between two domains to honor priorities from each other.) The server MAY, however, allow an untrusted source to lower its own message's priorities -- consider, for example, an email marketer that voluntarily sends its marketing messages at a negative priority.
- MAYThe SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy.
- SHOULDIf the SMTP server changes (lowers or raises) the priority of a message, it SHOULD use the X.3.6 Enhanced Status Code [RFC2034] in its response to the MAIL FROM or in the final response to the DATA (or similar) command.
- MAYAlternatively, an SMTP server that is an MSA MAY reject a message based on the determined priority.
- SHOULDIn such cases, the MSA SHOULD use the 450 or 550 reply code.
- MUSTThe corresponding Enhanced Status Code MUST be X.7.15 [RFC2034] if the determined priority level is below the lowest priority currently acceptable for the receiving SMTP server.
4.2 Relay of Messages to Other Conforming SMTP/LMTP Servers
- MUSTAn MT-PRIORITY parameter with the value determined by the procedure from Section 4.1 MUST appear in the MAIL FROM command issued when the message is relayed to an MTA/MDA (Mail Delivery Agent) that also supports the MT-PRIORITY extension.
4.4 Mailing Lists and Aliases
- SHOULDIf a message is subject to such processing, the Mediator node (Section 2.1 of [RFC5598]) SHOULD retain the MT-PRIORITY parameter value for all expanded and/or translated addresses.
4.5 Gatewaying a Message into a Foreign Environment
- SHOULDIf the destination environment is unable to provide an equivalent of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a non-conformant SMTP server (Section 4.3).
- SHOULDIf the destination environment is capable of providing an equivalent of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a conformant SMTP server (Section 4.2), converting the MT-PRIORITY value to the equivalent in the destination environment.
4.6 Interaction with the DSN SMTP Extension
- SHOULDAn MTA that needs to generate a delivery report (whether for successful delivery or delayed/failed delivery) for a message it is processing SHOULD use the priority value of the message as the priority of the generated delivery report.
5 The Priority Service Extension
- MUSTSMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), but they MUST implement all distinct priority levels specified in the Priority Assignment Policy (see Section 9.2) implemented by the server.
- MUSTIrrespective of the number of distinct priority levels supported by the SMTP server, when relaying the message to the next hop or delivering it over LMTP, the SMTP server MUST communicate the priority value as determined in Section 4.1.
- MAYAs per the Priority Assignment Policy, some SMTP servers MAY impose additional maximum message size constraints for different message transfer priorities; for example, messages with priority 6 might not
- SHOULDIf an SMTP server chooses to reject a message because it is too big for the determined priority, it SHOULD use 552 reply codes together with the X.7.16 Enhanced Status Code [RFC2034].
5.1 Expedited Transfer
- MAYAdditionally, the retry interval and/or default timeout before a non-delivery report is generated MAY be lower (more aggressive) for messages of higher priority.
9.2 Priority Assignment Policies
- SHOULDAdditional policies SHOULD be registered with IANA as specified in Section 10.1.
10 IANA Considerations
- MAYIn cases of significant changes to registrations (other than editorial clarifications), the Designated Expert MAY require registration of a Priority Assignment Policy with a new name instead of updating the existing one.
10.1 Requirements on Priority Assignment Policy Registrations
- MUSTPriority Assignment Policy registrations with IANA are accompanied by a policy specification document that MUST specify the following information:
12.2 Informative References
- SHOULDWhere SMTP is used to support military messaging, the following mappings SHOULD be used.
- SHOULDWhere SMTP is used to support MIXER messaging, the following mappings SHOULD be used.