Internet DRAFT - draft-bosch-sieve-eai
draft-bosch-sieve-eai
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
