[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 6710

Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Standards Track                             K. Carlberg
Expires: August 17, 2012                                             G11
                                                       February 14, 2012


Simple Mail Transfer Protocol extension for Message Transfer Priorities
                    draft-melnikov-smtp-priority-07

Abstract

   This memo defines an extension to the SMTP (Simple Mail Transfer
   Protocol) service whereby messages are sent with a priority to enable
   receivers to take this into account for onward processing, with the
   general goal of processing and/or transferring higher priority
   messages first.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 17, 2012.

Copyright Notice

   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, 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



Melnikov & Carlberg      Expires August 17, 2012                [Page 1]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Definition of the Priority SMTP Extension  . . . . . . . . . .  4
   4.  Handling of messages received via SMTP . . . . . . . . . . . .  5
     4.1.  Handling of the PRIORITY parameter by the receiving
           SMTP server  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Determining priority of a message  . . . . . . . . . . . .  5
     4.3.  Relay of messages to other conforming SMTP servers . . . .  6
     4.4.  Relay of messages to non-conforming SMTP servers . . . . .  6
     4.5.  Mailing lists and Aliases  . . . . . . . . . . . . . . . .  7
     4.6.  Gatewaying a message into a foreign environment  . . . . .  7
     4.7.  Interaction with DSN SMTP Extension  . . . . . . . . . . .  7
   5.  The Priority Service Extension . . . . . . . . . . . . . . . .  7
     5.1.  Expedited Transfer . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Timely Delivery  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Header field: MT-Priority  . . . . . . . . . . . . . . . . . . 10
   7.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 12
   10. Pending changes  . . . . . . . . . . . . . . . . . . . . . . . 12
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     12.1. Modification of MT-Priority header field and DKIM  . . . . 15
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     13.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Mapping of PRIORITY parameter values for Military
                Messaging . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix B.  Mapping of PRIORITY parameter values for MIXER  . . . 17
   Appendix C.  Mapping of National Security / Emergency
                Preparedness (NS/EP) Values . . . . . . . . . . . . . 18
   Appendix D.  Two possible implementation strategies  . . . . . . . 19
     D.1.  Probability  . . . . . . . . . . . . . . . . . . . . . . . 19
     D.2.  Preemption of sessions or transactions . . . . . . . . . . 19
   Appendix E.  Resource Allocation Models  . . . . . . . . . . . . . 20
   Appendix F.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20











Melnikov & Carlberg      Expires August 17, 2012                [Page 2]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


1.  Introduction

   Where resources for switching or transfer of messages are constrained
   (e.g., bandwidth, round trip time or processing capability) it is
   desirable to process high priority messages first.  This is
   particularly important during emergencies for first responders and
   for environments such as military 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 send higher priority
   messages first, there needs to be a mechanism to communicate (during
   both Message Submission [RFC6409] and Message Transfer [RFC5321]) the
   priority of each message.  This specification defines this mechanism
   by specification of an SMTP [RFC5321] extension.  It also enables
   communication of message priority through Message Transfer Agents
   (MTAs) that are not priority aware, by the specification of a new
   message header field [RFC5322].

   Various MUAs already use various other header fields that convey a
   similar meaning, such as message importance.  Example of such header
   fields are Importance [RFC2156], Priority [RFC2156] and X-Priority
   (undocumented).  Considering subtle differences in the meaning of
   these header fields and widely different syntax, this document
   defines a new header field.

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].

   The formal syntax use 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:" indicate lines sent by the client and
   server respectively.  Line breaks that do not start a new "C:" or
   "S:" exist for editorial reasons and are not a part of the protocol.

   This document uses the term "priority" in the meaning of expedited
   treatment of a message by the server according to the message's
   priority.

   This document uses the phrase "an email is waiting to be sent", if it
   resides in the outbound queue of an MTA or an Mail Submission Agent
   (MSA) and can be sent to the next hop or delivered to its final
   recipient(s) once available resources at the sending MTA/MSA allow



Melnikov & Carlberg      Expires August 17, 2012                [Page 3]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   this.  Emails having their processing delayed for some reason within
   the MTA/MSA are not waiting to be sent during this delay.  The most
   important reason for emails to be delayed is a transient error
   response from the next MTA to which the email must be transferred.

   This document uses the phrase "an email is ready to be sent", if it
   is waiting to be sent and either no emails with higher priority are
   waiting to be sent or available resources allow more emails to be
   sent in parallel than the number of emails with higher priorities
   that are waiting to be sent.  Note that an email may be ready to be
   sent but the transfer or delivery process can not yet be initiated,
   because the number of emails ready to be sent exceeds the number of
   emails that can be processed in parallel.

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

   3.  The EHLO keyword has no parameters.  Parameters are reserved for
       possible future extensions and MUST be ignored by clients that
       don't understand them.

   4.  No additional SMTP verbs are defined by this extension.

   5.  One optional parameter ("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.  The syntax of the 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 command line is increased by 13
       characters by the possible addition of the PRIORITY keyword and
       value.

   7.  The PRIORITY extension is valid for the submission service
       [RFC6409] and LTMP [RFC2033].








Melnikov & Carlberg      Expires August 17, 2012                [Page 4]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


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 PRIORITY parameter by the receiving SMTP server

   The following rules apply to SMTP transactions in which the PRIORITY
   parameter is used:

   1.  A conforming SMTP server SHOULD NOT refuse a MAIL command based
       on the absence of the PRIORITY parameter.  However, if any of the
       associated esmtp-values are not syntactically valid, or if there
       is more than one PRIORITY parameter in a particular MAIL command,
       the server MUST return an error, for example "501 syntax error in
       parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).

   Additionally, when inserting a Received header field as specified in
   Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
   "PRI" clause which syntax is specified in Section 7.

4.2.  Determining priority of a message

   An SMTP server compliant with this specification can determine the
   priority of a received message as follows:

   1.  If the sending SMTP client specified the PRIORITY parameter to
       the MAIL FROM command, then the value of this parameter is the
       message priority.

   2.  If the sending SMTP client hasn't specified the PRIORITY
       parameter to the MAIL FROM command, but the message has a single
       syntactically valid MT-Priority header field Section 6, then the
       value of this header field is the message priority.

   3.  Otherwise (if no PRIORITY parameter to the MAIL command was
       specified and the message doesn't contain a syntactically valid
       MT-Priority header field, or contains multiple MT-Priority header
       fields) the message has priority 0.

   Other message header fields, such as Importance [RFC2156], Priority
   [RFC2156] and X-Priority, MUST NOT be used for determining the
   priority under this "Priority Message Handling" SMTP extension.

   The SMTP server (MTA or MSA) SHOULD ignore or downgrade priorities
   from untrusted (e.g. unauthenticated) or insufficiently trusted
   sources.  (One example of an "insufficiently trusted source" might be
   an SMTP sender which authenticated using SMTP AUTH, but which is not



Melnikov & Carlberg      Expires August 17, 2012                [Page 5]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   explicitly whitelisted to use the SMTP PRIORITY service.)  If the
   SMTP server does that, it MAY use the X.7.TBD3 [RFC2034] enhanced
   status code.  Alternatively an SMTP server which is an MSA MAY reject
   a message based on the determined priority.  If the latter case, the
   MSA SHOULD use 450 or 550 reply code.  The corresponding enhanced
   status code MUST be X.7.TBD1 [RFC2034] if the determined priority
   level is below the lowest priority acceptable for the receiving SMTP
   server.  Note that this condition might be temporary, for example the
   server is temporarily operating under the Minimize condition where
   only high priority messages are accepted for transfer and delivery.

   Additionally, the MSA MAY alter the message priority (both to lower
   or to raise it) in order to enforce sender site policy.  If the MSA
   lowers the priority, it SHOULD use the X.7.TBD3 [RFC2034] enhanced
   status code.  For example the MSA can have a mapping table which
   assigns priorities to messages based on authentication credentials.

4.3.  Relay of messages to other conforming SMTP servers

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

   1.  A PRIORITY parameter with the value determined by the procedure
       from Section 4.2 MUST appear in the MAIL command issued when the
       message is relayed to an MTA/MDA which also supports the PRIORITY
       extension.  (For example, once an MTA accepts a message, the MTA
       MUST NOT change a (syntactically valid) priority value if the MTA
       doesn't support it.)  Note that this rule also applies to
       messages which didn't have any priority explicitly specified
       (using the PRIORITY MAIL FROM parameter or the MT-Priority header
       field).

   2.  Further processing of the PRIORITY parameter is described in
       Section 5.

4.4.  Relay of messages to non-conforming SMTP servers

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

   1.  A PRIORITY parameter MUST NOT appear in the MAIL command issued
       when relaying the message.





Melnikov & Carlberg      Expires August 17, 2012                [Page 6]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   2.  The relaying MTA MUST first remove any and all existing MT-
       Priority header fields from the message, and then add its own MT-
       Priority header field with the value determined by the procedure
       in Section 4.2.  One exception to this rule is that a message
       which didn't contain any MT-Priority header field and which
       didn't have the PRIORITY MAIL FROM parameter specified doesn't
       need to be updated to contain the "MT-Priority: 0" header field.
       Syntax of the MT-Priority header field is specified in Section 7.

4.5.  Mailing lists and Aliases

   Several options exist to translate the address of an email recipient
   into one or more other addresses.  Examples for this are aliases and
   mailing lists [RFC5321].

   If a recipient address is to be translated and/or expanded when
   delivered to an alias or a mailing list, the translating or expanding
   entity (MTA, etc.)  SHOULD retain the original priority for all
   expanded and/or translated addresses.

4.6.  Gatewaying a message into a foreign environment

   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 PRIORITY parameter, the conforming MTA SHOULD behave as if
       it is relaying to a non-conformant SMTP (Section 4.4).

   2.  If the destination environment is capable of providing an
       equivalent of the PRIORITY parameter, the conforming MTA SHOULD
       behave as if it is relaying to a conformant SMTP (Section 4.3),
       converting the PRIORITY parameter to the equivalent in the
       destination environment.

4.7.  Interaction with DSN SMTP Extension

   An MTA which also conforms to [RFC3461] SHOULD apply the same
   priority value to delivery reports (whether for successful delivery
   or failed delivery) it generates for a message.

5.  The Priority Service Extension

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



Melnikov & Carlberg      Expires August 17, 2012                [Page 7]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   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
   at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
   9.  I.e. an implementation that only supports the 6 priority levels
   will internally treat all syntactically valid priority values below
   and including -4 as priority -4, priorities -3 and -2 as priority -2,
   priorities -1 and 0 as priority 0, etc., with all priorities starting
   from 5 are treated as priority 9.  An SMTP server MAY support more
   than 6 different priority levels.  Decision about which levels to
   support in addition to the 6 mentioned above is a local matter.

   Irrespectively on 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 comminicate the
   priority value as determined in Section 4.2.

   Note: 19 possible priority levels are defined by this specification
   for extensibility, for example if a particular implementation or
   deployment environment needs to provide fine grainer control over
   message transfer priorities, for example a server implementation may
   need to have an extra high priority level to the 6 levels defined
   above.

   Some SMTP servers MAY impose additional maximum message size
   contraints 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.3.TBD2 enhanced status code [RFC2034].

   Note that rejections based on priority (see Section 4.2) or priority+
   message size combination SHOULD only be done by an MSA (i.e. they
   SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the
   Mail User Agents (MUAs) which generated the message and is in a
   position to perform a corrective action, such as resubmission of the
   message with lower priority, converting or truncating the message to
   make it smaller, etc.  Such actions usually need user confirmation.
   For this reason it is also important for MUAs to support enhanced
   status codes specified in this document (see Section 11 for the
   summary).  Any rejection caused by a downstream MTA is going to
   result in a bounce message.  Such bounce messages are not friendly to
   users and are frequently removed by antispam software.

   Implementation Note: If the SMTP server also supports the SMTP SIZE
   extension [RFC1870] then an SMTP client can use both SIZE= and
   PRIORITY= parameters on the MAIL FROM command.  This allows the



Melnikov & Carlberg      Expires August 17, 2012                [Page 8]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   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 DELIVERBY
   [RFC2852] SMTP service extension, however there is no requirement
   that both extensions are always implemented together.

5.1.  Expedited Transfer

   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 SHOULD send those with a higher priority before
   those with a lower one.  Additionally, the retry interval and/or
   default timeout before non-delivery report is generated MAY be lower
   (more aggressive) for messages of higher priority.

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

   As a default policy, emails with higher priority waiting to be sent
   by a client SHOULD NOT initiate transactions for emails with lower
   priorites.  If two or more emails with the same priority are ready to
   be sent at the same time, the MTA should use its regular algorithm
   (the algorithm used in absence of this SMTP extension) for deciding
   how to send them out.

   In networks with limited available bandwidth or long round trip times
   the actual message transfer over the network may create a significant
   portion of the overall message delivery time from a sender to a
   recipient.  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 [RFC2474], RSVP [RFC2205] and
   the work-in-progress effort extension to RSVP that prioritizes
   reservations.

   Most current SMTP MTAs are capable of handling several inbound and
   outbound connections at once.  With this feature it should be
   possible to start additional outbound connections for emails with
   higher priorities even if there are already several connections
   running for other emails.  Two possible ways of implementing
   expedited transfer are described in more details in Appendix D.





Melnikov & Carlberg      Expires August 17, 2012                [Page 9]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


5.2.  Timely Delivery

   An important constraint (usually associated with higher priority
   levels) is, that messages with that priority have to reach its
   destination within a defined period of time.  In some cases, higher
   priorities mean shorter maximum allowed time of delivery.

   Unextended SMTP does not offer a service for timely delivery.  The
   "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
   [RFC2852] is an example of an SMTP extension providing a service that
   can be used to implement such constraints.

6.  Header field: MT-Priority

   Applicable protocol: mail [RFC5322]
   Status: standard
   Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on
   behalf of the IETF
   Specification document(s): [[anchor11: this document]]

   The MT-Priority header field conveys message transfer priority when
   relaying a message through MTAs which don't support the PRIORITY SMTP
   extension.

   ABNF for this header field is defined as follows:


      priority-header-field = "MT-Priority:"
                              [CFWS] priority-value [CFWS] CRLF


   where "priority-value" is defined in Section 7

   Example:
   MT-Priority: -3

   Example:
   MT-Priority: 4 (ultra)













Melnikov & Carlberg      Expires August 17, 2012               [Page 10]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


7.  Syntax


      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 "PRI" FWS priority-value
                ; Complies with the <Additional-Registered-Clauses>
                ; non-terminal syntax from RFC 5321.

8.  Example

   An SMTP transaction with 2 recipients.  Note that the example is also
   making use of the DELIVERBY [RFC2852] and DSN [RFC3461] SMTP
   extensions, even thought there is no requirement that these other
   extensions are to be supported when the PRIORITY SMTP extension is
   implemented.

        S: 220 example.net SMTP server here
        C: EHLO example.com
        S: 250-example.net
        S: 250-DSN
        S: 250-DELIVERBY
        S: 250-PRIORITY
        C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
            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

   If the receiving SMTP server only supports 6 priority levels as
   described in Section 5, it will use the priority value 4 internally



Melnikov & Carlberg      Expires August 17, 2012               [Page 11]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   (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).

9.  Deployment Considerations

   If multiple DNS MX records are used to specify multiple servers for a
   domain in section 5 of [RFC5321], it is advised that all or none of
   them SHOULD support the 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.

10.  Pending changes

   [[anchor15: This section should be removed before publication]]

   Rename the PRIORITY extension/MAIL FROM parameter to something like
   MT-PRIORITY.  Please advise editors of this document if you have an
   opinion one way or another.

11.  IANA Considerations

   This specification requests IANA to add the PRIORITY SMTP extension
   to the "SMTP Service Extensions" registry (in
   http://www.iana.org/assignments/mail-parameters).

   IANA is also requested to add the following list of header field
   names to the "Permanent Message Header Field Names" registry (in
   http://www.iana.org/assignments/message-headers/perm-headers.html):

   Header field: MT-Priority
   Applicable protocol: mail
   Status: standard
   Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on
   behalf of the IETF
   Specification document(s): [[anchor16: this document]]

   This specification requests IANA to add the following new Received
   header field clause to the "Additional-registered-clauses" sub-
   registry (in http://www.iana.org/assignments/mail-parameters) to help
   with tracing email messages delivered using the PRIORITY SMTP
   extension:

   Clause name: PRI
   Description: Records the value of the PRIORITY parameter specified in
   the MAIL command
   Syntax of the value: See Section 7 of RFCXXXX



Melnikov & Carlberg      Expires August 17, 2012               [Page 12]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   Reference: [[anchor17: RFCXXXX]]

   This specification requests IANA to add the following Enumerated
   Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced
   Status Codes" registry established by [RFC5248] (in http://
   www.iana.org/assignments/smtp-enhanced-status-codes/
   smtp-enhanced-status-codes.xml):

   1.

       Code:  X.7.TBD1

       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 under the Minimize condition where only high
          priority messages are accepted for transfer and delivery.

       Reference:  RFC XXXX

       Submitter:  A. Melnikov

       Change controller:  IESG

   2.

       Code:  X.3.TBD2

       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 under the Minimize condition where only high
          priority messages are accepted for transfer and delivery.

       Reference:  RFC XXXX







Melnikov & Carlberg      Expires August 17, 2012               [Page 13]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


       Submitter:  A. Melnikov

       Change controller:  IESG

   3.

       Code:  X.3.TBD3

       Sample Text:  Requested priority was downgraded

       Associated basic status code:  250 or 251

       Description:  The message mas accepted for relay/delivery, but
          the requested priority can't be honoured and was downgraded.
          The human readable text after the status code contains the new
          priority, followed by SP (space) and explanatory human
          readable text.

       Reference:  RFC XXXX

       Submitter:  A. Melnikov

       Change controller:  IESG

12.  Security Considerations

   This document allows a message priority to be tunneled through MTAs
   which don't support the PRIORITY SMTP extension by specifying how it
   can be represented in the message itself (using the MT-Priority
   header field).  Thus it is important to ensure that an MTA receiving
   a message containing the MT-Priority header field can trust that it
   was set by an authorized agent.  Such trust can be realized, for
   example, by using DKIM Section 12.1 to sign the MT-Priority header
   field value, S/MIME, or by keeping a list of trusted senders (e.g.
   within a close environment) .

   Message Submission Agents can implement a policy that only allows
   authenticated users (or only certain groups of authenticated users)
   to specify message transfer priorities (whether by using the PRIORITY
   parameter to the MAIL command or the MT-Priority header field in the
   message itself), and to restrict maximum priority values different
   groups of users can request, or override the priority values
   specified by MUAs.  Such MSAs SHOULD strip any MT-Priority header
   field values that don't satisfy this policy.  See Section 12.1 for
   more details on when violation of this SHOULD is warranted.

   Similarly, MTAs can implement a policy that only allows authenticated
   and trusted senders (or only certain groups of authenticated senders)



Melnikov & Carlberg      Expires August 17, 2012               [Page 14]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   to specify message transfer priorities (whether by using the PRIORITY
   parameter to the MAIL command or the MT-Priority header field in the
   message itself), and to restrict maximum priority values different
   groups of senders can request, or override the priority values
   specified by them.  Such MTAs SHOULD strip any MT-Priority header
   field values that don't satisfy this policy.  See Section 12.1 for
   more details on when violation of this SHOULD is warranted.

   In the absence of the policy enforcement mentioned above an SMTP
   server (whether an MSA or an MTA) implementing this 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.

   To protect MT-Priority header field from modification or insertion,
   MUAs, MSAs and MTAs inserting it into messages SHOULD use message
   header protection mechanism such as DKIM [RFC6376].  But see
   Section 12.1.

12.1.  Modification of MT-Priority header field and DKIM

   A MSA/MTA that receives a message with an MT-Priority header field
   protected by DKIM, that wants to change the message priority due to
   its policy is forced to choose between a) breaking DKIM signatures
   (by replacing the MT-Priority header value), b) leaving the message
   as is (and using the PRIORITY MAIL FROM parameter), relying on the
   fact that all downstream MTAs are compliant with this specification,
   or c) rejecting the message.  All of these choices have pros and
   cons, which should be carefully considered during deployment.

   If the MSA/MTA decides to alter the message, it SHOULD re-sign the
   message with DKIM.

13.  References

13.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)",



Melnikov & Carlberg      Expires August 17, 2012               [Page 15]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


              RFC 3461, January 2003.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5234]  Crocker, D. 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.

   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              STD 72, RFC 6409, November 2011.

13.2.  Informative References

   [RFC1845]  Crocker, D. and N. Freed, "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., 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.

   [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)",



Melnikov & Carlberg      Expires August 17, 2012               [Page 16]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


              RFC 4412, February 2006.

   [RFC6376]  Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
              Identified Mail (DKIM) Signatures", RFC 6376,
              September 2011.

   [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., "Russian Dolls Bandwidth Constraints
              Model for Diffserv-aware MPLS Traffic Engineering",
              RFC 4127, June 2005.

   [RFC6401]  Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP
              Extensions for Admission Priority", RFC 6401,
              October 2011.

Appendix A.  Mapping of PRIORITY parameter values for Military Messaging

   Military Messaging as specified in STANAG 4406 defines six priority
   values.  Where SMTP is used to support military messaging, the
   following mappings SHOULD be used.

              Recommended mapping of PRIORITY values for MMHS

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

                                  Table 1

Appendix B.  Mapping of PRIORITY parameter values for MIXER

   MIXER [RFC2156] defines the Priority header field with 3 values.
   Where SMTP is used to support military messaging, the following
   mappings SHOULD be used.







Melnikov & Carlberg      Expires August 17, 2012               [Page 17]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


             Recommended mapping of PRIORITY values for MIXER

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

                                  Table 2

Appendix C.  Mapping of National Security / Emergency Preparedness
             (NS/EP) Values

   Communication systems used during an emergency or disaster are
   realized in several forms.  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.  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 established and
   continue communication given limited available resources.  [RFC4190]
   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.

   [RFC4412] 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 five priority values.  This is shown in
   the cases of the ETS and 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 five ascending values shown
   in the table below.

                   +----------------+------------------+
                   | Priority value | Relational Order |
                   +----------------+------------------+
                   |       -2       | Lowest Priority  |
                   |        0       | ----------       |
                   |        2       | ----------       |
                   |        4       | ----------       |




Melnikov & Carlberg      Expires August 17, 2012               [Page 18]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


                   |        6       | Highest Priority |
                   +----------------+------------------+

   As in the case of Appendix A and B, the gap in numeric values listed
   in this table provides room for future changes to expand the set of
   priorities at a future date, or in a local and non-standardized
   manner.

Appendix D.  Two possible implementation strategies

   This appendix suggest some implementation 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

   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.

D.2.  Preemption of sessions or transactions

   Preemption is a type of action that focusses only on a comparision of
   priorities to determine if previously established transactions must
   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 even can interrupt an active transaction and
   should 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 should 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 must 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 it can be restarted at
   the interruption point later, it should deploy it.  An example for a



Melnikov & Carlberg      Expires August 17, 2012               [Page 19]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


   mechanism providing such a service is the "SMTP Service Extension for
   Checkpoint/Restart" defined in [RFC1845].

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

Appendix E.  Resource Allocation Models

   Adding prioritization to a design moves the subject away from
   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 in
   specifying resource allocations models.  Examples include the Maximum
   Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and
   the Priority Bypass Model (Appendix A.3 of [RFC6401]).

   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.

Appendix F.  Acknowledgements

   This document copies lots of text from
   draft-schmeing-smtp-priorities-04.txt and
   draft-schmeing-smtp-priorities-05.txt.  So the authors of this
   document would like to acknowledge contributions made by the authors
   of draft-schmeing-smtp-priorities: 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 and
   Chris Newman.

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














Melnikov & Carlberg      Expires August 17, 2012               [Page 20]

Internet-Draft  Message Transfer Priority SMTP Extension   February 2012


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 & Carlberg      Expires August 17, 2012               [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/