idnits 2.17.1 draft-ietf-eai-dsn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 685. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3798, but the abstract doesn't seem to directly say this. It does mention RFC3798 though, so this could be OK. -- The draft header indicates that this document updates RFC3461, but the abstract doesn't seem to directly say this. It does mention RFC3461 though, so this could be OK. -- The draft header indicates that this document updates RFC3464, but the abstract doesn't seem to directly say this. It does mention RFC3464 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3461, updated by this document, for RFC5378 checks: 2001-06-21) (Using the creation date from RFC3464, updated by this document, for RFC5378 checks: 2001-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2007) is 6164 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-eai-downgrade' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC3501' is defined on line 588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-05 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-05 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-03 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Updates: 3461,3464,3798 A. Melnikov, Ed. 5 (if approved) Isode Ltd 6 Intended status: Experimental June 12, 2007 7 Expires: December 14, 2007 9 International Delivery and Disposition Notifications 10 draft-ietf-eai-dsn-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 14, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Delivery status notifications (DSNs) are critical to the correct 44 operation of an email system. However, the existing draft standard 45 is presently limited to US-ASCII text in the machine readable 46 portions of the protocol. This specification adds a new address type 47 for international email addresses so an original recipient address 48 with non-US-ASCII characters can be correctly preserved even after 49 downgrading. This also provides updated content return media types 50 for delivery status notifications and message disposition 51 notifications to support use of the new address type. 53 This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 59 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 60 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 5 61 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 7 64 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 8 65 6.3. message/utf-8-headers . . . . . . . . . . . . . . . . . . 8 66 6.4. message/utf-8-delivery-status . . . . . . . . . . . . . . 9 67 6.5. message/utf-8-disposition-notification . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 73 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 14 74 Appendix C. Changes from -00 . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . . . 16 78 1. Introduction 80 When an email message is transmitted using the UTF8SMTP 81 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 82 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 83 message or generate a Message Disposition Notification [RFC3798] 84 (MDN). As a message sent to multiple recipients can generate a 85 status and disposition notification for each recipient, it is helpful 86 if a client can correlate these returns based on the recipient 87 address it provided, thus preservation of the original recipient is 88 important. This specification describes how to preserve the original 89 recipient and updates the MDN and DSN formats to support the new 90 address types. 92 2. Conventions Used in this Document 94 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 95 in this document are to be interpreted as defined in "Key words for 96 use in RFCs to Indicate Requirement Levels" [RFC2119]. 98 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 99 notation including the core rules defined in Appendix B of RFC 4234 100 and the rules in section 4 of RFC 3629. 102 3. UTF-8 Address Type 104 An Extensible Message Format for Delivery Status Notifications 105 [RFC3464] defines the concept of an address type. The address format 106 introduced in Internationalized Email Headers 107 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 108 new address type in the context of status notifications follows: 110 An SMTP [RFC2821] server which advertises both the UTF8SMTP extension 111 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 112 utf-8 address type in the ORCPT parameter including 8-bit UTF-8 113 characters. This address type also includes a 7-bit encoding 114 suitable for use in a message/delivery-status body part or an ORCPT 115 parameter sent to an SMTP server which does not advertise UTF8SMTP. 117 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext 118 and utf-8-address. The first 2 forms are 7-bit safe. 120 The utf-8-address form is only suitable for use in newly defined 121 protocols capable of native representation of 8-bit characters. I.e. 122 the utf-8-address form MUST NOT be used in the ORCPT parameter when 123 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 124 server supports UTF8SMTP, but the address contains US-ASCII 125 characters not permitted in the ORCPT parameter (e.g. the ORCPT 126 parameter forbids SP and =); or in a 7-bit transport environment 127 including a message/delivery-status Original-Recipient or Final- 128 Recipient field. The utf-8-addr-xtext form (see below) MUST be used 129 instead in the former case, the utf-8-addr-unitext form MUST be used 130 in the latter case. The utf-8-address form MAY be used in the ORCPT 131 parameter when the SMTP server also advertises support for UTF8SMTP 132 and the address doesn't contains any US-ASCII characters not 133 permitted in the ORCPT parameter. It SHOULD be used in a message/ 134 utf-8-delivery-status Original-Recipient or Final-Recipient DSN 135 field; or an Original-Recipient header field [RFC3798] if the message 136 is a UTF-8 header message. 138 In addition, the utf-8-addr-unitext form can be used anywhere where 139 the utf-8-address form is allowed. 141 When using in the ORCPT parameter, the utf-8 address type requires 142 that US-ASCII CTLs, SP, %, + and = be encoded using xtext encoding as 143 described in [RFC3461]. This is described by the utf-8-addr-xtext 144 form in the ABNF below. Plane 1 Unicode characters MAY be included 145 in a utf-8 address type using a "%u####" syntax (QMIDCHAR, where # is 146 a hexadecimal digit) and other Unicode characters MAY be encoded 147 using "%U########" syntax (QHIGHCHAR). When sending data to a 148 UTF8SMTP capable server, native UTF-8 characters SHOULD be used 149 instead of the QMIDCHAR and QHIGHCHAR encodings described below. 150 When sending data to an SMTP server which does not advertise 151 UTF8SMTP, then the QMIDCHAR and QHIGHCHAR encodings MUST be used 152 instead of UTF-8. 154 When the ORCPT parameter is placed in a message/utf-8-delivery-status 155 Original-Recipient field, the utf-8-addr-xtext form of the utf-8 156 address type SHOULD be converted to the 'utf-8-address' form (see the 157 ABNF below) by removing all xtext encoding first (which will result 158 in the 'utf-8-addr-unitext' form), followed by removal of the 159 'unitext' encoding. However, if an address is labeled with the utf-8 160 address type but does not conform to utf-8 syntax, then it MUST be 161 copied into the message/utf-8-delivery-status field without 162 alteration. 164 The ability to encode characters with the QMIDCHAR or QHIGHCHAR 165 encodings should be viewed as a transitional mechanism. It is hoped 166 that as systems lacking support for UTF8SMTP become less common over 167 time, these encodings can eventually be phased out. 169 utf-8-type-addr = "utf-8;" utf-8-enc-addr 171 utf-8-address = uMailbox [ *WSP "<" Mailbox ">" ] 172 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 173 ; 'Mailbox' is defined in [RFC2821]. 175 utf-8-enc-addr = utf-8-addr-xtext / 176 utf-8-addr-unitext / 177 utf-8-address 179 ///Add comment about which where each type is used 181 utf-8-addr-xtext = xtext 182 ; xtext is defined in [RFC3461]. 183 ; When xtext encoding is removed, 184 ; the syntax MUST conform to 185 ; 'utf-8-addr-unitext'. 187 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 188 ; MUST follow 'utf-8-address' ABNF when 189 ; dequoted 191 ///Exclude '\'? 192 QUCHAR = %x21-2a / %x2c-3c / %x3e-7e / 193 UTF8-2 / UTF8-3 / UTF8-4 194 ; Printable except CTLs, SP, + and = 196 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 197 ; starts with "\x" 199 HEXPOINT = "5C" / ( NZHEXDIG 2*4HEXDIG ) / ( "10" 4*HEXDIG ) 200 ; represents either "\" or a Unicode code point outside the 201 ; US-ASCII repertoire 203 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 204 ; HEXDIG excluding "0" 206 4. UTF-8 Delivery Status Notifications 208 A traditional delivery status notification [RFC3464] comes in a 209 three-part multipart/report [RFC3462] container, where the first part 210 is human readable text describing the error, the second part is a 211 7-bit-only message/delivery-status and the optional third part is 212 used for content (message/rfc822) or header (text/rfc822-headers) 213 return. An SMTP server which advertises both UTF8SMTP and DSN SHOULD 214 return an undeliverable UTF8SMTP message without downgrading it 215 (assuming the return SMTP server supports UTF8SMTP). As the present 216 DSN format does not permit this, three new media types are needed. 218 The first type, message/utf-8-delivery-status has the syntax of 219 message/delivery-status with two modifications. First, the charset 220 for message/utf-8-delivery-status is UTF-8 and thus any field MAY 221 contain UTF-8 characters when appropriate. (In particular, the 222 Diagnostic-Code field MAY contain UTF-8 as described in UTF8SMTP 223 [I-D.ietf-eai-smtpext].) Second, systems generating a message/ 224 utf-8-delivery-status body part SHOULD use the utf-8-address form of 225 the utf-8 address type for all addresses containing characters 226 outside the US-ASCII repertoire. These systems SHOULD up-convert the 227 utf-8-addr-xtext or the utf-8-addr-unitext form of a utf-8 address 228 type in the ORCPT parameter to the utf-8-address form of a utf-8 229 address type in the Original-Recipient field. 231 The second type, used for content return, is message/utf-8 which is 232 similar to message/rfc822, except it contains a message with UTF-8 233 headers. This media type is described in [I-D.ietf-eai-utf8headers]. 235 The third type, used for header return, is message/utf-8-headers and 236 contains only the UTF-8 headers of a message (all lines prior to the 237 first blank line in a UTF8SMTP message). Unlike message/utf-8, this 238 body part provides no difficulties for present infrastructure. 240 All three new types will typically use the "8bit" Content-Transfer- 241 Encoding (in the event all content is 7-bit, the equivalent 242 traditional types for delivery status notifications are advised for 243 greater backwards compatibility). While MIME [RFC2046] advises 244 against the use of 8-bit in new message subtypes intended for the 245 email infrastructure, that advice does not apply to these new types 246 which are intended primarily for use by newer systems with full 247 support for 8-bit MIME and UTF-8 headers. 249 5. UTF-8 Message Disposition Notifications 251 Message Disposition Notifications [RFC3798] have a similar design and 252 structure to DSNs. As a result, they use the same basic return 253 format. When generating a MDN for a UTF-8 header message, content or 254 header return is the same as for DSNs. The second part of the 255 multipart/report uses a new media type, message/ 256 utf-8-disposition-notification, which has the syntax of message/ 257 disposition-notification with two modifications. First, the charset 258 for message/utf-8-disposition-notification is UTF-8 and thus any 259 field MAY contain UTF-8 characters when appropriate. Second, systems 260 generating a message/utf-8-disposition-notification body part 261 (typically a mail user agent) SHOULD use the utf-8 address type for 262 all addresses containing characters outside the US-ASCII repertoire. 264 The MDN specification also defines the Original-Recipient header 265 field which is added with a copy of the contents of ORCPT at delivery 266 time. When generating an Original-Recipient header field, a delivery 267 agent writing a UTF-8 header message in native format SHOULD convert 268 the utf-8-addr-xtext or the utf-8-addr-unitext form of a utf-8 269 address type in the ORCPT parameter to the corresponding utf-8- 270 address form. 272 The MDN specification also defines the Disposition-Notification-To 273 header which is an address header and thus follows the same 8-bit 274 rules as other address headers such as "From" and "To" when used in a 275 UTF-8 header message. 277 6. IANA Considerations 279 This specification does not create any new IANA registries. However 280 the following items are registered as a result of this document: 282 6.1. UTF-8 Mail Address Type Registration 284 The mail address type registry was created by RFC 3464. The 285 registration template response follows: 287 (a) The proposed address-type name. 289 UTF-8 291 (b) The syntax for mailbox addresses of this type, specified using 292 BNF, regular expressions, ASN.1, or other non-ambiguous language. 294 See Section 3. 296 (c) If addresses of this type are not composed entirely of graphic 297 characters from the US-ASCII repertoire, a specification for how they 298 are to be encoded as graphic US-ASCII characters in a DSN Original- 299 Recipient or Final-Recipient DSN field. 301 This address type has 3 forms (as defined in Section 3): utf-8-addr- 302 xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are 303 7-bit safe. 305 The utf-8-address form MUST NOT be used in the ORCPT parameter when 306 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 307 server supports UTF8SMTP, but the address contains US-ASCII 308 characters not permitted in the ORCPT parameter (e.g. the ORCPT 309 parameter forbids SP and =); or in a 7-bit transport environment 310 including a message/delivery-status Original-Recipient or Final- 311 Recipient field. The utf-8-addr-xtext form MUST be used instead in 312 the former case, the utf-8-addr-unitext form MUST be used in the 313 latter case. The utf-8-address form MAY be used in the ORCPT 314 parameter when the SMTP server also advertises support for UTF8SMTP 315 and the address doesn't contains any US-ASCII characters not 316 permitted in the ORCPT parameter; in a message/utf-8-delivery-status 317 Original-Recipient or Final-Recipient DSN field; or an Original- 318 Recipient header field [RFC3798] if the message is a UTF-8 header 319 message. 321 In addition, the utf-8-addr-unitext form can be used anywhere where 322 the utf-8-address form is allowed. 324 6.2. Update to 'smtp' Diagnostic Type Registration 326 The mail diagnostic type registry was created by RFC 3464. The 327 registration for the 'smtp' diagnostic type should be updated to 328 reference RFC XXXX in addition to RFC 3464. 330 When the 'smtp' diagnostic type is used in the context of a message/ 331 delivery-status body part, it remains as presently defined. When the 332 'smtp' diagnostic type is used in the context of a message/ 333 utf-8-delivery-status body part, the codes remain the same, but the 334 text portion MAY contain UTF-8 characters. 336 6.3. message/utf-8-headers 338 Type name: message 340 Subtype name: utf-8-headers 342 Required parameters: none 344 Optional parameters: none 346 Encoding considerations: This media type contains Internationalized 347 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 348 Whenever possible, the 8-bit content transfer encoding SHOULD be 349 used. When this media type passes through a 7-bit-only SMTP 350 infrastructure it MAY be encoded with the base64 or quoted- 351 printable content transfer encoding. 353 Security considerations: See Section 7 355 Interoperability considerations: It is important this media type is 356 not converted to a charset other than UTF-8. As a result, 357 implementations MUST NOT include a charset parameter with this 358 media type. Although it might be possible to downconvert this 359 media type to the text/rfc822-header media type, such conversion 360 is discouraged as it loses information. 362 Published specification: RFC XXXX 364 Applications that use this media type: UTF8SMTP servers and email 365 clients that support multipart/report generation or parsing. 367 Additional information: 369 Magic number(s): none 371 File extension(s): In the event this is saved to a file, the 372 extension ".u8hdr" is suggested. 374 Macintosh file type code(s): The 'TEXT' type code is suggested as 375 files of this type are typically used for diagnostic purposes and 376 suitable for analysis in a UTF-8 aware text editor. A uniform 377 type identifier (UTI) of "public.utf8-email-message-header" is 378 suggested. This type conforms to "public.utf8-plain-text" and 379 "public.plain-text". 381 Person & email address to contact for further information: See the 382 Author's address section of this document. 384 Intended usage: COMMON 386 Restrictions on usage: This media type contains textual data in the 387 UTF-8 charset. It typically contains octets with the 8th bit set. 388 As a result a transfer encoding is required when a 7-bit transport 389 is used. 391 Author: See Author's Address section of this document. 393 Change controller: IETF Standards Process 395 6.4. message/utf-8-delivery-status 397 Type name: message 399 Subtype name: utf-8-delivery-status 401 Required parameters: none 403 Optional parameters: none 404 Encoding considerations: This media type contains delivery status 405 notification attributes in the UTF-8 charset. The 8-bit content 406 transfer encoding MUST be used with this content-type, unless it 407 is sent over a 7-bit transport environment in which case quoted- 408 printable or base64 may be necessary. 410 Security considerations: See Section 7 412 Interoperability considerations: This media type provides 413 functionality similar to the message/delivery-status content type 414 for email message return information. Clients of the previous 415 format will need to be upgraded to interpret the new format, 416 however the new media type makes it simple to identify the 417 difference. 419 Published specification: RFC XXXX 421 Applications that use this media type: SMTP servers and email 422 clients that support delivery status notification generation or 423 parsing. 425 Additional information: 427 Magic number(s): none 429 File extension(s): The extension ".u8dsn" is suggested. 431 Macintosh file type code(s): A uniform type identifier (UTI) of 432 "public.utf8-email-message-delivery-status" is suggested. This 433 type conforms to "public.utf8-plain-text". 435 Person & email address to contact for further information: See the 436 Author's address section of this document. 438 Intended usage: COMMON 440 Restrictions on usage: This is expected to be the second part of a 441 multipart/report. 443 Author: See Author's Address section of this document. 445 Change controller: IETF Standards Process 447 6.5. message/utf-8-disposition-notification 448 Type name: message 450 Subtype name: utf-8-disposition-notification 452 Required parameters: none 454 Optional parameters: none 456 Encoding considerations: This media type contains disposition 457 notification attributes in the UTF-8 charset. The 8-bit content 458 transfer encoding MUST be used with this content-type, unless it 459 is sent over a 7-bit transport environment in which case quoted- 460 printable or base64 may be necessary. 462 Security considerations: See Section 7 464 Interoperability considerations: This media type provides 465 functionality similar to the message/disposition-notification 466 content type for email message disposition information. Clients 467 of the previous format will need to be upgraded to interpret the 468 new format, however the new media type makes it simple to identify 469 the difference. 471 Published specification: RFC XXXX 473 Applications that use this media type: Email clients or servers that 474 support message disposition notification generation or parsing. 476 Additional information: 478 Magic number(s): none 480 File extension(s): The extension ".u8mdn" is suggested. 482 Macintosh file type code(s): A uniform type identifier (UTI) of 483 "public.utf8-email-message-disposition-notification" is suggested. 484 This type conforms to "public.utf8-plain-text". 486 Person & email address to contact for further information: See the 487 Author's address section of this document. 489 Intended usage: COMMON 491 Restrictions on usage: This is expected to be the second part of a 492 multipart/report. 494 Author: See Author's Address section of this document. 496 Change controller: IETF Standards Process 498 7. Security Considerations 500 Automated use of report types without authentication presents several 501 security issues. Forging negative reports presents the opportunity 502 for denial-of-service attacks when the reports are used for automated 503 maintenance of directories or mailing lists. Forging positive 504 reports may cause the sender to incorrectly believe a message was 505 delivered when it was not. 507 Malicious users can generate report structures designed to trigger 508 coding flaws in report parsers. Report parsers need to use secure 509 coding techniques to avoid the risk of buffer overflow or denial-of- 510 service attacks against parser coding mistakes. Code reviews of such 511 parsers are also recommended. 513 Malicious users of the email system regularly send messages with 514 forged envelope return paths and these messages trigger delivery 515 status reports that result in a large amount of unwanted traffic on 516 the Internet. Many users choose to ignore delivery status 517 notifications because they are usually the result of "blowback" from 518 forged messages and thus never notice when messages they sent go 519 undelivered. As a result, support for correlation of delivery status 520 and message disposition notification messages with sent-messages has 521 become a critical feature of mail clients and possibly mail stores if 522 the email infrastructure is to remain reliable. In the short term, 523 simply correlating message-IDs may be sufficient to distinguish true 524 status notifications from those resulting from forged originator 525 addresses. But in the longer term, including cryptographic signature 526 material that can securely associate the status notification with the 527 original message is advisable. 529 As this specification permits UTF-8 in additional fields, the 530 security considerations of UTF-8 [RFC3629] apply. 532 8. References 534 8.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 540 April 2001. 542 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 543 Extension for Delivery Status Notifications (DSNs)", 544 RFC 3461, January 2003. 546 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 547 Reporting of Mail System Administrative Messages", 548 RFC 3462, January 2003. 550 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 551 for Delivery Status Notifications", RFC 3464, 552 January 2003. 554 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 555 10646", STD 63, RFC 3629, November 2003. 557 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 558 Notification", RFC 3798, May 2004. 560 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 561 Specifications: ABNF", RFC 4234, October 2005. 563 [I-D.ietf-eai-utf8headers] 564 Yang, A., "Internationalized Email Headers", 565 draft-ietf-eai-utf8headers-05 (work in progress), 566 April 2007. 568 [I-D.ietf-eai-smtpext] 569 Yao, J. and W. Mao, "SMTP extension for internationalized 570 email address", draft-ietf-eai-smtpext-05 (work in 571 progress), April 2007. 573 [I-D.ietf-eai-downgrade] 574 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 575 Email Address Internationalization (EAI)", 576 draft-ietf-eai-downgrade-03 (work in progress), Mar 2007. 578 8.2. Informative References 580 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 581 Extensions (MIME) Part One: Format of Internet Message 582 Bodies", RFC 2045, November 1996. 584 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 585 Extensions (MIME) Part Two: Media Types", RFC 2046, 586 November 1996. 588 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 589 4rev1", RFC 3501, March 2003. 591 Appendix A. Acknowledgements 593 Many thanks for input provided by Pete Resnick, James Galvin, Ned 594 Freed, John Klensin and members of the EAI WG to help solidify this 595 proposal. 597 Appendix B. Open Issues 599 Suggestion to change the utf-8-addr format from \-encoded Unicode to 600 \-encoded UTF-8 as used in URIs. 602 Use a single syntax for I18N addresses in ORCPT/DSN instead of two 603 (Chris) 605 Potential issue: an SMTP server can't deliver an EAI DSN to the next 606 hop - need to use a 7bit encoding, downgrade or discard? Need to 607 describe choices. 609 Tracker issue #1485: UTF8HDR 4.6/DSN: Choice of body part for 610 transport of UTF8SMTP messages 612 Tracker issue #1483: SMTPEXT 2.7: Non-ASCII in response texts 614 Appendix C. Changes from -00 616 Added paragraph about use of 8bit Content-Transfer-Encoding for new 617 message sub-types. 619 Updated the list of open issues. 621 Clarified that this document is targeted to become an Experimental 622 RFC. 624 Made the EAI downgrade document a normative reference. 626 Updated ABNF for utf-8-address. 628 Authors' Addresses 630 Chris Newman 631 Sun Microsystems 632 3401 Centrelake Dr., Suite 410 633 Ontario, CA 91761 634 US 636 Email: chris.newman@sun.com 638 Alexey Melnikov (editor) 639 Isode Ltd 640 5 Castle Business Village 641 36 Station Road 642 Hampton, Middlesex TW12 2BX 643 UK 645 Email: Alexey.Melnikov@isode.com 647 Full Copyright Statement 649 Copyright (C) The IETF Trust (2007). 651 This document is subject to the rights, licenses and restrictions 652 contained in BCP 78, and except as set forth therein, the authors 653 retain all their rights. 655 This document and the information contained herein are provided on an 656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 658 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 659 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 660 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 663 Intellectual Property 665 The IETF takes no position regarding the validity or scope of any 666 Intellectual Property Rights or other rights that might be claimed to 667 pertain to the implementation or use of the technology described in 668 this document or the extent to which any license under such rights 669 might or might not be available; nor does it represent that it has 670 made any independent effort to identify any such rights. Information 671 on the procedures with respect to rights in RFC documents can be 672 found in BCP 78 and BCP 79. 674 Copies of IPR disclosures made to the IETF Secretariat and any 675 assurances of licenses to be made available, or the result of an 676 attempt made to obtain a general license or permission for the use of 677 such proprietary rights by implementers or users of this 678 specification can be obtained from the IETF on-line IPR repository at 679 http://www.ietf.org/ipr. 681 The IETF invites any interested party to bring to its attention any 682 copyrights, patents or patent applications, or other proprietary 683 rights that may cover technology that may be required to implement 684 this standard. Please address the information to the IETF at 685 ietf-ipr@ietf.org. 687 Acknowledgment 689 Funding for the RFC Editor function is provided by the IETF 690 Administrative Support Activity (IASA).