<pre>Internet Engineering Task Force (IETF)                       A. Melnikov
Request for Comments: 6710                                     Isode Ltd
Category: Standards Track                                    K. Carlberg
ISSN: 2070-1721                                                      G11
                                                             August 2012


Simple Mail Transfer Protocol Extension for Message Transfer Priorities

Abstract

   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.

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6710">http://www.rfc-editor.org/info/rfc6710</a>.

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as 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 are provided without warranty as
   described in the Simplified BSD License.







<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


Table of Contents

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











<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Where resources for switching or transferring messages are
   constrained (e.g., bandwidth, round trip time, transition storage, or
   processing capability), it is desirable to give preferential handling
   to some messages over others, according to their labeled priority.
   This is particularly important during emergencies for first
   responders (Appendix C) and for environments such as military
   (Appendix A) and aviation (Appendix B) messaging, where messages have
   high operational significance, and the consequences of extraneous
   delay can be significant.

   In order for an SMTP receiver to be able to relay higher-priority
   messages first, there needs to be a mechanism to communicate (during
   both Message Submission [<a href="./rfc6409" title="&quot;Message Submission for Mail&quot;">RFC6409</a>] and Message Transfer [<a href="./rfc5321" title="&quot;Simple Mail Transfer Protocol&quot;">RFC5321</a>]) the
   priority of each message.  This specification defines this mechanism
   by specification of an SMTP [<a href="./rfc5321" title="&quot;Simple Mail Transfer Protocol&quot;">RFC5321</a>] extension.

   In order to permit end-to-end use of this extension across an email
   infrastructure that does not support it, a companion tunneling
   mechanism is defined in [<a href="#ref-PRIORITY-TUNNELING">PRIORITY-TUNNELING</a>] that uses a new message
   header field [<a href="./rfc5322" title="&quot;Internet Message Format&quot;">RFC5322</a>].

   This extension provides services to some classes of users in networks
   with limited available bandwidth or long round trip times, when the
   actual message transfer over the network can create a significant
   portion of the overall message delivery time from a sender to a
   recipient, for example, over a satellite or high-frequency radio
   link.  It is also useful in case of a Mail Transfer Agent (MTA) queue
   buildup due to the rate of incoming messages being higher than the
   rate of outgoing messages.  When neither of the two conditions
   mentioned above is true, the use of the MT-PRIORITY SMTP extension
   will not result in better SMTP service to any user.  Also note that
   while this SMTP extension can help in improving delivery speed for
   higher-priority messages, it does not provide any guarantees that for
   two given messages with priorities M and N (M &gt; N) submitted
   simultaneously, the message with priority M will arrive earlier than
   the message with priority N. That is, this extension calls for best
   effort to provide preferential processing.

   Besides the actions taken at the application level, it can thus be
   important to deploy priority or precedence mechanisms offered by the
   network itself to ensure timely delivery of the emails.  Examples
   would be the use of DiffServ [<a href="./rfc2474" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">RFC2474</a>], RSVP [<a href="./rfc2205" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">RFC2205</a>], and [<a href="./rfc6401" title="&quot;RSVP Extensions for Admission Priority&quot;">RFC6401</a>]
   (an extension to RSVP that prioritizes reservations).






<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions Used in This Document</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>] when they
   appear in ALL CAPS.  These words also appear in this document in
   lower case as plain English words, absent their normative meanings.

   The formal syntax uses the Augmented Backus-Naur Form (ABNF)
   [<a href="./rfc5234" title="&quot;Augmented BNF for Syntax Specifications: ABNF&quot;">RFC5234</a>] notation including the core rules defined in <a href="./rfc5234#appendix-B">Appendix&nbsp;B of
   RFC 5234</a> [<a href="./rfc5234" title="&quot;Augmented BNF for Syntax Specifications: ABNF&quot;">RFC5234</a>].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  Line breaks that do not start with a new "C:"
   or "S:" exist for editorial reasons and are not a part of the
   protocol.

   This document uses the term "priority" specifically in relation to
   the internal treatment of a message by the server.  Messages with
   higher priorities may be given expedited handling, and those with
   lower priorities may be handled only as resources become available.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Definition of the Priority SMTP Extension</span>

   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 associated with this extension is
       "MT-PRIORITY".

   3.  The EHLO keyword has an OPTIONAL parameter that conveys the name
       of the Priority Assignment Policy (see <a href="#section-9.2">Section 9.2</a>) used by the
       server.  (See the &lt;mt-priority-ehlo&gt; ABNF non-terminal in
       <a href="#section-7">Section 7</a> for details of its syntax.)  Absence of the parameter
       means that 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.  No additional SMTP verbs are defined by this extension.

   5.  One optional parameter ("MT-PRIORITY") is added to the MAIL FROM
       command.  The value associated with this parameter is a decimal
       integer number from -9 to 9 (inclusive) indicating the priority
       of the email message (see <a href="#appendix-E">Appendix E</a> for more details on why this
       range was selected).  The syntax of the MT-PRIORITY parameter is



<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


       described by the &lt;priority-value&gt; ABNF non-terminal defined in
       <a href="#section-7">Section 7</a>.  Higher numbers mean higher priority.

   6.  The maximum length of a MAIL FROM command line is increased by 15
       octets by the possible addition of a space, the MT-PRIORITY
       keyword, and a priority value.

   7.  The MT-PRIORITY extension is valid for the submission service
       [<a href="./rfc6409" title="&quot;Message Submission for Mail&quot;">RFC6409</a>] and the Local Mail Transfer Protocol (LMTP) [<a href="./rfc2033" title="&quot;Local Mail Transfer Protocol&quot;">RFC2033</a>].

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Handling of Messages Received via SMTP</span>

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

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server</span>

   The following rules apply to SMTP transactions in a server that
   supports the MT-PRIORITY parameter:

   1.  If any of the associated &lt;esmtp-value&gt;s (as defined in <a href="./rfc5321#section-4.1.2">Section</a>
       <a href="./rfc5321#section-4.1.2">4.1.2 of [RFC5321]</a>) 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
       [<a href="./rfc2034" title="&quot;SMTP Service Extension for Returning Enhanced Error Codes&quot;">RFC2034</a>] [<a href="./rfc5248" title="&quot;A Registry for SMTP Enhanced Mail System Status Codes&quot;">RFC5248</a>]).

   2.  When inserting a Received header field as specified in <a href="./rfc5321#section-4.4">Section</a>
       <a href="./rfc5321#section-4.4">4.4 of [RFC5321]</a>, the compliant MTA/MSA (Mail Submission Agent)
       SHOULD include the "PRIORITY" clause whose syntax is specified in
       <a href="#section-7">Section 7</a>.

   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



<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   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 [<a href="./rfc2034" title="&quot;SMTP Service Extension for Returning Enhanced Error Codes&quot;">RFC2034</a>] 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 [<a href="./rfc2034" title="&quot;SMTP Service Extension for Returning Enhanced Error Codes&quot;">RFC2034</a>] 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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Relay of Messages to Other Conforming SMTP/LMTP Servers</span>

   The following rules govern the behavior of a conforming MTA (in the
   role of an SMTP/LMTP client) when relaying a message that was
   received via the SMTP protocol to an SMTP/LMTP server that supports
   the MT-PRIORITY extension:

   1.  An MT-PRIORITY parameter with the value determined by the
       procedure from <a href="#section-4.1">Section 4.1</a> 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 <a href="#section-4.1">Section 4.1</a> 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 <a href="#section-5">Section 5</a>.)




<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   2.  Further processing of the MT-PRIORITY parameter is described in
       <a href="#section-5">Section 5</a>.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Relay of Messages to Non-Conforming SMTP/LMTP Servers</span>

   The following rules govern the behavior of a conforming MTA (in the
   role of an SMTP/LMTP client) when relaying a message that was
   received via the SMTP protocol to an SMTP/LMTP server that does not
   support the MT-PRIORITY extension:

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

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Mailing Lists and Aliases</span>

   Several types of mechanisms exist to redirect or forward messages to
   alternative or multiple addresses [<a href="./rfc5598" title="&quot;Internet Mail Architecture&quot;">RFC5598</a>].  Examples for this are
   aliases and mailing lists [<a href="./rfc5321" title="&quot;Simple Mail Transfer Protocol&quot;">RFC5321</a>].

   If a message is subject to such processing, the Mediator node
   (<a href="./rfc5598#section-2.1">Section&nbsp;2.1 of [RFC5598]</a>) SHOULD retain the MT-PRIORITY parameter
   value for all expanded and/or translated addresses.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Gatewaying a Message into a Foreign Environment</span>

   The following rules govern the behavior of a conforming MTA when
   gatewaying a message that was received via the SMTP protocol 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 (<a href="#section-4.3">Section 4.3</a>).

   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
       (<a href="#section-4.2">Section 4.2</a>), converting the MT-PRIORITY value to the equivalent
       in the destination environment.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  Interaction with the DSN SMTP Extension</span>

   An 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.  In particular, this
   requirement applies to MTAs that also implement [<a href="./rfc3461" title="&quot;Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)&quot;">RFC3461</a>].





<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   For delivery reports (DSNs) received by an MTA for relay, processing
   rules specified in <a href="#section-4.1">Section 4.1</a> apply -- there is no special
   processing for relayed DSNs.  It might seem tempting to try to detect
   DSNs and process them at an elevated priority under the assumption
   that failure notices need to get through quickly, even or perhaps
   especially if the DSN came from an untrusted source.  But such a
   policy can create an exposure to fake DSN attacks by giving untrusted
   systems a way to inject high-priority messages.  Implementation of
   such a policy also assumes that DSNs can be detected reliably, which
   may not be the case since some systems use nonstandard DSN formats.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  The Priority Service Extension</span>

   The priorities of messages affect the order in which messages are
   transferred from the client to the server.  This is largely
   independent from the order in which they were originally received by
   the server.

   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 <a href="#section-9.2">Section 9.2</a>) implemented by the server.  That is, an
   implementation that only supports N priority levels (where N &lt; 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 <a href="#section-9.2">Section 9.2</a> 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 <a href="#section-4.1">Section 4.1</a>.

   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 <a href="#appendix-E">Appendix E</a> 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



<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   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 [<a href="./rfc2034" title="&quot;SMTP Service Extension for Returning Enhanced Error Codes&quot;">RFC2034</a>].

   Implementation Note: If the SMTP server also supports the SMTP SIZE
   extension [<a href="./rfc1870" title="&quot;SMTP Service Extension for Message Size Declaration&quot;">RFC1870</a>], 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
   [<a href="./rfc2852" title="&quot;Deliver By SMTP Service Extension&quot;">RFC2852</a>] SMTP service extension; however, there is no requirement
   that both extensions always be implemented together.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Expedited Transfer</span>

   The main service provided by the Priority Message Handling SMTP
   Service Extension is expedited transfer of emails with a higher
   priority.  Therefore, an SMTP client that has more than one email to
   send at a given time sends those with a higher priority before those
   with a lower one.  Additionally, 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 as this SMTP extension requires some sort of trust
   relationship between a sender and a receiver and thus 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 [<a href="./rfc6647" title="&quot;Email Greylisting: An Applicability Statement for SMTP&quot;">RFC6647</a>], 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.

   In order 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.







<span class="grey">Melnikov &amp; Carlberg          Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   Several possible ways of implementing expedited transfer are
   described in more details in <a href="#appendix-D">Appendix D</a>.  Note that these sections
   don't describe all details and pitfalls for each implementation
   strategy.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Timely Delivery</span>

   An important constraint (usually associated with higher-priority
   levels) in some environments is that messages with high-priority
   values have some delivery time constraints.  In some cases, higher
   priorities mean a shorter maximum time allowed for delivery.

   Unextended SMTP does not offer a service for timely delivery, i.e.,
   "deliver this message within X seconds from submission" service.  The
   "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
   [<a href="./rfc2852" title="&quot;Deliver By SMTP Service Extension&quot;">RFC2852</a>] is an example of an SMTP extension providing a service that
   can be used to implement timely delivery.  Note that SMTP DELIVERBY
   and SMTP MT-PRIORITY extensions are complimentary and can be used
   together (assuming the SMTP server they are talking to advertises
   support for both).  However, note that use of the DELIVERBY extension
   alone does not guarantee any priority processing.  If the client is
   using both SMTP DELIVERBY and SMTP MT-PRIORITY at the same time, the
   client can consider using smaller DELIVERBY timeouts for higher-
   priority messages.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Use of MT-PRIORITY with LMTP</span>

   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
       [<a href="./rfc5228" title="&quot;Sieve: An Email Filtering Language&quot;">RFC5228</a>].












<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Syntax</span>

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

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

   CFWS = &lt;defined in <a href="./rfc5322">RFC 5322</a>&gt;

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

   mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile]
             ; Complies with the &lt;ehlo-line&gt; ABNF production
             ; from <a href="./rfc5321">RFC 5321</a>.

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

   ALPHA = &lt;Defined in <a href="./rfc5234">RFC 5234</a>&gt;

   DIGIT = &lt;Defined in <a href="./rfc5234">RFC 5234</a>&gt;

























<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Example</span>

   The original submission (from MUA (Mail User Agent) to MSA) might
   appear as shown below.  Note that the example is also making use of
   the STARTTLS [<a href="./rfc3207" title="&quot;SMTP Service Extension for Secure SMTP over Transport Layer Security&quot;">RFC3207</a>], DELIVERBY [<a href="./rfc2852" title="&quot;Deliver By SMTP Service Extension&quot;">RFC2852</a>], and DSN [<a href="./rfc3461" title="&quot;Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)&quot;">RFC3461</a>] SMTP
   extensions, even though there is no requirement that these other
   extensions be supported when the MT-PRIORITY SMTP extension is
   implemented.

        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:&lt;eljefe@example.com&gt; BY=125;R ENVID=QQ314159
            MT-PRIORITY=3
        S: 250 2.1.0 &lt;eljefe@example.com&gt; sender ok
        C: RCPT TO:&lt;topbanana@example.net&gt;
        S: 250 2.1.5 &lt;topbanana@example.net&gt; recipient ok
        C: RCPT TO:&lt;Dana@Ivory.example.net&gt; NOTIFY=SUCCESS,FAILURE
            ORCPT=<a href="./rfc822">rfc822</a>;Dana@Ivory.example.net
        S: 250 2.1.5 &lt;Dana@Ivory.example.net&gt; 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 the 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:










<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


        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:&lt;eljefe@example.com&gt; BY=125;R ENVID=QQ314159
        S: 250 2.1.0 &lt;eljefe@example.com&gt; sender ok
        C: RCPT TO:&lt;topbanana@example.net&gt;
        S: 250 2.1.5 &lt;topbanana@example.net&gt; recipient ok
        C: RCPT TO:&lt;Dana@Ivory.example.net&gt; NOTIFY=SUCCESS,FAILURE
            ORCPT=<a href="./rfc822">rfc822</a>;Dana@Ivory.example.net
        S: 250 2.1.5 &lt;Dana@Ivory.example.net&gt; 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 the above example, the MUA has not specified any priority, but the
   MSA has assigned priority 3 to the message.  Also note that the
   server is unwilling to adverte the Priority Assignment Policy it
   supports in the EHLO response.

   The MSA relays the message to the next MTA.


















<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


        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:&lt;eljefe@example.com&gt; BY=120;R ENVID=QQ314159
            MT-PRIORITY=3
        S: 250 &lt;eljefe@example.com&gt; sender ok
        C: RCPT TO:&lt;topbanana@example.net&gt;
        S: 250 &lt;topbanana@example.net&gt; recipient ok
        C: RCPT TO:&lt;Dana@Ivory.example.net&gt; NOTIFY=SUCCESS,FAILURE
            ORCPT=<a href="./rfc822">rfc822</a>;Dana@Ivory.example.net
        S: 250 &lt;Dana@Ivory.example.net&gt; 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 <a href="#appendix-A">Appendix A</a>.  This means that the server will use the
   priority value 4 internally (the next supported priority higher or
   equal to 3) and will communicate the priority value 3 when relaying
   it to the next hop (if necessary).

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Deployment Considerations</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Multiple MX Records</span>

   If multiple DNS MX records are used to specify multiple servers for a
   domain in <a href="./rfc5321#section-5">Section&nbsp;5 of [RFC5321]</a>, it is 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 is 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, which users might perceive as
   serious reliability issues.









<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Priority Assignment Policies</span>

   This document allows up to 19 distinct priority values.  In a
   particular operating environment, independent originators need to
   assign priority values according to, roughly, the same criteria, so
   that the same "high priority message" doesn't get associated with the
   value 3 for one sender and with the value 5 for another, as such
   messages might unintentionally receive different preferential
   treatment.

   In order to achieve consistent behavior in an operating environment,
   the Priority Assignment Policy (together with possible associated
   restrictions on maximum message sizes for each priority (if any),
   default timeouts, etc.) should be documented for the environment.
   Each SMTP/LMTP server supports a Priority Assignment Policy, whether
   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 <a href="#appendix-B">Appendix B</a>.  Two other
   policies are specified in <a href="#appendix-A">Appendix A</a> and <a href="#appendix-C">Appendix C</a>.  Additional
   policies SHOULD be registered with IANA as specified in <a href="#section-10.1">Section 10.1</a>.

   Moreover, all MSAs/MTAs/MDAs within any given Administrative
   Management Domain has 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, such Administrative 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.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  IANA Considerations</span>

   IANA has added the MT-PRIORITY SMTP extension to the "SMTP Service
   Extensions" registry
   (<a href="http://www.iana.org/assignments/mail-parameters">http://www.iana.org/assignments/mail-parameters</a>).  This extension is
   suitable for the Submit port.

   IANA has added the following new Received header field clause to the
   "Additional-registered-clauses" sub-registry
   (<a href="http://www.iana.org/assignments/mail-parameters">http://www.iana.org/assignments/mail-parameters</a>) to help with
   tracing email messages delivered using the MT-PRIORITY SMTP
   extension:




<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   Clause name: PRIORITY
   Description: Records the value of the MT-PRIORITY parameter specified
                in the MAIL FROM command
   Syntax of the value: See <a href="./rfc6710#section-7">Section&nbsp;7 of RFC 6710</a>
   Reference: <a href="./rfc6710">RFC 6710</a>

   IANA has added the following Enumerated Status Codes to the "Simple
   Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry
   (<a href="http://www.iana.org/assignments/smtp-enhanced-status-codes">http://www.iana.org/assignments/smtp-enhanced-status-codes</a>)
   established by [<a href="./rfc5248" title="&quot;A Registry for SMTP Enhanced Mail System Status Codes&quot;">RFC5248</a>]:

   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 specified priority level is below the lowest
          priority acceptable for the receiving SMTP server.  This
          condition might be temporary, for example the server is
          operating in a mode where only higher-priority messages are
          accepted for transfer and delivery, while lower-priority
          messages are rejected.

       Reference:  <a href="./rfc6710">RFC 6710</a>

       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 specified priority.
       This condition might be temporary, for example the server is
       operating in a mode where only higher-priority messages below a
       certain size are accepted for transfer and delivery.

       Reference:  <a href="./rfc6710">RFC 6710</a>

       Submitter:  A. Melnikov

       Change controller:  IESG



<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   3)  Code:  X.3.6

       Sample Text:  Requested priority was changed

       Associated basic status code:  250 or 251

       Description:  The message was accepted for relay/delivery, but
          the requested priority (possibly the implied default) was not
          honored.  The human readable text after the status code
          contains the new priority, followed by SP (space) and
          explanatory human readable text.

       Reference:  <a href="./rfc6710">RFC 6710</a>

       Submitter:  A. Melnikov

       Change controller:  IESG

   IANA has created a new IANA registry called "SMTP PRIORITY Extension
   Priority Assignment Policy".  Future registrations in this registry
   are governed by the "Specification Required" [<a href="./rfc5226" title="">RFC5226</a>] IANA
   registration policy.  Requirements on registrations (to be verified
   by the Designated Expert) are specified in <a href="#section-10.1">Section 10.1</a>.  Changes to
   registrations undergo the same process as initial registrations.  In
   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.

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Requirements on Priority Assignment Policy Registrations</span>

   Priority Assignment Policy registrations with IANA are accompanied by
   a policy specification document that MUST specify the following
   information:

   1.  The Priority Assignment Policy name, which is a case-insensitive
       string of 1 to 20 US-ASCII characters to be advertised as the
       MT-PRIORITY EHLO parameter.  Allowed characters are: ALPHA,
       DIGIT, "-", "_", and "."

   2.  Number of distinct priority levels supported by all servers
       implementing the policy and their respective values.

   3.  For each supported priority level: default retry timeouts (how
       often to retry sending a message if there is a temporary error to
       transfer/deliver it).  The policy specification can also
       explicitly define such information as implementation and/or
       deployment specific.



<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   4.  For each supported priority level: default expiration timeouts
       (how long to attempt transfer/delivery before the message expires
       and causes a non-delivery report to be generated).  The policy
       specification can also explicitly define such information as
       implementation and/or deployment specific.  Note that a client
       can override such default when it uses additional SMTP extensions
       (such as the one mentioned in <a href="#section-5.2">Section 5.2</a>).

   5.  Maximum message size associated with each priority level.  The
       policy specification can also explicitly define such information
       as implementation and/or deployment specific.

   6.  Any requirements/restrictions on the kind of SMTP client
       authentication required in order for an SMTP server implementing
       this policy to accept priority values specified by an SMTP
       client.  For example, this can limit which Simple Authentication
       and Security Layer (SASL) [<a href="./rfc4422" title="&quot;Simple Authentication and Security Layer (SASL)&quot;">RFC4422</a>] authentication mechanisms are
       to be used, require TLS, etc.

   7.  Any other information that might affect processing of messages
       with different priorities.

   8.  Note that the policy specification document is not allowed to
       redefine the allowed range of priorities specified in <a href="#section-5">Section 5</a>
       and other aspects of handling of different priorities, unless
       explicitly specified by this document.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Initial Priority Assignment Policy Registrations</span>

   IANA has registered the following initial values in the "SMTP
   PRIORITY Extension Priority Assignment Policy" registry:

             Initial Priority Assignment Policy Registrations

         +-------------+------------------------+----------------+
         | Policy Name | Reference              | Comment        |
         +-------------+------------------------+----------------+
         | MIXER       | <a href="./rfc6710#appendix-B">Appendix&nbsp;B of RFC 6710</a> | Default policy |
         | STANAG4406  | <a href="./rfc6710#appendix-A">Appendix&nbsp;A of RFC 6710</a> |                |
         | NSEP        | <a href="./rfc6710#appendix-C">Appendix&nbsp;C of RFC 6710</a> |                |
         +-------------+------------------------+----------------+

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Security Considerations</span>

   Message Submission Agents ought to only accept message transfer
   priorities from users (or only certain groups of such users) who are
   authenticated and authorized in some way that's acceptable to the
   MSA.  As part of this policy, they can also restrict maximum priority



<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   values that different groups of users can request, and can override
   the priority values specified by MUAs.

   Similarly, MTAs ought to only accept message transfer priorities from
   senders (or only certain groups of such senders) who are
   authenticated and authorized in some way that's acceptable to the
   MTA.  As part of this policy, they can also restrict maximum priority
   values that different groups of senders can request, and can override
   the priority values specified by them.

   In the absence of the policy enforcement mentioned above, an SMTP
   server (whether an MSA or an MTA) implementing this SMTP extension
   might be susceptible to a denial-of-service attack.  For example,
   malicious clients (MUAs/MSAs/MTAs) can try to abuse this feature by
   always requesting priority 9.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  References</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Normative References</span>

   [<a id="ref-RFC2033">RFC2033</a>]  Myers, J., "Local Mail Transfer Protocol", <a href="./rfc2033">RFC 2033</a>,
              October 1996.

   [<a id="ref-RFC2034">RFC2034</a>]  Freed, N., "SMTP Service Extension for Returning Enhanced
              Error Codes", <a href="./rfc2034">RFC 2034</a>, October 1996.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3461">RFC3461</a>]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              <a href="./rfc3461">RFC 3461</a>, January 2003.

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              May 2008.

   [<a id="ref-RFC5234">RFC5234</a>]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.

   [<a id="ref-RFC5248">RFC5248</a>]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
              Mail System Status Codes", <a href="https://www.rfc-editor.org/bcp/bcp138">BCP 138</a>, <a href="./rfc5248">RFC 5248</a>, June 2008.

   [<a id="ref-RFC5321">RFC5321</a>]  Klensin, J., "Simple Mail Transfer Protocol", <a href="./rfc5321">RFC 5321</a>,
              October 2008.






<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   [<a id="ref-RFC5322">RFC5322</a>]  Resnick, P., Ed., "Internet Message Format", <a href="./rfc5322">RFC 5322</a>,
              October 2008.

   [<a id="ref-RFC6409">RFC6409</a>]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, <a href="./rfc6409">RFC 6409</a>, November 2011.

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  Informative References</span>

   [<a id="ref-ACP123">ACP123</a>]   CCEB, "Common Messaging strategy and procedures", ACP 123,
              May 2009.

   [<a id="ref-PRIORITY-TUNNELING">PRIORITY-TUNNELING</a>]
              Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message
              Transfer Priorities", Work in Progress, July 2012.

   [<a id="ref-RFC1845">RFC1845</a>]  Crocker, D., Freed, N., and A. Cargille, "SMTP Service
              Extension for Checkpoint/Restart", <a href="./rfc1845">RFC 1845</a>,
              September 1995.

   [<a id="ref-RFC1870">RFC1870</a>]  Klensin, J., Freed, N., and K. Moore, "SMTP Service
              Extension for Message Size Declaration", STD 10, <a href="./rfc1870">RFC 1870</a>,
              November 1995.

   [<a id="ref-RFC2156">RFC2156</a>]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
              Mapping between X.400 and <a href="./rfc822">RFC 822</a>/MIME", <a href="./rfc2156">RFC 2156</a>,
              January 1998.

   [<a id="ref-RFC2205">RFC2205</a>]  Braden, B., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.

   [<a id="ref-RFC2474">RFC2474</a>]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>,
              December 1998.

   [<a id="ref-RFC2852">RFC2852</a>]  Newman, D., "Deliver By SMTP Service Extension", <a href="./rfc2852">RFC 2852</a>,
              June 2000.

   [<a id="ref-RFC3207">RFC3207</a>]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", <a href="./rfc3207">RFC 3207</a>, February 2002.

   [<a id="ref-RFC4125">RFC4125</a>]  Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
              Constraints Model for Diffserv-aware MPLS Traffic
              Engineering", <a href="./rfc4125">RFC 4125</a>, June 2005.






<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   [<a id="ref-RFC4127">RFC4127</a>]  Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
              Model for Diffserv-aware MPLS Traffic Engineering",
              <a href="./rfc4127">RFC 4127</a>, June 2005.

   [<a id="ref-RFC4190">RFC4190</a>]  Carlberg, K., Brown, I., and C. Beard, "Framework for
              Supporting Emergency Telecommunications Service (ETS) in
              IP Telephony", <a href="./rfc4190">RFC 4190</a>, November 2005.

   [<a id="ref-RFC4412">RFC4412</a>]  Schulzrinne, H. and J. Polk, "Communications Resource
              Priority for the Session Initiation Protocol (SIP)",
              <a href="./rfc4412">RFC 4412</a>, February 2006.

   [<a id="ref-RFC4422">RFC4422</a>]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", <a href="./rfc4422">RFC 4422</a>,
              June 2006.

   [<a id="ref-RFC5228">RFC5228</a>]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", <a href="./rfc5228">RFC 5228</a>, January 2008.

   [<a id="ref-RFC5598">RFC5598</a>]  Crocker, D., "Internet Mail Architecture", <a href="./rfc5598">RFC 5598</a>,
              July 2009.

   [<a id="ref-RFC6401">RFC6401</a>]  Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP
              Extensions for Admission Priority", <a href="./rfc6401">RFC 6401</a>,
              October 2011.

   [<a id="ref-RFC6647">RFC6647</a>]  Kucherawy, M. and D. Crocker, "Email Greylisting: An
              Applicability Statement for SMTP", <a href="./rfc6647">RFC 6647</a>, June 2012.

   [<a id="ref-SMTP-PRI-OLD">SMTP-PRI-OLD</a>]
              Schmeing, M., Brendecke, J., and K. Carlberg, "SMTP
              Service Extension for Priority Message Handling", Work
              in Progress, August 2006.

   [<a id="ref-STANAG-4406">STANAG-4406</a>]
              NATO, "STANAG 4406 Edition 2: Military Message Handling
              System", STANAG 4406, March 2005.














<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Priority Assignment Policy for Military Messaging</span>

   Military Messaging as specified in ACP 123 [<a href="#ref-ACP123" title="&quot;Common Messaging strategy and procedures&quot;">ACP123</a>] (also specified
   in STANAG 4406 [<a href="#ref-STANAG-4406">STANAG-4406</a>]) defines 6 priority ("precedence")
   values.  While 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), only 6 are 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.



<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Priority Assignment Policy for MIXER</span>

   MIXER [<a href="./rfc2156" title="&quot;MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME&quot;">RFC2156</a>] defines the Priority header field with 3 values.
   This section specifies the Priority Assignment Policy for MIXER and
   how the MT-PRIORITY parameter can be mapped when 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.

<span class="h2"><a class="selflink" id="appendix-C" href="#appendix-C">Appendix C</a>.  Priority Assignment Policy for National Security /</span>
             Emergency Preparedness (NS/EP)

   There are several forms of communication systems used during an
   emergency or disaster.  The most well known form involves the many-
   to-one model of the general public contacting a public safety access
   point via 911/999/112 calls through the public telephone network.




<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   Typically, these calls do not require authorization, nor do they
   invoke any prioritization.

   Another form of emergency communications involves a set of authorized
   users or nodes that use prioritized services to help establish and
   continue communication given limited available resources.  [<a href="./rfc4190" title="&quot;Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony&quot;">RFC4190</a>]
   includes descriptions of several systems that have been developed to
   support National Security / Emergency Preparedness (NS/EP).  These
   deployed systems require a form of authentication and have focused on
   prioritization of telephony-based services.  They have also been
   designed as a binary form (on/off) of signaled priority
   communications.

   [<a id="ref-RFC4412">RFC4412</a>] includes examples of a more expansive view of NS/EP
   communications in which priority migrates from a single on/off bit
   value to one that comprises 5 priority values.  This is shown in the
   cases of the Emergency Telecommunications Service (ETS) and Wireless
   Priority Service (WPS) Namespaces.  Given a lack of 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.




<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   6.  No restrictions on what kind of SMTP client authentication is
       required.

<span class="h2"><a class="selflink" id="appendix-D" href="#appendix-D">Appendix D</a>.  Possible Implementation Strategies</span>

   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.

<span class="h3"><a class="selflink" id="appendix-D.1" href="#appendix-D.1">D.1</a>.  Probability</span>

   As the name suggests, probability involves increasing the chances of
   obtaining resources without adversely affecting previously
   established connections.  One example would involve requesting
   resources set aside for specific priority levels.  If these
   additional resources are exhausted, then the desired connection is
   denied.  Queues, new timers, or combinations thereof can be used to
   facilitate the higher-priority requests, but the key is that
   mechanisms focus on increasing the probability of message transfer.

<span class="h3"><a class="selflink" id="appendix-D.2" href="#appendix-D.2">D.2</a>.  Preemption of Sessions or Transactions</span>

   Preemption is a type of action that focuses only on a comparison of
   priorities to determine if previously established transactions need
   to be displaced 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 directly after
   the current transaction.  The client can even interrupt an active
   transaction, and ought to do so if other constraints, such as
   delivery time (as specified in the DELIVERBY SMTP extension
   [<a href="./rfc2852" title="&quot;Deliver By SMTP Service Extension&quot;">RFC2852</a>]), 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 preliminary
   termination of sessions or transactions is called preemption.

   If preemption of running transactions occurs, the client needs to
   choose a transaction with the lowest priority currently processed.

   If the client has an option (i.e., it is supported by the next-hop
   MTA) to interrupt transactions in a way that allows them to be
   restarted at the interruption point later, it ought to deploy it.  An
   example for a mechanism providing such a service is the "SMTP Service
   Extension for Checkpoint/Restart" defined in [<a href="./rfc1845" title="&quot;SMTP Service Extension for Checkpoint/Restart&quot;">RFC1845</a>].





<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   If a client opts for the preemption of sessions instead of
   transactions, it needs to preempt the next session that reaches the
   end of a transaction.

<span class="h3"><a class="selflink" id="appendix-D.3" href="#appendix-D.3">D.3</a>.  Resource Allocation Models</span>

   Adding prioritization to a design moves the subject away from a
   strictly best effort (and a first-come-first-served) model to one
   that includes admission control and resource allocation models.  Over
   the years, a variety of work has been done within the IETF to specify
   resource allocations models.  Examples include the Maximum Allocation
   Model [<a href="./rfc4125" title="&quot;Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering&quot;">RFC4125</a>], the Russian Dolls Model [<a href="./rfc4127" title="&quot;Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering&quot;">RFC4127</a>], and the Priority
   Bypass Model (Appendix A.3 of [<a href="./rfc6401" title="&quot;RSVP Extensions for Admission Priority&quot;">RFC6401</a>]).

   While we recognize that these various models have been designed for
   other protocols (i.e., MPLS and RSVP), an understanding of their
   design characteristics may be beneficial in considering future
   implementations of a priority SMTP service.

   In cases where the processing of high-priority messages by an MTA is
   not considered negligible and exceeds engineered expectations, then
   operators managing that MTA may be notified in some form (e.g.,
   pushed alarm, polled status).

<span class="h2"><a class="selflink" id="appendix-E" href="#appendix-E">Appendix E</a>.  Background on Design Choices</span>

   This section provides some background on design choices made during
   development of the MT-PRIORITY SMTP extension.

   The priority applies per message, rather than per recipient, in order
   to keep the protocol simpler and because of the expectation that it
   will be uncommon to need different priorities for different
   recipients on the same message.  In cases where that is necessary, it
   can always be achieved by sending separate messages with the same
   content, segregating the recipients by desired message priority.

   The choice of the priority range -9 to 9 (as opposed to, say, 1 to 6,
   or 0 to 9) was made after taking the following into consideration:

   1.  Clearly, having multiple priority levels is the whole point of
       this extension.  Existing implementations of similar
       functionality in MTAs are already using 3 levels.  One of the use
       cases motivating this extension requires 6 levels, so at least 6
       different values are required.







<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


   2.  During discussions of this extension, several different use cases
       were suggested that required differing numbers of priority
       levels.  Defining just the 6 priority levels needed in item 1,
       above, would limit the extensibility for possible future use
       cases.  Therefore, this document is defining a wider range, which
       allows implementations and deployments to add higher or lower
       priority levels and to insert additional priority levels between
       the recommended set of 6.  This avoids the need to further extend
       this extension just to have 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 that are lower than normal, with
       positive numbers as higher priorities.

<span class="h2"><a class="selflink" id="appendix-F" href="#appendix-F">Appendix F</a>.  Acknowledgements</span>

   This document copies lots of text from "SMTP Service Extension for
   Priority Message Handling" [<a href="#ref-SMTP-PRI-OLD">SMTP-PRI-OLD</a>].  Therefore, the authors of
   this document would like to acknowledge contributions made by the
   authors of that document: Michael Schmeing and Jan-Wilhelm Brendecke.

   Many thanks for input provided by 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.

   Special thanks to Barry Leiba for agreeing to shepherd this document.






















<span class="grey">Melnikov &amp; Carlberg          Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6710">RFC 6710</a>        Message Transfer Priority SMTP Extension     August 2012</span>


Authors' Addresses

   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
































Melnikov &amp; Carlberg          Standards Track                   [Page 28]
</pre>