idnits 2.17.1 draft-bosch-sieve-eai-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 417 lines 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 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). -- The document date (21 March 2020) is 1495 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) == Missing Reference: 'MIMEPARAM' is mentioned on line 212, but not defined -- Obsolete informational reference (is this intentional?): RFC 2368 (ref. 'URI-MAILTO') (Obsoleted by RFC 6068) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bosch 3 Internet-Draft Dovecot Oy 4 Intended status: Standards Track 21 March 2020 5 Expires: 22 September 2020 7 Sieve: Internationalized Email 8 draft-bosch-sieve-eai-00 10 Abstract 12 This document defines an extension to the Sieve language called "eai" 13 which adds full support for internationalized email. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 22 September 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction 49 2. Conventions Used in This Document 50 3. Headers 51 4. Addresses 52 5. Modified commands 53 5.1. Test address 54 5.2. Test header 55 5.3. Action redirect 56 6. Modified extensions 57 6.1. Body Extension 58 6.2. Convert Extension 59 6.3. Editheader Extension 60 6.4. Envelope Extension 61 6.5. Enotify Extension 62 6.6. Reject and Extended Reject Extensions 63 6.7. Mime Extension 64 6.8. Replace Extension 65 6.9. Enclose Extension 66 6.10. Other Extensions? 67 7. Downgrading 68 8. Mailing lists 69 9. Examples 70 10. Acknowledgements 71 11. IANA Considerations 72 12. Security Considerations 73 13. References 74 13.1. Normative References 75 13.2. Informative References 76 Author's Address 78 1. Introduction 80 Many parts of the Sieve mail filtering language [SIEVE] such as 81 strings and comments are already designed primarily for use with the 82 UTF-8 encoding [UTF-8] , thereby supporting all the international 83 characters specified by the Unicode standard. Also, Sieve can 84 already work with message header fields that contain UTF-8 85 characters, provided these are encoded using MIME encoded-word 86 [MIME3]. However, the Sieve language was conceived before the 87 Framework for Internationalized Email [RFC6530] was finished, which 88 means that filtered email messages are still restricted to the 89 conventional Internet Message Format [IMAIL], which mainly means that 90 only the conventional US-ASCII email addresses can be used [SMTP]. 91 This poses problems for using the Sieve language in a mail system 92 where internationalized email is to be supported. 94 This document defines an extension to the Sieve language called "eai" 95 which adds full support for internationalized email. 97 [FIXME: Any ideas for a better name for the extension?] 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in 105 all capitals, as shown here. 107 3. Headers 109 The "eai" extension presented in this document does not alter the 110 handling of conventional Internet messages [IMAIL], which have 111 content type "message/rfc822". For such conventional messages, it 112 expects UTF-8 characters in header field values to be encoded using 113 MIME encoded-words [MIME3]. In contrast, when the filtered message 114 (or message part) has content type "message/global" [RFC6532], the 115 header field value can contain UTF-8 characters directly and MIME 116 encoded-words SHOULD NOT be interpreted. 118 Note that internationalized email header names are still restricted 119 to ASCII characters only [RFC6532], which means that the Sieve tests 120 in which header fields are evaluated will never match when the 121 provided header name contains UTF-8 characters. 123 4. Addresses 125 Section 2.4.2.3 of [SIEVE] defines a constrained version of the US- 126 ASCII email address format defined in [IMAIL], section 3 for use in 127 the Sieve language. The address format defined in [IMAIL] is amended 128 by [RFC6532], section 3.2, which adds internationalization support. 129 The "eai" extension amends the Sieve language such that the changes 130 in [RFC6532], section 3.2 also apply to the syntax of address values 131 used in Sieve. Without the "eai" extension, only conventional 132 addresses are recognized. 134 When the "eai" extension is active, the domain part of an email 135 address used in Sieve MUST be evaluated as an U-Label as defined in 136 [RFC5890], section 2.3.2.1. This means that both the domain and 137 localpart of the email address are always evaluated as a string 138 encoded in UTF-8. 140 [FIXME: Do we want to provide a special address part tag for 141 evaluating the domain in A-label format instead?] 143 5. Modified commands 145 5.1. Test address 147 Refer to section Section 4 for changes to the email address format. 149 [FIXME: Any other changes?] 151 5.2. Test header 153 Refer to section Section 3 for changes to the email header field 154 format. 156 FIXME: Any other changes? 158 5.3. Action redirect 160 The Sieve "redirect" action is used to send the message to another 161 user at a supplied address. The only real change that the Sieve 162 "eai" extension introduces for the "redirect" action is that the 163 address parameter will support internationalized email address 164 values. When such an internationalized address is used, it will need 165 to use the SMTPUTF8 capability [RFC6531] in the SMTP session . 167 The "redirect" action may add headers to the message. When it amends 168 a message that has "message/global" content type, it MUST use the 169 header field format described in [RFC6531] when the Sieve "eai" 170 extension is active. It SHOULD also do so when that extension is not 171 active. 173 6. Modified extensions 175 6.1. Body Extension 177 The Sieve "body" extension [SIEVE-BODY] adds the "body" test. It 178 tests for the occurrence of one or more strings in the body of an 179 email message. Prior to matching content in a message body, 180 transformations can be applied that filter and decode certain parts 181 of the body. These transformations are selected by a body transform 182 keyword parameter. If the body transform is ":content", the MIME 183 parts that have the specified content types are matched against 184 independently. If the :content specification matches a "message/ 185 rfc822" MIME part, only the header of the nested message will be 186 searched for the key strings, treating the header as a single string; 187 the contents of the nested message body parts are only searched if 188 their content type matches the :content specification. The Sieve 189 "eai" extension modifies the ":content" transform of the "body" test 190 to handle a "message/global" part the same as a "message/rfc822" 191 part, as described above. 193 6.2. Convert Extension 195 [FIXME: Investigate RFC6558] 197 [FIXME: Define a conversion for downgrade?] 199 6.3. Editheader Extension 201 The Sieve "editheader" extension adds the "addheader" and 202 "deleteheader" actions. The "addheader" action adds a header field 203 to the filtered message and the "deleteheader" action can delete 204 header fields. The "eai" extension presented in this document does 205 not alter the processing of conventional Internet messages [IMAIL] 206 with these actions. Specifically, if the specified field value does 207 not match the [IMAIL] "unstructured" nonterminal syntax element, the 208 implementation MUST either flag an error or encode the field using 209 the encodings described in [MIME3] or [MIMEPARAM] to be compliant 210 with [IMAIL]. In contrast, when the filtered message has content 211 type "message/global" [RFC6532], the "addheader" action MUST NOT use 212 the encodings described in [MIME3] or [MIMEPARAM]. Instead, it MUST 213 write header values in UTF-8 encoding [UTF-8]. 215 6.4. Envelope Extension 217 Refer to section Section 4 for changes to the email address format. 219 [FIXME: Any other changes?] 221 6.5. Enotify Extension 223 The Sieve "enotify" extension [SIEVE-NOTIFY] provides generic support 224 for sending instant notifications. Using the specific "mailto" 225 notification method [SIEVE-NOTIFY-MAILTO], notifications can be sent 226 as an email message. 228 The "mailto" method is defined to use "mailto" URIs as specified in 229 [URI-MAILTO], which is now obsolete. The Sieve "eai" extension 230 updates the Sieve "mailto" notification method to use the updated 231 "mailto" URI format instead [IRI-MAILTO], which adds better 232 internationalization and compatibility with Internationalized 233 Resource Identifiers [IRI]. 235 [FIXME: Unfortunately, even the last mailto URI specification 236 predates RFC653x, which means that no support is available for 237 internationalized email addresses. Do we need to update the mailto 238 URI specificiation, or am I missing an RFC?] 240 If one of the targets of the "mailto" notification method is an 241 internationalized e-mail address, the produced notification message 242 MUST be a "message/global" message, as specified by [RFC6532]. 244 6.6. Reject and Extended Reject Extensions 246 The Sieve "reject" and "ereject" extensions [SIEVE-REJECT] 247 respectively add the "reject" and "ereject" actions. These actions 248 both cancel the implicit keep and refuse delivery of a message. One 249 of the options for notifying the sender about the failure is sending 250 back a Delivery Status Notification [DSN]. The format and rules for 251 such notifications are updated by the Framework for Internationalized 252 Email [RFC6530] in [RFC6533]. When the Sieve "eai" extension is also 253 active, any DSN messages sent by the "reject" and "ereject" actions 254 MUST additionally adhere to [RFC6533]. 256 [FIXME: When the rejection message is shown in SMTP/LMTP reply, can 257 we rely upon SMTPUTF8 to send UTF-8 messages there as well, thereby 258 making the difference between reject and ereject mostly 259 insignificant?] 261 6.7. Mime Extension 263 [FIXME: Investigate RFC5703] 265 6.8. Replace Extension 267 [FIXME: Investigate RFC5703] 269 6.9. Enclose Extension 271 [FIXME: Investigate RFC5703] 273 6.10. Other Extensions? 275 [FIXME: Any other extensions that need to be addressed?] 277 7. Downgrading 279 [FIXME: any words about downgrading and Sieve? RFC6530, RFC6858] 281 8. Mailing lists 283 [FIXME: Any mailing list EAI considerations in Sieve? RFC6783] 285 9. Examples 287 [FIXME: provide some] 289 10. Acknowledgements 291 [TBD; Reviews and comments are welcome.] 293 11. IANA Considerations 295 [FIXME: extension definitions] 297 12. Security Considerations 299 [FIXME: provide some] 301 13. References 303 13.1. Normative References 305 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 306 for Delivery Status Notifications", RFC 3464, 307 DOI 10.17487/RFC3464, January 2003, 308 . 310 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 311 DOI 10.17487/RFC5322, October 2008, 312 . 314 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 315 Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, 316 January 2005, . 318 [IRI-MAILTO] 319 Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 320 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 321 . 323 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997, 325 . 327 [KEYWORDS-UPD] 328 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 329 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 330 May 2017, . 332 [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 333 Part Three: Message Header Extensions for Non-ASCII Text", 334 RFC 2047, DOI 10.17487/RFC2047, November 1996, 335 . 337 [MIMEPARAM]Freed, N. and K. Moore, "MIME Parameter Value and Encoded 338 Word Extensions: Character Sets, Languages, and 339 Continuations", RFC 2231, DOI 10.17487/RFC2231, November 340 1997, . 342 [RFC5890] Klensin, J., "Internationalized Domain Names for 343 Applications (IDNA): Definitions and Document Framework", 344 RFC 5890, DOI 10.17487/RFC5890, August 2010, 345 . 347 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 348 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 349 February 2012, . 351 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 352 Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, 353 . 355 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 356 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 357 2012, . 359 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, 360 "Internationalized Delivery Status and Disposition 361 Notifications", RFC 6533, DOI 10.17487/RFC6533, February 362 2012, . 364 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 365 Language", RFC 5228, January 2008, 366 . 368 [SIEVE-BODY] 369 Degener, J. and P. Guenther, "Sieve Email Filtering: Body 370 Extension", RFC 5173, DOI 10.17487/RFC5173, April 2008, 371 . 373 [SIEVE-NOTIFY] 374 Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 375 Martin, "Sieve Email Filtering: Extension for 376 Notifications", RFC 5435, DOI 10.17487/RFC5435, January 377 2009, . 379 [SIEVE-NOTIFY-MAILTO] 380 Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 381 mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009, 382 . 384 [SIEVE-REJECT] 385 Stone, A., Ed., "Sieve Email Filtering: Reject and 386 Extended Reject Extensions", RFC 5429, 387 DOI 10.17487/RFC5429, March 2009, 388 . 390 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 391 DOI 10.17487/RFC5321, October 2008, 392 . 394 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 395 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 396 2003, . 398 13.2. Informative References 400 [URI-MAILTO] 401 Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 402 URL scheme", RFC 2368, DOI 10.17487/RFC2368, July 1998, 403 . 405 Author's Address 407 Dovecot Oy 408 Stephan Bosch 409 Lars Sonckin Kaari 16 410 FI-02600 Espoo 411 Finland 413 Email: stephan.bosch@dovecot.fi