Internet-Draft Sieve: Internationalized Email May 2021
Bosch Expires 26 November 2021 [Page]
Network Working Group
Intended Status:
Standards Track
S. Bosch
Open-Xchange OY

Sieve: Internationalized Email


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

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.

Table of Contents

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 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 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

Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, , <>.
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <>.
Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, , <>.
Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, , <>.
Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, , <>.
Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, , <>.
Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, , <>.
Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, , <>.
Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, , <>.
Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, , <>.
Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, , <>.
Degener, J. and P. Guenther, "Sieve Email Filtering: Body Extension", RFC 5173, DOI 10.17487/RFC5173, , <>.
Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, DOI 10.17487/RFC5435, , <>.
Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, DOI 10.17487/RFC5436, , <>.
Stone, A., Ed., "Sieve Email Filtering: Reject and Extended Reject Extensions", RFC 5429, DOI 10.17487/RFC5429, , <>.
Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, , <>.
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <>.

13.2. Informative References

Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, DOI 10.17487/RFC2368, , <>.

Author's Address

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