idnits 2.17.1 draft-melnikov-smtp-priority-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2033 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-04) exists of draft-melnikov-smtp-priority-tunneling-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track K. Carlberg 5 Expires: January 10, 2013 G11 6 July 9, 2012 8 Simple Mail Transfer Protocol extension for Message Transfer Priorities 9 draft-melnikov-smtp-priority-21 11 Abstract 13 This memo defines an extension to the SMTP (Simple Mail Transfer 14 Protocol) service whereby messages are given a label to indicate 15 preferential handling, to enable mail handling nodes to take this 16 into account for onward processing. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 10, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 54 3. Definition of the Priority SMTP Extension . . . . . . . . . . 4 55 4. Handling of messages received via SMTP . . . . . . . . . . . . 5 56 4.1. Handling of the MT-PRIORITY parameter by the receiving 57 SMTP server . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Relay of messages to other conforming SMTP servers . . . . 6 59 4.3. Relay of messages to non-conforming SMTP servers . . . . . 7 60 4.4. Mailing lists and Aliases . . . . . . . . . . . . . . . . 7 61 4.5. Gatewaying a message into a foreign environment . . . . . 7 62 4.6. Interaction with DSN SMTP Extension . . . . . . . . . . . 7 63 5. The Priority Service Extension . . . . . . . . . . . . . . . . 8 64 5.1. Expedited Transfer . . . . . . . . . . . . . . . . . . . . 9 65 5.2. Timely Delivery . . . . . . . . . . . . . . . . . . . . . 10 66 6. Use of MT-PRIORITY with LMTP . . . . . . . . . . . . . . . . . 10 67 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 14 70 9.1. Multiple MX records . . . . . . . . . . . . . . . . . . . 14 71 9.2. Priority Assignment Policies . . . . . . . . . . . . . . . 14 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 10.1. Requirements on Priority Assignment Policy 74 registrations . . . . . . . . . . . . . . . . . . . . . . 17 75 10.2. Initial Priority Assignment Policy registrations . . . . . 18 76 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 80 Appendix A. Priority Assignment Policy for Military Messaging . . 21 81 Appendix B. Priority Assignment Policy for MIXER . . . . . . . . 22 82 Appendix C. Priority Assignment Policy for National Security 83 / Emergency Preparedness (NS/EP) . . . . . . . . . . 23 84 Appendix D. Possible implementation strategies . . . . . . . . . 24 85 D.1. Probability . . . . . . . . . . . . . . . . . . . . . . . 25 86 D.2. Preemption of sessions or transactions . . . . . . . . . . 25 87 D.3. Resource Allocation Models . . . . . . . . . . . . . . . . 25 88 Appendix E. Background on Design Choices . . . . . . . . . . . . 26 89 Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 27 91 1. Introduction 93 Where resources for switching or transfer of messages are constrained 94 (e.g., bandwidth, round trip time, transition storage or processing 95 capability) it is desirable to give preferential handling to some 96 messages over others, according to their labeled priority. This is 97 particularly important during emergencies for first responders 98 (Appendix C) and for environments such as military (Appendix A) and 99 aviation (Appendix B) messaging, where messages have high operational 100 significance, and the consequences of extraneous delay can be 101 significant. 103 In order for an SMTP receiver to be able to relay higher priority 104 messages first, there needs to be a mechanism to communicate (during 105 both Message Submission [RFC6409] and Message Transfer [RFC5321]) the 106 priority of each message. This specification defines this mechanism 107 by specification of an SMTP [RFC5321] extension. 109 In order to permit end-to-end use of this extension across email 110 infrastructure that does not support it, a companion tunneling 111 mechanism is defined in [PRIORITY-TUNNELING] through use of a new 112 message header field [RFC5322]. 114 This extension provides services to some classes of users in networks 115 with limited available bandwidth or long round trip times, when the 116 actual message transfer over the network can create a significant 117 portion of the overall message delivery time from a sender to a 118 recipient, for example over a satellite or high frequency radio link. 119 It is also useful in case of a Mail Transfer Agent (MTA) queue 120 build-up due to the rate of incoming messages being higher than the 121 rate of outgoing messages. When neither of the two conditions 122 mentioned above is true, the use of the MT-PRIORITY SMTP extension 123 will not result in a better SMTP service to any user. Also note that 124 while this SMTP extension can help in improving delivery speed for 125 higher priority messages, it does not provide any sort of guarantees 126 that for two given messages with priorities M and N (M > N) submitted 127 simultaneously the message with priority M will arrive earlier than 128 the message with priority N. I.e. this extension calls for best 129 effort to provide preferential processing. 131 Besides the actions taken at the application level it can thus be 132 important to deploy priority or precedence mechanisms offered by the 133 network itself to ensure timely delivery of the emails. Examples 134 would be the use of DiffServ [RFC2474], RSVP [RFC2205] and the work- 135 in-progress effort extension to RSVP that prioritizes reservations. 137 2. Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] when they 142 appear in ALL CAPS. These words also appear in this document in 143 lower case as plain English words, absent their normative meanings. 145 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 146 notation including the core rules defined in Appendix B of RFC 5234 147 [RFC5234]. 149 In examples, "C:" and "S:" indicate lines sent by the client and 150 server respectively. Line breaks that do not start with a new "C:" 151 or "S:" exist for editorial reasons and are not a part of the 152 protocol. 154 This document uses the term "priority" specifically in relation to 155 the internal treatment of a message by the server: Messages with 156 higher priorities may be given expedited handling, and those with 157 lower priorities may be handled only as resources become available. 159 3. Definition of the Priority SMTP Extension 161 The Priority SMTP service extension is defined as follows: 163 1. The textual name of this extension is "Priority Message 164 Handling". 166 2. The EHLO keyword value associated with this extension is "MT- 167 PRIORITY". 169 3. The EHLO keyword has an OPTIONAL parameter which conveys the name 170 of the Priority Assignment Policy (see Section 9.2) used by the 171 server. (See the ABNF non terminal in 172 Section 7 for details of its syntax.) Absence of the parameter 173 means that the server is unwilling to disclose its Priority 174 Assignment Policy. Clients can choose to use the MT-PRIORITY 175 SMTP extension even if they don't recognize a partilar Priority 176 Assignment Policy name advertised by a server. 178 4. No additional SMTP verbs are defined by this extension. 180 5. One optional parameter ("MT-PRIORITY") is added to the MAIL FROM 181 command. The value associated with this parameter is a decimal 182 integer number from -9 to 9 (inclusive) indicating the priority 183 of the email message (See Appendix E for more details on why this 184 range was selected.) The syntax of the MT-PRIORITY parameter is 185 described by the ABNF non-terminal defined in 186 Section 7. Higher numbers mean higher priority. 188 6. The maximum length of a MAIL FROM command line is increased by 15 189 octets by the possible addition of a space, the MT-PRIORITY 190 keyword and a priority value. 192 7. The MT-PRIORITY extension is valid for the submission service 193 [RFC6409] and LMTP [RFC2033]. 195 4. Handling of messages received via SMTP 197 This section describes how a conforming SMTP server should handle any 198 messages received via SMTP. 200 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server 202 The following rules apply to SMTP transactions in a server that 203 supports the MT-PRIORITY parameter: 205 1. If any of the associated s (as defined in Section 206 4.1.2 of [RFC5321]) are not syntactically valid, or if there is 207 more than one MT-PRIORITY parameter in a particular MAIL FROM 208 command, the server MUST return an error, for example "501 syntax 209 error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034] 210 [RFC5248]). 212 2. When inserting a Received header field as specified in Section 213 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the 214 "PRIORITY" clause whose syntax is specified in Section 7. 216 3. The received MT-PRIORITY parameter value SHOULD be logged as part 217 of any logging of message transactions. 219 4. If the sending SMTP client specified the MT-PRIORITY parameter to 220 the MAIL FROM command, then the value of this parameter is the 221 message priority. 223 5. If no priority has been determined by the above, the server may 224 use its normal policies to set the message's priority. By 225 default, each message has priority 0. 227 The SMTP server MUST NOT allow "upgraded" (positive) priorities from 228 untrusted (e.g. unauthenticated) or unauthorized sources. (One 229 example of an "unauthorized source" might be an SMTP sender which 230 successfully authenticated using SMTP AUTH, but which is not 231 explicitly authorized to use the SMTP MT-PRIORITY service. In case 232 of MTA-to-MTA transfer such authorization will usually be done as a 233 bilateral agreement between two domains to honour priorities from 234 each other.) The server MAY, however, allow an untrusted source to 235 lower its own message's priorities -- consider, for example, an email 236 marketer that voluntarily sends its marketing messages at a negative 237 priority. 239 The SMTP server MAY also alter the message priority (to lower or to 240 raise it) in order to enforce some other site policy. (Note that 241 this also includes the case when the priority is not explicitly 242 specified.) For example, an MSA might have a mapping table that 243 assigns priorities to messages based on authentication credentials. 245 If the SMTP server changes (lowers or raises) the priority of a 246 message, it SHOULD use the X.7.TBD3 Enhanced Status Code [RFC2034] in 247 its response to the MAIL FROM or in the final response to the DATA 248 (or similar) command. The human readable text part after the status 249 code contains the new priority, followed by SP (ASCII space) and 250 explanatory human readable text. 252 Alternatively an SMTP server, which is an MSA, MAY reject a message 253 based on the determined priority. In such cases, the MSA SHOULD use 254 450 or 550 reply code. The corresponding Enhanced Status Code MUST 255 be X.7.TBD1 [RFC2034] if the determined priority level is below the 256 lowest priority currently acceptable for the receiving SMTP server. 257 Note that this condition might be temporary. In some environments, 258 operational policies might permit periods of operation that relay 259 only higher priority messages and reject lower priority ones. Such 260 handling choices need to be specified for that operational 261 environment. 263 4.2. Relay of messages to other conforming SMTP servers 265 The following rules govern the behavior of a conforming MTA (in the 266 role of an SMTP/LMTP client), when relaying a message which was 267 received via the SMTP protocol, to an SMTP/LMTP server that supports 268 the MT-PRIORITY extension: 270 1. A MT-PRIORITY parameter with the value determined by the 271 procedure from Section 4.1 MUST appear in the MAIL FROM command 272 issued when the message is relayed to an MTA/MDA which also 273 supports the MT-PRIORITY extension. (Note that due to site 274 policy this value might be different from the value received from 275 the SMTP client. See Section 4.1 for details. Also note that 276 this value might be different than the priority level at which 277 the MTA actually handles the request, due to the rounding 278 described in Section 5.) 280 2. Further processing of the MT-PRIORITY parameter is described in 281 Section 5. 283 4.3. Relay of messages to non-conforming SMTP servers 285 The following rules govern the behavior of a conforming MTA (in the 286 role of an SMTP/LMTP client), when relaying a message which was 287 received via the SMTP protocol, to an SMTP/LMTP server that does not 288 support the MT-PRIORITY extension: 290 1. The MTA relays the message without including the MT-PRIORITY 291 parameter in the MAIL FROM command. 293 [[RFC Editor note: The lonely list item above is numbered for 294 reference from another document, and should be left as a numbered 295 item.]] 297 4.4. Mailing lists and Aliases 299 Several types of mechanisms exist to redirect or forward messages to 300 alternative or multiple addresses [RFC5598]. Examples for this are 301 aliases and mailing lists [RFC5321]. 303 If a message is subject to such processing, the Mediator node 304 (Section 2.1 of [RFC5598]), SHOULD retain the MT-PRIORITY parameter 305 value for all expanded and/or translated addresses. 307 4.5. Gatewaying a message into a foreign environment 309 The following rules govern the behavior of a conforming MTA, when 310 gatewaying a message that was received via the SMTP protocol, into a 311 foreign (non-SMTP) environment: 313 1. If the destination environment is unable to provide an equivalent 314 of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as 315 if it is relaying to a non-conformant SMTP server (Section 4.3). 317 2. If the destination environment is capable of providing an 318 equivalent of the MT-PRIORITY parameter, the conforming MTA 319 SHOULD behave as if it is relaying to a conformant SMTP server 320 (Section 4.2), converting the MT-PRIORITY value to the equivalent 321 in the destination environment. 323 4.6. Interaction with DSN SMTP Extension 325 An MTA which needs to generate a delivery report (whether for 326 successful delivery or delayed/failed delivery) for a message it is 327 processing SHOULD use the priority value of the message as the 328 priority of the generated delivery report. In particular this 329 requirement applies to MTAs that also implements [RFC3461]. 331 For delivery reports (DSNs) received by an MTA for relay, processing 332 rules specified in Section 4.1 apply -- there is no special 333 processing for relayed DSNs. It might seem tempting to try to detect 334 DSNs and process them at elevated priority under the assumption that 335 failure notices need to get through quickly, even or perhaps 336 especially if the DSN came from an untrusted source. But such a 337 policy can create an exposure to fake-DSN attacks by giving untrusted 338 systems a way to inject high-priority messages. Implementation of 339 such a policy also assumes that DSNs can be detected reliability, 340 which may not be the case since some systems use nonstandard DSN 341 formats. 343 5. The Priority Service Extension 345 The priorities of messages affect the order the messages are 346 transferred from the client to the server. This is largely 347 independent from the order in which they were originally received by 348 the server. 350 A message priority is a decimal integer in the range from -9 to 9 351 (inclusive). SMTP servers compliant with this specification are not 352 required to support all 19 distinct priority levels (i.e. to treat 353 each priority value as a separate priority), but they MUST implement 354 all distinct priority levels specified in the Priority Assignment 355 Policy (see Section 9.2) implemented by the server, i.e. an 356 implementation that only supports N priority levels (where N < 19) 357 will internally round up a syntactically valid priority value that 358 isn't supported to the next higher supported number (or to the 359 highest supported priority, if the value is higher than any supported 360 priority). For example, an implementation can treat priority values 361 below and including -4 as priority -4, priority -3 as priority -2, 362 and all priorities starting from 5 can be treated as priority 6. 363 (See Section 9.2 for implementation/deployment considerations related 364 to Priority Assignment Policy.) 366 Irrespective of the number of distinct priority levels supported by 367 the SMTP server, when relaying the message to the next hop or 368 delivering it over LMTP, the SMTP server MUST communicate the 369 priority value as determined in Section 4.1. 371 Note: 19 possible priority levels are defined by this specification 372 for extensibility. For example, a particular implementation or 373 deployment environment might need to provide finer-grained control 374 over message transfer priorities. See Appendix E for more details on 375 why the range from -9 to 9 was selected. 377 As per the Priority Assignment Policy, some SMTP servers MAY impose 378 additional maximum message size constraints for different message 379 transfer priorities, for example messages with priority 6 might not 380 be larger than 4 Kb. If an SMTP server chooses to reject a message 381 because it is too big for the determined priority, it SHOULD use 552 382 reply codes, together with the X.3.TBD2 Enhanced Status Code 383 [RFC2034]. 385 Implementation Note: If the SMTP server also supports the SMTP SIZE 386 extension [RFC1870] then an SMTP client can use both SIZE= and MT- 387 PRIORITY= parameters on the MAIL FROM command. This allows the 388 server to perform early rejection of a message in case the message 389 size is too big for the specified priority, thus avoiding wasting 390 bandwidth by transferring the message first and then rejecting it due 391 to its size. 393 The Priority Service Extension can be combined with DELIVERBY 394 [RFC2852] SMTP service extension, however there is no requirement 395 that both extensions are always implemented together. 397 5.1. Expedited Transfer 399 The main service provided by the Priority Message Handling SMTP 400 Service Extension is expedited transfer of emails with a higher 401 priority. Therefore an SMTP client that has more than one email to 402 send at a given time sends those with a higher priority before those 403 with a lower one. Additionally, the retry interval and/or default 404 timeout before non-delivery report is generated MAY be lower (more 405 aggressive) for messages of higher priority. Lower retry intervals/ 406 default timeouts are controlled by the local MTA policy. 408 Note that as this SMTP extension requires some sort of trust 409 relationship between a sender and a receiver and thus some form of 410 authentication (whether using SMTP AUTH, TLS, IP address whitelist, 411 etc.), so senders using this SMTP extension will not be subject to 412 greylisting [GREYLISTING], unless they are unauthorized to use this 413 SMTP extension, due to an explicit policy decision or a 414 misconfiguration error. But note that in case of connection-level or 415 SMTP HELO/HELO greylisting SMTP AUTH or TLS authentication options 416 are not available to server. 418 In order to make implementations of this extension easier, this SMTP 419 extension only allows a single priority for all recipients of the 420 same message. 422 Within a priority level, the MTA uses its normal algorithm (the 423 algorithm used in absence of this SMTP extension) for determining 424 message processing order. 426 Several possible ways of implementing expedited transfer are 427 described in more details in Appendix D. Note that these sections 428 don't describe all details and pitfalls for each implementation 429 strategy. 431 5.2. Timely Delivery 433 An important constraint (usually associated with higher priority 434 levels) in some environments is that messages with high priority 435 values have some delivery time constraints. In some cases, higher 436 priorities mean a shorter maximum time allowed for delivery. 438 Unextended SMTP does not offer a service for timely delivery, i.e. 439 "deliver this message within X seconds from submission" service. The 440 "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in 441 [RFC2852] is an example of an SMTP extension providing a service that 442 can be used to implement timely delivery. Note that SMTP DELIVERBY 443 and SMTP MT-PRIORITY extensions are complimentary and can be used 444 together (assuming the SMTP server they are talking to advertises 445 support for both). However note that use of the DELIVERBY extension 446 alone does not guarantee any priority processing. If the client is 447 using both SMTP DELIVERBY and SMTP MT-PRIORITY at the same time, 448 client can consider using smaller DELIVERBY timeouts for higher 449 priority messages. 451 6. Use of MT-PRIORITY with LMTP 453 An LMTP server can advertise support for the MT-PRIORITY extension if 454 it supports any combination of the following features: 456 1. The LMTP server is architected in such a way that it can deliver 457 higher priority messages quicker than lower priority messages. 459 2. The LMTP server logs that MT-PRIORITY extension was used by the 460 previous SMTP hop. 462 3. The LMTP server is exposing information about MT-PRIORITY 463 extension to a delivery time filtering engine such as Sieve 464 [RFC5228]. 466 7. Syntax 468 priority-value = (["-"] NZDIGIT) / "0" 469 ; Allowed values are from -9 to 9 inclusive 471 NZDIGIT = %x31-39 472 ; "1"-"9" 474 CFWS = 476 ; New "clause" that can be used in the Received header field 477 Pri = CFWS "PRIORITY" FWS priority-value 478 ; Complies with the 479 ; non-terminal syntax from RFC 5321. 481 mt-priority-ehlo = "MT-PRIORITY" [SP priority-profile] 482 ; Complies with the ABNF production from RFC 5321. 484 priority-profile = 1*20 (ALPHA / DIGIT / "-" / "_" / ".") 485 ; name of the Priority Assignment Profile advertized in 486 ; the MT-PRIORITY EHLO response. 488 ALPHA = 490 DIGIT = 492 8. Example 494 The original submission (from MUA to MSA) might look like shown 495 below. Note that the example is also making use of the DELIVERBY 496 [RFC2852] and DSN [RFC3461] SMTP extensions, even though there is no 497 requirement that these other extensions are to be supported when the 498 MT-PRIORITY SMTP extension is implemented. 500 S: 220 example.com SMTP server here 501 C: EHLO mua.example.com 502 S: 250-example.com 503 S: 250-AUTH STARTTLS 504 S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5 505 S: 250-DSN 506 S: 250-DELIVERBY 507 S: 250-ENHANCEDSTATUSCODES 508 S: 250 MT-PRIORITY MIXER 509 C: AUTH SCRAM-SHA-1 510 [...authentication exchange...] 511 S: 235 2.7.0 Authentication successful 512 C: MAIL FROM: BY=125;R ENVID=QQ314159 513 MT-PRIORITY=3 514 S: 250 2.1.0 sender ok 515 C: RCPT TO: 516 S: 250 2.1.5 recipient ok 517 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 518 ORCPT=rfc822;Dana@Ivory.example.net 519 S: 250 2.1.5 recipient ok 520 C: DATA 521 S: 354 okay, send message 522 C: (message goes here) 523 C: . 524 S: 250 2.1.0 message accepted 525 C: QUIT 526 S: 221 2.0.0 goodbye 528 In the above example the MUA has specified the priority 3 and the 529 server has accepted it. The server is advertising the MIXER Priority 530 Assignment Policy (the default). Another variant of the initial 531 submission might look like: 533 S: 220 example.com SMTP server here 534 C: EHLO mua.example.com 535 S: 250-example.com 536 S: 250-AUTH STARTTLS 537 S: 250-AUTH SCRAM-SHA-1 DIGEST-MD5 538 S: 250-DSN 539 S: 250-DELIVERBY 540 S: 250-ENHANCEDSTATUSCODES 541 S: 250 MT-PRIORITY 542 C: AUTH SCRAM-SHA-1 543 [...authentication exchange...] 544 S: 235 2.7.0 Authentication successful 545 C: MAIL FROM: BY=125;R ENVID=QQ314159 546 S: 250 2.1.0 sender ok 547 C: RCPT TO: 548 S: 250 2.1.5 recipient ok 549 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 550 ORCPT=rfc822;Dana@Ivory.example.net 551 S: 250 2.1.5 recipient ok 552 C: DATA 553 S: 354 okay, send message 554 C: (message goes here) 555 C: . 556 S: 250 2.7.TBD3 3 is the new priority assigned to the message 557 C: QUIT 558 S: 221 2.0.0 goodbye 560 [[RFC Editor, please fix TBD3 in the example above.]] In the above 561 example the MUA has not specified any priority, but the MSA has 562 assigned priority 3 to the message. Also note that the server is 563 unwilling to adverte the Priority Assignment Policy it supports in 564 the EHLO response. 566 The MSA relays the message to the next MTA. 568 S: 220 example.net SMTP server here 569 C: EHLO example.com 570 S: 250-example.net 571 S: 250-DSN 572 S: 250-DELIVERBY 573 S: 250 MT-PRIORITY STANAG4406 574 C: MAIL FROM: BY=120;R ENVID=QQ314159 575 MT-PRIORITY=3 576 S: 250 sender ok 577 C: RCPT TO: 578 S: 250 recipient ok 579 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 580 ORCPT=rfc822;Dana@Ivory.example.net 581 S: 250 recipient ok 582 C: DATA 583 S: 354 okay, send message 584 C: (message goes here) 585 C: . 586 S: 250 message accepted 587 C: QUIT 588 S: 221 goodbye 590 The receiving SMTP server advertises support for the "STANAG4406" 591 Priority Assignment Policy which supports 6 priority levels as 592 described in Appendix A. This means that the server will use the 593 priority value 4 internally (the next supported priority higher or 594 equal to 3) and will communicate the priority value 3 when relaying 595 it to the next hop (if necessary). 597 9. Deployment Considerations 599 9.1. Multiple MX records 601 If multiple DNS MX records are used to specify multiple servers for a 602 domain in section 5 of [RFC5321], it is strongly advised that all of 603 them support the MT-PRIORITY extension and handles priorities in 604 exactly the same way. If one or more servers behave differently in 605 this respect, then it is strongly suggested that none of the servers 606 support the MT-PRIORITY extension. Otherwise, unexpected differences 607 in message delivery speed or even rejections can happen during 608 temporary or permanent failures, which users might perceive as 609 serious reliability issues. 611 9.2. Priority Assignment Policies 613 This document allows up to 19 distinct priority values. In a 614 particular operating environment independent originators need to 615 assign priority values according to roughly the same criteria, so 616 that the same "high priority message" doesn't get associated with the 617 value 3 for one sender and with the value 5 for another, as such 618 messages might end up getting different preferential treatment when 619 it was not the intent. 621 In order to achieve consistent behaviour in an operating environment, 622 the Priority Assignment Policy (together with possible associated 623 restrictions on maximum message sizes for each priority (if any), 624 default timeouts, etc.) should be documented for the environment. 625 Each SMTP/LMTP server supports a Priority Assignment Policy, whether 626 explicit (advertised in the MT-PRIORITY EHLO response) or implict 627 (not advertised). The default Priority Assignment Policy (assumed by 628 the client when no Priority Assignment Policy name is advertised in 629 the MT-PRIORITY EHLO response) is specified in Appendix B. Two other 630 policies are specified in Appendix A and Appendix C. Additional 631 policies SHOULD be registered with IANA as specified in Section 10.1. 633 Moreover, all MSAs/MTAs/MDAs within any given Administrative 634 Management Domain has to be configured to use the same Priority 635 Assignement Policy. Otherwise a differently configured MSA/MTA/MDA 636 can expose the whole domain to possible attacks, like injection of 637 hight priority fake-DSN. 639 When this SMTP extension is deployed across multiple cooperating 640 Administrative Domains, such Administrative Domains need to use the 641 same or at least compatible policies. Again, differences in policies 642 (for example differences in how users are authenticated or 643 differences in how priorities are handled) can expose an 644 Administrative Domain to weaknesses in a partner domain. 646 10. IANA Considerations 648 This specification requests IANA to add the MT-PRIORITY SMTP 649 extension to the "SMTP Service Extensions" registry (in 650 http://www.iana.org/assignments/mail-parameters). This extension is 651 suitable for the Submit port. 653 This specification requests IANA to add the following new Received 654 header field clause to the "Additional-registered-clauses" sub- 655 registry (in http://www.iana.org/assignments/mail-parameters) to help 656 with tracing email messages delivered using the MT-PRIORITY SMTP 657 extension: 659 Clause name: PRIORITY 660 Description: Records the value of the MT-PRIORITY parameter specified 661 in the MAIL FROM command 662 Syntax of the value: See Section 7 of RFCXXXX 663 Reference: [[anchor12: RFCXXXX]] 664 This specification requests IANA to add the following Enumerated 665 Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced 666 Status Codes" registry established by [RFC5248] (in http:// 667 www.iana.org/assignments/smtp-enhanced-status-codes/ 668 smtp-enhanced-status-codes.xml): 670 1. 672 Code: X.7.TBD1 674 Sample Text: Priority Level is too low 676 Associated basic status code: 450, 550 (other 4XX or 5XX codes 677 are allowed) 679 Description: The specified priority level is below the lowest 680 priority acceptable for the receiving SMTP server. This 681 condition might be temporary, for example the server is 682 operating in a mode where only higher priority messages are 683 accepted for transfer and delivery, while lower priority 684 messages are rejected. 686 Reference: RFC XXXX 688 Submitter: A. Melnikov 690 Change controller: IESG 692 2. 694 Code: X.3.TBD2 696 Sample Text: Message is too big for the specified priority 698 Associated basic status code: 552 (other 4XX or 5XX codes are 699 allowed) 701 Description: The message is too big for the specified priority. 702 This condition might be temporary, for example the server is 703 operating in a mode where only higher priority messages below 704 certain size are accepted for transfer and delivery. 706 Reference: RFC XXXX 708 Submitter: A. Melnikov 709 Change controller: IESG 711 3. 713 Code: X.3.TBD3 715 Sample Text: Requested priority was changed 717 Associated basic status code: 250 or 251 719 Description: The message was accepted for relay/delivery, but 720 the requested priority (possibly the implied default) was not 721 honoured. The human readable text after the status code 722 contains the new priority, followed by SP (space) and 723 explanatory human readable text. 725 Reference: RFC XXXX 727 Submitter: A. Melnikov 729 Change controller: IESG 731 IANA is also requested to create a new IANA registry called "SMTP 732 PRIORITY extension Priority Assignment Policy". Future registrations 733 in this registry are governed by the "Specification Required" 734 [RFC5226] IANA registration policy. Requirements on registrations 735 (to be verified by the Designated Expert) are specified in 736 Section 10.1. Changes to registrations undergo the same process as 737 initial registrations. In cases of significant changes to 738 registrations (other than editorial clarifications) the Designated 739 Expert MAY require registration of a Priority Assignment Policy with 740 a new name instead of updating the existing one. 742 10.1. Requirements on Priority Assignment Policy registrations 744 Priority Assignment Policy registrations with IANA are accompanied by 745 a policy specification document, that MUST specify the following 746 information: 748 1. The Priority Assignment Policy name, which is a case-insensitive 749 string of 1 to 20 US-ASCII characters to be advertised as the MT- 750 PRIORITY EHLO parameter. Allowed characters are: ALPHA, DIGIT, 751 "-", "_" and "." 753 2. Number of distinct priority levels supported by all servers 754 implementing the policy and their respective values. 756 3. For each supported priority level: default retry timeouts (how 757 often to retry sending a message if there is a temporary error to 758 transfer/deliver it). The policy specification can also 759 explicitly define such information as implementation and/or 760 deployment specific. 762 4. For each supported priority level: default expiration timeouts 763 (how long to attempt transfer/delivery before the message expires 764 and causes a non delivery report to be generated). The policy 765 specification can also explicitly define such information as 766 implementation and/or deployment specific. Note that a client 767 can override such default when it uses additional SMTP extensions 768 (such as the one mentioned in Section 5.2). 770 5. Maximum message size associated with each priority level. The 771 policy specification can also explicitly define such information 772 as implementation and/or deployment specific. 774 6. Any requirements/restrictions on what kind of SMTP client 775 authentication is required in order for a SMTP server 776 implementing this policy to accept priority values specified by a 777 SMTP client. For example this can limit which SASL [RFC4422] 778 authentication mechanisms are to be used, require TLS, etc. 780 7. Any other information that might affect processing of messages 781 with different priorities. 783 8. Note that the policy specification document is not allowed to 784 redefine the allowed range of priorities specified in Section 5 785 and other aspects of handling of different priorities, unless 786 explicitly specified by this document. 788 10.2. Initial Priority Assignment Policy registrations 790 IANA is requested to register the following initial values in the 791 "SMTP PRIORITY extension Priority Assignment Policy" registry: 793 Initial Priority Assignment Policy registrations 795 +-------------+-----------------------+----------------+ 796 | Policy Name | Reference | Comment | 797 +-------------+-----------------------+----------------+ 798 | MIXER | Appendix B of RFCXXXX | Default policy | 799 | STANAG4406 | Appendix A of RFCXXXX | | 800 | NSEP | Appendix C of RFCXXXX | | 801 +-------------+-----------------------+----------------+ 803 11. Security Considerations 805 Message Submission Agents ought to only accept message transfer 806 priorities from users (or only certain groups of such users) who are 807 authenticated and authorized in some way that's acceptable to the 808 MSA. As part of this policy, they can also restrict maximum priority 809 values that different groups of users can request, and can override 810 the priority values specified by MUAs. 812 Similarly, MTAs ought to only accept message transfer priorities from 813 senders (or only certain groups of such senders) who are 814 authenticated and authorized in some way that's acceptable to the 815 MTA. As part of this policy, they can also restrict maximum priority 816 values that different groups of senders can request, and can override 817 the priority values specified by them. 819 In the absence of the policy enforcement mentioned above an SMTP 820 server (whether an MSA or an MTA) implementing this SMTP extension 821 might be susceptible to a Denial of Service attack. For example, 822 malicious clients (MUAs/MSAs/MTAs) can try to abuse this feature by 823 always requesting Priority 9. 825 12. References 827 12.1. Normative References 829 [RFC2033] Myers, J., "Local Mail Transfer Protocol", 830 RFC 2033, October 1996. 832 [RFC2034] Freed, N., "SMTP Service Extension for 833 Returning Enhanced Error Codes", RFC 2034, 834 October 1996. 836 [RFC2119] Bradner, S., "Key words for use in RFCs to 837 Indicate Requirement Levels", BCP 14, RFC 2119, 838 March 1997. 840 [RFC3461] Moore, K., "Simple Mail Transfer Protocol 841 (SMTP) Service Extension for Delivery Status 842 Notifications (DSNs)", RFC 3461, January 2003. 844 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", 845 RFC 5321, October 2008. 847 [RFC5322] Resnick, P., Ed., "Internet Message Format", 848 RFC 5322, October 2008. 850 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 851 Writing an IANA Considerations Section in 852 RFCs", BCP 26, RFC 5226, May 2008. 854 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for 855 Syntax Specifications: ABNF", STD 68, RFC 5234, 856 January 2008. 858 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP 859 Enhanced Mail System Status Codes", BCP 138, 860 RFC 5248, June 2008. 862 [RFC6409] Gellens, R. and J. Klensin, "Message Submission 863 for Mail", STD 72, RFC 6409, November 2011. 865 12.2. Informative References 867 [RFC5598] Crocker, D., "Internet Mail Architecture", 868 RFC 5598, July 2009. 870 [RFC1845] Crocker, D. and N. Freed, "SMTP Service 871 Extension for Checkpoint/Restart", RFC 1845, 872 September 1995. 874 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP 875 Service Extension for Message Size 876 Declaration", STD 10, RFC 1870, November 1995. 878 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced 879 Relay): Mapping between X.400 and RFC 822/ 880 MIME", RFC 2156, January 1998. 882 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., 883 and S. Jamin, "Resource ReSerVation Protocol 884 (RSVP) -- Version 1 Functional Specification", 885 RFC 2205, September 1997. 887 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. 888 Black, "Definition of the Differentiated 889 Services Field (DS Field) in the IPv4 and IPv6 890 Headers", RFC 2474, December 1998. 892 [RFC2852] Newman, D., "Deliver By SMTP Service 893 Extension", RFC 2852, June 2000. 895 [RFC4190] Carlberg, K., Brown, I., and C. Beard, 896 "Framework for Supporting Emergency 897 Telecommunications Service (ETS) in IP 898 Telephony", RFC 4190, November 2005. 900 [RFC4412] Schulzrinne, H. and J. Polk, "Communications 901 Resource Priority for the Session Initiation 902 Protocol (SIP)", RFC 4412, February 2006. 904 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple 905 Authentication and Security Layer (SASL)", 906 RFC 4422, June 2006. 908 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email 909 Filtering Language", RFC 5228, January 2008. 911 [PRIORITY-TUNNELING] Melnikov, A. and K. Carlberg, "Tunneling of 912 SMTP Message Transfer Priorities", 913 draft-melnikov-smtp-priority-tunneling-00 (work 914 in progress), 2012. 916 [ACP123] CCEB, "Common Messaging strategy and 917 procedures", ACP 123, May 2009. 919 [STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message 920 Handling System", STANAG 4406, March 2005. 922 [GREYLISTING] Kucherawy, M. and D. Crocker, "Email 923 Greylisting: An Applicability Statement for 924 SMTP", draft-ietf-appsawg-greylisting (work in 925 progress), April 2012. 927 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation 928 Bandwidth Constraints Model for Diffserv-aware 929 MPLS Traffic Engineering", RFC 4125, June 2005. 931 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth 932 Constraints Model for Diffserv-aware MPLS 933 Traffic Engineering", RFC 4127, June 2005. 935 [RFC6401] Le Faucheur, F., Polk, J., and K. Carlberg, 936 "RSVP Extensions for Admission Priority", 937 RFC 6401, October 2011. 939 Appendix A. Priority Assignment Policy for Military Messaging 941 Military Messaging as specified in ACP 123 [ACP123] (also specified 942 in STANAG 4406 [STANAG-4406]) defines 6 priority ("precedence") 943 values. While ACP 123/STANAG 4406 allow for 32 different priority 944 levels (16 levels are reserved for NATO and additional 16 are 945 reserved for national use), only 6 are in use in practice. This 946 section specified the Priority Assignment Policy for Military 947 Messaging and how the MT-PRIORITY parameter can be mapped when 948 gatewaying between an SMTP and a ACP 123/STANAG 4406 environments. 950 Where SMTP is used to support military messaging, the following 951 mappings SHOULD be used. 953 Recommended mapping of MT-PRIORITY values for MMHS 955 +----------------+----------------------+ 956 | Priority value | MMHS Precedence name | 957 +----------------+----------------------+ 958 | -4 | Deferred | 959 | -2 | Routine | 960 | 0 | Priority | 961 | 2 | Immediate | 962 | 4 | Flash | 963 | 6 | Override | 964 +----------------+----------------------+ 966 Table 1 968 The Priority Assignment Policy registration for Military Messaging is 969 as follows: 971 1. The Priority Assignment Policy name is "STANAG4406". 973 2. Number of distinct priority levels: 6, as specified in the table 974 above. 976 3. Default retry timeouts for each priority level are implementation 977 and/or deployment specific. 979 4. Default expiration timeouts for each priority level are 980 implementation and/or deployment specific. 982 5. Maximum message size associated with each priority level: 983 implementation and/or deployment specific. 985 6. No restrictions on what kind of SMTP client authentication is 986 required. 988 Appendix B. Priority Assignment Policy for MIXER 990 MIXER [RFC2156] defines the Priority header field with 3 values. 991 This section specified the Priority Assignment Policy for MIXER and 992 how the MT-PRIORITY parameter can be mapped when used with MIXER. 994 Where SMTP is used to support MIXER messaging, the following mappings 995 SHOULD be used. 997 Recommended mapping of MT-PRIORITY values for MIXER 999 +----------------------+-------------------+ 1000 | MIXER Priority value | MT-PRIORITY value | 1001 +----------------------+-------------------+ 1002 | non-urgent | -4 | 1003 | normal | 0 | 1004 | urgent | 4 | 1005 +----------------------+-------------------+ 1007 Table 2 1009 The Priority Assignment Policy registration for MIXER is as follows: 1011 1. The Priority Assignment Policy name is "MIXER". 1013 2. Number of distinct priority levels: 3, as specified in the table 1014 above. 1016 3. Default retry timeouts for each priority level are implementation 1017 and/or deployment specific. 1019 4. Default expiration timeouts for each priority level are 1020 implementation and/or deployment specific. 1022 5. Maximum message size associated with each priority level: 1023 implementation and/or deployment specific. 1025 6. No restrictions on what kind of SMTP client authentication is 1026 required. 1028 Appendix C. Priority Assignment Policy for National Security / 1029 Emergency Preparedness (NS/EP) 1031 There are several forms of communication systems used during an 1032 emergency or disaster. The most well known form involves the many- 1033 to-one model of the general public contacting a public safety access 1034 point via 911/999/112 calls through the public telephone network. 1035 Typically, these calls do not require authorization, nor do they 1036 invoke any prioritization. 1038 Another form of emergency communications involves a set of authorized 1039 users or nodes that use prioritized services to help established and 1040 continue communication given limited available resources. [RFC4190] 1041 includes descriptions of several systems that have been developed to 1042 support National Security / Emergency Preparedness (NS/EP). These 1043 deployed systems require a form of authentication and have focused on 1044 prioritization of telephony based services. They have also been 1045 designed as a binary form (on/off) of signaled priority 1046 communications. 1048 [RFC4412] includes examples of a more expansive view of NS/EP 1049 communications in which priority migrates from a single on/off bit 1050 value to one that comprises 5 priority values. This is shown in the 1051 cases of the ETS and WPS Namespaces. Given a lack of pre-existing 1052 NS/EP values assigned for email, we follow the paradigm of the ETS 1053 and WPS Namespaces and recommend 5 ascending values shown in the 1054 table below. 1056 +----------------+------------------+ 1057 | Priority value | Relational Order | 1058 +----------------+------------------+ 1059 | -2 | Lowest Priority | 1060 | 0 | ---------- | 1061 | 2 | ---------- | 1062 | 4 | ---------- | 1063 | 6 | Highest Priority | 1064 +----------------+------------------+ 1066 The Priority Assignment Policy registration for NS/EP is as follows: 1068 1. The Priority Assignment Policy name is "NSEP". 1070 2. Number of distinct priority levels: 5, as specified in the table 1071 above. 1073 3. Default retry timeouts for each priority level are implementation 1074 and/or deployment specific. 1076 4. Default expiration timeouts for each priority level are 1077 implementation and/or deployment specific. 1079 5. Maximum message size associated with each priority level: 1080 implementation and/or deployment specific. 1082 6. No restrictions on what kind of SMTP client authentication is 1083 required. 1085 Appendix D. Possible implementation strategies 1087 This appendix suggests some implementation strategies to implement 1088 the SMTP extension defined in this document. The list is not 1089 exhaustive. 1091 This appendix and its subsections are Informative. 1093 D.1. Probability 1095 As the name suggests, probability involves increasing the chances of 1096 obtaining resources without adversely affecting previously 1097 established connections. One example would involve requesting 1098 resources set aside for specific priority levels. If these 1099 additional resources are exhausted, then the desired connection is 1100 denied. Queues, new timers, or combinations thereof can be used to 1101 facilitate the higher priority requests, but the key is that 1102 mechanisms focus on increasing the probability of message transfer. 1104 D.2. Preemption of sessions or transactions 1106 Preemption is a type of action that focuses only on a comparison of 1107 priorities to determine if previously established transactions need 1108 to be displaced in favor of higher priority requests. If no 1109 additional connection is possible, the client aborts a running 1110 session for emails with lower priority no later than directly after 1111 the current transaction. The client even can interrupt an active 1112 transaction and ought to do so, if other constraints such as delivery 1113 time (as specified in the DELIVERBY SMTP extension [RFC2852]) would 1114 be violated for the email with higher priority. When interrupting an 1115 active transaction, the client ought to take the total message size 1116 and the size of the transferred portion of the message being 1117 interrupted into consideration. This preliminary termination of 1118 sessions or transactions is called preemption. 1120 If preemption of running transactions occurs, the client needs to 1121 choose a transaction with the lowest priority currently processed. 1123 If the client has an option (i.e. it is supported by the next hop 1124 MTA) to interrupt transactions in a way that it can be restarted at 1125 the interruption point later, it ought to deploy it. An example for 1126 a mechanism providing such a service is the "SMTP Service Extension 1127 for Checkpoint/Restart" defined in [RFC1845]. 1129 If a client opts for the preemption of sessions instead of 1130 transactions, it needs to preempt the next session that reaches the 1131 end of a transaction. 1133 D.3. Resource Allocation Models 1135 Adding prioritization to a design moves the subject away from 1136 strictly best effort (and a first-come-first-served model) to one 1137 that includes admission control and resource allocation models. Over 1138 the years, a variety of work has been done within the IETF in 1139 specifying resource allocations models. Examples include the Maximum 1140 Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and 1141 the Priority Bypass Model (Appendix A.3 of [RFC6401]). 1143 While we recognize that these various models have been designed for 1144 other protocols (i.e., MPLS and RSVP), an understanding of their 1145 design characteristics may be beneficial in considering future 1146 implementations of a priority SMTP service. 1148 In cases where the processing of high priority messages by an MTA is 1149 not considered negligible and exceeds engineered expectations, then 1150 operators managing that MTA may be notified in some form (e.g., 1151 pushed alarm, polled status). 1153 Appendix E. Background on Design Choices 1155 This Section provides some background on design choices made during 1156 development of the MT-PRIORITY SMTP extension. 1158 The priority applies per message, rather than per recipient in order 1159 to keep the protocol simpler, and because of the expectation that it 1160 will be uncommon to need different priorities for different 1161 recipients on the same message. In cases where that is necessary, it 1162 can always be achieved by sending separate messages with the same 1163 content, segregating the recipients by desired message priority. 1165 The choice of the priority range -9 to 9 (as opposed to, say, 1 to 6, 1166 or 0 to 9) was made after taking the following into consideration: 1168 1. Clearly, having multiple priority levels is the whole point of 1169 this extension. Existing implementations of similar 1170 functionality in MTAs are already using three levels. One of the 1171 use cases motivating this extension requires 6 levels. So at 1172 least 6 different values are required. 1174 2. During discussions of this extension, several different use cases 1175 were suggested that required differing numbers of priority 1176 levels. Defining just the 6 priority levels needed in item 1, 1177 above, would limit the extensibility for possible future use 1178 cases. Therefore, this document is defining a wider range, which 1179 allows implementations and deployments to add higher or lower 1180 priority levels and to insert additional priority levels between 1181 the recommended set of 6. This avoids the need to further extend 1182 this extension just to have a few more priority levels. 1184 3. It seems natural to use 0 for the "normal" or default priority, 1185 rather than picking some non-zero number and having the 1186 priorities go up or down from there. This way, negative numbers 1187 always represent priorities that are lower than normal, with 1188 positive numbers as higher priorities. 1190 Appendix F. Acknowledgements 1192 This document copies lots of text from 1193 draft-schmeing-smtp-priorities-04.txt and 1194 draft-schmeing-smtp-priorities-05.txt. So the authors of this 1195 document would like to acknowledge contributions made by the authors 1196 of draft-schmeing-smtp-priorities: Michael Schmeing and Jan-Wilhelm 1197 Brendecke. 1199 Many thanks for input provided by Steve Kille, David Wilson, John 1200 Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba, 1201 Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick, 1202 Chris Newman, Ned Freed and Claudio Allocchio. 1204 Special thanks to Barry Leiba for agreeing to shepherd this document. 1206 Authors' Addresses 1208 Alexey Melnikov 1209 Isode Ltd 1210 5 Castle Business Village 1211 36 Station Road 1212 Hampton, Middlesex TW12 2BX 1213 UK 1215 EMail: Alexey.Melnikov@isode.com 1217 Ken Carlberg 1218 G11 1219 1601 Clarendon Blvd, #203 1220 Arlington, VA 22209 1221 USA 1223 EMail: carlberg@g11.org.uk