Sieve: Internationalized Email
draft-bosch-sieve-eai-01

Document Type Active Internet-Draft (individual)
Author Stephan Bosch 
Last updated 2021-05-25
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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,
              <https://www.rfc-editor.org/info/rfc3464>.

   [IMAIL]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [IRI]      Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987,
              January 2005, <https://www.rfc-editor.org/info/rfc3987>.

   [IRI-MAILTO]
              Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <https://www.rfc-editor.org/info/rfc6068>.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [KEYWORDS-UPD]
              Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc2047>.

   [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, <https://www.rfc-editor.org/info/rfc2231>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
              February 2012, <https://www.rfc-editor.org/info/rfc6530>.

   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
              <https://www.rfc-editor.org/info/rfc6531>.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.

   [RFC6533]  Hansen, T., Ed., Newman, C., and A. Melnikov,
              "Internationalized Delivery Status and Disposition
              Notifications", RFC 6533, DOI 10.17487/RFC6533, February
              2012, <https://www.rfc-editor.org/info/rfc6533>.

   [SIEVE]    Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", RFC 5228, January 2008,
              <https://www.rfc-editor.org/info/rfc5228>.

   [SIEVE-BODY]
              Degener, J. and P. Guenther, "Sieve Email Filtering: Body
              Extension", RFC 5173, DOI 10.17487/RFC5173, April 2008,
              <https://www.rfc-editor.org/info/rfc5173>.

   [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, <https://www.rfc-editor.org/info/rfc5435>.

   [SIEVE-NOTIFY-MAILTO]
              Leiba, B. and M. Haardt, "Sieve Notification Mechanism:
              mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009,
              <https://www.rfc-editor.org/info/rfc5436>.

   [SIEVE-REJECT]
              Stone, A., Ed., "Sieve Email Filtering: Reject and
              Extended Reject Extensions", RFC 5429,
              DOI 10.17487/RFC5429, March 2009,
              <https://www.rfc-editor.org/info/rfc5429>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

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,
              <https://www.rfc-editor.org/info/rfc2368>.

Author's Address

   Open-Xchange OY
   Stephan Bosch
   Lars Sonckin Kaari 12
   FI-02600 Espoo
   Finland

   Email: stephan.bosch@open-xchange.com