Sieve: Internationalized Email
Open-Xchange OY
Lars Sonckin Kaari 12
02600
Espoo
Finland
stephan.bosch@open-xchange.com
General
sieve
eai
This document defines an extension to the Sieve language called "eai" which
adds full support for internationalized email.
Introduction
Many parts of the Sieve mail filtering language
such as strings and comments are already designed
primarily for use with the UTF-8 encoding , 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
. However, the Sieve language was conceived before the
Framework for Internationalized Email was finished,
which means that filtered email messages are still restricted to the
conventional Internet Message Format , which mainly means
that only the conventional US-ASCII email addresses can be used
. 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?]
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
when, and only when,
they appear in all capitals, as shown here.
Headers
The "eai" extension presented in this document does not alter the handling
of conventional Internet messages , 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
. In contrast, when the filtered message (or message part)
has content type "message/global" , 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 , which means that the Sieve tests in
which header fields are evaluated will never match when the provided header name
contains UTF-8 characters.
Addresses
Section 2.4.2.3 of defines a constrained version of
the US-ASCII email address format defined in , section 3
for use in the Sieve language. The address format defined in
is amended by , section 3.2,
which adds internationalization support. The "eai" extension amends the Sieve
language such that the changes in , 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 ,
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?]
Modified commands
Test address
Refer to section for changes to the email
address format.
[FIXME: Any other changes?]
Test header
Refer to section for changes to the email
header field format.
FIXME: Any other changes?
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 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 when the Sieve "eai" extension is
active. It SHOULD also do so when that extension is not active.
Modified extensions
Body Extension
The Sieve "body" extension 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.
Convert Extension
[FIXME: Investigate RFC6558]
[FIXME: Define a conversion for downgrade?]
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 with these actions.
Specifically, if the specified field value does not match the
"unstructured" nonterminal syntax element, the
implementation MUST either flag an error or encode the field using the
encodings described in or to
be compliant with . In contrast, when the filtered message
has content type "message/global" , the "addheader"
action MUST NOT use the encodings described in or
. Instead, it MUST write header values in UTF-8
encoding .
Envelope Extension
Refer to section for changes to the email
address format.
[FIXME: Any other changes?]
Enotify Extension
The Sieve "enotify" extension provides generic
support for sending instant notifications. Using the specific "mailto"
notification method , notifications can be
sent as an email message.
The "mailto" method is defined to use "mailto" URIs as specified in
, which is now obsolete. The Sieve "eai" extension
updates the Sieve "mailto" notification method to use the updated "mailto" URI
format instead , which adds better
internationalization and compatibility with Internationalized Resource
Identifiers .
[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 .
Reject and Extended Reject Extensions
The Sieve "reject" and "ereject" extensions
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 . The format and rules for such notifications
are updated by the Framework for Internationalized Email
in . When the Sieve "eai"
extension is also active, any DSN messages sent by the "reject" and "ereject"
actions MUST additionally adhere to .
[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?]
Mime Extension
[FIXME: Investigate RFC5703]
Replace Extension
[FIXME: Investigate RFC5703]
Enclose Extension
[FIXME: Investigate RFC5703]
Other Extensions?
[FIXME: Any other extensions that need to be addressed?]
Downgrading
[FIXME: any words about downgrading and Sieve? RFC6530, RFC6858]
Mailing lists
[FIXME: Any mailing list EAI considerations in Sieve? RFC6783]
Examples
[FIXME: provide some]
Acknowledgements
[TBD; Reviews and comments are welcome.]
IANA Considerations
[FIXME: extension definitions]
Security Considerations
[FIXME: provide some]
References
Normative References
An Extensible Message Format for Delivery Status Notifications
Internet Message Format
Internationalized Resource Identifiers (IRIs)
The 'mailto' URI Scheme
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
Overview and Framework for Internationalized Email
SMTP Extension for Internationalized Email
Internationalized Email Headers
Internationalized Delivery Status and Disposition Notifications
Sieve: An Email Filtering Language
Sieve Email Filtering: Body Extension
Sieve Email Filtering: Extension for Notifications
Sieve Notification Mechanism: mailto
Sieve Email Filtering: Reject and Extended Reject Extensions
Simple Mail Transfer Protocol
UTF-8, a transformation format of ISO 10646
Informative References
The mailto URL scheme