draft-ietf-extra-sieve-fcc.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'
[
<!ENTITY rfc2119 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2045 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY rfc2046 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml'>
<!ENTITY rfc2047 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2047.xml'>
<!ENTITY rfc2231 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2231.xml'>
<!ENTITY rfc5228 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5228.xml'>
<!ENTITY rfc5230 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5230.xml'>
<!ENTITY rfc5232 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5232.xml'>
<!ENTITY rfc5234 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY rfc5321 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml'>
<!ENTITY rfc5322 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml'>
<!ENTITY rfc5429 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5429.xml'>
<!ENTITY rfc5435 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5435.xml'>
<!ENTITY rfc5436 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5436.xml'>
<!ENTITY rfc5437 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5437.xml'>
<!ENTITY rfc5490 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5490.xml'>
<!ENTITY rfc6131 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6131.xml'>
<!ENTITY rfc7942 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml'>
<!ENTITY rfc8174 PUBLIC ''
'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'>
<!ENTITY idSpecialUse PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-extra-sieve-special-use.xml'>
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<rfc category="std" ipr='trust200902'
     updates="5230, 5435"
     docName='draft-ietf-extra-sieve-fcc-09'>
  <front>
    <title abbrev="Sieve Fcc">Sieve Extension: File Carbon Copy (Fcc)</title>
    <author initials="K." surname="Murchison" fullname="Kenneth Murchison">
      <organization abbrev="FastMail">FastMail US LLC</organization>
      <address>
        <postal>
          <street>1429 Walnut Street - Suite 1201</street>
          <city>Philadelphia</city> <region>PA</region>
          <code>19102</code> <country>USA</country>
        </postal>
        <email>murch@fastmailteam.com</email>
      </address>
    </author>

    <author initials="B." surname="Gondwana" fullname="Bron Gondwana">
      <organization abbrev="FastMail">FastMail Pty Ltd</organization>
      <address>
        <postal>
          <street>Level 2, 114 William Street</street>
          <city>Melbourne</city> <region>VIC</region>
          <code>3000</code> <country>Australia</country>
        </postal>
        <email>brong@fastmailteam.com</email>
      </address>
    </author>

    <date />

    <area>ART</area>
    <workgroup>EXTRA</workgroup>

    <keyword>Sieve</keyword>
    <keyword>Vacation</keyword>
    <keyword>Notify</keyword>
    <abstract>
      <t>The Sieve Email Filtering Language provides a number of
      action commands, some of which can generate additional messages
      on behalf of the user.  This document defines an extension to
      such commands to allow a copy of any generated message to be
      filed into a target mailbox.</t>

      <t>This document updates RFC5230 and RFC5435 by adding a new
      tagged argument to the "vacation" and "enotify" actions
      respectively.</t>
    </abstract>
  </front>

  <middle>
    <section title='Introduction'>
      <t>The <xref target='RFC5228'>Sieve Email Filtering
      Language</xref> provides a number of action commands, some of
      which can generate additional messages on behalf of the user.
      It is sometimes desirable for a Sieve user to maintain an
      archive of the messages generated by these commands.</t>

      <t>This extension defines a new optional tagged argument ":fcc"
      to action commands that generate additional messages to allow a
      copy of the generated message to be filed into a target
      mailbox.</t>

      <t>The capability string associated with this extension is
      "fcc".</t>

      <t>Each new action that generates additional messages will need to
      specify how it interacts with :fcc. This document
      specifies the interaction of :fcc with the
      <xref target='RFC5230'>Vacation</xref> and
      <xref target='RFC5435'>Notify</xref> extensions.</t> 

    </section>

    <section title='Conventions Used in This Document'>
      <t>Conventions for notations are as in Section 1.1 of <xref
      target='RFC5228'/>, including use of the "Usage:" label for the
      definition of action and tagged arguments syntax.</t>

      <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
      <eref target="https://tools.ietf.org/html/bcp14">BCP 14</eref>
      <xref target='RFC2119' /> <xref target='RFC8174' /> 
      when, and only when, they appear in all capitals, as shown here.</t>

    </section>  <!-- Intro -->
    
    <section title='Tagged Argument ":fcc"' anchor='fcc'>

      <t>This document specifies a new optional tagged argument ":fcc"
      that alters the behavior of action commands that generate
      additional messages on behalf of the user.</t>

      <figure>
        <artwork><![CDATA[
Usage: :fcc <mailbox: string>
]]></artwork>
      </figure>

      <t>The :fcc tagged argument instructs the Sieve interpreter to
      file a copy of the generated message into the mailbox provided
      in the subsequent argument.
      The semantics and treatment of the mailbox argument are defined
      to match
      those of the mailbox argument to the "fileinto" action specified
      in Section 4.1 of <xref target='RFC5228' />.
      Specifically, use of an invalid mailbox name MAY be treated as
      an error or result in delivery to an implementation-defined
      mailbox, and if the specified mailbox doesn't exist, the
      implementation MAY treat it as an error, create the mailbox, or
      file the message into an implementation-defined mailbox.</t>

      <section title='Interaction with Fileinto Extensions'
               anchor='fileinto'>

        <t>Some tagged arguments defined in extensions to the
        "fileinto" action can be used together with ":fcc".
        The sections below describe these interactions.
        Tagged arguments in future extensions to the "fileinto" action 
        need to describe their interaction with ":fcc", if any.</t>

        <t>When any "fileinto" extension arguments are used with
        ":fcc", the corresponding extension MUST be enabled,
        and the arguments are defined to have the same syntax,
        semantics, and treatment as they do with "fileinto".</t>

        <section title='Imap4flags Extension' anchor='imap4flags'>

          <t>This document extends the definition of the ":flags"
          tagged argument (see Section 5 of <xref target='RFC5232'/>)
          so that it can optionally be used with the ":fcc" argument.</t>

          <figure>
            <artwork><![CDATA[
Usage: :fcc <mailbox: string> [:flags <list-of-flags: string-list>]
]]></artwork>
          </figure>

          <t>If the optional ":flags" argument is specified with
          ":fcc", it instructs the Sieve interpreter to set the IMAP4
          flags provided in the subsequent argument when the generated
          message is filed into the target mailbox.</t> 

        </section> <!-- imapflags -->

        <section title='Mailbox Extension' anchor='mailbox'>

          <t>This document extends the definition of the ":create"
          tagged argument (see Section 3.2 of <xref target='RFC5490' />) 
          so that it can optionally be used with the ":fcc" argument.</t>

          <figure>
            <artwork><![CDATA[
Usage: :fcc <mailbox: string> [:create]
]]></artwork>
          </figure>

          <t>If the optional ":create" argument is specified with
          ":fcc", it instructs the Sieve interpreter to create the
          target mailbox, if needed, before attempting to file the
          generated message into the target mailbox.</t>

        </section> <!-- mailbox -->

        <section title='Special-Use Extension' anchor='specialuse'>

          <t>This document extends the definition of the ":specialuse"
          tagged argument (see Section 4 of
          <xref target='I-D.ietf-extra-sieve-special-use' />)
          so that it can optionally be used with the ":fcc" argument.</t>

          <figure>
            <artwork><![CDATA[
Usage: :fcc <mailbox: string> [:specialuse <special-use-flag: string>]
]]></artwork>
          </figure>

          <t>If the optional ":specialuse" argument is specified with
          ":fcc", it instructs the Sieve interpreter to check whether
          a mailbox exists with the specific special-use flag assigned
          to it.  If such a mailbox exists, the generated message is filed
          into the special-use mailbox.  Otherwise, the generated message
          is filed into the target mailbox.</t>

          <t>If both the optional ":specialuse" and ":create"
          arguments are specified with ":fcc", the Sieve interpreter
          is instructed to create the target mailbox per Section 4.1
          of <xref target='I-D.ietf-extra-sieve-special-use'/>, if
          needed.</t>

        </section> <!-- specialuse -->

      </section> <!-- fileinto -->

      <section title='Collected Grammar' anchor='grammar'>
        <t>For convenience, the "FCC" syntax element is
        defined here using <xref target='RFC5234'>ABNF</xref>
        so that it can be augmented by other extensions.</t>

        <t>Note that the following is the grammar of "FCC" after it has
        been lexically interpreted.  No whitespace or comments appear
        below.</t>

          <figure>
          <artwork><![CDATA[
FCC         = ":fcc" string *FCC-OPTS
                ; per Section 2.6.2 of RFC5228,
                ; the tagged arguments in FCC may appear in any order

FCC-OPTS    = CREATE / IMAP-FLAGS / SPECIAL-USE
                ; each option MUST NOT appear more than once

CREATE      = ":create"
IMAP-FLAGS  = ":flags" string-list
SPECIAL-USE = ":specialuse" string
]]></artwork>
        </figure>

      </section> <!-- grammar -->

    </section> <!-- fcc -->

    <section title='Format of File Carbon Copied Messages'
             anchor='format'>

      <t>Copies of messages filed into a mailbox via this extension
      are REQUIRED to be in <xref target="RFC5322">Internet Message
      Format</xref>.  Some messages generated by Sieve actions might
      already conform to this format and MAY be filed without
      modification.  Messages generated in other formats MUST be
      encapsulated using constructs from <xref target="RFC5322"/>
      and MIME (<xref target="RFC2045"/>, <xref target="RFC2046"/>,
      <xref target="RFC2047"/>, <xref target="RFC2231"/>).</t>

      <t>The general requirements for encapsulating the copies of
      messages to be filed are the following:

      <list style='symbols'>
        <t>Date: The Date header field is REQUIRED and SHOULD
        be set to the date and time when the message was
        generated.</t>

        <t>From: The From header field is REQUIRED and SHOULD
        be set to the email address of the owner of the Sieve
        script, unless explicitly overridden by rules for
        encapsulating a particular message type.</t>

        <t>To: The To header field is OPTIONAL and MAY be set
        to the email address of the recipient of the generated
        message, if available.</t>

        <t>Subject: The Subject header field is OPTIONAL and
        MAY be generated as follows: The subject is set to the
        characters "Fcc: " followed by the subject of the message
        being processed by the Sieve interpreter.</t>

        <t>In-Reply-To: The In-Reply-To header field is OPTIONAL
        and MAY be set to the Message-ID of the message being
        processed by the Sieve interpreter.</t>

        <t>Message Body: The body of the filed message is REQUIRED
        and is composed of one or more MIME-parts containing
        the generated message and any related metadata.  The
        Content-Type header field(s) MUST be set to the
        appropriate MIME types.  If any of the MIME-parts include
        8-bit or binary data, the Content-Transfer-Encoding header
        field(s) MUST be set accordingly.</t>
      </list>
      </t>

    </section> <!-- format -->

    <section title='Interaction with the Vacation Action'
             anchor='vacation'>

      <t>This document extends the
      <xref target="RFC5230">"vacation"</xref> action (see also
      <xref target="RFC6131">"vacation-seconds"</xref>) to
      optionally store a copy of the auto-reply messages into a
      target mailbox.</t>

      <figure>
        <artwork><![CDATA[
Usage:   vacation [FCC]
                  [":days" number | ":seconds" number]
                  [":subject" string]
                  [":from" string]
                  [":addresses" string-list]
                  [":mime"]
                  [":handle" string]
                  <reason: string>
]]></artwork>
      </figure>

      <figure>
        <preamble>Example (with fileinto extensions):</preamble>
        <artwork><![CDATA[
require ["vacation", "fcc", "mailbox", "special-use", "imap4flags"];

vacation :days 7
         :from "hemingway@example.com" "Gone Fishin'"
         :specialuse "\\Sent" :create
         :fcc "INBOX.Sent" :flags ["\\Seen"];
                           
]]></artwork>
      </figure>

      <t>Vacation auto-reply messages are MIME-compliant and can be
      filed into the target mailbox without modification.</t>

    </section> <!-- vacation -->

    <section title='Interaction with the Notify Action'
             anchor='notify'>

      <t>This document extends the
      <xref target="RFC5435">"notify"</xref> action to optionally
      store a copy of the notification messages into a target
      mailbox.</t>

      <figure>
        <artwork><![CDATA[
Usage:   notify [FCC]
                [":from" string]
                [":importance" <"1" / "2" / "3">]
                [":options" string-list]
                [":message" string]
                <method: string>
]]></artwork>
      </figure>

      <figure>
        <preamble>Example:</preamble>
        <artwork><![CDATA[
require ["enotify", "fcc"];

notify :fcc "INBOX.Sent"
       :message "You got mail!"
       "mailto:ken@example.com";
]]></artwork>
      </figure>

      <t>Messages generated using the
      <xref target='RFC5436'>"mailto"</xref> notification method are
      MIME-compliant and can be filed into the target mailbox without
      modification.</t>

      <t>Messages generated by other notification methods (e.g. <xref
      target="RFC5437">"xmpp"</xref>) MUST be encapsulated per
      <xref target="format"/> before being filed.  The body of the
      filed message MUST include the :message parameter and MAY
      include one or more of the :from, :importance, or :options
      parameters.  The MIME-type(s) of the body part(s) used to
      encapsulate the parameters is an implementation decision.</t>

      <t>An implementation MAY only support :fcc in conjunction with a
      subset of the notification methods it supports.  An error occurs
      if :fcc is combined with a notification method that doesn't
      support it.  Notification methods that support :fcc can be
      discovered at run-time using the mechanism <xref
      target='method-capa'>described below</xref>.</t>

      <section title='Notification-Capability "fcc"'
               anchor='method-capa'>
        <t>This document defines a new notification-capability value
        "fcc" for use with the notify_method_capability test (see
        Section 5 of <xref target='RFC5435'/>.  For the "fcc"
        notification-capability, the notify_method_capability test can
        match one of the following key-list values:

          <list style='hanging'>
            <t hangText="yes">A copy of the notification message sent
            using the method identified by the notification-uri can be
            filed into a target mailbox.</t>

            <t hangText="no">A copy of the notification message sent
            using the method identified by the notification-uri can
            not be filed into a target mailbox.</t>
          </list>

          Note that the "fcc" notify_method_capability test does not
          require the notification-uri argument to specify anything
          other than a scheme.

          <figure>
            <preamble>Example:</preamble>
            <artwork><![CDATA[
require ["enotify", "fcc"];

if notify_method_capability "xmpp:" "fcc" "yes" {
    notify :fcc "INBOX.Sent"
           :message "You got mail"
           "xmpp:ken@example.com?message;subject=SIEVE";
} else {
    notify :fcc "INBOX.Sent"
           :message "You got mail!"
           "mailto:ken@example.com";
}
]]></artwork>
          </figure>
        </t>
      </section>  <!-- notification-capability -->

    </section> <!-- notify -->

    <section title='Compatibility with the Reject and Extended Reject
                    Actions' anchor='reject'>

      <t>Implementations MUST NOT allow use of "fcc" with the 
      <xref target='RFC5429'>"reject" and "ereject"</xref> actions.
      Allowing "fcc" with these actions would violate the <xref
      target='RFC5321'>SMTP</xref> principle that a message is
      either delivered or bounced back to the sender.  Namely, the
      saved copy of the rejection message will contain the original
      message.</t>

      <t>It is an error for a script to use the ":fcc" tagged
      argument with either "reject" or "ereject".</t>

    </section>

    <section title='Compatibility with Other Actions'
             anchor='other'>

      <t>The "fcc" extension is not compatible with any Sieve action
      that does not generate an additional message on behalf of the
      user.
      It is an error for a script to use the ":fcc" tagged argument
      with any such action.</t>

      <t>Future extensions that define actions that generate
      additional messages on behalf of the user need to describe
      their compatibility with ":fcc", and how to MIME-encapsulate
      the message, if required.</t>

    </section> <!-- other -->
<!--
    <section title='Extended Example' anchor='example'>

      <figure>
        <artwork><![CDATA[
require ["vacation", "fcc", "mailbox", "special-use", "imap4flags"];

vacation :days 7
         :from "hemingway@example.com" "Gone Fishin'"
         :fcc "INBOX.Sent" :specialuse "\\Sent" :create
         :flags ["\\Seen"];
]]></artwork>
      </figure>

    </section>
-->
    <section title="Implementation Status" anchor="impl">

      <t>&lt; RFC Editor: before publication please remove this section
	and the reference to <xref target="RFC7942"/> &gt;</t>

      <t>This section records the status of known implementations of
	the protocol defined by this specification at the time of
	posting of this Internet-Draft, and is based on a proposal
	described in <xref target="RFC7942"/>.  The
	description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing
	drafts to RFCs.  Please note that the listing of any
	individual implementation here does not imply endorsement by
	the IETF.  Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF
	contributors.  This is not intended as, and must not be
	construed to be, a catalog of available implementations or
	their features.  Readers are advised to note that other
	implementations may exist.</t>

	<t>According to <xref target="RFC7942"/>,
	"this will allow reviewers and working groups to assign due
	consideration to documents that have the benefit of running
	code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented
	protocols more mature.  It is up to the individual working
	groups to use this information as they see fit".</t>

      <section title="Cyrus Server" anchor="cyrus" toc="exclude">
	<t>The open source <eref
	target="http://www.cyrusimap.org/">Cyrus Server</eref> project
        is a highly scalable enterprise mail system which supports
	Sieve email filtering at the point of final delivery.  This
        production level Sieve implementation supports all of the
        requirements described in this document.  This implementation
        is freely distributable under a BSD style license from
	<eref target="http://www.cmu.edu/computing/">
          Computing Services at Carnegie Mellon University</eref>.</t>
      </section>

      <section title="Oracle Communications Messaging Server"
               anchor="oracle" toc="exclude">
	<t>The <eref
	target="https://www.oracle.com/industries/communications/enterprise/products/messaging-server/index.html">
        Oracle Communications Messaging Server</eref> is a
        highly scalable, reliable, and available messaging platform.
        This production level product supports the :fcc extension in
        conjunction with both the notify and vacation extensions.
        The implementation meets all the requirements given in this
        document.
        The product also supports the imap4flags extension so the
        :flags may be used in conjunction :fcc.</t>
      </section>

    </section> <!-- Implementations -->

    <section title='Security Considerations' anchor='security'>
      <t>In addition to the security considerations in
      <xref target='RFC5228'/>, <xref target='RFC5230'/>,
      <xref target='RFC5435'/>, and <xref target='RFC6131'/>,
      it should be noted that filing copies of generated messages may
      cause the Sieve script owner to exceed their allocated storage
      (quota) on the mail system, thereby preventing delivery of
      future messages destined for the owner.</t>
    </section>

    <section title='Privacy Considerations' anchor='privacy'>
      <t>In addition to the privacy considerations in
      <xref target='RFC5228'/>, <xref target='RFC5230'/>,
      <xref target='RFC5435'/>, and <xref target='RFC6131'/>,
      it should be noted that a copy of a generated message filed into
      a shared or public maibox (as opposed to a private mailbox)
      could expose private information about the Sieve script owner to
      third parties.  For instance, users that have access to the
      shared/public mailbox might discover that the Sieve script owner
      is on holiday or might discover the owner's physical location.</t>
    </section>

    <section title='IANA Considerations'>

      <section title="Registration of Sieve Extension">
	<t>
	  <list style='empty'>
	    <t>To: iana@iana.org</t>
	    <t>Subject: Registration of new Sieve extension</t>
	    <t>Capability name: fcc</t>
	    <t>Description: Adds the ":fcc" parameter to Sieve action
            commands that generate additional messages.</t>
	    <t>RFC number: RFC XXXX</t>
	    <t>Contact address: The Sieve discussion list
            &lt;sieve@ietf.org&gt;</t>
	  </list>
	</t>
      </section>

      <section title="Registration of Notification-Capability
                      Parameter">
        <t>
          <list style='empty'>
            <t>To: iana@iana.org</t>
            <t>Subject:  Registration of a new notification-capability
            parameter</t>
            <t>Capability name: fcc</t>
            <t>Description: Returns whether a copy of the notification
            message sent using the method identified by the
            notification-uri parameter to the notify_method_capability
            test can be filed into a target mailbox.</t>
            <t>Syntax:  Can contain one of two values: "yes" or "no".
            Values MUST be in lowercase.</t>
            <t>Permanent and readily available reference(s):  This RFC</t>
            <t>Contact information:  The Sieve discussion list
            &lt;ietf-mta-filters@imc.org&gt;</t>
          </list>
        </t>
      </section>

    </section> <!-- IANA -->

    <section title='Acknowledgments'>
      <t>The authors would like to thank the following individuals for
      contributing their ideas and support for writing this
      specification: Ned Freed, Stan Kalisch, and Alexey Melnikov.</t>
    </section>

  </middle>

  <back>
    <references title='Normative References'>
      &rfc2119;
      &rfc2045;
      &rfc2046;
      &rfc2047;
      &rfc2231;
      &rfc5228;
      &rfc5230;
      &rfc5232;
      &rfc5234;
      &rfc5322;
      &rfc5429;
      &rfc5435;
      &rfc5490;
      &rfc8174;
      &idSpecialUse;
    </references>

    <references title='Informative References'>
      &rfc5321;
      &rfc5436;
      &rfc5437;
      &rfc6131;
      &rfc7942;
    </references>

    <section title="Change History (To be removed by RFC Editor before
                    publication)">
      <t>Changes since draft-ietf-extra-sieve-fcc-08:
      <list style='symbols'>
        <t>Introduced additional security and privacy considerations.</t>
        <t>Reintroduced text describing incompatibility with [e]reject.</t>
        <t>Reverted to RFC 5228 fileinto language regarding
        invalid/non-existent FCC mailbox.</t>
        <t>Editorial changes from IESG review.</t>
        <t>Editorial changes from Gen-ART review.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-07:
      <list style='symbols'>
        <t>Added comments regarding FCC ABNF per Alexey Melnikov.</t>
        <t>Reordered arguments in the "vacation" example to show ":fcc"
        appearing amongst FCC-OPTS.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-06:
      <list style='symbols'>
        <t>Reorganized sections.</t>
        <t>Switched to using proper ABNF for FCC and fileinto extensions.</t>
        <t>Fcc into INBOX if specified target mailbox doesn't exist.</t>
        <t>Editorial changes from Alexey Melnikov.</t>
        <t>Other minor editorial changes.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-05:
      <list style='symbols'>
        <t>Editorial changes from Jiankang Yao.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-04:
      <list style='symbols'>
        <t>Editorial changes from Ned Freed.</t>
        <t>Added information on Oracle implementation.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-03:
      <list style='symbols'>
        <t>Fixed typo in ABNF.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-02:
      <list style='symbols'>
        <t>Updated Keywords boilerplate.</t>
        <t>Noted that :fcc mailbox argument and any fileinto extension
        arguments used wth :fcc have the same syntax and semantics as
        they have with fileinto.</t>
        <t>Removed section on [e]Reject.</t>
        <t>Added "fcc" notification-capability.</t>
        <t>Added Implementation Status section.</t>
        <t>Editorial changes from Ned Freed.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-01: 
      <list style='symbols'>
        <t>Added text discussing how to handle generated messages that
        are not in MIME format.</t>

        <t>Adjusted ABNF so that tagged arguments that supplement :fcc
        no longer appear as positional.</t>
      </list>
      </t>

      <t>Changes since draft-ietf-extra-sieve-fcc-00: 
      <list style='symbols'>
        <t>Updated abstract with text from Ned.</t>
        <t>Added support for :fcc to notify extension.</t>
        <t>Prohibit use of :fcc with reject and ereject extensions.</t>
        <t>Added registration of the extension with IANA.</t>
        <t>Added Acknowledgments.</t>
        <t>Minor editorial changes.</t>
      </list>
      </t>
    </section>

  </back>
</rfc>