RFC 6758

Tunneling of SMTP Message Transfer Priorities

📅 published October 2012, from ietf

Tunneling of SMTP Message Transfer Priorities (Part 1 of 2) 🎀

Title Block 💌

Okay so this RFC is by A. Melnikov from Isode Ltd and K. Carlberg from G11, published in October 2012. It's an Informational doc, so it's published for information and isn't a Standards Track spec 📚. Its ISSN is 2070-1721, and its number is RFC 6758 ✨. The title block doesn't have any "obsoletes" or "updates" fields, but Section 3 does say its subsections update the matching subsections of Section 4 of [RFC6710] 🦋.

Bestie, this part is the legal stuff, but I'm keeping it all. Here's the Status of This Memo 💖

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 💅.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6758 🔗.

Next is the 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) as in effect on the date of publication. Please read these carefully, since they explain your rights and restrictions for 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 they come without warranty, as described in the Simplified BSD License 🔥.

Table of Contents 🗺️

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
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 ....4
   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 the DSN SMTP Extension ....................5
4. Header Field: MT-Priority .......................................5
5. Example .........................................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
   7.1. Modification of the MT-Priority Header Field and DKIM ......9
8. References ......................................................9
   8.1. Normative References .......................................9
   8.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11

1. Introduction ✨

Okay, so the SMTP Message Transfer Priorities extension [RFC6710] lets a message carry a label that says it needs preferential handling, so mail nodes can factor that into what they do next 🚀. The catch is that every SMTP Message Transfer Agent (MTA) between the source and destination has to support the extension for it to work 😭. This document describes an application-layer tunneling of message priority. It carries the priority through MTAs that don't support the Message Transfer Priorities extension 🦋. The tunnel is a new message header field added to the Internet Message Format from [RFC5322] 💖.

There are already a bunch of header fields, mostly in Message User Agents (MUAs), that try to say how important or urgent a message is 🌈. Some examples are Importance [RFC2156], Priority [RFC2156], and X-Priority (undocumented). Their meanings are sometimes subtly different, sometimes really different, and their syntax is all over the place, so this document defines a brand 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) an unextended MUA talking to an MT-PRIORITY-aware MSA. We'll go through both below 🍓.

Use case (1) is an MT-PRIORITY-capable MUA talking to a non-MT-PRIORITY-capable MSA [RFC6409], which then talks to an MT-PRIORITY-capable MTA [RFC5321]. The MSA and MTA are in the same ADministrative Management Domain (ADMD) and on a fast network. Some recipients, though, are reached through an MTA that talks over a slow link to the next MTA 🐢. That slow link can totally benefit from the MT-PRIORITY SMTP extension 🧚.

In use case (2), a widely deployed client, like a desktop client, talks to an MT-PRIORITY-capable MSA 🖥️. The client might be extendable through a plug-in API from its developers. But existing APIs often make it easy to manipulate email header fields while not allowing additions to SMTP protocol features 🙈. In that case, a plug-in that sets the MT-Priority header field can get the MT-PRIORITY SMTP extension deployed sooner in an organization, without changing the desktop clients 👑.

These use cases aren't exhaustive. Other variations might exist too. This document doesn't try to cover every scenario. It just gives examples that show why we need a tunneling mechanism for SMTP-capable devices that don't support [RFC6710] 💜.

2. Conventions Used in This Document 📖

Here's the key word thing. 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, without their normative meanings 🎀.

The formal syntax uses 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:" mean lines sent by the client and server, respectively. Line breaks that don't start with a new "C:" or "S:" are there for editorial reasons and aren't part of the protocol 📝.

This document uses the term "priority" specifically for how the server internally treats a message. Messages with higher priorities may get expedited handling, and messages with lower priorities may only be handled when resources become available ⚡.

3. Handling of Messages Received via SMTP 📬

The subsections of this section update the corresponding subsections of Section 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 in Section 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 (see Section 4), then the value of this header field is the message priority 🎯.

4b. When both the MT-PRIORITY MAIL FROM parameter and the MT-Priority header field are absent, 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, though, that the Importance [RFC2156] header field MUST NOT be used for determining the priority under this "Priority Message Handling" SMTP extension, because 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 💖.

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 🏷️

Here's the header field's registration info, kept exactly as written 🧾:

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 a message is relayed through MTAs that don't support the MT-PRIORITY SMTP extension 🚀.

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 🎀

okay so this example is giving multi-step transaction, and it's also using STARTTLS [RFC3207] and the Delivery Status Notification (DSN) [RFC3461] SMTP extensions 🧚 but bestie, there is NO requirement that those other extensions be supported when MT-PRIORITY is implemented. ngl that's a fun detail to flag.

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 server supports the "STANAG4406" Priority Assignment Policy [RFC6710] with 6 priority levels, so it's going to use priority value 4 internally (the next supported priority higher or equal to 3 💅) and will communicate priority value 3 when relaying it to the next hop (if necessary). 🌸 When relaying to a 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 🦋

okay so IANA added a header field name to the "Permanent Message Header Field Names" registry 📋 (you can find it at <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 💀

bestie, this section is SERIOUS 😭 okay so this document lets a message priority get tunneled through MTAs that don't support the MT-PRIORITY SMTP extension, by representing it in the message itself using the MT-Priority header field. So it is super important that an MTA receiving a message with the MT-Priority header field can trust that an authorized agent set it 🔒. Technologies like DomainKeys Identified Mail (DKIM) [RFC6376] or S/MIME can be used to sign the MT-Priority header field value, so a recipient can verify whether the priority value came from a trusted agent 🫶. DKIM signing in particular lets a recipient verify that the priority value was present when the message got signed, and verify who signed it. Plot twist though: 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 through the MT-PRIORITY parameter on the MAIL FROM command or the MT-Priority header field in the message itself) from users (or only certain groups of those users) who are authenticated and authorized in some acceptable way. 💅 As part of that policy, they can also restrict the maximum priority values different groups can request, and they can override priority values set 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 what those changes might mean.

Similarly, MTAs ought to only accept message transfer priorities (through the MT-PRIORITY parameter on the MAIL FROM command or the MT-Priority header field in the message itself) from senders (or only certain groups of senders) who are authenticated and authorized in some way acceptable to the MTA. Same deal: they can restrict maximum priority values per group and override the values set by those senders. 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 the consequences.

Without that policy enforcement, an SMTP server (MSA or MTA) implementing the MT-PRIORITY SMTP extension might be open to a denial-of-service attack 🚨. For example, malicious clients (MUAs/MSAs/MTAs) could try to abuse the feature by always requesting priority 9. not cool 😤

To protect the MT-Priority header field from being modified or inserted, MUAs, MSAs, and MTAs that insert it into messages SHOULD use a message header protection mechanism such as DKIM [RFC6376]; however, see Section 7.1 for more information. 🛡️

7.1. Modification of the MT-Priority Header Field and DKIM 🌈

An MSA/MTA that receives a message with a DKIM-protected MT-Priority header field, and that wants to change the message priority because of 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 😭. Each one works in a particular situation, so they 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.

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.

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

That's the whole RFC, bestie! 🌈✨ Thanks for reading along 💜

📦 where this page comes from