Movatterモバイル変換

Internet Engineering Task Force (IETF)                       A. MelnikovRequest for Comments: 6758                                     Isode LtdCategory: Informational                                      K. CarlbergISSN: 2070-1721                                                      G11                                                            October 2012Tunneling of SMTP Message Transfer PrioritiesAbstract   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 document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Not all documents   approved by the IESG are a candidate for any level of Internet   Standard; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6758.Copyright Notice   Copyright (c) 2012 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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           Informational                     [Page 1]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012Table of Contents1. Introduction ....................................................22. Conventions Used in This Document ...............................33. Handling of Messages Received via SMTP ..........................4      3.1. Handling of the MT-PRIORITY Parameter by the           Receiving SMTP Server ......................................43.2. Relay of Messages to Other Conforming SMTP/LMTP Servers ....43.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers ......53.4. Mailing Lists and Aliases ..................................53.5. Gatewaying a Message into a Foreign Environment ............53.6. Interaction with the DSN SMTP Extension ....................54. Header Field: MT-Priority .......................................55. Example .........................................................66. IANA Considerations .............................................77. Security Considerations .........................................77.1. Modification of the MT-Priority Header Field and DKIM ......98. References ......................................................98.1. Normative References .......................................98.2. Informative References ....................................10Appendix A. Acknowledgements ......................................111.  Introduction   The SMTP Message Transfer Priorities extension [RFC6710] specifies a   mechanism to allow messages to be given a label to indicate   preferential handling, to enable mail handling nodes to take this   into account for onward processing.  However, as with all SMTP   extensions, all SMTP Message Transfer Agents (MTAs) between the   source and the destination must support the extension in order for it   to be successfully used.  This document describes an application-   layer tunneling of message priority, to convey the priority of the   messages through MTAs that do not support the Message Transfer   Priorities extension.  The tunneling is done by adding a new message   header field to the Internet Message Format specified in [RFC5322].   A number of other header fields are already in use, mostly in Message   User Agents (MUAs), to convey meanings related to importance or   priority of messages.  Examples 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) an MUA   talking to a non-MT-PRIORITY-aware Message Submission Agent (MSA),   and (2) the use of an unextended MUA to talk to an MT-PRIORITY-aware   MSA.  These 2 use cases are discussed in more detail below.Melnikov & Carlberg           Informational                     [Page 2]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012   Use case (1) is about an MT-PRIORITY-capable MUA talking to a   non-MT-PRIORITY-capable MSA [RFC6409], which in turn is talking to an   MT-PRIORITY-capable MTA [RFC5321].  Both the MSA and MTA are within   the same ADministrative Management Domain (ADMD) and are on a fast   network; however, some recipients are accessible via the MTA that is   talking over a slow link to the next MTA.  Communications over that   slow link can benefit from the use of the MT-PRIORITY SMTP extension.   In use case (2), a widely deployed client (such as a desktop client)   is talking to an MT-PRIORITY-capable MSA.  The client might be   extendable via a plug-in 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 plug-in on the client that   can set the MT-Priority header field could provide easier and earlier   deployment of the 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 [RFC6710].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 uses the Augmented Backus-Naur Form (ABNF)   [RFC5234] notation, including the core rules defined inAppendix 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.Melnikov & Carlberg           Informational                     [Page 3]

RFC 6758        Tunneling of Message Transfer Priorities    October 20123.  Handling of Messages Received via SMTP   The subsections of this section update the corresponding subsections   ofSection 4 of [RFC6710].3.1.  Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server   This specification inserts the following between steps 4 and 5 inSection 4.1 of [RFC6710]:   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 (seeSection 4),        then the value of this header field is the message priority.   4b.  In the 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.  Note, however, 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.3.2.  Relay of Messages to Other Conforming SMTP/LMTP Servers   This specification inserts the following between steps 1 and 2 inSection 4.2 of [RFC6710].   1a.  Note that rule 1 also applies to messages that didn't have any        priority explicitly specified using the MT-PRIORITY MAIL FROM        parameter or the MT-Priority header field.Melnikov & Carlberg           Informational                     [Page 4]

RFC 6758        Tunneling of Message Transfer Priorities    October 20123.3.  Relay of Messages to Non-Conforming SMTP/LMTP Servers   This specification appends the following after step 1 inSection 4.3   of [RFC6710]:   2.  The relaying MTA MUST first remove any and all existing       MT-Priority header fields from the message.  (Please seeSection 7 for additional considerations related to removal of the       MT-Priority header field.)   3.  If the incoming message had an MT-PRIORITY parameter specified in       the MAIL FROM command *or* there was an MT-Priority header field       removed in step 2 above, then the relaying MTA MUST add its own       MT-Priority header field with the value determined by the       procedure inSection 3.1.  The syntax of the MT-Priority header       field is specified inSection 4.3.4.  Mailing Lists and Aliases   This specification makes no changes toSection 4.4 of [RFC6710].3.5.  Gatewaying a Message into a Foreign Environment   This specification inserts the following between steps 1 and 2 inSection 4.5 of [RFC6710].   1a.  Note that if the destination environment doesn't support the        transport of an arbitrary header field, the requirement inSection 3.3 to add an MT-Priority header field doesn't apply.3.6.  Interaction with the DSN SMTP Extension   This specification makes no changes toSection 4.6 of [RFC6710].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):RFC 6758   The MT-Priority header field conveys message transfer priority when   relaying a message through MTAs that don't support the MT-PRIORITY   SMTP extension.Melnikov & Carlberg           Informational                     [Page 5]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012   The 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 [RFC6710].   Example:   MT-Priority: -3   Example:   MT-Priority: 4 (ultra)5.  Example   Note that the following example of an SMTP transaction with 2   recipients is also making use of the STARTTLS [RFC3207] and Delivery   Status Notification (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-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 [RFC6710] with 6 priority levels, so it will use   the priority value 4 internally (the next supported priority higherMelnikov & Carlberg           Informational                     [Page 6]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012   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 that doesn't support the MT-PRIORITY SMTP   extension, the transaction might look like this:        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 goodbye6.  IANA Considerations   IANA has added 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):RFC 67587.  Security Considerations   This document allows a message priority to be tunneled through MTAs   that 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 receivingMelnikov & Carlberg           Informational                     [Page 7]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012   a message containing the MT-Priority header field can trust that it   was set by an authorized agent.  The use of technologies such as   DomainKeys Identified Mail (DKIM) [RFC6376] or S/MIME to sign the   MT-Priority header field value can enable a recipient to verify   whether the specified priority value was generated by a trusted   agent.  In particular, DKIM signing allows a recipient to verify that   the specified priority value was present when the message was signed,   and to verify who signed the message.  Note, however, that the DKIM   signer might not be the same agent that generated the MT-Priority   header field.   MSAs 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.  When relaying to non-MT-PRIORITY-capable SMTP/LMTP (Local Mail   Transfer Protocol) servers, such MSAs are required to replace any   MT-Priority header field values that don't satisfy this policy.  SeeSection 7.1 for more details on what the consequences of such changes   might be.   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.  When relaying to non-MT-PRIORITY-capable SMTP/   LMTP servers, such MTAs are required to replace any MT-Priority   header field values that don't satisfy this policy.  SeeSection 7.1   for more details on what the consequences of such changes might be.   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 the MT-Priority header field from modification or   insertion, MUAs, MSAs, and MTAs inserting it into messages SHOULD use   a message header protection mechanism such as DKIM [RFC6376];   however, seeSection 7.1 for more information.Melnikov & Carlberg           Informational                     [Page 8]

RFC 6758        Tunneling of Message Transfer Priorities    October 20127.1.  Modification of the MT-Priority Header Field and DKIM   An MSA/MTA that receives a message with an MT-Priority header field   protected by DKIM and 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 MT-PRIORITY MAIL FROM       parameter), relying on the fact that all downstream MTAs are       compliant with this specification, and   c.  rejecting the message.   None of these choices are perfect.  They 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.  References8.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.   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax              Specifications: ABNF", STD 68,RFC 5234, January 2008.   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol",RFC 5321,              October 2008.   [RFC5322]  Resnick, P., Ed., "Internet Message Format",RFC 5322,              October 2008.   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",              STD 72,RFC 6409, November 2011.   [RFC6710]  Melnikov, A. and K. Carlberg, "Simple Mail Transfer              Protocol Extension for Message Transfer Priorities",RFC 6710, August 2012.Melnikov & Carlberg           Informational                     [Page 9]

RFC 6758        Tunneling of Message Transfer Priorities    October 20128.2.  Informative References   [RFC2156]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):              Mapping between X.400 andRFC 822/MIME",RFC 2156,              January 1998.   [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.   [SMTP-PRI-OLD]              Schmeing, M., Brendecke, J., and K. Carlberg, "SMTP              Service Extension for Priority Message Handling", Work              in Progress, August 2006.Melnikov & Carlberg           Informational                    [Page 10]

RFC 6758        Tunneling of Message Transfer Priorities    October 2012Appendix A.  Acknowledgements   This document copies lots of text from "SMTP Service Extension for   Priority Message Handling" [SMTP-PRI-OLD].  Therefore, the authors of   this document would like to acknowledge contributions made by the   authors of that document: Michael Schmeing and Jan-Wilhelm Brendecke.   Many thanks for input provided by Steve Kille, David Wilson, John   Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba,   Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick,   Chris Newman, Ned Freed, Claudio Allocchio, Martin Thomson, and   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.ukMelnikov & Carlberg           Informational                    [Page 11]