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

Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Standards Track                             K. Carlberg
Expires: December 3, 2012                                            G11
                                                            June 1, 2012

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

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
   into account for onward processing.

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 December 3, 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
   described in the Simplified BSD License.

Melnikov & Carlberg     Expires December 3, 2012                [Page 1]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Definition of the Priority SMTP Extension  . . . . . . . . . .  3
   4.  Handling of messages received via SMTP . . . . . . . . . . . .  4
     4.1.  Handling of the MT-PRIORITY parameter by the receiving
           SMTP server  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Relay of messages to other conforming SMTP servers . . . .  5
     4.3.  Relay of messages to non-conforming SMTP servers . . . . .  6
     4.4.  Mailing lists and Aliases  . . . . . . . . . . . . . . . .  6
     4.5.  Gatewaying a message into a foreign environment  . . . . .  6
     4.6.  Interaction with DSN SMTP Extension  . . . . . . . . . . .  7
   5.  The Priority Service Extension . . . . . . . . . . . . . . . .  7
     5.1.  Expedited Transfer . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Timely Delivery  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Deployment Considerations  . . . . . . . . . . . . . . . . . . 11
     8.1.  Multiple MX records  . . . . . . . . . . . . . . . . . . . 11
     8.2.  Deciding how many priority levels to support . . . . . . . 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Mapping of MT-PRIORITY parameter values for
                Military Messaging  . . . . . . . . . . . . . . . . . 16
   Appendix B.  Mapping of MT-PRIORITY parameter values for MIXER . . 16
   Appendix C.  Mapping of National Security / Emergency
                Preparedness (NS/EP) Values . . . . . . . . . . . . . 17
   Appendix D.  Two possible implementation strategies  . . . . . . . 17
     D.1.  Probability  . . . . . . . . . . . . . . . . . . . . . . . 18
     D.2.  Preemption of sessions or transactions . . . . . . . . . . 18
     D.3.  Resource Allocation Models . . . . . . . . . . . . . . . . 18
   Appendix E.  Background on Design Choices  . . . . . . . . . . . . 19
   Appendix F.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20

Melnikov & Carlberg     Expires December 3, 2012                [Page 2]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

1.  Introduction

   Where resources for switching or transfer of 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 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 relay 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.

   In order to permit end-to-end use of this extension across email
   infrastructure that does not support it, a companion tunneling
   mechanism is defined in [PRIORITY-TUNNELING] through use of a new
   message header field [RFC5322].

2.  Conventions Used in This Document

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

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

3.  Definition of the Priority SMTP Extension

   The Priority SMTP service extension is defined as follows:

Melnikov & Carlberg     Expires December 3, 2012                [Page 3]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   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 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 ("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 Appendix E for more details on why this
       range was selected).  The syntax of the MT-PRIORITY parameter is
       described by the <priority-value> ABNF non-terminal defined in
       Section 6.  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 value.

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

4.  Handling of messages received via SMTP

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

4.1.  Handling of the MT-PRIORITY parameter by the receiving SMTP server

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

   1.  If any of the associated <esmtp-value>s (as defined in Section
       4.1.2 of [RFC5321]) are not syntactically valid, or if there is
       more than one MT-PRIORITY parameter in a particular MAIL FROM
       command, the server MUST return an error, for example "501 syntax
       error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).

   2.  When inserting a Received header field as specified in Section
       4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
       "PRIORITY" clause whose syntax is specified in Section 6.

Melnikov & Carlberg     Expires December 3, 2012                [Page 4]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

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

   4.  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 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 explicitly
   whitelisted to use the SMTP MT-PRIORITY service.)  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 low priority.

   The SMTP server MAY also alter the message priority (to lower or to
   raise it) in order to enforce some other site policy.  For example an
   MSA might have a mapping table that assigns priorities to messages
   based on authentication credentials.

   If the SMTP server lowers the priority of a message, it SHOULD 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.  In such cases, 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 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.

4.2.  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 MT-
   PRIORITY SMTP extension:

   1.  A MT-PRIORITY parameter with the value determined by the
       procedure from Section 4.1 MUST appear in the MAIL FROM command
       issued when the message is relayed to an MTA/MDA which also
       supports the MT-PRIORITY extension.  For example, once an MTA
       accepts a message, the MTA MUST NOT change a (syntactically

Melnikov & Carlberg     Expires December 3, 2012                [Page 5]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

       valid) priority value if that value is not supported (as a
       distinct priority value) by the MTA's implementation of this
       extension.

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

4.3.  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
   MT-PRIORITY SMTP extension:

   1.  The relaying MTA MUST NOT use the MT-PRIORITY parameter in the
       MAIL FROM command issued when relaying the message.

4.4.  Mailing lists and Aliases

   Several services 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 MT-PRIORITY parameter value for
   all expanded and/or translated addresses.

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

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

Melnikov & Carlberg     Expires December 3, 2012                [Page 6]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

4.6.  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
   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
   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 round up a syntactically valid level that isn't
   supported to the next higher supported number.  For example, such an
   implementation will treat priority values below and including -4 as
   priority -4, priority -3 as priority -2, and 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.  (See
   Section 8.2 for implementation/deployment considerations related to
   priority assignment policy.)

   Irrespectively of the number of distinct priority levels supported by
   the SMTP server, when relaying the message to the next hop or
   delivering it over LMTP, the SMTP server MUST communicate the
   priority value as determined in Section 4.1.

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

   Some SMTP servers MAY impose additional maximum message size
   constraints for different message transfer priorities, for example
   messages with priority 6 might not be larger than 4 Kb.  If an SMTP
   server chooses to reject a message because it is too big for the
   determined priority, it SHOULD use 552 reply codes, together with the
   X.3.TBD2 enhanced status code [RFC2034].

Melnikov & Carlberg     Expires December 3, 2012                [Page 7]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   Note that rejections based on priority (see Section 4.1) 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 require user interaction.
   For this reason it is also important for MUAs to support enhanced
   status codes specified in this document (see Section 9 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 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 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 sends 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.

   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 [GREYLISTING], unless they are unauthorized to use this
   SMTP extension, due to an explicit policy decision or a
   misconfiguration error.

   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

Melnikov & Carlberg     Expires December 3, 2012                [Page 8]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   algorithm used in absence of this SMTP extension) for ordering for
   the messages.

   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.

   This extension provides benefits 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.  It is also
   useful in case of a congestion, for example resulting from an MTA
   queue build-up.  When neither of the two conditions mentioned above
   is true, the use of the MT-PRIORITY SMTP extension will not result in
   a better SMTP service.

   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.

5.2.  Timely Delivery

   An important constraint (usually associated with higher priority
   levels) is that messages with high priority 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.  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.  But note that use of the
   DELIVERBY extension alone does not guarantee any priority processing.

Melnikov & Carlberg     Expires December 3, 2012                [Page 9]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

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

7.  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 though there is no requirement that these other
   extensions are to be supported when the MT-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 MT-PRIORITY
        C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
            MT-PRIORITY=3
        S: 250 <eljefe@example.com> sender ok
        C: RCPT TO:<topbanana@example.net>
        S: 250 <topbanana@example.net> recipient ok
        C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
            ORCPT=rfc822;Dana@Ivory.example.net
        S: 250 <Dana@Ivory.example.net> recipient ok
        C: DATA
        S: 354 okay, send message
        C:  (message goes here)
        C: .
        S: 250 message accepted
        C: QUIT
        S: 221 goodbye

Melnikov & Carlberg     Expires December 3, 2012               [Page 10]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   If the receiving SMTP server only supports 6 priority levels as
   described in Section 5, it 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).

8.  Deployment Considerations

8.1.  Multiple MX records

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

8.2.  Deciding how many priority levels to support

   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 end up getting different preferential treatment when
   it was not the intent.

   In order to achieve consistent behaviour in an operating environment,
   the priority assignment policy (together with restrictions on maximum
   message sized for each priority (if any), default timeouts, etc.)
   should be documented for the environment.  The default priority
   assignment policy is specified in Appendix A.  Two other anticipated
   policies are specified in Appendix B and Appendix C.

9.  IANA Considerations

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

   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 MT-PRIORITY SMTP

Melnikov & Carlberg     Expires December 3, 2012               [Page 11]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   extension:

   Clause name: PRIORITY
   Description: Records the value of the MT-PRIORITY parameter specified
   in the MAIL FROM command
   Syntax of the value: See Section 6 of RFCXXXX
   Reference: [[anchor13: 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 in a mode where only higher priority messages are
          accepted for transfer and delivery, while lower priority
          messages are rejected.

       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)

Melnikov & Carlberg     Expires December 3, 2012               [Page 12]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

       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
          certain size are accepted for transfer and delivery.

       Reference:  RFC XXXX

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

10.  Security Considerations

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

   Similarly, MTAs MUST implement a policy that only allows
   authenticated and trusted senders (or only certain groups of
   authenticated senders) to specify message transfer priorities, and
   MAY restrict maximum priority values different groups of senders can
   request, or MAY 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 extension might

Melnikov & Carlberg     Expires December 3, 2012               [Page 13]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   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.

11.  References

11.1.  Normative References

   [RFC2033]             Myers, J., "Local Mail Transfer Protocol",
                         RFC 2033, October 1996.

   [RFC2034]             Freed, N., "SMTP Service Extension for
                         Returning Enhanced Error Codes", RFC 2034,
                         October 1996.

   [RFC2119]             Bradner, S., "Key words for use in RFCs to
                         Indicate Requirement Levels", BCP 14, RFC 2119,
                         March 1997.

   [RFC3461]             Moore, K., "Simple Mail Transfer Protocol
                         (SMTP) Service Extension for Delivery Status
                         Notifications (DSNs)", RFC 3461, January 2003.

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

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

Melnikov & Carlberg     Expires December 3, 2012               [Page 14]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

                         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)", RFC 4412, February 2006.

   [PRIORITY-TUNNELING]  Melnikov, A. and K. Carlberg, "Tunneling of
                         SMTP Message Transfer Priorities",
                         draft-melnikov-smtp-priority-tunneling-00 (work
                         in progress), 2012.

   [ACP123]              CCEB, "Common Messaging strategy and
                         procedures", ACP 123, May 2009.

   [STANAG-4406]         NATO, "STANAG 4406 Edition 2: Military Message
                         Handling System", STANAG 4406, March 2005.

   [GREYLISTING]         Kucherawy, M. and D. Crocker, "Email
                         Greylisting: An Applicability Statement for
                         SMTP", draft-ietf-appsawg-greylisting (work in
                         progress), April 2012.

   [RFC4125]             Le Faucheur, F. and W. Lai, "Maximum Allocation
                         Bandwidth Constraints Model for Diffserv-aware
                         MPLS Traffic Engineering", RFC 4125, June 2005.

Melnikov & Carlberg     Expires December 3, 2012               [Page 15]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   [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 MT-PRIORITY parameter values for Military
             Messaging

   Military Messaging as specified in ACP 123 [ACP123] (also specified
   in STANAG 4406 [STANAG-4406]) defines six priority values.  Where
   SMTP is used to support military messaging, the following mappings
   SHOULD be used.

            Recommended mapping of MT-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 MT-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.

            Recommended mapping of MT-PRIORITY values for MIXER

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

                                  Table 2

Melnikov & Carlberg     Expires December 3, 2012               [Page 16]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

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

   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.
   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       | ----------       |
                   |        6       | Highest Priority |
                   +----------------+------------------+

   As in the case of Appendix A and Appendix 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.

Melnikov & Carlberg     Expires December 3, 2012               [Page 17]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   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 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 even can interrupt an active
   transaction and ought to do so, if other constraints such as delivery
   time (as specified in the DELIVERBY SMTP extension [RFC2852]) would
   be violated for the email with higher priority.  When interrupting an
   active transaction, the client ought to take the total message size
   and the size of the transferred portion of the message being
   interrupted into consideration.  This 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 it can 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 [RFC1845].

   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.

D.3.  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

Melnikov & Carlberg     Expires December 3, 2012               [Page 18]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

   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 E.  Background on Design Choices

   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 three levels.  One of the
       use cases motivating this extension requires six levels.  So at
       least six different values are required.

   2.  During discussions of this extension, several different use cases
       were suggested that required differing numbers of priority
       levels.  Defining just the six 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 six.  This avoids the need to further
       extend this extension just to have a few more priority levels.

   3.  It seems natural to use 0 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.

Melnikov & Carlberg     Expires December 3, 2012               [Page 19]
Internet-Draft  Message Transfer Priority SMTP Extension       June 2012

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,
   Chris Newman, Ned Freed and Claudio Allocchio.

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

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 December 3, 2012               [Page 20]