Network Working Group S. Bosch Internet-Draft Open-Xchange OY Intended status: Standards Track 25 May 2021 Expires: 26 November 2021 Sieve: Internationalized Email draft-bosch-sieve-eai-01 Abstract This document defines an extension to the Sieve language called "eai" which adds full support for internationalized email. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 November 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Conventions Used in This Document 3. Headers 4. Addresses 5. Modified commands 5.1. Test address 5.2. Test header 5.3. Action redirect 6. Modified extensions 6.1. Body Extension 6.2. Convert Extension 6.3. Editheader Extension 6.4. Envelope Extension 6.5. Enotify Extension 6.6. Reject and Extended Reject Extensions 6.7. Mime Extension 6.8. Replace Extension 6.9. Enclose Extension 6.10. Other Extensions? 7. Downgrading 8. Mailing lists 9. Examples 10. Acknowledgements 11. IANA Considerations 12. Security Considerations 13. References 13.1. Normative References 13.2. Informative References Author's Address 1. Introduction Many parts of the Sieve mail filtering language [SIEVE] such as strings and comments are already designed primarily for use with the UTF-8 encoding [UTF-8] , thereby supporting all the international characters specified by the Unicode standard. Also, Sieve can already work with message header fields that contain UTF-8 characters, provided these are encoded using MIME encoded-word [MIME3]. However, the Sieve language was conceived before the Framework for Internationalized Email [RFC6530] was finished, which means that filtered email messages are still restricted to the conventional Internet Message Format [IMAIL], which mainly means that only the conventional US-ASCII email addresses can be used [SMTP]. This poses problems for using the Sieve language in a mail system where internationalized email is to be supported. This document defines an extension to the Sieve language called "eai" which adds full support for internationalized email. [FIXME: Any ideas for a better name for the extension?] 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in all capitals, as shown here. 3. Headers The "eai" extension presented in this document does not alter the handling of conventional Internet messages [IMAIL], which have content type "message/rfc822". For such conventional messages, it expects UTF-8 characters in header field values to be encoded using MIME encoded-words [MIME3]. In contrast, when the filtered message (or message part) has content type "message/global" [RFC6532], the header field value can contain UTF-8 characters directly and MIME encoded-words SHOULD NOT be interpreted. Note that internationalized email header names are still restricted to ASCII characters only [RFC6532], which means that the Sieve tests in which header fields are evaluated will never match when the provided header name contains UTF-8 characters. 4. Addresses Section 2.4.2.3 of [SIEVE] defines a constrained version of the US- ASCII email address format defined in [IMAIL], section 3 for use in the Sieve language. The address format defined in [IMAIL] is amended by [RFC6532], section 3.2, which adds internationalization support. The "eai" extension amends the Sieve language such that the changes in [RFC6532], section 3.2 also apply to the syntax of address values used in Sieve. Without the "eai" extension, only conventional addresses are recognized. When the "eai" extension is active, the domain part of an email address used in Sieve MUST be evaluated as an U-Label as defined in [RFC5890], section 2.3.2.1. This means that both the domain and localpart of the email address are always evaluated as a string encoded in UTF-8. [FIXME: Do we want to provide a special address part tag for evaluating the domain in A-label format instead?] 5. Modified commands 5.1. Test address Refer to section Section 4 for changes to the email address format. [FIXME: Any other changes?] 5.2. Test header Refer to section Section 3 for changes to the email header field format. FIXME: Any other changes? 5.3. Action redirect The Sieve "redirect" action is used to send the message to another user at a supplied address. The only real change that the Sieve "eai" extension introduces for the "redirect" action is that the address parameter will support internationalized email address values. When such an internationalized address is used, it will need to use the SMTPUTF8 capability [RFC6531] in the SMTP session . The "redirect" action may add headers to the message. When it amends a message that has "message/global" content type, it MUST use the header field format described in [RFC6531] when the Sieve "eai" extension is active. It SHOULD also do so when that extension is not active. 6. Modified extensions 6.1. Body Extension The Sieve "body" extension [SIEVE-BODY] adds the "body" test. It tests for the occurrence of one or more strings in the body of an email message. Prior to matching content in a message body, transformations can be applied that filter and decode certain parts of the body. These transformations are selected by a body transform keyword parameter. If the body transform is ":content", the MIME parts that have the specified content types are matched against independently. If the :content specification matches a "message/ rfc822" MIME part, only the header of the nested message will be searched for the key strings, treating the header as a single string; the contents of the nested message body parts are only searched if their content type matches the :content specification. The Sieve "eai" extension modifies the ":content" transform of the "body" test to handle a "message/global" part the same as a "message/rfc822" part, as described above. 6.2. Convert Extension [FIXME: Investigate RFC6558] [FIXME: Define a conversion for downgrade?] 6.3. Editheader Extension The Sieve "editheader" extension adds the "addheader" and "deleteheader" actions. The "addheader" action adds a header field to the filtered message and the "deleteheader" action can delete header fields. The "eai" extension presented in this document does not alter the processing of conventional Internet messages [IMAIL] with these actions. Specifically, if the specified field value does not match the [IMAIL] "unstructured" nonterminal syntax element, the implementation MUST either flag an error or encode the field using the encodings described in [MIME3] or [MIMEPARAM] to be compliant with [IMAIL]. In contrast, when the filtered message has content type "message/global" [RFC6532], the "addheader" action MUST NOT use the encodings described in [MIME3] or [MIMEPARAM]. Instead, it MUST write header values in UTF-8 encoding [UTF-8]. 6.4. Envelope Extension Refer to section Section 4 for changes to the email address format. [FIXME: Any other changes?] 6.5. Enotify Extension The Sieve "enotify" extension [SIEVE-NOTIFY] provides generic support for sending instant notifications. Using the specific "mailto" notification method [SIEVE-NOTIFY-MAILTO], notifications can be sent as an email message. The "mailto" method is defined to use "mailto" URIs as specified in [URI-MAILTO], which is now obsolete. The Sieve "eai" extension updates the Sieve "mailto" notification method to use the updated "mailto" URI format instead [IRI-MAILTO], which adds better internationalization and compatibility with Internationalized Resource Identifiers [IRI]. [FIXME: Unfortunately, even the last mailto URI specification predates RFC653x, which means that no support is available for internationalized email addresses. Do we need to update the mailto URI specificiation, or am I missing an RFC?] If one of the targets of the "mailto" notification method is an internationalized e-mail address, the produced notification message MUST be a "message/global" message, as specified by [RFC6532]. 6.6. Reject and Extended Reject Extensions The Sieve "reject" and "ereject" extensions [SIEVE-REJECT] respectively add the "reject" and "ereject" actions. These actions both cancel the implicit keep and refuse delivery of a message. One of the options for notifying the sender about the failure is sending back a Delivery Status Notification [DSN]. The format and rules for such notifications are updated by the Framework for Internationalized Email [RFC6530] in [RFC6533]. When the Sieve "eai" extension is also active, any DSN messages sent by the "reject" and "ereject" actions MUST additionally adhere to [RFC6533]. [FIXME: When the rejection message is shown in SMTP/LMTP reply, can we rely upon SMTPUTF8 to send UTF-8 messages there as well, thereby making the difference between reject and ereject mostly insignificant?] 6.7. Mime Extension [FIXME: Investigate RFC5703] 6.8. Replace Extension [FIXME: Investigate RFC5703] 6.9. Enclose Extension [FIXME: Investigate RFC5703] 6.10. Other Extensions? [FIXME: Any other extensions that need to be addressed?] 7. Downgrading [FIXME: any words about downgrading and Sieve? RFC6530, RFC6858] 8. Mailing lists [FIXME: Any mailing list EAI considerations in Sieve? RFC6783] 9. Examples [FIXME: provide some] 10. Acknowledgements [TBD; Reviews and comments are welcome.] 11. IANA Considerations [FIXME: extension definitions] 12. Security Considerations [FIXME: provide some] 13. References 13.1. Normative References [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, . [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, . [IRI-MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, . [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [KEYWORDS-UPD] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, . [MIMEPARAM]Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, . [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, . [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, . [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, . [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008, . [SIEVE-BODY] Degener, J. and P. Guenther, "Sieve Email Filtering: Body Extension", RFC 5173, DOI 10.17487/RFC5173, April 2008, . [SIEVE-NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, DOI 10.17487/RFC5435, January 2009, . [SIEVE-NOTIFY-MAILTO] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009, . [SIEVE-REJECT] Stone, A., Ed., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, DOI 10.17487/RFC5429, March 2009, . [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . 13.2. Informative References [URI-MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, DOI 10.17487/RFC2368, July 1998, . Author's Address Open-Xchange OY Stephan Bosch Lars Sonckin Kaari 12 FI-02600 Espoo Finland Email: stephan.bosch@open-xchange.com