Tunneling of SMTP Message Transfer Priorities
RFC 6758

"
        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 in
   Section 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 2012

3.3.  Relay of Messages to Non-Conforming SMTP/LMTP Servers

   This specification appends the following after step 1 in Section 4.3
   of [RFC6710]:

   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 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 in Section 3.1.  The 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 [RFC6710].

3.5.  Gatewaying a Message into a Foreign Environment

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

   1a.  Note that if the destination environment doesn't support the
        transport of an arbitrary header field, the requirement in
        Section 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 to Section 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 higher

Melnikov & 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 goodbye

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

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

Melnikov & 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.  See
   Section 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.  See Section 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, see Section 7.1 for more information.

Melnikov & Carlberg           Informational                     [Page 8]
RFC 6758        Tunneling of Message Transfer Priorities    October 2012

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

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

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

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

Melnikov & Carlberg           Informational                    [Page 11]