idnits 2.17.1 draft-melnikov-smtp-priority-tunneling-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2012) is 4250 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: Informational K. Carlberg 5 Expires: January 31, 2013 G11 6 July 30, 2012 8 Tunneling of SMTP Message Transfer Priorities 9 draft-melnikov-smtp-priority-tunneling-04 11 Abstract 13 This memo defines a mechanism for tunneling of SMTP (Simple Mail 14 Transfer Protocol) Message Transfer Priority values through MTAs 15 (Message Transfer Agents) that don't support the MT-PRIORITY SMTP 16 extension. 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 31, 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. Handling of messages received via SMTP . . . . . . . . . . . . 4 55 3.1. Handling of the MT-PRIORITY parameter by the receiving 56 SMTP server . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Relay of messages to other conforming SMTP/LMTP servers . 5 58 3.3. Relay of messages to non-conforming SMTP/LMTP servers . . 5 59 3.4. Mailing lists and Aliases . . . . . . . . . . . . . . . . 5 60 3.5. Gatewaying a message into a foreign environment . . . . . 5 61 3.6. Interaction with DSN SMTP Extension . . . . . . . . . . . 5 62 4. Header field: MT-Priority . . . . . . . . . . . . . . . . . . 6 63 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7.1. Modification of MT-Priority header field and DKIM . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 This document is an experimental extension to the SMTP Message 75 Transfer Priorities extension [SMTP-PRIORITY]. It specifies 76 application layer tunneling of message priority, to convey the 77 priority of the messages through Message Transfer Agents (MTAs) that 78 do not support the Message Transfer Priorities extension. The 79 tunneling is done by adding a new message header field to Internet 80 message format specified in [RFC5322]. 82 A number of other header fields are already in use, mostly in Mail 83 User Agents (MUAs), to convey meanings related to importance or 84 priority of messages. Examples of such header fields are Importance 85 [RFC2156], Priority [RFC2156] and X-Priority (undocumented). 86 Considering sometimes subtle and sometimes significant differences in 87 the meaning of these header fields and widely different syntax, this 88 document defines a new header field. 90 This document is motivated by 2 main deployment scenarios: (1) Mail 91 User Agent (MUA) talking to a non MT-PRIORITY aware Message 92 Submission Server (MSA), and (2) use of unextended MUA to talk to a 93 MT-PRIORITY aware MSA. These 2 use cases are discussed in more 94 details below. 96 The use case (1) is about a MT-PRIORITY capable MUA talking to a non 97 MT-PRIORITY capable MSA [RFC6409], which in turn is talking to a MT- 98 PRIORITY capable MTA [RFC5321]. Both MSA and MTA are within the same 99 Administrative and Management Domain (ADMD) and are on a fast 100 network, however some recipients are accessible via the MTA which is 101 talking over a slow link to the next MTA. Communications over that 102 slow link can benefit from use of MT-PRIORITY SMTP extension. 104 In the use case (2) a widely deployed client (such as a desktop 105 client) is talking to MT-PRIORITY capable MSA. The client might be 106 extendable via a plugin API provided by the client developers, 107 however existing APIs frequently allow easy manipulation of email 108 header fields, while not allowing for addition of SMTP protocol 109 features. In such a case installing a plugin to the client that can 110 set MT-Priority header field could provide easier and earlier 111 deployment of MT-PRIORITY SMTP extension in an organization without 112 requiring changes to desktop clients. 114 We note that the above use cases are not exhaustive and that other 115 use cases, variations of the above, may exist. The purpose of this 116 document is not to consider every scenario, but rather examples that 117 reinforce the need to consider a tunneling mechanism that can deal 118 with SMTP capable devices that do not support [SMTP-PRIORITY]. 120 2. Conventions Used in This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119] when they 125 appear in ALL CAPS. These words also appear in this document in 126 lower case as plain English words, absent their normative meanings. 128 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 129 notation including the core rules defined in Appendix B of RFC 5234 130 [RFC5234]. 132 In examples, "C:" and "S:" indicate lines sent by the client and 133 server respectively. Line breaks that do not start with a new "C:" 134 or "S:" exist for editorial reasons and are not a part of the 135 protocol. 137 This document uses the term "priority" specifically in relation to 138 the internal treatment of a message by the server: messages with 139 higher priorities may be given expedited handling, and those with 140 lower priorities may be handled only as resources become available. 142 3. Handling of messages received via SMTP 144 The subsections of this section update the corresponding subsections 145 of Section 4 of [SMTP-PRIORITY]. 147 3.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server 149 This specification inserts the following between steps 4 and 5 in 150 Section 4.1 of [SMTP-PRIORITY]: 152 4a. If the sending SMTP client hasn't specified the MT-PRIORITY 153 parameter to the MAIL FROM command, but the message has a single 154 syntactically valid MT-Priority header field (see Section 4), 155 then the value of this header field is the message priority. 157 4b. In absence of both the MT-PRIORITY MAIL FROM parameter and the 158 MT-Priority header field, other message header fields, such as 159 Priority [RFC2156] and X-Priority, MAY be used for determining 160 the priority under this "Priority Message Handling" SMTP 161 extension. But note that the Importance [RFC2156] header field 162 MUST NOT be used for determining the priority under this 163 "Priority Message Handling" SMTP extension, as it has different 164 semantics: the Importance header field is aimed at the user 165 recipient and not at the nodes responsible for transferring the 166 message. 168 3.2. Relay of messages to other conforming SMTP/LMTP servers 170 This specification inserts the following between steps 1 and 2 in 171 Section 4.2 of [SMTP-PRIORITY]. 173 1a. Note that rule 1 also applies to messages which didn't have any 174 priority explicitly specified using the MT-PRIORITY MAIL FROM 175 parameter or the MT-Priority header field. 177 3.3. Relay of messages to non-conforming SMTP/LMTP servers 179 This specification appends the following after step 1 in Section 4.3 180 of [SMTP-PRIORITY]: 182 2. The relaying MTA MUST first remove any and all existing MT- 183 Priority header fields from the message. (Please see Section 7 184 for additional considerations related to removal of the MT- 185 Priority header field.) 187 3. If the incoming message had a MT-PRIORITY parameter specified in 188 the MAIL FROM command *or* there was an MT-Priority header field 189 removed in the above step 2, then the relaying MTA MUST add its 190 own MT-Priority header field with the value determined by the 191 procedure in Section 3.1. Syntax of the MT-Priority header field 192 is specified in Section 4. 194 3.4. Mailing lists and Aliases 196 This specification makes no changes to Section 4.4 of 197 [SMTP-PRIORITY]. 199 3.5. Gatewaying a message into a foreign environment 201 This specification inserts the following between steps 1 and 2 in 202 Section 4.5 of [SMTP-PRIORITY]. 204 1a. Note that if the destination environment doesn't support 205 transport of arbitrary header field, the requirement in 206 Section 3.3 to add an MT-Priority header field doesn't apply. 208 3.6. Interaction with DSN SMTP Extension 210 This specification makes no changes to Section 4.6 of 211 [SMTP-PRIORITY]. 213 4. Header field: MT-Priority 215 Applicable protocol: mail [RFC5322] 216 Status: standard 217 Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on 218 behalf of the IETF 219 Specification document(s): [[anchor7: this document]] 221 The MT-Priority header field conveys message transfer priority when 222 relaying a message through MTAs which don't support the MT-PRIORITY 223 SMTP extension. 225 ABNF for this header field is defined as follows: 227 priority-header-field = "MT-Priority:" 228 [CFWS] priority-value [CFWS] CRLF 230 where "priority-value" is defined in [SMTP-PRIORITY]. 232 Example: 233 MT-Priority: -3 235 Example: 236 MT-Priority: 4 (ultra) 238 5. Example 240 An SMTP transaction with 2 recipients. Note that the example is also 241 making use of the STARTTLS [RFC3207] and DSN [RFC3461] SMTP 242 extensions, even though there is no requirement that these other 243 extensions are to be supported when the MT-PRIORITY SMTP extension is 244 implemented. 246 S: 220 example.net SMTP server here 247 C: EHLO example.com 248 S: 250-example.net 249 S: 250-DSN 250 S: 250-STARTTLS 251 S: 250 MT-PRIORITY STANAG4406 252 C: STARTTLS 253 [...TLS negotiation...] 254 C: MAIL FROM: ENVID=QQ314159 255 MT-PRIORITY=3 256 S: 250 sender ok 257 C: RCPT TO: 258 S: 250 recipient ok 259 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 260 ORCPT=rfc822;Dana@Ivory.example.net 261 S: 250 recipient ok 262 C: DATA 263 S: 354 okay, send message 264 C: (message goes here) 265 C: . 266 S: 250 message accepted 267 C: QUIT 268 S: 221 goodbye 270 Here the receiving SMTP server supports the "STANAG4406" Priority 271 Assignment Policy [SMTP-PRIORITY] with 6 priority levels, so it will 272 use the priority value 4 internally (the next supported priority 273 higher or equal to 3) and will communicate the priority value 3 when 274 relaying it to the next hop (if necessary). When relaying the 275 message to the next hop which doesn't support the MT-PRIORITY SMTP 276 extension the transaction might look like this: 278 S: 220 example.org SMTP server here 279 C: EHLO example.net 280 S: 250-example.org 281 S: 250-DSN 282 S: 250-STARTTLS 283 S: 250 SIZE 284 C: STARTTLS 285 [...TLS negotiation...] 286 C: MAIL FROM: ENVID=QQ314159 287 S: 250 sender ok 288 C: RCPT TO: 289 S: 250 recipient ok 290 C: RCPT TO: NOTIFY=SUCCESS,FAILURE 291 ORCPT=rfc822;Dana@Ivory.example.net 292 S: 250 recipient ok 293 C: DATA 294 S: 354 okay, send message 295 C: MT-Priority: 3 296 C: (the rest of the message goes here) 297 C: . 298 S: 250 message accepted 299 C: QUIT 300 S: 221 goodbye 302 6. IANA Considerations 304 IANA is requested to add the following list of header field names to 305 the "Permanent Message Header Field Names" registry (in 306 http://www.iana.org/assignments/message-headers/perm-headers.html): 308 Header field: MT-Priority 309 Applicable protocol: mail 310 Status: standard 311 Author/change controller: Alexey Melnikov / IESG (iesg@ietf.org) on 312 behalf of the IETF 313 Specification document(s): [[anchor9: this document]] 315 7. Security Considerations 317 This document allows a message priority to be tunneled through MTAs 318 which don't support the MT-PRIORITY SMTP extension by specifying how 319 it can be represented in the message itself (using the MT-Priority 320 header field). Thus it is important to ensure that an MTA receiving 321 a message containing the MT-Priority header field can trust that it 322 was set by an authorized agent. Use of technologies such as DKIM 323 [RFC6376] or S/MIME to sign the MT-Priority header field value can 324 enable a recipient to verify whether the specified priority value was 325 generated by a trusted agent. In particular DKIM signing allows a 326 recipient to verify that the specified priority value was present 327 when the message was signed, and to verify who signed the message. 328 But note that the DKIM signer might not be the same agent that 329 generated the MT-Priority header field. 331 Message Submission Agents ought to only accept message transfer 332 priorities (whether by using the MT-PRIORITY parameter to the MAIL 333 FROM command or the MT-Priority header field in the message itself) 334 from users (or only certain groups of such users) who are 335 authenticated and authorized in some way that's acceptable to the 336 MSA. As part of this policy, they can also restrict maximum priority 337 values that different groups of users can request, and can override 338 the priority values specified by MUAs. Such MSAs are required to 339 replace any MT-Priority header field values that don't satisfy this 340 policy, when relaying to non MT-PRIORITY capable SMTP/LMTP servers. 341 See Section 7.1 for more details on on what might be consequences of 342 such changes. 344 Similarly, MTAs ought to only accept message transfer priorities 345 (whether by using the MT-PRIORITY parameter to the MAIL FROM command 346 or the MT-Priority header field in the message itself) from senders 347 (or only certain groups of such senders) who are authenticated and 348 authorized in some way that's acceptable to the MTA. As part of this 349 policy, they can also restrict maximum priority values that different 350 groups of senders can request, and can override the priority values 351 specified by them. Such MTAs are required to replace any MT-Priority 352 header field values that don't satisfy this policy, when relaying to 353 non MT-PRIORITY capable SMTP/LMTP servers. See Section 7.1 for more 354 details on on what might be consequences of such changes. 356 In the absence of the policy enforcement mentioned above an SMTP 357 server (whether an MSA or an MTA) implementing the MT-PRIORITY SMTP 358 extension might be susceptible to a Denial of Service attack. For 359 example, malicious clients (MUAs/MSAs/MTAs) can try to abuse this 360 feature by always requesting Priority 9. 362 To protect MT-Priority header field from modification or insertion, 363 MUAs, MSAs and MTAs inserting it into messages SHOULD use message 364 header protection mechanism such as DKIM [RFC6376]. But see 365 Section 7.1. 367 7.1. Modification of MT-Priority header field and DKIM 369 A MSA/MTA that receives a message with an MT-Priority header field 370 protected by DKIM, that wants to change the message priority due to 371 its policy is forced to choose between 372 a. breaking DKIM signatures (by replacing the MT-Priority header 373 value), 375 b. leaving the message as is (and using the MT-PRIORITY MAIL FROM 376 parameter), relying on the fact that all downstream MTAs are 377 compliant with this specification, 379 c. rejecting the message. 381 Each of these choices is not perfect and work in a particular 382 situation, so these choices should be carefully considered during 383 implementation and deployment. 385 If the MSA/MTA decides to alter the message, it SHOULD re-sign the 386 message with DKIM. 388 8. References 390 8.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) 396 Service Extension for Delivery Status Notifications 397 (DSNs)", RFC 3461, January 2003. 399 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", 400 RFC 5321, October 2008. 402 [RFC5322] Resnick, P., Ed., "Internet Message Format", 403 RFC 5322, October 2008. 405 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for 406 Syntax Specifications: ABNF", STD 68, RFC 5234, 407 January 2008. 409 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for 410 Mail", STD 72, RFC 6409, November 2011. 412 [SMTP-PRIORITY] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 413 Protocol extension for Message Transfer Priorities", 414 draft-melnikov-smtp-priority-21 (work in progress), 415 2012. 417 8.2. Informative References 419 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced 420 Relay): Mapping between X.400 and RFC 822/MIME", 421 RFC 2156, January 1998. 423 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP 424 over Transport Layer Security", RFC 3207, 425 February 2002. 427 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, 428 "DomainKeys Identified Mail (DKIM) Signatures", 429 RFC 6376, September 2011. 431 Appendix A. Acknowledgements 433 This document copies lots of text from 434 draft-schmeing-smtp-priorities-04.txt and 435 draft-schmeing-smtp-priorities-05.txt. So the authors of this 436 document would like to acknowledge contributions made by the authors 437 of draft-schmeing-smtp-priorities: Michael Schmeing and Jan-Wilhelm 438 Brendecke. 440 Many thanks for input provided by Steve Kille, David Wilson, John 441 Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba, 442 Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick, 443 Chris Newman, Ned Freed, Claudio Allocchio, Martin Thomson, Joseph 444 Yee. 446 Special thanks to Barry Leiba for agreeing to shepherd this document. 448 Authors' Addresses 450 Alexey Melnikov 451 Isode Ltd 452 5 Castle Business Village 453 36 Station Road 454 Hampton, Middlesex TW12 2BX 455 UK 457 EMail: Alexey.Melnikov@isode.com 458 Ken Carlberg 459 G11 460 1601 Clarendon Blvd, #203 461 Arlington, VA 22209 462 USA 464 EMail: carlberg@g11.org.uk