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

Versions: 00 01 02 03 04 RFC 6758

Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Experimental                                K. Carlberg
Expires: January 13, 2013                                            G11
                                                           July 12, 2012


             Tunneling of SMTP Message Transfer Priorities
               draft-melnikov-smtp-priority-tunneling-03

Abstract

   This memo defines a mechanism for tunneling of SMTP (Simple Mail
   Transfer Protocol) Message Transfer Priority values through MTAs
   (Message Transfer Agents) that don't support the MT-PRIORITY SMTP
   extension.

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 January 13, 2013.

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 January 13, 2013                [Page 1]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Handling of messages received via SMTP . . . . . . . . . . . .  4
     3.1.  Handling of the MT-PRIORITY parameter by the receiving
           SMTP server  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Relay of messages to other conforming SMTP/LMTP servers  .  5
     3.3.  Relay of messages to non-conforming SMTP/LMTP servers  . .  5
     3.4.  Mailing lists and Aliases  . . . . . . . . . . . . . . . .  5
     3.5.  Gatewaying a message into a foreign environment  . . . . .  5
     3.6.  Interaction with DSN SMTP Extension  . . . . . . . . . . .  5
   4.  Header field: MT-Priority  . . . . . . . . . . . . . . . . . .  6
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
     7.1.  Modification of MT-Priority header field and DKIM  . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11






























Melnikov & Carlberg     Expires January 13, 2013                [Page 2]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


1.  Introduction

   This document is an experimental extension to the SMTP Message
   Transfer Priorities extension [SMTP-PRIORITY].  It specifies
   application layer tunneling of message priority, to convey the
   priority of the messages through Message Transfer Agents (MTAs) that
   do not support the Message Transfer Priorities extension.  The
   tunneling is done by adding a new message header field to Internet
   message format specified in [RFC5322].

   A number of other header fields are already in use, mostly in Mail
   User Agents (MUAs), to convey meanings related to importance or
   priority of messages.  Example of such header fields are Importance
   [RFC2156], Priority [RFC2156] and X-Priority (undocumented).
   Considering sometimes subtle and sometimes significant differences in
   the meaning of these header fields and widely different syntax, this
   document defines a new header field.

   This document is motivated by 2 main deployment scenarios: (1) Mail
   User Agent (MUA) talking to a non MT-PRIORITY aware Message
   Submission Server (MSA), and (2) use of unextended MUA to talk to a
   MT-PRIORITY aware MSA.  These 2 use cases are discussed in more
   details below.

   The use case (1) is about a MT-PRIORITY capable MUA talking to a non
   MT-PRIORITY capable MSA [RFC6409], which in turn is talking to a MT-
   PRIORITY capable MTA [RFC5321].  Both MSA and MTA are within the same
   Administrative and Management Domain (ADMD) and are on a fast
   network, however some recipients are accessible via the MTA which is
   talking over a slow link to the next MTA.  Communications over that
   slow link can benefit from use of MT-PRIORITY SMTP extension.

   In the use case (2) a widely deployed client (such as a desktop
   client) is talking to MT-PRIORITY capable MSA.  The client might be
   extendable via a plugin API provided by the client developers,
   however existing APIs frequently allow easy manipulation of email
   header fields, while not allowing for addition of SMTP protocol
   features.  In such a case installing a plugin to the client that can
   set MT-Priority header field could provide easier and earlier
   deployment of MT-PRIORITY SMTP extension in an organization without
   requiring changes to desktop clients.

   We note that the above use cases are not exhaustive and that other
   use cases, variations of the above, may exist.  The purpose of this
   document is not to consider every scenario, but rather examples that
   reinforce the need to consider a tunneling mechanism that can deal
   with SMTP capable devices that do not support [SMTP-PRIORITY].




Melnikov & Carlberg     Expires January 13, 2013                [Page 3]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


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.  Handling of messages received via SMTP

   The subsections of this section update the corresponding subsections
   of Section 4 of [SMTP-PRIORITY].

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

   This specification inserts the following between steps 4 and 5 in
   Section 4.1 of [SMTP-PRIORITY]:

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

   4b.  In absence of both the MT-PRIORITY MAIL FROM parameter and the
        MT-Priority header field, other message header fields, such as
        Priority [RFC2156] and X-Priority, MAY be used for determining
        the priority under this "Priority Message Handling" SMTP
        extension.  But note that the Importance [RFC2156] header field
        MUST NOT be used for determining the priority under this
        "Priority Message Handling" SMTP extension, as it has different
        semantics: the Importance header field is aimed at the user
        recipient and not at the nodes responsible for transferring the
        message.




Melnikov & Carlberg     Expires January 13, 2013                [Page 4]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


3.2.  Relay of messages to other conforming SMTP/LMTP servers

   This specification inserts the following between steps 1 and 2 in
   Section 4.2 of [SMTP-PRIORITY].

   1a.  Note that rule 1 also applies to messages which didn't have any
        priority explicitly specified using the MT-PRIORITY MAIL FROM
        parameter or the MT-Priority header field.

3.3.  Relay of messages to non-conforming SMTP/LMTP servers

   This specification appends the following after step 1 in Section 4.3
   of [SMTP-PRIORITY]:

   2.  The relaying MTA MUST first remove any and all existing MT-
       Priority header fields from the message.  (Please see Section 7
       for additional considerations related to removal of the MT-
       Priority header field.)

   3.  If the incoming message had a MT-PRIORITY parameter specified in
       the MAIL FROM command *or* there was an MT-Priority header field
       removed in the above step 2, then the relaying MTA MUST add its
       own MT-Priority header field with the value determined by the
       procedure in Section 3.1.  Syntax of the MT-Priority header field
       is specified in Section 4.

3.4.  Mailing lists and Aliases

   This specification makes no changes to Section 4.4 of
   [SMTP-PRIORITY].

3.5.  Gatewaying a message into a foreign environment

   This specification inserts the following between steps 1 and 2 in
   Section 4.5 of [SMTP-PRIORITY].

   1a.  Note that if the destination environment doesn't support
        transport of arbitrary header field, the requirement in
        Section 3.3 to add an MT-Priority header field doesn't apply.

3.6.  Interaction with DSN SMTP Extension

   This specification makes no changes to Section 4.6 of
   [SMTP-PRIORITY].







Melnikov & Carlberg     Expires January 13, 2013                [Page 5]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


4.  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): [[anchor7: this document]]

   The MT-Priority header field conveys message transfer priority when
   relaying a message through MTAs which don't support the MT-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 [SMTP-PRIORITY].

   Example:
   MT-Priority: -3

   Example:
   MT-Priority: 4 (ultra)

5.  Example

   An SMTP transaction with 2 recipients.  Note that the example is also
   making use of the STARTTLS [RFC3207] 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.

















Melnikov & Carlberg     Expires January 13, 2013                [Page 6]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


        S: 220 example.net SMTP server here
        C: EHLO example.com
        S: 250-example.net
        S: 250-DSN
        S: 250-STARTTLS
        S: 250 MT-PRIORITY STANAG4406
        C: STARTTLS
        [...TLS negotiation...]
        C: MAIL FROM:<eljefe@example.com> 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

   Here the receiving SMTP server supports the "STANAG4406" Priority
   Assignment Policy [SMTP-PRIORITY] with 6 priority levels, so 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).  When relaying the
   message to the next hop which doesn't support the MT-PRIORITY SMTP
   extension the transaction might look like this:




















Melnikov & Carlberg     Expires January 13, 2013                [Page 7]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


        S: 220 example.org SMTP server here
        C: EHLO example.net
        S: 250-example.org
        S: 250-DSN
        S: 250-STARTTLS
        S: 250 SIZE
        C: STARTTLS
        [...TLS negotiation...]
        C: MAIL FROM:<eljefe@example.com> ENVID=QQ314159
        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: MT-Priority: 3
        C:  (the rest of the message goes here)
        C: .
        S: 250 message accepted
        C: QUIT
        S: 221 goodbye


6.  IANA Considerations

   IANA is 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): [[anchor9: this document]]

7.  Security Considerations

   This document allows a message priority to be tunneled through MTAs
   which don't support the MT-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.  Use of technologies such as DKIM
   [RFC6376] or S/MIME to sign the MT-Priority header field value can
   enable the recipient to verify whether the specified priority value



Melnikov & Carlberg     Expires January 13, 2013                [Page 8]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


   was generated by a trusted agent.

   Message Submission Agents ought to only accept message transfer
   priorities (whether by using the MT-PRIORITY parameter to the MAIL
   FROM command or the MT-Priority header field in the message itself)
   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
   values that different groups of users can request, and can override
   the priority values specified by MUAs.  Such MSAs are required to
   strip any MT-Priority header field values that don't satisfy this
   policy, when relaying to non MT-PRIORITY capable SMTP/LMTP servers.
   See Section 7.1 for more details on when violation of this
   requirement is warranted.

   Similarly, MTAs ought to only accept message transfer priorities
   (whether by using the MT-PRIORITY parameter to the MAIL FROM command
   or the MT-Priority header field in the message itself) 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.  Such MTAs are required to strip any MT-Priority
   header field values that don't satisfy this policy, when relaying to
   non MT-PRIORITY capable SMTP/LMTP servers.  See Section 7.1 for more
   details on when violation of this requirement is warranted.

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

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

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





Melnikov & Carlberg     Expires January 13, 2013                [Page 9]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


   b.  leaving the message as is (and using the MT-PRIORITY MAIL FROM
       parameter), relying on the fact that all downstream MTAs are
       compliant with this specification,

   c.  rejecting the message.

   Each of these choices is not perfect and work in a particular
   situation, so these choices should be carefully considered during
   implementation and deployment.

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

8.  References

8.1.  Normative References

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

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

   [SMTP-PRIORITY]  Melnikov, A. and K. Carlberg, "Simple Mail Transfer
                    Protocol extension for Message Transfer Priorities",
                    draft-melnikov-smtp-priority-21 (work in progress),
                    2012.

8.2.  Informative References

   [RFC2156]        Kille, S., "MIXER (Mime Internet X.400 Enhanced
                    Relay): Mapping between X.400 and RFC 822/MIME",
                    RFC 2156, January 1998.




Melnikov & Carlberg     Expires January 13, 2013               [Page 10]

Internet-Draft  Tunneling of Message Transfer Priorities       July 2012


   [RFC3207]        Hoffman, P., "SMTP Service Extension for Secure SMTP
                    over Transport Layer Security", RFC 3207,
                    February 2002.

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

Appendix A.  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, Claudio Allocchio, Martin Thomson, Joseph
   Yee.

   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 January 13, 2013               [Page 11]


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