RFC 6710

Simple Mail Transfer Protocol Extension for Message Transfer Priorities

📅 published August 2012, from ietf

Simple Mail Transfer Protocol Extension for Message Transfer Priorities 💌

  • RFC: 6710 🎀
  • Authors: A. Melnikov (Isode Ltd) and K. Carlberg (G11) ✨
  • Category: Standards Track 🦋
  • Date: August 2012 📅
  • ISSN: 2070-1721 💜
  • Obsoletes / Updates: the title block doesn't list any Obsoletes or Updates entries 🫶

Abstract ✨

This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service that lets messages get a label for preferential handling, so mail handling nodes can take that info into account for onward processing. 📬

Status of This Memo 🌸

This is an Internet Standards Track document. 💖

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 🧚

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6710. 🔥

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🌈

Table of Contents 📖

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
3.  Definition of the Priority SMTP Extension  . . . . . . . . . .  4
4.  Handling of Messages Received via SMTP . . . . . . . . . . . .  5
  4.1.  Handling of the MT-PRIORITY Parameter by the Receiving
        SMTP Server  . . . . . . . . . . . . . . . . . . . . . . .  5
  4.2.  Relay of Messages to Other Conforming SMTP/LMTP Servers  .  6
  4.3.  Relay of Messages to Non-Conforming SMTP/LMTP Servers  . .  7
  4.4.  Mailing Lists and Aliases  . . . . . . . . . . . . . . . .  7
  4.5.  Gatewaying a Message into a Foreign Environment  . . . . .  7
  4.6.  Interaction with the DSN SMTP Extension  . . . . . . . . .  7
5.  The Priority Service Extension . . . . . . . . . . . . . . . .  8
  5.1.  Expedited Transfer . . . . . . . . . . . . . . . . . . . .  9
  5.2.  Timely Delivery  . . . . . . . . . . . . . . . . . . . . . 10
6.  Use of MT-PRIORITY with LMTP . . . . . . . . . . . . . . . . . 10
7.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 14
  9.1.  Multiple MX Records  . . . . . . . . . . . . . . . . . . . 14
  9.2.  Priority Assignment Policies . . . . . . . . . . . . . . . 15
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
  10.1. Requirements on Priority Assignment Policy
        Registrations  . . . . . . . . . . . . . . . . . . . . . . 17
  10.2. Initial Priority Assignment Policy Registrations . . . . . 18
11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
  12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A.  Priority Assignment Policy for Military Messaging . . 22
Appendix B.  Priority Assignment Policy for MIXER  . . . . . . . . 23
Appendix C.  Priority Assignment Policy for National Security
             / Emergency Preparedness (NS/EP)  . . . . . . . . . . 24
Appendix D.  Possible Implementation Strategies  . . . . . . . . . 25
  D.1.  Probability  . . . . . . . . . . . . . . . . . . . . . . . 25
  D.2.  Preemption of Sessions or Transactions . . . . . . . . . . 25
  D.3.  Resource Allocation Models . . . . . . . . . . . . . . . . 26
Appendix E.  Background on Design Choices  . . . . . . . . . . . . 26
Appendix F.  Acknowledgements  . . . . . . . . . . . . . . . . . . 27

1. Introduction 🌷

When resources for switching or transferring messages are constrained (think bandwidth, round trip time, transition storage, or processing capability), it's desirable to give some messages preferential handling over others, based on their labeled priority. 🚀 This is especially important in emergencies for first responders (Appendix C), and for military (Appendix A) and aviation (Appendix B) messaging, where messages have high operational significance and extra delay can have big consequences. 😭

So an SMTP receiver can relay higher-priority messages first, there needs to be a way to communicate each message's priority during both Message Submission [RFC6409] and Message Transfer [RFC5321]. This specification defines that mechanism as an SMTP [RFC5321] extension. 💌

To allow end-to-end use of this extension across an email infrastructure that doesn't support it, a companion tunneling mechanism is defined in [PRIORITY-TUNNELING]. That one uses a new message header field [RFC5322]. 🦋

This extension helps some classes of users on networks with limited bandwidth or long round trip times, where the actual message transfer over the network can make up a big chunk of the total delivery time from sender to recipient, for example over a satellite or high-frequency radio link. ✨ It's also useful when an Mail Transfer Agent (MTA) queue builds up because incoming messages arrive faster than outgoing ones leave. 🫶 When neither of those two conditions is true, using the MT-PRIORITY SMTP extension won't give any user better SMTP service. 🙈

Also, while this SMTP extension can speed up delivery of higher-priority messages, it doesn't guarantee anything about two messages with priorities M and N (M > N) submitted at the same time. The message with priority M won't necessarily arrive before the one with priority N. In other words, this extension asks for best effort to provide preferential processing. 💀

Besides what happens at the application level, it can be important to also use the priority or precedence mechanisms the network itself offers, so emails get delivered on time. 👑 Examples include DiffServ [RFC2474], RSVP [RFC2205], and [RFC6401] (an extension to RSVP that prioritizes reservations). 🌈

2. Conventions Used in This Document 🍓

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words also appear in this document in lower case as plain English words, without their normative meanings. 💅

The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of RFC 5234 [RFC5234]. 🧚

In examples, "C:" and "S:" mark lines sent by the client and server, respectively. Line breaks that don't start with a new "C:" or "S:" are there for editorial reasons and aren't part of the protocol. 🎀

This document uses the term "priority" specifically for how the server internally treats a message. Messages with higher priorities may get expedited handling, and those with lower priorities may only be handled as resources become available. 🔥

3. Definition of the Priority SMTP Extension 💖

The Priority SMTP service extension is defined as follows: 🌸

  1. The textual name of this extension is "Priority Message Handling". ✨
  2. The EHLO keyword value for this extension is MT-PRIORITY. 🦋
  3. The EHLO keyword has an OPTIONAL parameter that carries the name of the Priority Assignment Policy (see Section 9.2) the server uses. (See the <mt-priority-ehlo> ABNF non-terminal in Section 7 for the details of its syntax.) If the parameter is absent, the server is unwilling to disclose its Priority Assignment Policy. Clients can choose to use the MT-PRIORITY SMTP extension even if they don't recognize a particular Priority Assignment Policy name advertised by a server. 🫶
  4. This extension defines no additional SMTP verbs. 🙈
  5. One optional parameter (MT-PRIORITY) is added to the MAIL FROM command. Its value is a decimal integer from -9 to 9 (inclusive) that indicates the priority of the email message (see Appendix E for more details on why this range was picked). The syntax of the MT-PRIORITY parameter is described by the <priority-value> ABNF non-terminal defined in Section 7. Higher numbers mean higher priority. 👑
  6. The maximum length of a MAIL FROM command line goes up by 15 octets, to allow for a possible space, the MT-PRIORITY keyword, and a priority value. 🌈
  7. The MT-PRIORITY extension is valid for the submission service [RFC6409] and for the Local Mail Transfer Protocol (LMTP) [RFC2033]. 💜

4. Handling of Messages Received via SMTP 🌷

This section describes how a conforming SMTP server should handle any messages received via SMTP. 🚀

4.1. Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server ✨

okay so here are the rules for any SMTP transaction hitting a server that supports the MT-PRIORITY parameter 💖

  1. If 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]). 🙅‍♀️
  2. When 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. 🧾
  3. The received MT-PRIORITY parameter value SHOULD be logged as part of any logging of message transactions. 📝
  4. If the sending SMTP client specified the MT-PRIORITY parameter to the MAIL FROM command, then the value of this parameter is the message priority. 💅
  5. If no priority has been determined by the above, the server may use its normal policies to set the message's priority. By default, each message has priority 0. 🫶

The SMTP server MUST NOT allow "upgraded" (positive) priorities from untrusted (e.g., unauthenticated) or unauthorized sources. 🚫 (One example of an "unauthorized source" might be an SMTP sender that successfully authenticated using SMTP AUTH, but that is not explicitly authorized to use the SMTP MT-PRIORITY service. In case of 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. 📧

The SMTP server MAY also alter the message priority (to lower or to raise it) in order to enforce some other site policy. ⚖️ (Note that this also includes the case in which the priority is not explicitly specified.) For example, an MSA might have a mapping table that assigns priorities to messages based on authentication credentials. 🗂️

If 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. The human readable text part after the status code contains the new priority, followed by SP (ASCII space) and explanatory human readable text. 🔁

Alternatively, an SMTP server that is an MSA MAY reject a message based on the determined priority. In such cases, the MSA SHOULD use the 450 or 550 reply code. The 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. Note that this condition might be temporary. In some environments, operational policies might permit periods of operation that relay only higher-priority messages and reject lower priority ones. Such handling choices need to be specified for that operational environment. this part is giving "it depends on your setup," and that's valid 🌸

4.2. Relay of Messages to Other Conforming SMTP/LMTP Servers 🦋

okay so this is how a conforming MTA (acting as an SMTP/LMTP client) should behave when it relays a message it got over SMTP to an SMTP/LMTP server that supports the MT-PRIORITY extension 🎀

  1. An 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. (Note that due to site policy, this value might be different from the value received from the SMTP client. See Section 4.1 for details. Also note that this value might be different than the priority level at which the MTA actually handles the request, due to the rounding described in Section 5.) 🔄
  2. Further processing of the MT-PRIORITY parameter is described in Section 5. 👀

4.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers 🙈

this one's for when the conforming MTA is relaying to an SMTP/LMTP server that does NOT support the MT-PRIORITY extension. Same vibe, different target 💜

  1. The MTA relays the message without including the MT-PRIORITY parameter in the MAIL FROM command. 📭

4.4. Mailing Lists and Aliases 📬

so there are a bunch of ways to redirect or forward messages to other or multiple addresses [RFC5598]. Aliases and mailing lists [RFC5321] are two examples 🧚

If a message goes through that kind of 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 🌈

this covers a conforming MTA gatewaying a message it got over SMTP into a foreign (non-SMTP) environment ✨

  1. If 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). 🙃
  2. If 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 💌

an MTA that has to generate a delivery report (for successful delivery or delayed/failed delivery) for a message it's processing SHOULD use the priority value of the message as the priority of the generated delivery report. This applies especially to MTAs that also implement [RFC3461]. 💅

For delivery reports (DSNs) an MTA receives for relay, the processing rules in Section 4.1 apply. There's no special processing for relayed DSNs. 🚫 It might seem tempting to try to detect DSNs and process them at an elevated priority, on the assumption that failure notices need to get through quickly, even or perhaps especially if the DSN came from an untrusted source. But that kind of policy can create an exposure to fake DSN attacks, giving untrusted systems a way to inject high-priority messages. 😱 Implementing that policy also assumes DSNs can be detected reliably, which may not be the case since some systems use nonstandard DSN formats. 🫠

5. The Priority Service Extension 👑

the priority of a message affects the order in which it gets transferred from the client to the server. This is largely independent of the order in which the server originally received it. 🏃‍♀️

A message priority is a decimal integer in the range from -9 to 9 (inclusive). SMTP 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. That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported priority). For example, an implementation can treat priority values below and including -4 as priority -4, priority -3 as priority -2, and all priorities starting from 5 can be treated as priority 6. (See Section 9.2 for implementation/deployment considerations related to Priority Assignment Policy.) 🧮

Irrespective 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. 📣

Note: 19 possible priority levels are defined by this specification for extensibility. For example, a particular implementation or deployment environment might need to provide finer-grained control over message transfer priorities. See Appendix E for more details on why the range from -9 to 9 was selected. 🔍

As 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 be larger than 4 Kb. If 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]. 🐣

Implementation Note: If the SMTP server also supports the SMTP SIZE extension [RFC1870], then an SMTP client can use both SIZE= and MT-PRIORITY= parameters on the MAIL FROM command. This allows the server to perform early rejection of a message in case the message size is too big for the specified priority, thus avoiding wasting bandwidth by transferring the message first and then rejecting it due to its size. 🧠

The Priority Service Extension can be combined with the DELIVERBY [RFC2852] SMTP service extension; however, there is no requirement that both extensions always be implemented together. 🤝

5.1. Expedited Transfer 🦋

the main service the Priority Message Handling SMTP Service Extension provides is expedited transfer of emails with a higher priority. So an SMTP client that has more than one email to send at a given time sends the higher-priority ones before the lower-priority ones. 🚀 Also, the retry interval and/or default timeout before a non-delivery report is generated MAY be lower (more aggressive) for messages of higher priority. Lower retry intervals/default timeouts are controlled by the local MTA policy. ⏱️

Note that this SMTP extension requires some sort of trust relationship between a sender and a receiver, and therefore some form of authentication (whether using SMTP AUTH, TLS, IP address whitelist, etc.). So senders using this SMTP extension will not be subject to greylisting [RFC6647], unless they are unauthorized to use this SMTP extension due to an explicit policy decision or a misconfiguration error. However, note that in case of connection-level or SMTP EHLO/HELO greylisting, SMTP AUTH or TLS authentication options are not available to the server. 🧐

To make implementations of this extension easier, this SMTP extension only allows a single priority for all recipients of the same message. 💖

Within a priority level, the MTA uses its normal algorithm (the algorithm used in absence of this SMTP extension) for determining message processing order. 🎯

Several possible ways of implementing expedited transfer are described in more detail in Appendix D. Note that these sections don't describe all details and pitfalls for each implementation strategy. 📚

5.2. Timely Delivery ⏰

okay so in some environments, the higher priority levels come with delivery time constraints 😭 like the higher the priority, the shorter the max time allowed for delivery. no cap, that's giving urgency 🔥

Unextended SMTP doesn't have a service for timely delivery, aka the "deliver this message within X seconds from submission" vibe 🙅‍♀️. The "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in [RFC2852] is one example of an SMTP extension that provides a service you can use to build timely delivery ⏱️.

Also, SMTP DELIVERBY and SMTP MT-PRIORITY are complementary, so they can be used together (as long as the SMTP server you're talking to advertises support for both) 🫶. Just know that using DELIVERBY alone doesn't guarantee any priority processing 👀. If the client uses both SMTP DELIVERBY and SMTP MT-PRIORITY at the same time, it can consider using smaller DELIVERBY timeouts for higher-priority messages 🧚✨.

6. Use of MT-PRIORITY with LMTP 📬

an LMTP server can advertise support for the MT-PRIORITY extension if it supports any combination of the following features 💅:

  1. The LMTP server is architected in such a way that it can deliver higher-priority messages quicker than lower-priority messages.
  2. The LMTP server logs that the MT-PRIORITY extension was used by the previous SMTP hop.
  3. The LMTP server is exposing information about the MT-PRIORITY extension to a delivery-time filtering engine such as Sieve [RFC5228].

7. Syntax 🧩

the grammar is giving very precise, so here it is in full:

priority-value = (["-"] NZDIGIT) / "0"
                 ; Allowed values are from -9 to 9 inclusive

NZDIGIT = %x31-39
          ; "1"-"9"

CFWS = <defined in RFC 5322>

; New "clause" that can be used in the Received header field
Pri  = CFWS "PRIORITY" FWS priority-value
          ; Complies with the <Additional-Registered-Clauses>
          ; non-terminal syntax from RFC 5321.

mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile]
          ; Complies with the <ehlo-line> ABNF production
          ; from RFC 5321.

priority-profile = 1*20(ALPHA / DIGIT / "-" / "_" / ".")
          ; name of the Priority Assignment Profile advertized in
          ; the MT-PRIORITY EHLO response.

ALPHA = <Defined in RFC 5234>

DIGIT = <Defined in RFC 5234>

8. Example 💌

the original submission (from MUA (Mail User Agent) to MSA) might look like this. Heads up, the example also uses the STARTTLS [RFC3207], DELIVERBY [RFC2852], and DSN [RFC3461] SMTP extensions 🙈. There's no requirement that those other extensions be supported when the MT-PRIORITY SMTP extension is implemented, though!

     S: 220 example.com SMTP server here
     C: EHLO mua.example.com
     S: 250-example.com
     S: 250-STARTTLS
     S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
     S: 250-DSN
     S: 250-DELIVERBY
     S: 250-ENHANCEDSTATUSCODES
     S: 250 MT-PRIORITY MIXER
     C: AUTH SCRAM-SHA-1
     [...authentication exchange...]
     S: 235 2.7.0 Authentication successful
     C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
         MT-PRIORITY=3
     S: 250 2.1.0 <eljefe@example.com> sender ok
     C: RCPT TO:<topbanana@example.net>
     S: 250 2.1.5 <topbanana@example.net> recipient ok
     C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
         ORCPT=rfc822;Dana@Ivory.example.net
     S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
     C: DATA
     S: 354 okay, send message
     C:  (message goes here)
     C: .
     S: 250 2.1.0 message accepted
     C: QUIT
     S: 221 2.0.0 goodbye

in the above example, the MUA has specified priority 3 and the server has accepted it 🎀. The server is advertising the MIXER Priority Assignment Policy (the default). Another variant of the initial submission might look like this:

     S: 220 example.com SMTP server here
     C: EHLO mua.example.com
     S: 250-example.com
     S: 250-STARTTLS
     S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
     S: 250-DSN
     S: 250-DELIVERBY
     S: 250-ENHANCEDSTATUSCODES
     S: 250 MT-PRIORITY
     C: AUTH SCRAM-SHA-1
     [...authentication exchange...]
     S: 235 2.7.0 Authentication successful
     C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
     S: 250 2.1.0 <eljefe@example.com> sender ok
     C: RCPT TO:<topbanana@example.net>
     S: 250 2.1.5 <topbanana@example.net> recipient ok
     C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
         ORCPT=rfc822;Dana@Ivory.example.net
     S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
     C: DATA
     S: 354 okay, send message
     C:  (message goes here)
     C: .
     S: 250 X.3.6 3 is the new priority assigned to the message
     C: QUIT
     S: 221 2.0.0 goodbye

in this one, the MUA hasn't specified any priority, but the MSA has assigned priority 3 to the message 🪄. Also, the server is unwilling to advertise the Priority Assignment Policy it supports in the EHLO response 🙃.

The MSA relays the message to the next MTA 📨:

     S: 220 example.net SMTP server here
     C: EHLO example.com
     S: 250-example.net
     S: 250-DSN
     S: 250-DELIVERBY
     S: 250 MT-PRIORITY STANAG4406
     C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
         MT-PRIORITY=3
     S: 250 <eljefe@example.com> sender ok
     C: RCPT TO:<topbanana@example.net>
     S: 250 <topbanana@example.net> recipient ok
     C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
         ORCPT=rfc822;Dana@Ivory.example.net
     S: 250 <Dana@Ivory.example.net> recipient ok
     C: DATA
     S: 354 okay, send message
     C:  (message goes here)
     C: .
     S: 250 message accepted
     C: QUIT
     S: 221 goodbye

the receiving SMTP server advertises support for the "STANAG4406" Priority Assignment Policy, which supports 6 priority levels as described in Appendix A 🧠. So this server will use priority value 4 internally (the next supported priority higher or equal to 3), and it will communicate priority value 3 when relaying the message to the next hop (if necessary) 🔄.

9. Deployment Considerations 🚀

9.1. Multiple MX Records 📍

if multiple DNS MX records are used to specify multiple servers for a domain in Section 5 of [RFC5321], it's strongly advised that all of them support the MT-PRIORITY extension and handle priorities in exactly the same way 🫠. If one or more servers behave differently in this respect, then it's strongly suggested that none of the servers support the MT-PRIORITY extension. Otherwise, unexpected differences in message delivery speed or even rejections can happen during temporary or permanent failures, and users might perceive that as serious reliability issues 😱.

9.2. Priority Assignment Policies 🗂️

this document allows up to 19 distinct priority values 🔢. In a particular operating environment, independent originators need to assign priority values using roughly the same criteria. That way, the same "high priority message" doesn't get tagged with 3 by one sender and 5 by another, because those messages might unintentionally get different preferential treatment 💔.

To get consistent behavior in an operating environment, the Priority Assignment Policy (together with any associated restrictions on maximum message sizes for each priority, default timeouts, etc.) should be documented for that environment 📋. Each SMTP/LMTP server supports a Priority Assignment Policy, either explicit (advertised in the MT-PRIORITY EHLO response) or implicit (not advertised). The default Priority Assignment Policy (assumed by the client when no Priority Assignment Policy name is advertised in the MT-PRIORITY EHLO response) is specified in Appendix B. Two other policies are specified in Appendix A and Appendix C. Additional policies SHOULD be registered with IANA as specified in Section 10.1 🌈.

Moreover, all MSAs/MTAs/MDAs within any given Administrative Management Domain have to be configured to use the same Priority Assignment Policy 🔒. Otherwise, a differently configured MSA/MTA/MDA can expose the whole domain to possible attacks, like injection of a high-priority fake DSN 🚨.

When this SMTP extension is deployed across multiple cooperating Administrative Domains, those domains need to use the same or at least compatible policies 🤝. Again, differences in policies (for example, differences in how users are authenticated or differences in how priorities are handled) can expose an Administrative Domain to weaknesses in a partner domain 💀.

10. IANA Considerations ✨

okay so IANA added the MT-PRIORITY SMTP extension to the "SMTP Service Extensions" registry (http://www.iana.org/assignments/mail-parameters) 🎀 and it's suitable for the Submit port 💅

IANA also added a new Received header field clause to the "Additional-registered-clauses" sub-registry (http://www.iana.org/assignments/mail-parameters) so people can trace emails delivered with the MT-PRIORITY SMTP extension 🦋 the new clause is:

  • Clause name: PRIORITY
  • Description: Records the value of the MT-PRIORITY parameter specified in the MAIL FROM command
  • Syntax of the value: See Section 7 of RFC 6710
  • Reference: RFC 6710

IANA then added three new Enumerated Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry (http://www.iana.org/assignments/smtp-enhanced-status-codes) that was set up by [RFC5248] 🧚

  1. Code: X.7.15
    • Sample Text: Priority Level is too low
    • Associated basic status code: 450, 550 (other 4XX or 5XX codes are allowed)
    • Description: the priority level you asked for is under the lowest priority the receiving SMTP server will accept. This can be temporary 🥺 like when the server is only taking higher-priority messages for transfer and delivery and bouncing the lower ones.
    • Reference: RFC 6710
    • Submitter: A. Melnikov
    • Change controller: IESG
  2. Code: X.7.16
    • Sample Text: Message is too big for the specified priority
    • Associated basic status code: 552 (other 4XX or 5XX codes are allowed)
    • Description: the message is too big for the priority it was given. This can also be temporary, for example when the server only takes higher-priority messages under a certain size for transfer and delivery.
    • Reference: RFC 6710
    • Submitter: A. Melnikov
    • Change controller: IESG
  3. Code: X.3.6
    • Sample Text: Requested priority was changed
    • Associated basic status code: 250 or 251
    • Description: the message got accepted for relay or delivery, but the priority that was requested (or the implied default) didn't stick 😭 The human readable text after the status code shows the new priority, then an SP (space), then some explanation.
    • Reference: RFC 6710
    • Submitter: A. Melnikov
    • Change controller: IESG

IANA also made a brand new registry called "SMTP PRIORITY Extension Priority Assignment Policy" 👑 Future registrations go through the "Specification Required" [RFC5226] IANA registration policy. The Designated Expert checks the requirements on registrations, which are in Section 10.1. Changes to registrations go through the same process as the first registration. For significant changes (not just editorial clarifications), the Designated Expert MAY require registering a Priority Assignment Policy under a new name instead of updating the existing one 🌸

10.1. Requirements on Priority Assignment Policy Registrations

okay this part is the checklist 📋 Priority Assignment Policy registrations come with a policy specification document that MUST specify the following information:

  1. The Priority Assignment Policy name. It's a case-insensitive string of 1 to 20 US-ASCII characters that gets advertised as the MT-PRIORITY EHLO parameter. Allowed characters are: ALPHA, DIGIT, "-", "_", and "."
  2. The number of distinct priority levels supported by all servers implementing the policy, and their respective values.
  3. For each supported priority level, the default retry timeouts. That's how often to retry sending a message after a temporary error trying to transfer or deliver it. The policy specification can also explicitly define this as implementation and/or deployment specific 🫶
  4. For each supported priority level, the default expiration timeouts. That's how long to keep trying to transfer or deliver before the message expires and a non-delivery report gets generated 💀 The policy specification can also explicitly define this as implementation and/or deployment specific. Note that a client can override this default when it uses additional SMTP extensions (such as the one mentioned in Section 5.2).
  5. The maximum message size for each priority level. The policy specification can also explicitly define this as implementation and/or deployment specific.
  6. Any requirements or restrictions on the kind of SMTP client authentication needed before an SMTP server running this policy will accept priority values from an SMTP client. For example, this can limit which Simple Authentication and Security Layer (SASL) [RFC4422] authentication mechanisms get used, require TLS, and so on 🔐
  7. Any other information that might affect how messages with different priorities get processed ✨
  8. The policy specification document is not allowed to redefine the allowed range of priorities specified in Section 5 or other aspects of handling different priorities, unless this document explicitly specifies it 🙅‍♀️

10.2. Initial Priority Assignment Policy Registrations

IANA registered these initial values in the "SMTP PRIORITY Extension Priority Assignment Policy" registry 🍓

          Initial Priority Assignment Policy Registrations

    +-------------+------------------------+----------------+
    | Policy Name | Reference              | Comment        |
    +-------------+------------------------+----------------+
    | MIXER       | Appendix B of RFC 6710 | Default policy |
    | STANAG4406  | Appendix A of RFC 6710 |                |
    | NSEP        | Appendix C of RFC 6710 |                |
    +-------------+------------------------+----------------+

11. Security Considerations 🚨

this section is serious, bestie 😤 Message Submission Agents ought to only accept message transfer priorities from users (or only certain groups of those users) who are authenticated and authorized in some way the MSA finds acceptable. As part of this policy, they can also restrict the maximum priority values different groups of users can request, and they can override the priority values the MUAs specified.

MTAs ought to do the same thing 🔥 They should only accept message transfer priorities from senders (or only certain groups of senders) who are authenticated and authorized in some way the MTA finds acceptable. As part of that policy, they can restrict the maximum priority values different groups of senders can request, and they can override the priority values the senders specified.

If that enforcement isn't in place, an SMTP server (whether it's an MSA or an MTA) running this SMTP extension could be open to a denial-of-service attack 💀 For example, malicious clients (MUAs/MSAs/MTAs) could try to abuse this feature by always requesting priority 9. Nobody wants that, so lock it down 🔒

12. References 📚

12.1. Normative References

  • [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
  • [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.
  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

12.2. Informative References

  • [ACP123] CCEB, "Common Messaging strategy and procedures", ACP 123, May 2009.
  • [PRIORITY-TUNNELING] Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message Transfer Priorities", Work in Progress, July 2012.
  • [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service Extension for Checkpoint/Restart", RFC 1845, September 1995.
  • [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
  • [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
  • [RFC2205] Braden, B., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
  • [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005.
  • [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, June 2005.
  • [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
  • [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
  • [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
  • [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, January 2008.
  • [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
  • [RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP Extensions for Admission Priority", RFC 6401, October 2011.
  • [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An Applicability Statement for SMTP", RFC 6647, June 2012.
  • [SMTP-PRI-OLD] Schmeing, M., Brendecke, J., and K. Carlberg, "SMTP Service Extension for Priority Message Handling", Work in Progress, August 2006.
  • [STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406, March 2005.

Appendix A. Priority Assignment Policy for Military Messaging ✨

okay so military messaging, as in ACP 123 [ACP123] (also in STANAG 4406 [STANAG-4406]), defines 6 priority ("precedence") values 💅 ACP 123/STANAG 4406 allow for 32 different priority levels (16 levels are reserved for NATO and an additional 16 are reserved for national use), but only 6 are actually in use in practice 🫶 This section specifies the Priority Assignment Policy for Military Messaging and how the MT-PRIORITY parameter can be mapped when gatewaying between SMTP and ACP 123/STANAG 4406 environments 🎀

Where SMTP is used to support military messaging, the following mappings SHOULD be used 🌸

         Recommended Mapping of MT-PRIORITY Values for MMHS

            +-------------------+----------------------+
            | MT-PRIORITY value | MMHS Precedence name |
            +-------------------+----------------------+
            |         -4        | Deferred             |
            |         -2        | Routine              |
            |         0         | Priority             |
            |         2         | Immediate            |
            |         4         | Flash                |
            |         6         | Override             |
            +-------------------+----------------------+

Table 1

The Priority Assignment Policy registration for Military Messaging is as follows 📝

  1. The Priority Assignment Policy name is "STANAG4406".
  2. Number of distinct priority levels: 6, as specified in the table above.
  3. Default retry timeouts for each priority level are implementation and/or deployment specific.
  4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
  5. Maximum message size associated with each priority level is implementation and/or deployment specific.
  6. No restrictions on what kind of SMTP client authentication is required.

Appendix B. Priority Assignment Policy for MIXER 🦋

MIXER [RFC2156] defines the Priority header field with 3 values, and this section is the Priority Assignment Policy for MIXER, plus how the MT-PRIORITY parameter can be mapped when it's used with MIXER 💜

Where SMTP is used to support MIXER messaging, the following mappings SHOULD be used ✨

         Recommended Mapping of MT-PRIORITY Values for MIXER

            +-------------------+----------------------+
            | MT-PRIORITY value | MIXER Priority value |
            +-------------------+----------------------+
            | -4                | non-urgent           |
            | 0                 | normal               |
            | 4                 | urgent               |
            +-------------------+----------------------+

Table 2

The Priority Assignment Policy registration for MIXER is as follows 📝

  1. The Priority Assignment Policy name is "MIXER".
  2. Number of distinct priority levels: 3, as specified in the table above.
  3. Default retry timeouts for each priority level are implementation and/or deployment specific.
  4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
  5. Maximum message size associated with each priority level is implementation and/or deployment specific.
  6. No restrictions on what kind of SMTP client authentication is required.

Appendix C. Priority Assignment Policy for National Security / Emergency Preparedness (NS/EP) 🚨

there are a few different kinds of communication systems people use during an emergency or disaster 🌈 the most famous one is the many-to-one thing where the general public calls a public safety access point via 911/999/112 through the public telephone network 📞

typically, these calls don't require authorization, and they don't invoke any prioritization 🙈

another kind of emergency communications is a set of authorized users or nodes that use prioritized services to help establish and continue communication when resources are limited 👑 [RFC4190] describes several systems that have been developed to support National Security / Emergency Preparedness (NS/EP) 💀 these deployed systems need some form of authentication and have focused on prioritization of telephony-based services 📱 they've also been designed as a binary form (on/off) of signaled priority communications 🔘

[RFC4412] shows a more expansive view of NS/EP communications, where priority goes from a single on/off bit value to one that has 5 priority values ✨ this shows up in the Emergency Telecommunications Service (ETS) and Wireless Priority Service (WPS) Namespaces 🫶 since there aren't any pre-existing NS/EP values assigned for email, we follow the paradigm of the ETS and WPS Namespaces and recommend the 5 ascending values shown in the table below 🦋

              +-------------------+------------------+
              | MT-PRIORITY value | Relational Order |
              +-------------------+------------------+
              |         -2        | Lowest Priority  |
              |         0         | ----------       |
              |         2         | ----------       |
              |         4         | ----------       |
              |         6         | Highest Priority |
              +-------------------+------------------+

The Priority Assignment Policy registration for NS/EP is as follows 📝

  1. The Priority Assignment Policy name is "NSEP".
  2. Number of distinct priority levels: 5, as specified in the table above.
  3. Default retry timeouts for each priority level are implementation and/or deployment specific.
  4. Default expiration timeouts for each priority level are implementation and/or deployment specific.
  5. Maximum message size associated with each priority level is implementation and/or deployment specific.
  6. No restrictions on what kind of SMTP client authentication is required.

Appendix D. Possible Implementation Strategies 🧚

this appendix suggests some strategies to implement the SMTP extension defined in this document 💖 the list is not exhaustive 🌸

This appendix and its subsections are Informative.

D.1. Probability 🎲

okay so probability is all about increasing the chances of getting resources without messing up connections that were already established 🦋 one example would be requesting resources set aside for specific priority levels 🍓 if those extra resources run out, the connection you wanted gets denied 🙅‍♀️ queues, new timers, or combinations of those can be used to help the higher-priority requests, but the key thing is that mechanisms focus on increasing the probability of message transfer ✨

D.2. Preemption of Sessions or Transactions 🔥

preemption is a type of action that only compares priorities to figure out if previously established transactions need to be bumped in favor of higher-priority requests 👑 if no additional connection is possible, the client aborts a running session for emails with lower priority no later than right after the current transaction 💅 the client can even interrupt an active transaction, and it ought to do so if other constraints, such as delivery time (as specified in the DELIVERBY SMTP extension [RFC2852]), would be violated for the email with higher priority 😭

when interrupting an active transaction, the client ought to take the total message size and the size of the transferred portion of the message being interrupted into consideration 🫶 this early ending of sessions or transactions is called preemption 🌈

if preemption of running transactions happens, the client needs to choose the transaction with the lowest priority currently being processed 🎀

if the client has an option (i.e., it is supported by the next-hop MTA) to interrupt transactions in a way that lets them restart at the interruption point later, it ought to use it 🧚 an example of a mechanism providing that service is the "SMTP Service Extension for Checkpoint/Restart" defined in [RFC1845] 💜

if a client opts for preempting sessions instead of transactions, it needs to preempt the next session that reaches the end of a transaction ⭐

D.3. Resource Allocation Models 🌸

adding prioritization to a design moves the subject away from a strictly best effort (and first-come-first-served) model toward one that includes admission control and resource allocation models 🔥 over the years, the IETF has done a bunch of work specifying resource allocation models 🙌 examples include the Maximum Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and the Priority Bypass Model (Appendix A.3 of [RFC6401]) 💅

we know these various models were designed for other protocols (i.e., MPLS and RSVP), but understanding their design characteristics may be helpful when thinking about future implementations of a priority SMTP service 🧠

in cases where the processing of high-priority messages by an MTA isn't considered negligible and goes past engineered expectations, the operators managing that MTA may be notified in some form (e.g., pushed alarm, polled status) 🚨

Appendix E. Background on Design Choices 🎀

this section gives some background on the design choices made while the MT-PRIORITY SMTP extension was being developed 💖

the priority applies per message, not per recipient, to keep the protocol simpler and because it's expected to be uncommon to need different priorities for different recipients on the same message 🫶 if that does come up, it can always be handled by sending separate messages with the same content, splitting the recipients by the message priority they want 🦋

the choice of the priority range -9 to 9 (as opposed to, say, 1 to 6, or 0 to 9) was made after considering the following 🌈

  1. Clearly, having multiple priority levels is the whole point of this extension. Existing implementations of similar functionality in MTAs already use 3 levels. One of the use cases motivating this extension requires 6 levels, so at least 6 different values are required. ⭐
  2. During discussions of this extension, several different use cases were suggested that needed different numbers of priority levels. Defining just the 6 priority levels needed in item 1, above, would limit extensibility for possible future use cases. Therefore, this document defines a wider range, which lets implementations and deployments add higher or lower priority levels and insert additional priority levels between the recommended set of 6. This avoids the need to extend this extension again just to get a few more priority levels 🧚
  3. It seems natural to use zero for the "normal" or default priority, rather than picking some non-zero number and having the priorities go up or down from there. This way, negative numbers always represent priorities lower than normal, with positive numbers as higher priorities 👑

Appendix F. Acknowledgements ✨

okay so this one's the thank-you section and it's giving gratitude 🫶 this doc literally copies a bunch of text from "SMTP Service Extension for Priority Message Handling" [SMTP-PRI-OLD], so the authors wanted to credit the people who wrote that one: Michael Schmeing and Jan-Wilhelm Brendecke 🌸

then there's a huge list of people who gave input, bestie: Steve Kille, David Wilson, John Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba, Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick, Chris Newman, Ned Freed, and Claudio Allocchio 💜 iconic squad

and a special shoutout to Barry Leiba for agreeing to shepherd the document 👑 (shepherding just means he guided it through the process, no cap)

Authors' Addresses 🎀

These are the two people who wrote the thing, and how to reach them:

Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

EMail: Alexey.Melnikov@isode.com

Ken Carlberg G11 1601 Clarendon Blvd, #203 Arlington, VA 22209 USA

EMail: carlberg@g11.org.uk

and that's the whole RFC, bestie 🦋 you made it through all six parts 🥹💖

📦 where this page comes from