Network Working Group A. Melnikov Internet-Draft Isode Ltd Intended status: Standards Track K. Carlberg Expires: August 3, 2012 G11 January 31, 2012 Simple Mail Transfer Protocol extension for Message Transfer Priorities draft-melnikov-smtp-priority-06 Abstract This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are sent with a priority to enable the receiving MTA (Message Transfer Agent) to take this into account for onward processing, with the general goal of processing and/or transferring higher priority messages first. 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 August 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 Melnikov & Carlberg Expires August 3, 2012 [Page 1] Internet-Draft Message Transfer Priority SMTP Extension January 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Definition of the Priority SMTP Extension . . . . . . . . . . 4 4. Handling of messages received via SMTP . . . . . . . . . . . . 4 4.1. Handling of the PRIORITY parameter by the receiving SMTP server . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Determining priority of a message . . . . . . . . . . . . 5 4.3. Relay of messages to other conforming SMTP servers . . . . 6 4.4. Relay of messages to non-conforming SMTP servers . . . . . 6 4.5. Mailing lists and Aliases . . . . . . . . . . . . . . . . 7 4.6. Gatewaying a message into a foreign environment . . . . . 7 4.7. Interaction with DSN SMTP Extension . . . . . . . . . . . 7 5. The Priority Service Extension . . . . . . . . . . . . . . . . 7 5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 8 5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 9 6. Header field: MT-Priority . . . . . . . . . . . . . . . . . . 9 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 11 10. Pending changes . . . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12.1. Modification of MT-Priority header field and DKIM . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Mapping of PRIORITY parameter values for Military Messaging . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Mapping of PRIORITY parameter values for MIXER . . . 16 Appendix C. Mapping of National Security / Emergency Preparedness (NS/EP) Values . . . . . . . . . . . . . 17 Appendix D. Two possible implementation strategies . . . . . . . 18 D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 18 D.2. Preemption of sessions or transactions . . . . . . . . . . 18 Appendix E. Resource Allocation Models . . . . . . . . . . . . . 19 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Melnikov & Carlberg Expires August 3, 2012 [Page 2] Internet-Draft Message Transfer Priority SMTP Extension January 2012 1. Introduction Where resources for switching or transfer of messages are constrained (e.g., bandwidth, round trip time or processing capability) it is desirable to process high priority messages first. 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 MTA to be able to send 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. It also enables communication of message priority through MTAs that are not priority aware, by the specification of a new message header field [RFC5322]. Various MUAs already use various other header fields that convey a similar meaning, such as message importance. Example of such header fields are Importance [RFC2156], Priority [RFC2156] and X-Priority (undocumented). Considering subtle differences in the meaning of these header fields and widely different syntax, this document defines a new header field. 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]. 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 a new "C:" or "S:" exist for editorial reasons and are not a part of the protocol. This document uses the term "priority" in the meaning of expedited treatment of a message by the server according to the message's priority. This document uses the phrase "an email is waiting to be sent", if it resides in the outbound queue of an MTA and can be sent to the next hop or delivered to its final recipient(s) once available resources at the sending MTA allow this. Emails having their processing delayed for some reason within the MTA are not waiting to be sent Melnikov & Carlberg Expires August 3, 2012 [Page 3] Internet-Draft Message Transfer Priority SMTP Extension January 2012 during this delay. The most important reason for emails to be delayed is a transient error response from the next MTA to which the email must be transferred. This document uses the phrase "an email is ready to be sent", if it is waiting to be sent and either no emails with higher priority are waiting to be sent or available resources allow more emails to be sent in parallel than the number of emails with higher priorities that are waiting to be sent. Note that an email may be ready to be sent but the transfer or delivery process can not yet be initiated, because the number of emails ready to be sent exceeds the number of emails that can be processed in parallel. 3. Definition of the Priority SMTP Extension The Priority SMTP service extension is defined as follows: 1. The textual name of this extension is "Priority Message Handling". 2. The EHLO keyword value associated with this extension is "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 ("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. The syntax of the PRIORITY parameter is described by the ABNF non-terminal defined in Section 7. Higher numbers mean higher priority. 6. The maximum length of a MAIL command line is increased by 13 characters by the possible addition of the PRIORITY keyword and value. 7. The PRIORITY extension is valid for the submission service [RFC6409] and LTMP [RFC2033]. 4. Handling of messages received via SMTP This section describes how a conforming MTA should handle any messages received via SMTP. Melnikov & Carlberg Expires August 3, 2012 [Page 4] Internet-Draft Message Transfer Priority SMTP Extension January 2012 4.1. Handling of the PRIORITY parameter by the receiving SMTP server The following rules apply to SMTP transactions in which the PRIORITY parameter is used: 1. A conforming SMTP server SHOULD NOT refuse a MAIL command based on the absence of the PRIORITY parameter. However, if any of the associated esmtp-values are not syntactically valid, or if there is more than one PRIORITY parameter in a particular MAIL command, the server MUST return an error, for example "501 syntax error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034]). Additionally, when inserting a Received header field as specified in Section 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the "PRI" clause which syntax is specified in Section 7. 4.2. Determining priority of a message An SMTP server compliant with this specification can determine the priority of a received message as follows: 1. If the sending SMTP client specified the PRIORITY parameter to the MAIL command, then the value of this parameter is the message priority. 2. If the sending SMTP client hasn't specified the PRIORITY parameter to the MAIL command, but the message has a single syntactically valid MT-Priority header field Section 6, then the value of this header field is the message priority. 3. Otherwise (if no PRIORITY parameter to the MAIL command was specified and the message doesn't contain a syntactically valid MT-Priority header field, or contains multiple MT-Priority header fields) the message has priority 0. Other message header fields, such as Importance [RFC2156], Priority [RFC2156] and X-Priority, MUST NOT be used for determining the priority under this "Priority Message Handling" SMTP extension. The SMTP server SHOULD ignore or downgrade priorities from untrusted (e.g. unauthenticated) or insufficiently trusted sources. (One example of an "insufficiently trusted source" might be an SMTP sender which which authenticated using SMTP AUTH, but which is not explicitly whitelisted to use SMTP PRIORITY service.) Alternatively an SMTP server MAY reject a message based on the determined priority. If the latter case, the server 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 acceptable for Melnikov & Carlberg Expires August 3, 2012 [Page 5] Internet-Draft Message Transfer Priority SMTP Extension January 2012 the receiving SMTP server. Note that this condition might be temporary, for example the server is temporarily operating under the Minimize condition where only high priority messages are accepted for transfer and delivery. Additionally, Mail Submission Agent (MSA) MAY alter the message priority (both to lower or to raise it) in order to enforce sender site policy. 4.3. 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 PRIORITY SMTP extension: 1. A PRIORITY parameter with the value determined by the procedure from Section 4.2 MUST appear in the MAIL command issued when the message is relayed to an MTA/MDA which also supports the PRIORITY extension. (For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if the MTA doesn't support it.) Note that this rule also applies to messages which didn't have any priority explicitly specified (using the PRIORITY MAIL FROM parameter or the MT-Priority header field). 2. Further processing of the PRIORITY parameter is described in Section 5. 4.4. 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 PRIORITY SMTP extension: 1. A PRIORITY parameter MUST NOT appear in the MAIL command issued when relaying the message. 2. The relaying MTA MUST first remove any and all existing MT- Priority header fields from the message, and then add its own MT- Priority header field with the value determined by the procedure in Section 4.2. One exception to this rule is that a message which didn't contain any MT-Priority header field and which didn't have the PRIORITY MAIL FROM parameter specified doesn't need to be updated to contain the "MT-Priority: 0" header field. Syntax of the MT-Priority header field is specified in Section 7. Melnikov & Carlberg Expires August 3, 2012 [Page 6] Internet-Draft Message Transfer Priority SMTP Extension January 2012 4.5. Mailing lists and Aliases Several options 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 original priority for all expanded and/or translated addresses. 4.6. 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 PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a non-conformant SMTP (Section 4.4). 2. If the destination environment is capable of providing an equivalent of the PRIORITY parameter, the conforming MTA SHOULD behave as if it is relaying to a conformant SMTP (Section 4.3), converting the PRIORITY parameter to the equivalent in the destination environment. 4.7. 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 transfered 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 treat all syntactically valid priority values below and including -4 as priority -4, priorities -3 and -2 as priority -2, Melnikov & Carlberg Expires August 3, 2012 [Page 7] Internet-Draft Message Transfer Priority SMTP Extension January 2012 priorities -1 and 0 as priority 0, etc., with 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. Irrespectively on 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 comminicate the priority value as determined in Section 4.2. Note: 19 possible priority levels are defined by this specification for extensibility, for example if a particular implementation or deployment environment needs to provide fine grainer control over message transfer priorities, for example a server implementation may need to have an extra high priority level to the 6 levels defined above. 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. Some SMTP servers MAY impose additional maximum message size contraints 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]. Implementation Note: If the SMTP server also supports the SMTP SIZE extension [RFC1870] then an SMTP client can use both SIZE= and 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 wasted bandwidth. 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 SHOULD send 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. In order to make implementations of this extension easier, this SMTP extension only allows a single priority for all recipients of the same message. As a default policy, emails with higher priority waiting to be sent Melnikov & Carlberg Expires August 3, 2012 [Page 8] Internet-Draft Message Transfer Priority SMTP Extension January 2012 by a client SHOULD NOT initiate transactions for emails with lower priorites. If two or more emails with the same priority are ready to be sent at the same time, the MTA should use its regular algorithm (the algorithm used in absence of this SMTP extension) for deciding how to send them out. In networks with limited available bandwidth or long round trip times the actual message transfer over the network may create a significant portion of the overall message delivery time from a sender to a recipient. 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. 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. 5.2. Timely Delivery An important constraint (usually associated with higher priority levels) is, that messages with that priority have to reach its destination within a defined period of time. In some cases, higher priorities mean shorter maximum allowed time of 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. 6. 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): [[anchor11: this document]] The MT-Priority header field conveys message transfer priority when relaying a message through MTAs which don't support the PRIORITY SMTP extension. ABNF for this header field is defined as follows: Melnikov & Carlberg Expires August 3, 2012 [Page 9] Internet-Draft Message Transfer Priority SMTP Extension January 2012 priority-header-field = "MT-Priority:" [CFWS] priority-value [CFWS] CRLF where "priority-value" is defined in Section 7 Example: MT-Priority: -30 7. Syntax priority-value = (["-"] NZDIGIT) / "0" ; Allowed values are from -9 to 9 inclusive NZDIGIT = %x31-39 ; "1"-"9" CFWS = ; New "clause" that can be used in the Received header field Pri = CFWS "PRI" FWS priority-value ; Complies with the ; non-terminal syntax from RFC 5321. 8. 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 thought there is no requirement that these other extensions are to be supported when the PRIORITY SMTP extension is implemented. Melnikov & Carlberg Expires August 3, 2012 [Page 10] Internet-Draft Message Transfer Priority SMTP Extension January 2012 S: 220 example.net SMTP server here C: EHLO example.com S: 250-example.net S: 250-DSN S: 250-DELIVERBY S: 250-PRIORITY C: MAIL FROM: BY=120;R ENVID=QQ314159 PRIORITY=3 S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=rfc822;Dana@Ivory.example.net S: 250 recipient ok C: DATA S: 354 okay, send message C: (message goes here) C: . S: 250 message accepted C: QUIT S: 221 goodbye 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). 9. Deployment Considerations If multiple DNS MX records are used to specify multiple servers for a domain in section 5 of [RFC5321], it is advised that all or none of them SHOULD support the 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. 10. Pending changes [[anchor15: This section should be removed before publication]] Rename the PRIORITY extension/MAIL FROM parameter to something like MT-PRIORITY. Please advise editors of this document if you have an opinion one way or another. Melnikov & Carlberg Expires August 3, 2012 [Page 11] Internet-Draft Message Transfer Priority SMTP Extension January 2012 11. IANA Considerations This specification requests IANA to add the PRIORITY SMTP extension to the "SMTP Service Extensions" registry (in http://www.iana.org/assignments/mail-parameters). IANA is also 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): [[anchor17: this document]] 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 PRIORITY SMTP extension: Clause name: PRI Description: Records the value of the PRIORITY parameter specified in the MAIL command Syntax of the value: See Section 7 of RFCXXXX Reference: [[anchor18: 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 under the Minimize condition where only high Melnikov & Carlberg Expires August 3, 2012 [Page 12] Internet-Draft Message Transfer Priority SMTP Extension January 2012 priority messages are accepted for transfer and delivery. 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) Description: The message is too big for the specified priority. Reference: RFC XXXX Submitter: A. Melnikov Change controller: IESG 12. Security Considerations This document allows a message priority to be tunneled through MTAs which don't support the 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. Such trust can be realized, for example, by using DKIM Section 12.1 to sign the MT-Priority header field value, S/MIME, or by keeping a list of trusted senders (e.g. within a close environment) . Message Submission Agents can implement a policy that only allows authenticated users (or only certain groups of authenticated users) to specify message transfer priorities (whether by using the PRIORITY parameter to the MAIL command or the MT-Priority header field in the message itself), and to restrict maximum priority values different groups of users can request, or override the priority values specified by MUAs. Such MSAs SHOULD strip any MT-Priority header field values that don't satisfy this policy. See Section 12.1 for more details on when violation of this SHOULD is warranted. Similarly, MTAs can implement a policy that only allows authenticated Melnikov & Carlberg Expires August 3, 2012 [Page 13] Internet-Draft Message Transfer Priority SMTP Extension January 2012 and trusted senders (or only certain groups of authenticated senders) to specify message transfer priorities (whether by using the PRIORITY parameter to the MAIL command or the MT-Priority header field in the message itself), and to restrict maximum priority values different groups of senders can request, or override the priority values specified by them. Such MTAs SHOULD strip any MT-Priority header field values that don't satisfy this policy. See Section 12.1 for more details on when violation of this SHOULD is warranted. In the absence of the policy enforcement mentioned above an SMTP server (whether an MSA or an MTA) implementing this 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 12.1. 12.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), b) leaving the message as is (and using the PRIORITY MAIL FROM parameter), relying on the fact that all downstream MTAs are compliant with this specification, or c) rejecting the message. All of these choices have pros and cons, which should be carefully considered during deployment. If the MSA/MTA decides to alter the message, it SHOULD re-sign the message with DKIM. 13. References 13.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 Melnikov & Carlberg Expires August 3, 2012 [Page 14] Internet-Draft Message Transfer Priority SMTP Extension January 2012 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. 13.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 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 Melnikov & Carlberg Expires August 3, 2012 [Page 15] Internet-Draft Message Transfer Priority SMTP Extension January 2012 Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, June 2005. [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 PRIORITY parameter values for Military Messaging Military Messaging as specified in STANAG 4406 defines six priority values. Where SMTP is used to support military messaging, the following mappings SHOULD be used. Recommended mapping of 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 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. Melnikov & Carlberg Expires August 3, 2012 [Page 16] Internet-Draft Message Transfer Priority SMTP Extension January 2012 Recommended mapping of PRIORITY values for MIXER +----------------------+----------------+ | MIXER Priority value | PRIORITY value | +----------------------+----------------+ | non-urgent | -4 | | normal | 0 | | urgent | 4 | +----------------------+----------------+ Table 2 Appendix C. Mapping of National Security / Emergency Preparedness (NS/EP) Values Communication systems used during an emergency or disaster are realized in several forms. 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 | ---------- | Melnikov & Carlberg Expires August 3, 2012 [Page 17] Internet-Draft Message Transfer Priority SMTP Extension January 2012 | 6 | Highest Priority | +----------------+------------------+ As in the case of Appendix A and 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. 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 focusses only on a comparision of priorities to determine if previously established transactions must 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 should 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 should 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 must 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 should deploy it. An example for a Melnikov & Carlberg Expires August 3, 2012 [Page 18] Internet-Draft Message Transfer Priority SMTP Extension January 2012 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 must preempt the next session that reaches the end of a transaction. Appendix E. 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 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 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 and Chris Newman. Special thanks to Barry Leiba for agreeing to shepherd this document. Melnikov & Carlberg Expires August 3, 2012 [Page 19] Internet-Draft Message Transfer Priority SMTP Extension January 2012 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 August 3, 2012 [Page 20]