<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  consensus="true"
  docName="draft-bosch-sieve-eai-01"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  tocInclude="true"
  tocDepth="4"
  symRefs="true"
  sortRefs="true"
  version="3">

<!-- ***** FRONT MATTER ***** -->
<front>

<title abbrev="Sieve: Internationalized Email">Sieve: Internationalized Email</title>

<author fullname="Stephan Bosch" initials="S." surname="Bosch">
  <organization>Open-Xchange OY</organization>
  <address>
    <postal>
    <street>Lars Sonckin Kaari 12</street>
    <code>02600</code>
    <city>Espoo</city>
    <country>Finland</country>
    </postal>
    <email>stephan.bosch@open-xchange.com</email>
  </address>
</author>

<area>General</area>
<keyword>sieve</keyword>
<keyword>eai</keyword>

<abstract>
<t>This document defines an extension to the Sieve language called "eai" which
adds full support for internationalized email.</t>
</abstract>
</front>

<!-- ***** CONTENT ***** -->
<middle>

<!-- Introduction -->
<section numbered="true" toc="default">
<name>Introduction</name>
<t>Many parts of the Sieve mail filtering language
<xref target="SIEVE"/> such as strings and comments are already designed
primarily for use with the UTF-8 encoding <xref target="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
<xref target="MIME3"/>. However, the Sieve language was conceived before the
Framework for Internationalized Email <xref target="RFC6530"/>  was finished,
which means that filtered email messages are still restricted to the
conventional Internet Message Format <xref target="IMAIL"/>, which mainly means
that only the conventional US-ASCII email addresses can be used
<xref target="SMTP"/>. This poses problems for using the Sieve language in a
mail system where internationalized email is to be supported.</t>
<t>This document defines an extension to the Sieve language called "eai" which
adds full support for internationalized email.</t>
<t>[FIXME: Any ideas for a better name for the extension?]</t>
</section>

<!-- Conventions Used in This Document -->
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>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&nbsp;14
<xref target="KEYWORDS"/> <xref target="KEYWORDS-UPD"/> when, and only when,
they appear in all capitals, as shown here. </t>
</section>

<section numbered="true" toc="default" anchor="sec-headers">
<name>Headers</name>
<t>The "eai" extension presented in this document does not alter the handling
of conventional Internet messages <xref target="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
<xref target="MIME3"/>. In contrast, when the filtered message (or message part)
has content type "message/global" <xref target="RFC6532"/>, the header field
value can contain UTF-8 characters directly and MIME encoded-words SHOULD NOT be
interpreted.</t>
<t>Note that internationalized email header names are still restricted to ASCII
characters only <xref target="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.</t>
</section>

<section numbered="true" toc="default" anchor="sec-addresses">
<name>Addresses</name>
<t>Section 2.4.2.3 of <xref target="SIEVE"/> defines a constrained version of
the US-ASCII email address format defined in <xref target="IMAIL"/>, section 3
for use in the Sieve language. The address format defined in
<xref target="IMAIL"/> is amended by <xref target="RFC6532"/>, section 3.2,
which adds internationalization support. The "eai" extension amends the Sieve
language such that the changes in <xref target="RFC6532"/>, section 3.2 also
apply to the syntax of address values used in Sieve. Without the "eai"
extension, only conventional addresses are recognized.</t>
<t>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 <xref target="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.
</t>
<t>[FIXME: Do we want to provide a special address part tag for evaluating the
domain in A-label format instead?]</t>
</section>

<section numbered="true" toc="default">
<name>Modified commands</name>

<section numbered="true" toc="default">
<name>Test address</name>
<t>Refer to section <xref target="sec-addresses"/> for changes to the email
address format.</t>
<t>[FIXME: Any other changes?]</t>
</section>

<section numbered="true" toc="default">
<name>Test header</name>
<t>Refer to section <xref target="sec-headers"/> for changes to the email
header field format.</t>
<t>FIXME: Any other changes?</t>
</section>

<section numbered="true" toc="default">
<name>Action redirect</name>
<t>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 <xref target="RFC6531"/> in
the SMTP session .</t>
<t>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 <xref target="RFC6531"/> when the Sieve "eai" extension is
active. It SHOULD also do so when that extension is not active.
</t>
</section>
</section>

<section numbered="true" toc="default">
<name>Modified extensions</name>

<section numbered="true" toc="default">
<name>Body Extension</name>
<t>The Sieve "body" extension <xref target="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.</t>
</section>

<section numbered="true" toc="default">
<name>Convert Extension</name>
<t>[FIXME: Investigate RFC6558]</t>
<t>[FIXME: Define a conversion for downgrade?]</t>
</section>

<section numbered="true" toc="default">
<name>Editheader Extension</name>
<t>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 <xref target="IMAIL"/> with these actions.
Specifically, if the specified field value does not match the
<xref target="IMAIL"/> "unstructured" nonterminal syntax element, the
implementation MUST either flag an error or encode the field using the
encodings described in <xref target="MIME3"/> or <xref target="MIMEPARAM"/> to
be compliant with <xref target="IMAIL"/>. In contrast, when the filtered message
has content type "message/global" <xref target="RFC6532"/>, the "addheader"
action MUST NOT use the encodings described in <xref target="MIME3"/> or
<xref target="MIMEPARAM"/>. Instead, it MUST write header values in UTF-8
encoding <xref target="UTF-8"/>.</t>
</section>

<section numbered="true" toc="default">
<name>Envelope Extension</name>
<t>Refer to section <xref target="sec-addresses"/> for changes to the email
address format.</t>
<t>[FIXME: Any other changes?]</t>
</section>

<section numbered="true" toc="default">
<name>Enotify Extension</name>
<t>The Sieve "enotify" extension <xref target="SIEVE-NOTIFY"/> provides generic
support for sending instant notifications. Using the specific "mailto"
notification method <xref target="SIEVE-NOTIFY-MAILTO"/>, notifications can be
sent as an email message.</t>
<t>The "mailto" method is defined to use "mailto" URIs as specified in
<xref target="URI-MAILTO"/>, which is now obsolete. The Sieve "eai" extension
updates the Sieve "mailto" notification method to use the updated "mailto" URI
format instead <xref target="IRI-MAILTO"/>, which adds better
internationalization and compatibility with Internationalized Resource
Identifiers  <xref target="IRI"/>.</t>
<t>[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?]</t>
<t>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 <xref target="RFC6532"/>.</t>
</section>

<section numbered="true" toc="default">
<name>Reject and Extended Reject Extensions</name>
<t>The Sieve "reject" and "ereject" extensions <xref target="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 <xref target="DSN"/>. The format and rules for such notifications
are updated by the Framework for Internationalized Email
<xref target="RFC6530"/> in <xref target="RFC6533"/>. When the Sieve "eai"
extension is also active, any DSN messages sent by the "reject" and "ereject"
actions MUST additionally adhere to <xref target="RFC6533"/>.</t>
<t>[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?]</t>
</section>

<section numbered="true" toc="default">
<name>Mime Extension</name>
<t>[FIXME: Investigate RFC5703]</t>
</section>

<section numbered="true" toc="default">
<name>Replace Extension</name>
<t>[FIXME: Investigate RFC5703]</t>
</section>

<section numbered="true" toc="default">
<name>Enclose Extension</name>
<t>[FIXME: Investigate RFC5703]</t>
</section>

<section numbered="true" toc="default">
<name>Other Extensions?</name>
<t>[FIXME: Any other extensions that need to be addressed?]</t>
</section>


</section>

<section numbered="true" toc="default">
<name>Downgrading</name>
<t>[FIXME: any words about downgrading and Sieve? RFC6530, RFC6858]</t>
</section>

<section numbered="true" toc="default">
<name>Mailing lists</name>
<t>[FIXME: Any mailing list EAI considerations in Sieve? RFC6783]</t>
</section>

<section numbered="true" toc="default">
<name>Examples</name>
<t>[FIXME: provide some]</t>
</section>

<!-- Acknowledgements -->
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>[TBD; Reviews and comments are welcome.]</t>
</section>

<!-- IANA Considerations -->
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>[FIXME: extension definitions]</t>
</section>

<!-- Security considerations -->
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>[FIXME: provide some]</t>
</section>

</middle>

<!-- ***** BACK MATTER ***** -->
<back>

<!-- References split into informative and normative -->
<references>
  <name>References</name>
  <references>
    <name>Normative References</name>

    <reference  anchor='DSN' target='https://www.rfc-editor.org/info/rfc3464'>
      <front>
      <title>An Extensible Message Format for Delivery Status Notifications</title>
      <author initials='K.' surname='Moore' fullname='K. Moore'><organization /></author>
      <author initials='G.' surname='Vaudreuil' fullname='G. Vaudreuil'><organization /></author>
      <date year='2003' month='January' />
      </front>
      <seriesInfo name='RFC' value='3464'/>
      <seriesInfo name='DOI' value='10.17487/RFC3464'/>
    </reference>

    <reference  anchor='IMAIL' target='https://www.rfc-editor.org/info/rfc5322'>
      <front>
      <title>Internet Message Format</title>
      <author initials='P.' surname='Resnick' fullname='P. Resnick' role='editor'><organization /></author>
      <date year='2008' month='October' />
      </front>
      <seriesInfo name='RFC' value='5322'/>
      <seriesInfo name='DOI' value='10.17487/RFC5322'/>
    </reference>

    <reference anchor='IRI' target='https://www.rfc-editor.org/info/rfc3987'>
      <front>
      <title>Internationalized Resource Identifiers (IRIs)</title>
      <author initials='M.' surname='Duerst' fullname='M. Duerst'><organization /></author>
      <author initials='M.' surname='Suignard' fullname='M. Suignard'><organization /></author>
      <date year='2005' month='January' />
      </front>
      <seriesInfo name='RFC' value='3987'/>
      <seriesInfo name='DOI' value='10.17487/RFC3987'/>
    </reference>

    <reference  anchor='IRI-MAILTO' target='https://www.rfc-editor.org/info/rfc6068'>
      <front>
      <title>The 'mailto' URI Scheme</title>
      <author initials='M.' surname='Duerst' fullname='M. Duerst'><organization /></author>
      <author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
      <author initials='J.' surname='Zawinski' fullname='J. Zawinski'><organization /></author>
      <date year='2010' month='October' />
      </front>
      <seriesInfo name='RFC' value='6068'/>
      <seriesInfo name='DOI' value='10.17487/RFC6068'/>
    </reference>

    <reference anchor='KEYWORDS'>
      <front>
      <title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
      <author initials='S.' surname='Bradner' fullname='Scott Bradner'>
      <organization>Harvard University</organization>
      <address>
        <postal>
          <street>1350 Mass. Ave.</street>
          <street>Cambridge</street>
          <street>MA 02138</street>
        </postal>
        <phone>- +1 617 495 3864</phone>
        <email>sob@harvard.edu</email>
      </address>
      </author>
      <date year='1997' month='March' />
      <area>General</area>
      <keyword>keyword</keyword>
      </front>
      <seriesInfo name='BCP' value='14' />
      <seriesInfo name='RFC' value='2119' />
      <format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
      <format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
      <format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
    </reference>

    <reference  anchor='KEYWORDS-UPD' target='https://www.rfc-editor.org/info/rfc8174'>
      <front>
      <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
      <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
      <date year='2017' month='May' />
      </front>
      <seriesInfo name='BCP' value='14'/>
      <seriesInfo name='RFC' value='8174'/>
      <seriesInfo name='DOI' value='10.17487/RFC8174'/>
    </reference>

    <reference  anchor='MIME3' target='https://www.rfc-editor.org/info/rfc2047'>
      <front>
      <title>MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
      <author initials='K.' surname='Moore' fullname='K. Moore'><organization /></author>
      <date year='1996' month='November' />
      </front>
      <seriesInfo name='RFC' value='2047'/>
      <seriesInfo name='DOI' value='10.17487/RFC2047'/>
    </reference>

    <reference  anchor='MIMEPARAM' target='https://www.rfc-editor.org/info/rfc2231'>
      <front>
      <title>MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
      <author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
      <author initials='K.' surname='Moore' fullname='K. Moore'><organization /></author>
      <date year='1997' month='November' />
      </front>
      <seriesInfo name='RFC' value='2231'/>
      <seriesInfo name='DOI' value='10.17487/RFC2231'/>
    </reference>

    <reference  anchor='RFC5890' target='https://www.rfc-editor.org/info/rfc5890'>
    <front>
    <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
    <author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
    <date year='2010' month='August' />
    </front>
    <seriesInfo name='RFC' value='5890'/>
    <seriesInfo name='DOI' value='10.17487/RFC5890'/>
    </reference>

    <reference anchor='RFC6530' target='https://www.rfc-editor.org/info/rfc6530'>
      <front>
      <title>Overview and Framework for Internationalized Email</title>
      <author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
      <author initials='Y.' surname='Ko' fullname='Y. Ko'><organization /></author>
      <date year='2012' month='February' />
      </front>
      <seriesInfo name='RFC' value='6530'/>
      <seriesInfo name='DOI' value='10.17487/RFC6530'/>
    </reference>

    <reference  anchor='RFC6531' target='https://www.rfc-editor.org/info/rfc6531'>
    <front>
    <title>SMTP Extension for Internationalized Email</title>
    <author initials='J.' surname='Yao' fullname='J. Yao'><organization /></author>
    <author initials='W.' surname='Mao' fullname='W. Mao'><organization /></author>
    <date year='2012' month='February' />
    </front>
    <seriesInfo name='RFC' value='6531'/>
    <seriesInfo name='DOI' value='10.17487/RFC6531'/>
    </reference>

    <reference  anchor='RFC6532' target='https://www.rfc-editor.org/info/rfc6532'>
      <front>
      <title>Internationalized Email Headers</title>
      <author initials='A.' surname='Yang' fullname='A. Yang'><organization /></author>
      <author initials='S.' surname='Steele' fullname='S. Steele'><organization /></author>
      <author initials='N.' surname='Freed' fullname='N. Freed'><organization /></author>
      <date year='2012' month='February' />
      </front>
      <seriesInfo name='RFC' value='6532'/>
      <seriesInfo name='DOI' value='10.17487/RFC6532'/>
    </reference>

    <reference  anchor='RFC6533' target='https://www.rfc-editor.org/info/rfc6533'>
      <front>
      <title>Internationalized Delivery Status and Disposition Notifications</title>
      <author initials='T.' surname='Hansen' fullname='T. Hansen' role='editor'><organization /></author>
      <author initials='C.' surname='Newman' fullname='C. Newman'><organization /></author>
      <author initials='A.' surname='Melnikov' fullname='A. Melnikov'><organization /></author>
      <date year='2012' month='February' />
      </front>
      <seriesInfo name='RFC' value='6533'/>
      <seriesInfo name='DOI' value='10.17487/RFC6533'/>
    </reference>

    <reference anchor='SIEVE'>
      <front>
      <title>Sieve: An Email Filtering Language</title>
      <author initials='P.' surname='Guenther' fullname='P. Guenther'>
      <organization /></author>
      <author initials='T.' surname='Showalter' fullname='T. Showalter'>
      <organization /></author>
      <date year='2008' month='January' />
      </front>
      <seriesInfo name='RFC' value='5228' />
      <format type='TXT' octets='87531' target='http://www.rfc-editor.org/rfc/rfc5228.txt' />
    </reference>

    <reference  anchor='SIEVE-BODY' target='https://www.rfc-editor.org/info/rfc5173'>
      <front>
      <title>Sieve Email Filtering: Body Extension</title>
      <author initials='J.' surname='Degener' fullname='J. Degener'><organization /></author>
      <author initials='P.' surname='Guenther' fullname='P. Guenther'><organization /></author>
      <date year='2008' month='April' />
      </front>
      <seriesInfo name='RFC' value='5173'/>
      <seriesInfo name='DOI' value='10.17487/RFC5173'/>
    </reference>

    <reference  anchor='SIEVE-NOTIFY' target='https://www.rfc-editor.org/info/rfc5435'>
      <front>
      <title>Sieve Email Filtering: Extension for Notifications</title>
      <author initials='A.' surname='Melnikov' fullname='A. Melnikov' role='editor'><organization /></author>
      <author initials='B.' surname='Leiba' fullname='B. Leiba' role='editor'><organization /></author>
      <author initials='W.' surname='Segmuller' fullname='W. Segmuller'><organization /></author>
      <author initials='T.' surname='Martin' fullname='T. Martin'><organization /></author>
      <date year='2009' month='January' />
      </front>
      <seriesInfo name='RFC' value='5435'/>
      <seriesInfo name='DOI' value='10.17487/RFC5435'/>
    </reference>

    <reference  anchor='SIEVE-NOTIFY-MAILTO' target='https://www.rfc-editor.org/info/rfc5436'>
      <front>
      <title>Sieve Notification Mechanism: mailto</title>
      <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
      <author initials='M.' surname='Haardt' fullname='M. Haardt'><organization /></author>
      <date year='2009' month='January' />
      </front>
      <seriesInfo name='RFC' value='5436'/>
      <seriesInfo name='DOI' value='10.17487/RFC5436'/>
    </reference>

    <reference  anchor='SIEVE-REJECT' target='https://www.rfc-editor.org/info/rfc5429'>
    <front>
    <title>Sieve Email Filtering: Reject and Extended Reject Extensions</title>
    <author initials='A.' surname='Stone' fullname='A. Stone' role='editor'><organization /></author>
    <date year='2009' month='March' />
    </front>
    <seriesInfo name='RFC' value='5429'/>
    <seriesInfo name='DOI' value='10.17487/RFC5429'/>
    </reference>

    <reference  anchor='SMTP' target='https://www.rfc-editor.org/info/rfc5321'>
      <front>
      <title>Simple Mail Transfer Protocol</title>
      <author initials='J.' surname='Klensin' fullname='J. Klensin'><organization /></author>
      <date year='2008' month='October' />
      </front>
      <seriesInfo name='RFC' value='5321'/>
      <seriesInfo name='DOI' value='10.17487/RFC5321'/>
    </reference>

    <reference  anchor='UTF-8' target='https://www.rfc-editor.org/info/rfc3629'>
      <front>
      <title>UTF-8, a transformation format of ISO 10646</title>
      <author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
      <date year='2003' month='November' />
      </front>
      <seriesInfo name='STD' value='63'/>
      <seriesInfo name='RFC' value='3629'/>
      <seriesInfo name='DOI' value='10.17487/RFC3629'/>
    </reference>

  </references>
  <references>
    <name>Informative References</name>

    <reference anchor='URI-MAILTO' target='https://www.rfc-editor.org/info/rfc2368'>
      <front>
      <title>The mailto URL scheme</title>
      <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
      <author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
      <author initials='J.' surname='Zawinski' fullname='J. Zawinski'><organization /></author>
      <date year='1998' month='July' />
      </front>
      <seriesInfo name='RFC' value='2368'/>
      <seriesInfo name='DOI' value='10.17487/RFC2368'/>
    </reference>

  </references>
</references>
</back>

</rfc>
