7Internet Engineering Task Force (IETF) A. Melnikov
8Request for Comments: 6710 Isode Ltd
9Category: Standards Track K. Carlberg
14Simple Mail Transfer Protocol Extension for Message Transfer Priorities
18 This memo defines an extension to the SMTP (Simple Mail Transfer
19 Protocol) service whereby messages are given a label to indicate
20 preferential handling, to enable mail handling nodes to take this
21 information into account for onward processing.
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 5741.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 http://www.rfc-editor.org/info/rfc6710.
39 Copyright (c) 2012 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
58Melnikov & Carlberg Standards Track [Page 1]
60RFC 6710 Message Transfer Priority SMTP Extension August 2012
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
67 3. Definition of the Priority SMTP Extension . . . . . . . . . . 4
68 4. Handling of Messages Received via SMTP . . . . . . . . . . . . 5
69 4.1. Handling of the MT-PRIORITY Parameter by the Receiving
70 SMTP Server . . . . . . . . . . . . . . . . . . . . . . . 5
71 4.2. Relay of Messages to Other Conforming SMTP/LMTP Servers . 6
72 4.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers . . 7
73 4.4. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 7
74 4.5. Gatewaying a Message into a Foreign Environment . . . . . 7
75 4.6. Interaction with the DSN SMTP Extension . . . . . . . . . 7
76 5. The Priority Service Extension . . . . . . . . . . . . . . . . 8
77 5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 9
78 5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10
79 6. Use of MT-PRIORITY with LMTP . . . . . . . . . . . . . . . . . 10
80 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
81 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
82 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14
83 9.1. Multiple MX Records . . . . . . . . . . . . . . . . . . . 14
84 9.2. Priority Assignment Policies . . . . . . . . . . . . . . . 15
85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
86 10.1. Requirements on Priority Assignment Policy
87 Registrations . . . . . . . . . . . . . . . . . . . . . . 17
88 10.2. Initial Priority Assignment Policy Registrations . . . . . 18
89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
91 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
92 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
93 Appendix A. Priority Assignment Policy for Military Messaging . . 22
94 Appendix B. Priority Assignment Policy for MIXER . . . . . . . . 23
95 Appendix C. Priority Assignment Policy for National Security
96 / Emergency Preparedness (NS/EP) . . . . . . . . . . 24
97 Appendix D. Possible Implementation Strategies . . . . . . . . . 25
98 D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 25
99 D.2. Preemption of Sessions or Transactions . . . . . . . . . . 25
100 D.3. Resource Allocation Models . . . . . . . . . . . . . . . . 26
101 Appendix E. Background on Design Choices . . . . . . . . . . . . 26
102 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 27
114Melnikov & Carlberg Standards Track [Page 2]
116RFC 6710 Message Transfer Priority SMTP Extension August 2012
121 Where resources for switching or transferring messages are
122 constrained (e.g., bandwidth, round trip time, transition storage, or
123 processing capability), it is desirable to give preferential handling
124 to some messages over others, according to their labeled priority.
125 This is particularly important during emergencies for first
126 responders (Appendix C) and for environments such as military
127 (Appendix A) and aviation (Appendix B) messaging, where messages have
128 high operational significance, and the consequences of extraneous
129 delay can be significant.
131 In order for an SMTP receiver to be able to relay higher-priority
132 messages first, there needs to be a mechanism to communicate (during
133 both Message Submission [RFC6409] and Message Transfer [RFC5321]) the
134 priority of each message. This specification defines this mechanism
135 by specification of an SMTP [RFC5321] extension.
137 In order to permit end-to-end use of this extension across an email
138 infrastructure that does not support it, a companion tunneling
139 mechanism is defined in [PRIORITY-TUNNELING] that uses a new message
140 header field [RFC5322].
142 This extension provides services to some classes of users in networks
143 with limited available bandwidth or long round trip times, when the
144 actual message transfer over the network can create a significant
145 portion of the overall message delivery time from a sender to a
146 recipient, for example, over a satellite or high-frequency radio
147 link. It is also useful in case of a Mail Transfer Agent (MTA) queue
148 buildup due to the rate of incoming messages being higher than the
149 rate of outgoing messages. When neither of the two conditions
150 mentioned above is true, the use of the MT-PRIORITY SMTP extension
151 will not result in better SMTP service to any user. Also note that
152 while this SMTP extension can help in improving delivery speed for
153 higher-priority messages, it does not provide any guarantees that for
154 two given messages with priorities M and N (M > N) submitted
155 simultaneously, the message with priority M will arrive earlier than
156 the message with priority N. That is, this extension calls for best
157 effort to provide preferential processing.
159 Besides the actions taken at the application level, it can thus be
160 important to deploy priority or precedence mechanisms offered by the
161 network itself to ensure timely delivery of the emails. Examples
162 would be the use of DiffServ [RFC2474], RSVP [RFC2205], and [RFC6401]
163 (an extension to RSVP that prioritizes reservations).
170Melnikov & Carlberg Standards Track [Page 3]
172RFC 6710 Message Transfer Priority SMTP Extension August 2012
1752. Conventions Used in This Document
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119] when they
180 appear in ALL CAPS. These words also appear in this document in
181 lower case as plain English words, absent their normative meanings.
183 The formal syntax uses the Augmented Backus-Naur Form (ABNF)
184 [RFC5234] notation including the core rules defined in Appendix B of
187 In examples, "C:" and "S:" indicate lines sent by the client and
188 server, respectively. Line breaks that do not start with a new "C:"
189 or "S:" exist for editorial reasons and are not a part of the
192 This document uses the term "priority" specifically in relation to
193 the internal treatment of a message by the server. Messages with
194 higher priorities may be given expedited handling, and those with
195 lower priorities may be handled only as resources become available.
1973. Definition of the Priority SMTP Extension
199 The Priority SMTP service extension is defined as follows:
201 1. The textual name of this extension is "Priority Message
204 2. The EHLO keyword value associated with this extension is
207 3. The EHLO keyword has an OPTIONAL parameter that conveys the name
208 of the Priority Assignment Policy (see Section 9.2) used by the
209 server. (See the <mt-priority-ehlo> ABNF non-terminal in
210 Section 7 for details of its syntax.) Absence of the parameter
211 means that the server is unwilling to disclose its Priority
212 Assignment Policy. Clients can choose to use the MT-PRIORITY
213 SMTP extension even if they don't recognize a particular Priority
214 Assignment Policy name advertised by a server.
216 4. No additional SMTP verbs are defined by this extension.
218 5. One optional parameter ("MT-PRIORITY") is added to the MAIL FROM
219 command. The value associated with this parameter is a decimal
220 integer number from -9 to 9 (inclusive) indicating the priority
221 of the email message (see Appendix E for more details on why this
222 range was selected). The syntax of the MT-PRIORITY parameter is
226Melnikov & Carlberg Standards Track [Page 4]
228RFC 6710 Message Transfer Priority SMTP Extension August 2012
231 described by the <priority-value> ABNF non-terminal defined in
232 Section 7. Higher numbers mean higher priority.
234 6. The maximum length of a MAIL FROM command line is increased by 15
235 octets by the possible addition of a space, the MT-PRIORITY
236 keyword, and a priority value.
238 7. The MT-PRIORITY extension is valid for the submission service
239 [RFC6409] and the Local Mail Transfer Protocol (LMTP) [RFC2033].
2414. Handling of Messages Received via SMTP
243 This section describes how a conforming SMTP server should handle any
244 messages received via SMTP.
2464.1. Handling of the MT-PRIORITY Parameter by the Receiving SMTP Server
248 The following rules apply to SMTP transactions in a server that
249 supports the MT-PRIORITY parameter:
251 1. If any of the associated <esmtp-value>s (as defined in Section
252 4.1.2 of [RFC5321]) are not syntactically valid, or if there is
253 more than one MT-PRIORITY parameter in a particular MAIL FROM
254 command, the server MUST return an error, for example "501 syntax
255 error in parameter" (with the 5.5.2 Enhanced Status Code
256 [RFC2034] [RFC5248]).
258 2. When inserting a Received header field as specified in Section
259 4.4 of [RFC5321], the compliant MTA/MSA (Mail Submission Agent)
260 SHOULD include the "PRIORITY" clause whose syntax is specified in
263 3. The received MT-PRIORITY parameter value SHOULD be logged as part
264 of any logging of message transactions.
266 4. If the sending SMTP client specified the MT-PRIORITY parameter to
267 the MAIL FROM command, then the value of this parameter is the
270 5. If no priority has been determined by the above, the server may
271 use its normal policies to set the message's priority. By
272 default, each message has priority 0.
274 The SMTP server MUST NOT allow "upgraded" (positive) priorities from
275 untrusted (e.g., unauthenticated) or unauthorized sources. (One
276 example of an "unauthorized source" might be an SMTP sender that
277 successfully authenticated using SMTP AUTH, but that is not
278 explicitly authorized to use the SMTP MT-PRIORITY service. In case
282Melnikov & Carlberg Standards Track [Page 5]
284RFC 6710 Message Transfer Priority SMTP Extension August 2012
287 of MTA-to-MTA transfer, such authorization will usually be done as a
288 bilateral agreement between two domains to honor priorities from each
289 other.) The server MAY, however, allow an untrusted source to lower
290 its own message's priorities -- consider, for example, an email
291 marketer that voluntarily sends its marketing messages at a negative
294 The SMTP server MAY also alter the message priority (to lower or to
295 raise it) in order to enforce some other site policy. (Note that
296 this also includes the case in which the priority is not explicitly
297 specified.) For example, an MSA might have a mapping table that
298 assigns priorities to messages based on authentication credentials.
300 If the SMTP server changes (lowers or raises) the priority of a
301 message, it SHOULD use the X.3.6 Enhanced Status Code [RFC2034] in
302 its response to the MAIL FROM or in the final response to the DATA
303 (or similar) command. The human readable text part after the status
304 code contains the new priority, followed by SP (ASCII space) and
305 explanatory human readable text.
307 Alternatively, an SMTP server that is an MSA MAY reject a message
308 based on the determined priority. In such cases, the MSA SHOULD use
309 the 450 or 550 reply code. The corresponding Enhanced Status Code
310 MUST be X.7.15 [RFC2034] if the determined priority level is below
311 the lowest priority currently acceptable for the receiving SMTP
312 server. Note that this condition might be temporary. In some
313 environments, operational policies might permit periods of operation
314 that relay only higher-priority messages and reject lower priority
315 ones. Such handling choices need to be specified for that
316 operational environment.
3184.2. Relay of Messages to Other Conforming SMTP/LMTP Servers
320 The following rules govern the behavior of a conforming MTA (in the
321 role of an SMTP/LMTP client) when relaying a message that was
322 received via the SMTP protocol to an SMTP/LMTP server that supports
323 the MT-PRIORITY extension:
325 1. An MT-PRIORITY parameter with the value determined by the
326 procedure from Section 4.1 MUST appear in the MAIL FROM command
327 issued when the message is relayed to an MTA/MDA (Mail Delivery
328 Agent) that also supports the MT-PRIORITY extension. (Note that
329 due to site policy, this value might be different from the value
330 received from the SMTP client. See Section 4.1 for details.
331 Also note that this value might be different than the priority
332 level at which the MTA actually handles the request, due to the
333 rounding described in Section 5.)
338Melnikov & Carlberg Standards Track [Page 6]
340RFC 6710 Message Transfer Priority SMTP Extension August 2012
343 2. Further processing of the MT-PRIORITY parameter is described in
3464.3. Relay of Messages to Non-Conforming SMTP/LMTP Servers
348 The following rules govern the behavior of a conforming MTA (in the
349 role of an SMTP/LMTP client) when relaying a message that was
350 received via the SMTP protocol to an SMTP/LMTP server that does not
351 support the MT-PRIORITY extension:
353 1. The MTA relays the message without including the MT-PRIORITY
354 parameter in the MAIL FROM command.
3564.4. Mailing Lists and Aliases
358 Several types of mechanisms exist to redirect or forward messages to
359 alternative or multiple addresses [RFC5598]. Examples for this are
360 aliases and mailing lists [RFC5321].
362 If a message is subject to such processing, the Mediator node
363 (Section 2.1 of [RFC5598]) SHOULD retain the MT-PRIORITY parameter
364 value for all expanded and/or translated addresses.
3664.5. Gatewaying a Message into a Foreign Environment
368 The following rules govern the behavior of a conforming MTA when
369 gatewaying a message that was received via the SMTP protocol into a
370 foreign (non-SMTP) environment:
372 1. If the destination environment is unable to provide an equivalent
373 of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as
374 if it is relaying to a non-conformant SMTP server (Section 4.3).
376 2. If the destination environment is capable of providing an
377 equivalent of the MT-PRIORITY parameter, the conforming MTA
378 SHOULD behave as if it is relaying to a conformant SMTP server
379 (Section 4.2), converting the MT-PRIORITY value to the equivalent
380 in the destination environment.
3824.6. Interaction with the DSN SMTP Extension
384 An MTA that needs to generate a delivery report (whether for
385 successful delivery or delayed/failed delivery) for a message it is
386 processing SHOULD use the priority value of the message as the
387 priority of the generated delivery report. In particular, this
388 requirement applies to MTAs that also implement [RFC3461].
394Melnikov & Carlberg Standards Track [Page 7]
396RFC 6710 Message Transfer Priority SMTP Extension August 2012
399 For delivery reports (DSNs) received by an MTA for relay, processing
400 rules specified in Section 4.1 apply -- there is no special
401 processing for relayed DSNs. It might seem tempting to try to detect
402 DSNs and process them at an elevated priority under the assumption
403 that failure notices need to get through quickly, even or perhaps
404 especially if the DSN came from an untrusted source. But such a
405 policy can create an exposure to fake DSN attacks by giving untrusted
406 systems a way to inject high-priority messages. Implementation of
407 such a policy also assumes that DSNs can be detected reliably, which
408 may not be the case since some systems use nonstandard DSN formats.
4105. The Priority Service Extension
412 The priorities of messages affect the order in which messages are
413 transferred from the client to the server. This is largely
414 independent from the order in which they were originally received by
417 A message priority is a decimal integer in the range from -9 to 9
418 (inclusive). SMTP servers compliant with this specification are not
419 required to support all 19 distinct priority levels (i.e., to treat
420 each priority value as a separate priority), but they MUST implement
421 all distinct priority levels specified in the Priority Assignment
422 Policy (see Section 9.2) implemented by the server. That is, an
423 implementation that only supports N priority levels (where N < 19)
424 will internally round up a syntactically valid priority value that
425 isn't supported to the next higher supported number (or to the
426 highest supported priority, if the value is higher than any supported
427 priority). For example, an implementation can treat priority values
428 below and including -4 as priority -4, priority -3 as priority -2,
429 and all priorities starting from 5 can be treated as priority 6.
430 (See Section 9.2 for implementation/deployment considerations related
431 to Priority Assignment Policy.)
433 Irrespective of the number of distinct priority levels supported by
434 the SMTP server, when relaying the message to the next hop or
435 delivering it over LMTP, the SMTP server MUST communicate the
436 priority value as determined in Section 4.1.
438 Note: 19 possible priority levels are defined by this specification
439 for extensibility. For example, a particular implementation or
440 deployment environment might need to provide finer-grained control
441 over message transfer priorities. See Appendix E for more details on
442 why the range from -9 to 9 was selected.
444 As per the Priority Assignment Policy, some SMTP servers MAY impose
445 additional maximum message size constraints for different message
446 transfer priorities; for example, messages with priority 6 might not
450Melnikov & Carlberg Standards Track [Page 8]
452RFC 6710 Message Transfer Priority SMTP Extension August 2012
455 be larger than 4 Kb. If an SMTP server chooses to reject a message
456 because it is too big for the determined priority, it SHOULD use 552
457 reply codes together with the X.7.16 Enhanced Status Code [RFC2034].
459 Implementation Note: If the SMTP server also supports the SMTP SIZE
460 extension [RFC1870], then an SMTP client can use both SIZE= and
461 MT-PRIORITY= parameters on the MAIL FROM command. This allows the
462 server to perform early rejection of a message in case the message
463 size is too big for the specified priority, thus avoiding wasting
464 bandwidth by transferring the message first and then rejecting it due
467 The Priority Service Extension can be combined with the DELIVERBY
468 [RFC2852] SMTP service extension; however, there is no requirement
469 that both extensions always be implemented together.
4715.1. Expedited Transfer
473 The main service provided by the Priority Message Handling SMTP
474 Service Extension is expedited transfer of emails with a higher
475 priority. Therefore, an SMTP client that has more than one email to
476 send at a given time sends those with a higher priority before those
477 with a lower one. Additionally, the retry interval and/or default
478 timeout before a non-delivery report is generated MAY be lower (more
479 aggressive) for messages of higher priority. Lower retry intervals/
480 default timeouts are controlled by the local MTA policy.
482 Note that as this SMTP extension requires some sort of trust
483 relationship between a sender and a receiver and thus some form of
484 authentication (whether using SMTP AUTH, TLS, IP address whitelist,
485 etc.), so senders using this SMTP extension will not be subject to
486 greylisting [RFC6647], unless they are unauthorized to use this SMTP
487 extension due to an explicit policy decision or a misconfiguration
488 error. However, note that in case of connection-level or SMTP EHLO/
489 HELO greylisting, SMTP AUTH or TLS authentication options are not
490 available to the server.
492 In order to make implementations of this extension easier, this SMTP
493 extension only allows a single priority for all recipients of the
496 Within a priority level, the MTA uses its normal algorithm (the
497 algorithm used in absence of this SMTP extension) for determining
498 message processing order.
506Melnikov & Carlberg Standards Track [Page 9]
508RFC 6710 Message Transfer Priority SMTP Extension August 2012
511 Several possible ways of implementing expedited transfer are
512 described in more details in Appendix D. Note that these sections
513 don't describe all details and pitfalls for each implementation
518 An important constraint (usually associated with higher-priority
519 levels) in some environments is that messages with high-priority
520 values have some delivery time constraints. In some cases, higher
521 priorities mean a shorter maximum time allowed for delivery.
523 Unextended SMTP does not offer a service for timely delivery, i.e.,
524 "deliver this message within X seconds from submission" service. The
525 "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
526 [RFC2852] is an example of an SMTP extension providing a service that
527 can be used to implement timely delivery. Note that SMTP DELIVERBY
528 and SMTP MT-PRIORITY extensions are complimentary and can be used
529 together (assuming the SMTP server they are talking to advertises
530 support for both). However, note that use of the DELIVERBY extension
531 alone does not guarantee any priority processing. If the client is
532 using both SMTP DELIVERBY and SMTP MT-PRIORITY at the same time, the
533 client can consider using smaller DELIVERBY timeouts for higher-
5366. Use of MT-PRIORITY with LMTP
538 An LMTP server can advertise support for the MT-PRIORITY extension if
539 it supports any combination of the following features:
541 1. The LMTP server is architected in such a way that it can deliver
542 higher-priority messages quicker than lower-priority messages.
544 2. The LMTP server logs that the MT-PRIORITY extension was used by
545 the previous SMTP hop.
547 3. The LMTP server is exposing information about the MT-PRIORITY
548 extension to a delivery-time filtering engine such as Sieve
562Melnikov & Carlberg Standards Track [Page 10]
564RFC 6710 Message Transfer Priority SMTP Extension August 2012
569 priority-value = (["-"] NZDIGIT) / "0"
570 ; Allowed values are from -9 to 9 inclusive
575 CFWS = <defined in RFC 5322>
577 ; New "clause" that can be used in the Received header field
578 Pri = CFWS "PRIORITY" FWS priority-value
579 ; Complies with the <Additional-Registered-Clauses>
580 ; non-terminal syntax from RFC 5321.
582 mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile]
583 ; Complies with the <ehlo-line> ABNF production
586 priority-profile = 1*20(ALPHA / DIGIT / "-" / "_" / ".")
587 ; name of the Priority Assignment Profile advertized in
588 ; the MT-PRIORITY EHLO response.
590 ALPHA = <Defined in RFC 5234>
592 DIGIT = <Defined in RFC 5234>
618Melnikov & Carlberg Standards Track [Page 11]
620RFC 6710 Message Transfer Priority SMTP Extension August 2012
625 The original submission (from MUA (Mail User Agent) to MSA) might
626 appear as shown below. Note that the example is also making use of
627 the STARTTLS [RFC3207], DELIVERBY [RFC2852], and DSN [RFC3461] SMTP
628 extensions, even though there is no requirement that these other
629 extensions be supported when the MT-PRIORITY SMTP extension is
632 S: 220 example.com SMTP server here
633 C: EHLO mua.example.com
636 S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
639 S: 250-ENHANCEDSTATUSCODES
640 S: 250 MT-PRIORITY MIXER
642 [...authentication exchange...]
643 S: 235 2.7.0 Authentication successful
644 C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
646 S: 250 2.1.0 <eljefe@example.com> sender ok
647 C: RCPT TO:<topbanana@example.net>
648 S: 250 2.1.5 <topbanana@example.net> recipient ok
649 C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
650 ORCPT=rfc822;Dana@Ivory.example.net
651 S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
653 S: 354 okay, send message
654 C: (message goes here)
656 S: 250 2.1.0 message accepted
660 In the above example, the MUA has specified the priority 3 and the
661 server has accepted it. The server is advertising the MIXER Priority
662 Assignment Policy (the default). Another variant of the initial
663 submission might look like:
674Melnikov & Carlberg Standards Track [Page 12]
676RFC 6710 Message Transfer Priority SMTP Extension August 2012
679 S: 220 example.com SMTP server here
680 C: EHLO mua.example.com
683 S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5
686 S: 250-ENHANCEDSTATUSCODES
689 [...authentication exchange...]
690 S: 235 2.7.0 Authentication successful
691 C: MAIL FROM:<eljefe@example.com> BY=125;R ENVID=QQ314159
692 S: 250 2.1.0 <eljefe@example.com> sender ok
693 C: RCPT TO:<topbanana@example.net>
694 S: 250 2.1.5 <topbanana@example.net> recipient ok
695 C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
696 ORCPT=rfc822;Dana@Ivory.example.net
697 S: 250 2.1.5 <Dana@Ivory.example.net> recipient ok
699 S: 354 okay, send message
700 C: (message goes here)
702 S: 250 X.3.6 3 is the new priority assigned to the message
706 In the above example, the MUA has not specified any priority, but the
707 MSA has assigned priority 3 to the message. Also note that the
708 server is unwilling to adverte the Priority Assignment Policy it
709 supports in the EHLO response.
711 The MSA relays the message to the next MTA.
730Melnikov & Carlberg Standards Track [Page 13]
732RFC 6710 Message Transfer Priority SMTP Extension August 2012
735 S: 220 example.net SMTP server here
740 S: 250 MT-PRIORITY STANAG4406
741 C: MAIL FROM:<eljefe@example.com> BY=120;R ENVID=QQ314159
743 S: 250 <eljefe@example.com> sender ok
744 C: RCPT TO:<topbanana@example.net>
745 S: 250 <topbanana@example.net> recipient ok
746 C: RCPT TO:<Dana@Ivory.example.net> NOTIFY=SUCCESS,FAILURE
747 ORCPT=rfc822;Dana@Ivory.example.net
748 S: 250 <Dana@Ivory.example.net> recipient ok
750 S: 354 okay, send message
751 C: (message goes here)
753 S: 250 message accepted
757 The receiving SMTP server advertises support for the "STANAG4406"
758 Priority Assignment Policy, which supports 6 priority levels as
759 described in Appendix A. This means that the server will use the
760 priority value 4 internally (the next supported priority higher or
761 equal to 3) and will communicate the priority value 3 when relaying
762 it to the next hop (if necessary).
7649. Deployment Considerations
7669.1. Multiple MX Records
768 If multiple DNS MX records are used to specify multiple servers for a
769 domain in Section 5 of [RFC5321], it is strongly advised that all of
770 them support the MT-PRIORITY extension and handle priorities in
771 exactly the same way. If one or more servers behave differently in
772 this respect, then it is strongly suggested that none of the servers
773 support the MT-PRIORITY extension. Otherwise, unexpected differences
774 in message delivery speed or even rejections can happen during
775 temporary or permanent failures, which users might perceive as
776 serious reliability issues.
786Melnikov & Carlberg Standards Track [Page 14]
788RFC 6710 Message Transfer Priority SMTP Extension August 2012
7919.2. Priority Assignment Policies
793 This document allows up to 19 distinct priority values. In a
794 particular operating environment, independent originators need to
795 assign priority values according to, roughly, the same criteria, so
796 that the same "high priority message" doesn't get associated with the
797 value 3 for one sender and with the value 5 for another, as such
798 messages might unintentionally receive different preferential
801 In order to achieve consistent behavior in an operating environment,
802 the Priority Assignment Policy (together with possible associated
803 restrictions on maximum message sizes for each priority (if any),
804 default timeouts, etc.) should be documented for the environment.
805 Each SMTP/LMTP server supports a Priority Assignment Policy, whether
806 explicit (advertised in the MT-PRIORITY EHLO response) or implicit
807 (not advertised). The default Priority Assignment Policy (assumed by
808 the client when no Priority Assignment Policy name is advertised in
809 the MT-PRIORITY EHLO response) is specified in Appendix B. Two other
810 policies are specified in Appendix A and Appendix C. Additional
811 policies SHOULD be registered with IANA as specified in Section 10.1.
813 Moreover, all MSAs/MTAs/MDAs within any given Administrative
814 Management Domain has to be configured to use the same Priority
815 Assignment Policy. Otherwise, a differently configured MSA/MTA/MDA
816 can expose the whole domain to possible attacks, like injection of a
817 high-priority fake DSN.
819 When this SMTP extension is deployed across multiple cooperating
820 Administrative Domains, such Administrative Domains need to use the
821 same or at least compatible policies. Again, differences in policies
822 (for example, differences in how users are authenticated or
823 differences in how priorities are handled) can expose an
824 Administrative Domain to weaknesses in a partner domain.
82610. IANA Considerations
828 IANA has added the MT-PRIORITY SMTP extension to the "SMTP Service
830 (http://www.iana.org/assignments/mail-parameters). This extension is
831 suitable for the Submit port.
833 IANA has added the following new Received header field clause to the
834 "Additional-registered-clauses" sub-registry
835 (http://www.iana.org/assignments/mail-parameters) to help with
836 tracing email messages delivered using the MT-PRIORITY SMTP
842Melnikov & Carlberg Standards Track [Page 15]
844RFC 6710 Message Transfer Priority SMTP Extension August 2012
847 Clause name: PRIORITY
848 Description: Records the value of the MT-PRIORITY parameter specified
849 in the MAIL FROM command
850 Syntax of the value: See Section 7 of RFC 6710
853 IANA has added the following Enumerated Status Codes to the "Simple
854 Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry
855 (http://www.iana.org/assignments/smtp-enhanced-status-codes)
856 established by [RFC5248]:
860 Sample Text: Priority Level is too low
862 Associated basic status code: 450, 550 (other 4XX or 5XX codes
865 Description: The specified priority level is below the lowest
866 priority acceptable for the receiving SMTP server. This
867 condition might be temporary, for example the server is
868 operating in a mode where only higher-priority messages are
869 accepted for transfer and delivery, while lower-priority
870 messages are rejected.
874 Submitter: A. Melnikov
876 Change controller: IESG
880 Sample Text: Message is too big for the specified priority
882 Associated basic status code: 552 (other 4XX or 5XX codes are
885 Description: The message is too big for the specified priority.
886 This condition might be temporary, for example the server is
887 operating in a mode where only higher-priority messages below a
888 certain size are accepted for transfer and delivery.
892 Submitter: A. Melnikov
894 Change controller: IESG
898Melnikov & Carlberg Standards Track [Page 16]
900RFC 6710 Message Transfer Priority SMTP Extension August 2012
905 Sample Text: Requested priority was changed
907 Associated basic status code: 250 or 251
909 Description: The message was accepted for relay/delivery, but
910 the requested priority (possibly the implied default) was not
911 honored. The human readable text after the status code
912 contains the new priority, followed by SP (space) and
913 explanatory human readable text.
917 Submitter: A. Melnikov
919 Change controller: IESG
921 IANA has created a new IANA registry called "SMTP PRIORITY Extension
922 Priority Assignment Policy". Future registrations in this registry
923 are governed by the "Specification Required" [RFC5226] IANA
924 registration policy. Requirements on registrations (to be verified
925 by the Designated Expert) are specified in Section 10.1. Changes to
926 registrations undergo the same process as initial registrations. In
927 cases of significant changes to registrations (other than editorial
928 clarifications), the Designated Expert MAY require registration of a
929 Priority Assignment Policy with a new name instead of updating the
93210.1. Requirements on Priority Assignment Policy Registrations
934 Priority Assignment Policy registrations with IANA are accompanied by
935 a policy specification document that MUST specify the following
938 1. The Priority Assignment Policy name, which is a case-insensitive
939 string of 1 to 20 US-ASCII characters to be advertised as the
940 MT-PRIORITY EHLO parameter. Allowed characters are: ALPHA,
941 DIGIT, "-", "_", and "."
943 2. Number of distinct priority levels supported by all servers
944 implementing the policy and their respective values.
946 3. For each supported priority level: default retry timeouts (how
947 often to retry sending a message if there is a temporary error to
948 transfer/deliver it). The policy specification can also
949 explicitly define such information as implementation and/or
954Melnikov & Carlberg Standards Track [Page 17]
956RFC 6710 Message Transfer Priority SMTP Extension August 2012
959 4. For each supported priority level: default expiration timeouts
960 (how long to attempt transfer/delivery before the message expires
961 and causes a non-delivery report to be generated). The policy
962 specification can also explicitly define such information as
963 implementation and/or deployment specific. Note that a client
964 can override such default when it uses additional SMTP extensions
965 (such as the one mentioned in Section 5.2).
967 5. Maximum message size associated with each priority level. The
968 policy specification can also explicitly define such information
969 as implementation and/or deployment specific.
971 6. Any requirements/restrictions on the kind of SMTP client
972 authentication required in order for an SMTP server implementing
973 this policy to accept priority values specified by an SMTP
974 client. For example, this can limit which Simple Authentication
975 and Security Layer (SASL) [RFC4422] authentication mechanisms are
976 to be used, require TLS, etc.
978 7. Any other information that might affect processing of messages
979 with different priorities.
981 8. Note that the policy specification document is not allowed to
982 redefine the allowed range of priorities specified in Section 5
983 and other aspects of handling of different priorities, unless
984 explicitly specified by this document.
98610.2. Initial Priority Assignment Policy Registrations
988 IANA has registered the following initial values in the "SMTP
989 PRIORITY Extension Priority Assignment Policy" registry:
991 Initial Priority Assignment Policy Registrations
993 +-------------+------------------------+----------------+
994 | Policy Name | Reference | Comment |
995 +-------------+------------------------+----------------+
996 | MIXER | Appendix B of RFC 6710 | Default policy |
997 | STANAG4406 | Appendix A of RFC 6710 | |
998 | NSEP | Appendix C of RFC 6710 | |
999 +-------------+------------------------+----------------+
100111. Security Considerations
1003 Message Submission Agents ought to only accept message transfer
1004 priorities from users (or only certain groups of such users) who are
1005 authenticated and authorized in some way that's acceptable to the
1006 MSA. As part of this policy, they can also restrict maximum priority
1010Melnikov & Carlberg Standards Track [Page 18]
1012RFC 6710 Message Transfer Priority SMTP Extension August 2012
1015 values that different groups of users can request, and can override
1016 the priority values specified by MUAs.
1018 Similarly, MTAs ought to only accept message transfer priorities from
1019 senders (or only certain groups of such senders) who are
1020 authenticated and authorized in some way that's acceptable to the
1021 MTA. As part of this policy, they can also restrict maximum priority
1022 values that different groups of senders can request, and can override
1023 the priority values specified by them.
1025 In the absence of the policy enforcement mentioned above, an SMTP
1026 server (whether an MSA or an MTA) implementing this SMTP extension
1027 might be susceptible to a denial-of-service attack. For example,
1028 malicious clients (MUAs/MSAs/MTAs) can try to abuse this feature by
1029 always requesting priority 9.
103312.1. Normative References
1035 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
1038 [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
1039 Error Codes", RFC 2034, October 1996.
1041 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1042 Requirement Levels", BCP 14, RFC 2119, March 1997.
1044 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
1045 Extension for Delivery Status Notifications (DSNs)",
1046 RFC 3461, January 2003.
1048 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1049 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1052 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1053 Specifications: ABNF", STD 68, RFC 5234, January 2008.
1055 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
1056 Mail System Status Codes", BCP 138, RFC 5248, June 2008.
1058 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1066Melnikov & Carlberg Standards Track [Page 19]
1068RFC 6710 Message Transfer Priority SMTP Extension August 2012
1071 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1074 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
1075 STD 72, RFC 6409, November 2011.
107712.2. Informative References
1079 [ACP123] CCEB, "Common Messaging strategy and procedures", ACP 123,
1082 [PRIORITY-TUNNELING]
1083 Melnikov, A. and K. Carlberg, "Tunneling of SMTP Message
1084 Transfer Priorities", Work in Progress, July 2012.
1086 [RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service
1087 Extension for Checkpoint/Restart", RFC 1845,
1090 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
1091 Extension for Message Size Declaration", STD 10, RFC 1870,
1094 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
1095 Mapping between X.400 and RFC 822/MIME", RFC 2156,
1098 [RFC2205] Braden, B., Ed., Zhang, L., Berson, S., Herzog, S., and S.
1099 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
1100 Functional Specification", RFC 2205, September 1997.
1102 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
1103 "Definition of the Differentiated Services Field (DS
1104 Field) in the IPv4 and IPv6 Headers", RFC 2474,
1107 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
1110 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1111 Transport Layer Security", RFC 3207, February 2002.
1113 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
1114 Constraints Model for Diffserv-aware MPLS Traffic
1115 Engineering", RFC 4125, June 2005.
1122Melnikov & Carlberg Standards Track [Page 20]
1124RFC 6710 Message Transfer Priority SMTP Extension August 2012
1127 [RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints
1128 Model for Diffserv-aware MPLS Traffic Engineering",
1129 RFC 4127, June 2005.
1131 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
1132 Supporting Emergency Telecommunications Service (ETS) in
1133 IP Telephony", RFC 4190, November 2005.
1135 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
1136 Priority for the Session Initiation Protocol (SIP)",
1137 RFC 4412, February 2006.
1139 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
1140 Authentication and Security Layer (SASL)", RFC 4422,
1143 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
1144 Filtering Language", RFC 5228, January 2008.
1146 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1149 [RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, "RSVP
1150 Extensions for Admission Priority", RFC 6401,
1153 [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An
1154 Applicability Statement for SMTP", RFC 6647, June 2012.
1157 Schmeing, M., Brendecke, J., and K. Carlberg, "SMTP
1158 Service Extension for Priority Message Handling", Work
1159 in Progress, August 2006.
1162 NATO, "STANAG 4406 Edition 2: Military Message Handling
1163 System", STANAG 4406, March 2005.
1178Melnikov & Carlberg Standards Track [Page 21]
1180RFC 6710 Message Transfer Priority SMTP Extension August 2012
1183Appendix A. Priority Assignment Policy for Military Messaging
1185 Military Messaging as specified in ACP 123 [ACP123] (also specified
1186 in STANAG 4406 [STANAG-4406]) defines 6 priority ("precedence")
1187 values. While ACP 123/STANAG 4406 allow for 32 different priority
1188 levels (16 levels are reserved for NATO and an additional 16 are
1189 reserved for national use), only 6 are in use in practice. This
1190 section specifies the Priority Assignment Policy for Military
1191 Messaging and how the MT-PRIORITY parameter can be mapped when
1192 gatewaying between SMTP and ACP 123/STANAG 4406 environments.
1194 Where SMTP is used to support military messaging, the following
1195 mappings SHOULD be used.
1197 Recommended Mapping of MT-PRIORITY Values for MMHS
1199 +-------------------+----------------------+
1200 | MT-PRIORITY value | MMHS Precedence name |
1201 +-------------------+----------------------+
1208 +-------------------+----------------------+
1212 The Priority Assignment Policy registration for Military Messaging is
1215 1. The Priority Assignment Policy name is "STANAG4406".
1217 2. Number of distinct priority levels: 6, as specified in the table
1220 3. Default retry timeouts for each priority level are implementation
1221 and/or deployment specific.
1223 4. Default expiration timeouts for each priority level are
1224 implementation and/or deployment specific.
1226 5. Maximum message size associated with each priority level is
1227 implementation and/or deployment specific.
1229 6. No restrictions on what kind of SMTP client authentication is
1234Melnikov & Carlberg Standards Track [Page 22]
1236RFC 6710 Message Transfer Priority SMTP Extension August 2012
1239Appendix B. Priority Assignment Policy for MIXER
1241 MIXER [RFC2156] defines the Priority header field with 3 values.
1242 This section specifies the Priority Assignment Policy for MIXER and
1243 how the MT-PRIORITY parameter can be mapped when used with MIXER.
1245 Where SMTP is used to support MIXER messaging, the following mappings
1248 Recommended Mapping of MT-PRIORITY Values for MIXER
1250 +-------------------+----------------------+
1251 | MT-PRIORITY value | MIXER Priority value |
1252 +-------------------+----------------------+
1256 +-------------------+----------------------+
1260 The Priority Assignment Policy registration for MIXER is as follows:
1262 1. The Priority Assignment Policy name is "MIXER".
1264 2. Number of distinct priority levels: 3, as specified in the table
1267 3. Default retry timeouts for each priority level are implementation
1268 and/or deployment specific.
1270 4. Default expiration timeouts for each priority level are
1271 implementation and/or deployment specific.
1273 5. Maximum message size associated with each priority level is
1274 implementation and/or deployment specific.
1276 6. No restrictions on what kind of SMTP client authentication is
1279Appendix C. Priority Assignment Policy for National Security /
1280 Emergency Preparedness (NS/EP)
1282 There are several forms of communication systems used during an
1283 emergency or disaster. The most well known form involves the many-
1284 to-one model of the general public contacting a public safety access
1285 point via 911/999/112 calls through the public telephone network.
1290Melnikov & Carlberg Standards Track [Page 23]
1292RFC 6710 Message Transfer Priority SMTP Extension August 2012
1295 Typically, these calls do not require authorization, nor do they
1296 invoke any prioritization.
1298 Another form of emergency communications involves a set of authorized
1299 users or nodes that use prioritized services to help establish and
1300 continue communication given limited available resources. [RFC4190]
1301 includes descriptions of several systems that have been developed to
1302 support National Security / Emergency Preparedness (NS/EP). These
1303 deployed systems require a form of authentication and have focused on
1304 prioritization of telephony-based services. They have also been
1305 designed as a binary form (on/off) of signaled priority
1308 [RFC4412] includes examples of a more expansive view of NS/EP
1309 communications in which priority migrates from a single on/off bit
1310 value to one that comprises 5 priority values. This is shown in the
1311 cases of the Emergency Telecommunications Service (ETS) and Wireless
1312 Priority Service (WPS) Namespaces. Given a lack of pre-existing
1313 NS/EP values assigned for email, we follow the paradigm of the ETS
1314 and WPS Namespaces and recommend the 5 ascending values shown in the
1317 +-------------------+------------------+
1318 | MT-PRIORITY value | Relational Order |
1319 +-------------------+------------------+
1320 | -2 | Lowest Priority |
1324 | 6 | Highest Priority |
1325 +-------------------+------------------+
1327 The Priority Assignment Policy registration for NS/EP is as follows:
1329 1. The Priority Assignment Policy name is "NSEP".
1331 2. Number of distinct priority levels: 5, as specified in the table
1334 3. Default retry timeouts for each priority level are implementation
1335 and/or deployment specific.
1337 4. Default expiration timeouts for each priority level are
1338 implementation and/or deployment specific.
1340 5. Maximum message size associated with each priority level is
1341 implementation and/or deployment specific.
1346Melnikov & Carlberg Standards Track [Page 24]
1348RFC 6710 Message Transfer Priority SMTP Extension August 2012
1351 6. No restrictions on what kind of SMTP client authentication is
1354Appendix D. Possible Implementation Strategies
1356 This appendix suggests some strategies to implement the SMTP
1357 extension defined in this document. The list is not exhaustive.
1359 This appendix and its subsections are Informative.
1363 As the name suggests, probability involves increasing the chances of
1364 obtaining resources without adversely affecting previously
1365 established connections. One example would involve requesting
1366 resources set aside for specific priority levels. If these
1367 additional resources are exhausted, then the desired connection is
1368 denied. Queues, new timers, or combinations thereof can be used to
1369 facilitate the higher-priority requests, but the key is that
1370 mechanisms focus on increasing the probability of message transfer.
1372D.2. Preemption of Sessions or Transactions
1374 Preemption is a type of action that focuses only on a comparison of
1375 priorities to determine if previously established transactions need
1376 to be displaced in favor of higher-priority requests. If no
1377 additional connection is possible, the client aborts a running
1378 session for emails with lower priority no later than directly after
1379 the current transaction. The client can even interrupt an active
1380 transaction, and ought to do so if other constraints, such as
1381 delivery time (as specified in the DELIVERBY SMTP extension
1382 [RFC2852]), would be violated for the email with higher priority.
1384 When interrupting an active transaction, the client ought to take the
1385 total message size and the size of the transferred portion of the
1386 message being interrupted into consideration. This preliminary
1387 termination of sessions or transactions is called preemption.
1389 If preemption of running transactions occurs, the client needs to
1390 choose a transaction with the lowest priority currently processed.
1392 If the client has an option (i.e., it is supported by the next-hop
1393 MTA) to interrupt transactions in a way that allows them to be
1394 restarted at the interruption point later, it ought to deploy it. An
1395 example for a mechanism providing such a service is the "SMTP Service
1396 Extension for Checkpoint/Restart" defined in [RFC1845].
1402Melnikov & Carlberg Standards Track [Page 25]
1404RFC 6710 Message Transfer Priority SMTP Extension August 2012
1407 If a client opts for the preemption of sessions instead of
1408 transactions, it needs to preempt the next session that reaches the
1409 end of a transaction.
1411D.3. Resource Allocation Models
1413 Adding prioritization to a design moves the subject away from a
1414 strictly best effort (and a first-come-first-served) model to one
1415 that includes admission control and resource allocation models. Over
1416 the years, a variety of work has been done within the IETF to specify
1417 resource allocations models. Examples include the Maximum Allocation
1418 Model [RFC4125], the Russian Dolls Model [RFC4127], and the Priority
1419 Bypass Model (Appendix A.3 of [RFC6401]).
1421 While we recognize that these various models have been designed for
1422 other protocols (i.e., MPLS and RSVP), an understanding of their
1423 design characteristics may be beneficial in considering future
1424 implementations of a priority SMTP service.
1426 In cases where the processing of high-priority messages by an MTA is
1427 not considered negligible and exceeds engineered expectations, then
1428 operators managing that MTA may be notified in some form (e.g.,
1429 pushed alarm, polled status).
1431Appendix E. Background on Design Choices
1433 This section provides some background on design choices made during
1434 development of the MT-PRIORITY SMTP extension.
1436 The priority applies per message, rather than per recipient, in order
1437 to keep the protocol simpler and because of the expectation that it
1438 will be uncommon to need different priorities for different
1439 recipients on the same message. In cases where that is necessary, it
1440 can always be achieved by sending separate messages with the same
1441 content, segregating the recipients by desired message priority.
1443 The choice of the priority range -9 to 9 (as opposed to, say, 1 to 6,
1444 or 0 to 9) was made after taking the following into consideration:
1446 1. Clearly, having multiple priority levels is the whole point of
1447 this extension. Existing implementations of similar
1448 functionality in MTAs are already using 3 levels. One of the use
1449 cases motivating this extension requires 6 levels, so at least 6
1450 different values are required.
1458Melnikov & Carlberg Standards Track [Page 26]
1460RFC 6710 Message Transfer Priority SMTP Extension August 2012
1463 2. During discussions of this extension, several different use cases
1464 were suggested that required differing numbers of priority
1465 levels. Defining just the 6 priority levels needed in item 1,
1466 above, would limit the extensibility for possible future use
1467 cases. Therefore, this document is defining a wider range, which
1468 allows implementations and deployments to add higher or lower
1469 priority levels and to insert additional priority levels between
1470 the recommended set of 6. This avoids the need to further extend
1471 this extension just to have a few more priority levels.
1473 3. It seems natural to use zero for the "normal" or default
1474 priority, rather than picking some non-zero number and having the
1475 priorities go up or down from there. This way, negative numbers
1476 always represent priorities that are lower than normal, with
1477 positive numbers as higher priorities.
1479Appendix F. Acknowledgements
1481 This document copies lots of text from "SMTP Service Extension for
1482 Priority Message Handling" [SMTP-PRI-OLD]. Therefore, the authors of
1483 this document would like to acknowledge contributions made by the
1484 authors of that document: Michael Schmeing and Jan-Wilhelm Brendecke.
1486 Many thanks for input provided by Steve Kille, David Wilson, John
1487 Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba,
1488 Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick,
1489 Chris Newman, Ned Freed, and Claudio Allocchio.
1491 Special thanks to Barry Leiba for agreeing to shepherd this document.
1514Melnikov & Carlberg Standards Track [Page 27]
1516RFC 6710 Message Transfer Priority SMTP Extension August 2012
1523 5 Castle Business Village
1525 Hampton, Middlesex TW12 2BX
1528 EMail: Alexey.Melnikov@isode.com
1533 1601 Clarendon Blvd, #203
1537 EMail: carlberg@g11.org.uk
1570Melnikov & Carlberg Standards Track [Page 28]