rfc9042.original.xml   rfc9042.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" --> <!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-ietf-extra-sieve-mailboxid-09"
submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/ <rfc version="3" ipr="trust200902" docName="draft-ietf-extra-sieve-mailboxid-09"
2001/XInclude" updates="5228" consensus="true"> number="9042" submissionType="IETF" category="std" consensus="true" xml:lang="e
n" xmlns:xi="http://www.w3.org/2001/XInclude" updates="5228" sortRefs="true" sym
Refs="true" tocInclude="true">
<front> <front>
<title abbrev="Sieve MAILBOXID">Sieve Email Filtering: delivery by mailboxid</ti <title abbrev="Sieve MAILBOXID">Sieve Email Filtering: Delivery by
tle><seriesInfo value="draft-ietf-extra-sieve-mailboxid-09" stream="IETF" status MAILBOXID</title>
="standard" name="Internet-Draft"></seriesInfo> <seriesInfo name="RFC" value="9042"/>
<author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana"> <author role="editor" initials="B." surname="Gondwana" fullname="Bron Gondwana">
<organization>Fastmail</organization><address><postal><street>Level 2, 114 Willi <organization>Fastmail</organization>
am St</street> <address>
<postal>
<extaddr>Level 2</extaddr>
<street>114 William St</street>
<city>Melbourne</city> <city>Melbourne</city>
<code>VIC 3000</code> <region>VIC</region>
<code>3000</code>
<country>Australia</country> <country>Australia</country>
</postal><email>brong@fastmailteam.com</email> </postal>
<email>brong@fastmailteam.com</email>
<uri>https://www.fastmail.com</uri> <uri>https://www.fastmail.com</uri>
</address></author> </address></author>
<date year="2021" month="March" day="16"></date> <date year="2021" month="June"></date>
<area>Applications</area> <area>Applications</area>
<workgroup>EXTRA</workgroup> <workgroup>EXTRA</workgroup>
<keyword>sieve</keyword> <keyword>sieve</keyword>
<keyword>email</keyword> <keyword>email</keyword>
<abstract> <abstract>
<t>The OBJECTID capability of the IMAP protocol (RFC8474) allows clients to <t>The OBJECTID capability of IMAP (RFC 8474) allows clients to
identify mailboxes by a unique identifier which survives rename.</t> identify mailboxes by a unique identifier that survives renaming.</t>
<t>This document extends the Sieve mail filtering language (RFC5228) to <t>This document extends the Sieve email filtering language (RFC 5228) to
allow using that same unique identifier as a target for fileinto rules, allow using that same unique identifier as a target for fileinto rules
and for testing the existance of mailboxes.</t> and for testing the existence of mailboxes.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"><name>Introduction</name> <section anchor="introduction"><name>Introduction</name>
<t><xref target="RFC5228"></xref> Sieve rules are sometimes created using graphi cal interfaces <t>Sieve rules <xref target="RFC5228"></xref> are sometimes created using graphi cal interfaces,
which allow users to select the mailbox to be used as a target for a rule.</t> which allow users to select the mailbox to be used as a target for a rule.</t>
<t>If that mailbox is renamed, the client may also update its internal <t>If that mailbox is renamed, the client may also update its internal
representation of the rule and update the sieve script to match, representation of the rule and update the Sieve script to match;
however this is a multi-step process and subject to partial failures. however, this is a multistep process and subject to partial failures.
Also, if the folder is renamed by a different mechanism (e.g. another Also, if the folder is renamed by a different mechanism (e.g., another
IMAP client) the rules will get out of sync.</t> IMAP client), the rules will get out of sync.</t>
<t>By telling &quot;fileinto&quot; to reference the immutable mailboxid specifie <t>By telling fileinto to reference the immutable MAILBOXID specified
d by <xref target="RFC8474"></xref>, using the extension specified herein, Sieve r
by <xref target="RFC8474"></xref>, using the extension specified herein, sieve r ules can
ules can continue to target the same mailbox, even if it gets renamed.</t>
continue to target the same mailbox even if it gets renamed.</t>
</section> </section>
<section anchor="conventions-used-in-this-document"><name>Conventions Used In Th <section anchor="conventions-used-in-this-document"><name>Conventions Used in Th
is Document</name> is Document</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <t>
quot;SHALL&quot;, &quot;SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
&quot;NOT RECOMMENDED&quot;, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref be interpreted as
> when, and only when, described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
they appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="sieve-capability-string"><name>Sieve capability string</name> <section anchor="sieve-capability-string"><name>Sieve Capability String</name>
<t>Scripts which use the following extensions MUST explicitly require <t>Scripts that use the extensions defined in this document <bcp14>MUST</bcp14>
the capability &quot;mailboxid&quot;.</t> explicitly require
the capability "mailboxid".</t>
<t>Example:</t> <t>Example:</t>
<artwork>require &quot;mailboxid&quot;; <sourcecode type=""><![CDATA[
</artwork> require "mailboxid";
]]></sourcecode>
</section> </section>
<section anchor="argument-mailboxid-to-command-fileinto"><name>Argument &quot;:m <section anchor="argument-mailboxid-to-command-fileinto">
ailboxid&quot; to Command &quot;fileinto&quot;</name> <name>Argument :mailboxid to Command fileinto</name>
<t>Normally, the &quot;fileinto&quot; command delivers the message in the mailbo <t>Normally, the fileinto command delivers the message in the mailbox
x
specified using its positional mailbox argument. However, if the specified using its positional mailbox argument. However, if the
optional &quot;:mailboxid&quot; argument is also specified, the &quot;fileinto&q uot; optional :mailboxid argument is also specified, the fileinto
command first checks whether a mailbox exists in the user's personal command first checks whether a mailbox exists in the user's personal
namespace <xref target="RFC2342"></xref> with the specified <xref target="RFC847 4"></xref> MAILBOXID.</t> namespace <xref target="RFC2342"></xref> with the specified MAILBOXID <xref targ et="RFC8474"></xref>.</t>
<t>If a matching mailbox is found, that mailbox is used for delivery.</t> <t>If a matching mailbox is found, that mailbox is used for delivery.</t>
<t>If there is no such mailbox, the &quot;fileinto&quot; action proceeds as it w <t>If there is no such mailbox, the fileinto action proceeds as it would
ould without the :mailboxid argument.</t>
without the &quot;:mailboxid&quot; argument.</t> <t>The tagged argument :mailboxid to fileinto consumes one additional token,
<t>The tagged argument <tt>:mailboxid</tt> to fileinto consumes one additional t a string containing the OBJECTID of the target mailbox.</t>
oken,
a string with the objectid of the mailbox to file into.</t>
<t>Example:</t> <t>Example:</t>
<artwork>require &quot;fileinto&quot;; <sourcecode type=""><![CDATA[
require &quot;mailboxid&quot;; require "fileinto";
require "mailboxid";
if header :contains [&quot;from&quot;] &quot;coyote&quot; { if header :contains ["from"] "coyote" {
fileinto :mailboxid &quot;F6352ae03-b7f5-463c-896f-d8b48ee3&quot; fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
&quot;INBOX.harassment&quot;; "INBOX.harassment";
} }
</artwork> ]]></sourcecode>
<section anchor="interaction-with-mailbox-extension"><name>Interaction with &quo <section anchor="interaction-with-mailbox-extension"><name>Interaction with Mail
t;mailbox&quot; extension</name> box Extension</name>
<t>For servers which also support the <xref target="RFC5490"></xref> mailbox ext <t>For servers that also support the mailbox extension defined in <xref target="
ension, if both the RFC5490"></xref>, if both the
&quot;:create&quot; and &quot;:mailboxid&quot; arguments are provided to a &quot :create and :mailboxid arguments are provided to a fileinto command and
;fileinto&quot; command and
no matching mailbox is found, then a new mailbox will be created.</t> no matching mailbox is found, then a new mailbox will be created.</t>
<t>This new mailbox will have the name specified by the positional mailbox <t>This new mailbox will have the name specified by the positional mailbox
argument ([RFC5228] section 4.1), however it will get a different mailboxid argument (<xref target="RFC5228" sectionFormat="comma" section="4.1"/>); however
(chosen by the server) rather than the one specified by the &quot;:mailboxid&quo , it will get a different MAILBOXID
t; (chosen by the server) rather than the one specified by the :mailboxid
argument to fileinto.</t> argument to fileinto.</t>
<t>Example:</t> <t>Example:</t>
<artwork>require &quot;fileinto&quot;; <sourcecode type=""><![CDATA[
require &quot;mailboxid&quot;; require "fileinto";
require &quot;mailbox&quot;; require "mailboxid";
require "mailbox";
fileinto :mailboxid &quot;Fnosuch&quot; fileinto :mailboxid "Fnosuch"
:create :create
&quot;INBOX.no-such-folder&quot;; "INBOX.no-such-folder";
# creates INBOX.no-such-folder, but it doesn't # creates INBOX.no-such-folder, but it doesn't
# get the &quot;Fnosuch&quot; mailboxid. # get the "Fnosuch" mailboxid.
</artwork> ]]></sourcecode>
</section> </section>
<section anchor="interaction-with-specialuse-extension"><name>Interaction with & <section anchor="interaction-with-specialuse-extension"><name>Interaction with S
quot;specialuse&quot; extension</name> pecial-Use Extension</name>
<t>For servers which also support <xref target="RFC8579"></xref> delivery to spe <t>For servers that also support delivery to special-use mailboxes <xref target=
cial-use mailboxes, "RFC8579"></xref>,
it is an error to specify both &quot;:mailboxid&quot; and &quot;:specialuse&quot it is an error to specify both :mailboxid and :specialuse in the same
; in the same
fileinto command.</t> fileinto command.</t>
<t>Advanced filtering based on both special-use and mailboxid can be <t>Advanced filtering based on both special-use and MAILBOXID can be
built with explicit &quot;specialuse_exists&quot; and &quot;mailboxidexists&quot built with explicit specialuse_exists and mailboxidexists tests.</t>
; tests.</t> <aside>
<t>Note to developers of sieve generation tools: it is advisable to use <t>Note to developers of Sieve generation tools:</t>
special-use rather than mailboxid when creating rules that are based <t>It is advisable to use
on a special-use purpose (e.g. delivery directly to the Junk folder special-use rather than MAILBOXID when creating rules that are based
on a special-use purpose (e.g., delivery directly to the Junk folder
based on a header that was added by a scanning agent earlier in the based on a header that was added by a scanning agent earlier in the
mailflow).</t> mail flow).</t>
</aside>
</section> </section>
</section> </section>
<section anchor="interaction-with-fcc-extension"><name>Interaction with &quot;fc <section anchor="interaction-with-fcc-extension"><name>Interaction with FCC Exte
c&quot; extension</name> nsion</name>
<t>This document extends the definition of the &quot;:fcc&quot; argument defined <t>This document extends the definition of the :fcc argument defined in
in <xref target="RFC8580"></xref> so that it can optionally be used with the :mailb
<xref target="RFC8580"></xref> so that it can optionally be used with the &quot; oxid
:mailboxid&quot; argument. The syntax for FCC is extended here using ABNF <xref target="RFC5234"
argument. The syntax for &quot;FCC&quot; is extended here using ABNF <xref targ ></xref>:</t>
et="RFC5234"></xref>:</t>
<artwork>MAILBOXID-OPT = &quot;:mailboxid&quot; objectid <sourcecode type="abnf"><![CDATA[
MAILBOXID-OPT = ":mailboxid" objectid
FCC-OPTS =/ MAILBOXID-OPT FCC-OPTS =/ MAILBOXID-OPT
</artwork> ]]></sourcecode>
<t>If the optional &quot;:mailboxid&quot; argument is specified with &quot;:fcc& <t>If the optional :mailboxid argument is specified with :fcc, it
quot;, it
instructs the Sieve interpreter to check whether a mailbox exists instructs the Sieve interpreter to check whether a mailbox exists
with the specific mailboxid. If such a mailbox exists, the generated with the specific MAILBOXID. If such a mailbox exists, the generated
message is filed into that mailbox. Otherwise, the generated message message is filed into that mailbox. Otherwise, the generated message
is filed into the &quot;:fcc&quot; target mailbox.</t> is filed into the :fcc target mailbox.</t>
<t>As with fileinto, it is an error to specify both &quot;:mailboxid&quot; <t>As with fileinto, it is an error to specify both :mailboxid
and &quot;:specialuse&quot; for the same fcc rule.</t> and :specialuse for the same fcc rule.</t>
<t>Example:</t> <t>Example:</t>
<artwork>require [&quot;enotify&quot;, &quot;fcc&quot;, &quot;mailboxid&quot;]; <sourcecode type=""><![CDATA[
notify :fcc &quot;INBOX.Sent&quot; require ["enotify", "fcc", "mailboxid"];
:mailboxid &quot;F6352ae03-b7f5-463c-896f-d8b48ee3&quot; notify :fcc "INBOX.Sent"
:message &quot;You got mail!&quot; :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
&quot;mailto:ken@example.com&quot;; :message "You got mail!"
</artwork> "mailto:ken@example.com";
]]></sourcecode>
</section> </section>
<section anchor="test-mailboxidexists"><name>Test &quot;mailboxidexists&quot;</n <section anchor="test-mailboxidexists"><name>Test mailboxidexists</name>
ame> <t>Usage: mailboxidexists &lt;mailbox-objectids: string-list&gt;</t>
<t>The &quot;mailboxidexists&quot; test is true if all mailboxes listed in the <t>The mailboxidexists test is true if every string argument provided is the MAI
&quot;mailboxids&quot; argument exist in the mailstore, and each allows the LBOXID of a mailbox that exists in the mailstore and that allows the user in who
user in whose context the Sieve script runs to &quot;deliver&quot; messages se context the Sieve script runs to deliver messages into it.</t>
into it. When the mailstore is an IMAP server, &quot;delivery&quot; of <t>When the mailstore is an IMAP server that also supports IMAP
messages is possible if:</t> Access Control List (ACL) <xref target="RFC4314"></xref>, delivery is allowed if
<t>a) the READ-WRITE response code is present for the mailbox (see the user has the 'p' or 'i' rights for the mailbox (see
Section 7.1 of <xref target="RFC3501"></xref>), if IMAP Access Control List ( <xref target="RFC4314" sectionFormat="of" section="5.2"/>).</t>
ACL) <t> When the mailstore is an IMAP server that does not support IMAP ACL, deliver
<xref target="RFC4314"></xref> is not supported by the server, or</t> y is allowed if the READ-WRITE response code is present for the mailbox when sel
<t>b) the user has 'p' or 'i' rights for the mailbox (see Section 5.2 ected by the user (see <xref target="RFC3501" sectionFormat="of" section="7.1"/>
of <xref target="RFC4314"></xref>).</t> ).</t>
<t>Note that a successful &quot;mailboxidexists&quot; test for a mailbox doesn't <t>Note that a successful mailboxidexists test for a mailbox doesn't
necessarily mean that a &quot;fileinto :mailboxid&quot; action on this mailbox necessarily mean that a &quot;fileinto :mailboxid&quot; action on this mailbox
would succeed. For example, the &quot;fileinto&quot; action might put user over would succeed. For example, the fileinto action might put the user over
quota. The &quot;mailboxidexists&quot; test only verifies existence of the quota. The mailboxidexists test only verifies existence of the
mailbox and whether the user in whose context the Sieve script runs mailbox and whether the user in whose context the Sieve script runs
has permissions to execute &quot;fileinto&quot; on it.</t> has permissions to execute fileinto on it.</t>
<t>Example:</t> <t>Example:</t>
<artwork>require &quot;fileinto&quot;; <sourcecode type=""><![CDATA[
require &quot;mailboxid&quot;; require "fileinto";
require "mailboxid";
if header :contains [&quot;from&quot;] &quot;coyote&quot; { if header :contains ["from"] "coyote" {
if mailboxidexists &quot;F6352ae03-b7f5-463c-896f-d8b48ee3&quot; { if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
fileinto :mailboxid &quot;F6352ae03-b7f5-463c-896f-d8b48ee3&quot; fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
&quot;INBOX.name.will.not.be.used&quot;; "INBOX.name.will.not.be.used";
} else { } else {
fileinto &quot;INBOX.harassment&quot;; fileinto "INBOX.harassment";
} }
} }
</artwork> ]]></sourcecode>
<t>Note to implementers: this test behaves identically to the <aside>
<tt>mailboxexists</tt> test defined in <xref target="RFC5490"></xref> but operat <t>Note to implementers:</t>
es on <t>This test behaves identically to the
mailboxids rather than mailbox names.</t> mailboxexists test defined in <xref target="RFC5490"></xref> but operates on
MAILBOXIDs rather than mailbox names.</t>
</aside>
</section> </section>
<section anchor="interaction-with-variables-extension"><name>Interaction with va <section anchor="interaction-with-variables-extension"><name>Interaction with Va
riables extension</name> riables Extension</name>
<t>There is no special interaction defined, however as an objectid <t>There is no special interaction defined; however, as an OBJECTID
is a string in this document, objectid values can contain is a string in this document, OBJECTID values can contain
variable expansions if <xref target="RFC5229"></xref> is enabled.</t> variable expansions if <xref target="RFC5229"></xref> is enabled.</t>
</section> </section>
<section anchor="security-considerations"><name>Security considerations</name> <section anchor="security-considerations"><name>Security Considerations</name>
<t>Because mailboxid is always generated by the server, implementations <t>Because MAILBOXID is always generated by the server, implementations
MUST NOT allow sieve to make an endrun around this protection by <bcp14>MUST NOT</bcp14> allow Sieve to make an end run around this protection by
creating mailboxes with the specified ID by using &quot;:create&quot; and creating mailboxes with the specified ID by using :create and
&quot;:mailboxid&quot; in a fileinto rule for a non-existant mailbox.</t> :mailboxid in a fileinto rule for a nonexistent mailbox.</t>
<t>Implementers are referred to the security considerations sections <t>Implementers are referred to the Security Considerations sections
of <xref target="RFC5228"></xref> and <xref target="RFC8474"></xref>.</t> of <xref target="RFC5228"></xref> and <xref target="RFC8474"></xref>.</t>
</section> </section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>IANA has added the following capability to the "Sieve Extensions" registry
at <eref brackets="angle"
target="https://www.iana.org/assignments/sieve-extensions"/>:</t>
<section anchor="iana-considerations"><name>IANA considerations</name> <dl newline="false" spacing="compact">
<t>IANA are requested to add a capability to the sieve-extensions registry:</t> <dt>Capability name:</dt>
<dd>mailboxid</dd>
<artwork>To: iana@iana.org <dt>Description:</dt>
Subject: Registration of new Sieve extension <dd>adds a test for checking mailbox existence by OBJECTID
and new optional arguments to fileinto and :fcc that
Capability name: mailboxid allow selecting the destination mailbox by OBJECTID.</dd>
Description: adds a test for checking mailbox existence by objectid, <dt>RFC number:</dt>
and new optional arguments to fileinto and :fcc which <dd>RFC 9042</dd>
allow selecting the destination mailbox by objectid. <dt>Contact address:</dt>
RFC number: this RFC <dd>EXTRA discussion list &lt;extra@ietf.org&gt;</dd>
Contact address: The EXTRA discussion list &lt;extra@ietf.org&gt; </dl>
</artwork>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>This document borrows heavily from <xref target="RFC5490"></xref> for the mat
ching
mailboxexists test, and from <xref target="RFC8579"></xref> for an example of mo
difying
the fileinto command.</t>
<t>Thanks to Ned Freed and Ken Murchison and Alexey Melnikov for feedback
on the EXTRA mailing list.</t>
</section>
<section anchor="changes"><name>Changes</name>
<t>(EDITOR: remove this section before publication)</t>
<section anchor="draft-ietf-sieve-mailboxid-09"><name>draft-ietf-sieve-mailboxid
-09</name>
<ul>
<li>update FCC-OPTS to have an intermediate production for the :mailboxid
option, and reference <tt>objectid</tt> from RFC8474 as the valid format for
the option value.</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-08"><name>draft-ietf-sieve-mailboxid
-08</name>
<ul>
<li>IETF110 discussion - re-add FCC-OPTS syntax, and clarify that :mailboxid
is incompatible with :specialuse to parallel the fileinto behaviour</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-07"><name>draft-ietf-sieve-mailboxid
-07</name>
<ul>
<li>Martin Duke review - remove formal section</li>
<li>Martin Duke review - wording for section 4.1 (interaction with :create)</li>
<li>Ken Murchison review - fixed :special-use to :specialuse per RFC8579</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-06"><name>draft-ietf-sieve-mailboxid
-06</name>
<ul>
<li>GENART review - fixed example to not be semantically pointless</li>
<li>GENART review - fixed !@ to @! in RFC reference mmark syntax</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-05"><name>draft-ietf-sieve-mailboxid
-05</name>
<ul>
<li>disallow :mailboxid and :special-use in the same fileinto action.</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-04"><name>draft-ietf-sieve-mailboxid
-04</name>
<ul>
<li>made RFC5490 and RFC8579 normative</li>
<li>clarified wording based on AD feedback from Barry</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-03"><name>draft-ietf-sieve-mailboxid
-03</name>
<ul>
<li>Fixed ABNF syntax error</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-02"><name>draft-ietf-sieve-mailboxid
-02</name>
<ul>
<li>removed bogus : from &quot;mailboxidexists&quot; test title</li>
<li>moved FCC to its own top-level section since it is not used
with the fileinto command.</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-01"><name>draft-ietf-sieve-mailboxid
-01</name>
<ul>
<li>fixed idnits - RFC5228 not mentioned in the abstract</li>
<li>fixed other I-D references I had missed, oops</li>
</ul>
</section>
<section anchor="draft-ietf-sieve-mailboxid-00"><name>draft-ietf-sieve-mailboxid
-00</name>
<ul>
<li>Adopted into working group per adoption call on list</li>
<li>Updated references to old drafts which have since been published.</li>
<li>Fixed some typoes and simplified some language.</li>
<li>Removed stray leading colon on mailboxexists (thanks Alexey)</li>
<li>Added :fcc to the IANA registration description (thanks Alexey)</li>
<li>Mentioned that variables can be expanded (thanks Alexey)</li>
</ul>
</section>
<section anchor="draft-gondwana-sieve-mailboxid-02"><name>draft-gondwana-sieve-m
ailboxid-02</name>
<ul>
<li>Update document date by a couple of years! Ooops, it got forgotten after
a WGLC which got not dissent.</li>
<li>Create xml2rfc v3 output.</li>
</ul>
</section>
<section anchor="draft-gondwana-sieve-mailboxid-01"><name>draft-gondwana-sieve-m
ailboxid-01</name>
<ul>
<li>Switch to :mailboxid tagged parameter value with fallback mailbox name.</li>
<li>Document interaction with &quot;mailbox&quot;.</li>
<li>Document interaction with &quot;special-use&quot;.</li>
<li>Document interaction with &quot;fcc&quot;.</li>
<li>Document security considerations around :mailboxid and :create.</li>
</ul>
</section>
<section anchor="draft-gondwana-sieve-mailboxid-00"><name>draft-gondwana-sieve-m
ailboxid-00</name>
<ul>
<li>Initial version.</li>
</ul>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references><name>References</name>
<references><name>Normative References</name> <references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5228. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5228. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8474. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8474. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2342. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2342. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8580. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8580. xml"/>
</references> </references>
<references><name>Informative References</name> <references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8579. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8579. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5490. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5490. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4314. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4314. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5229. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5229. xml"/>
</references> </references>
</references>
<section anchor="acknowledgements" numbered="false"><name>Acknowledgements</name
>
<t>This document borrows heavily from <xref target="RFC5490"></xref> for the mat
ching
mailboxexists test and from <xref target="RFC8579"></xref> for an example of mod
ifying
the fileinto command.</t>
<t>Thanks to <contact fullname="Ned Freed"/>, <contact fullname="Ken Murchison"/
>, and <contact fullname="Alexey Melnikov"/> for feedback
on the EXTRA mailing list.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
308 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/