Sieve Email Filtering: Snooze ExtensionFastmail US LLC1429 Walnut Street - Suite 1201PhiladelphiaPA19102USAmurch@fastmailteam.comFastmail US LLC1429 Walnut Street - Suite 1201PhiladelphiaPA19102USArjbs@fastmailteam.comFastmail Pty LtdLevel 2, 114 William StreetMelbourneVIC3000Australianeilj@fastmailteam.com
ART
EXTRASieveThis document describes the "snooze" extension to the Sieve email
filtering language.
The "snooze" extension gives Sieve the ability to postpone the
delivery of an incoming email message into a target mailbox
until a later point in time.Users are not always ready, willing, or able to read and
respond to email messages at the time of their arrival.
Sometimes it is desirable to have messages appear in a mailbox
at a more convenient time for the user to act upon them.This document defines an extension to the
Sieve language that enables
scripts to postpone the delivery of a message into a target
mailbox until a later point in time.Conventions for notations are as in Section 1.1 of , including use of the "Usage:" label for the
definition of action and tagged arguments syntax.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.Sieve implementations that support this extension have
an identifier of "snooze" for use with the capability mechanism.The "snooze" action cancels the implicit keep and postpones
delivery of the message into the specified mailbox at a later
point in time.The snooze action is semantically equivalent to a delayed
fileinto action (see Section 4.1 of ).
The arguments of the snooze action specify when, where, and
how the awakened message will be filed.A Sieve interpreter MUST implement the snooze action by
delivering the message to a special "snoozed" mailbox within its
mailstore.
IMAP and JMAP
servers MUST apply the "Snoozed"
attribute to this mailbox.
The message will reside in this special mailbox until the
prescribed awaken time at which it will be moved into the
specified target mailbox.The optional :mailbox argument is used to specify the target
mailbox that the message will be filed into when it is awakened.
It is equivalent to the mailbox argument of the fileinto
action (see Section 4.1 of ).If :mailbox is omitted, or if the specified mailbox doesn't
exist at the time of awakening, the message will be filed
into the user's main mailbox.
For instance, in an implementation where an IMAP server is
running scripts on behalf of the user at time of delivery,
the user's "INBOX" would be the implicit target for
awakening messages.The optional :weekdays argument specifies the set of days
on which the specified set of awakening times apply.
Each day of the week is expressed as an integer between
"0" and "6". "0" is Sunday, "1" is Monday, etc.
This syntax matches that of the "weekday" date-part argument
to the date test extension (see Section 4.2 of
).If :weekdays is omitted, the set of awakening times applies
to every day of the week.The required times argument, along with the optional :tzid
argument, are used to specify when a snoozed message will be
awakened.
Each time is specified in "hh:mm:ss" format and is interpreted
as the local time in the time zone specified by the :tzid
argument.The value of the :tzid argument MUST be a time zone
identifier from the
IANA Time Zone Database.
If :tzid is omitted, the time zone of the Sieve
interpreter is used.
The combination of the weekdays and times form a
chronological list of awaken times. When a message is
snoozed, it is assigned the next future awaken time in the
list. If a message is snoozed on a day with no awaken times,
or after the last awaken time on a given day,
the first awaken time on the next available day is used.
If the local time in the specified time zone occurs more
than once (daylight saving to standard time transition), the
first occurrence of the specified time value is used.
If the local time in the specified time zone does not occur
(standard to daylight saving time transition), the specified
time value is interpreted using the UTC offset prior to the
transition.The following examples show, given the specified snooze
action and a set of message arrival times, the corresponding
times at which the message would be awakened and filed.Arrival (UTC)Arrival (Melbourne)Awaken (Melbourne)2020-07-30T00:00:00Z--07-30T10:00:00+10--07-30T12:00:00+102020-07-30T04:00:00Z--07-30T14:00:00+10--07-30T16:00:00+102020-07-30T08:00:00Z--07-30T18:00:00+10--07-31T08:00:00+102020-07-31T12:00:00Z--07-31T22:00:00+10--08-03T08:00:00+102020-08-01T16:00:00Z--08-02T02:00:00+10--08-03T08:00:00+10Arrival (UTC)Arrival (New York)Awaken (New York)2020-11-01T05:00:00Z--11-01T01:00:00-04--11-01T01:30:00-042020-11-01T06:00:00Z--11-01T01:00:00-05--11-02T01:30:00-052020-11-01T07:00:00Z--11-01T02:00:00-05--11-02T01:30:00-05Arrival (UTC)Arrival (New York)Awaken (New York)2021-03-13T06:30:00Z--03-13T01:30:00-05--03-13T02:30:00-052021-03-14T06:30:00Z--03-14T01:30:00-05--03-14T03:30:00-042021-03-14T07:30:00Z--03-14T03:30:00-04--03-15T02:30:00-04Some tagged arguments defined in extensions to the fileinto
action can be used together with the snooze action.
The sections below describe these interactions.
Tagged arguments in future extensions to the fileinto action
need to describe their interaction with the snooze extension,
if any.When any fileinto extension arguments are used with the
snooze extension, the corresponding extension MUST be enabled,
and the arguments are defined to have the same syntax,
semantics, and treatment as they do with the fileinto action.When the "imap4flags"
extension is enabled in a script, two additional tagged
arguments are added to "snooze" that allow manipulating the
set of flags on a snoozed message.The optional :addflags and :removeflags arguments are used
to specify which IMAP flags
should be added to and/or removed from the set of IMAP flags
present on the snoozed message at the time of awakening.
Note the set of IMAP flags present at the time of awakening may
be the empty set.If the "setflag" and/or "addflag" actions have been used to
store IMAP flags in the imap4flags internal variable,
the Sieve interpreter MUST use the current value of the
internal variable as the set of flags to associate with the
message when storing it into the "snoozed" mailbox.This document doesn't dictate how the Sieve interpreter
will set the IMAP flags.
In particular, the Sieve interpreter may work as an IMAP
client or may have direct access to the mailstore.The general requirements for flag handling specified in
Section 2 of MUST be followed.The following example leverages the
Date,
Relational, and
Imap4flags extensions
to snooze messages received after business hours until the
following work day. Note that the message is marked as
important when it is snoozed, and will be marked as unread
when it is awakened.This document extends the definition of the
":create" tagged argument so
that it can be used with the snooze action.If the optional ":create" argument is specified with
snooze, it instructs the Sieve interpreter to create the
target mailbox, if needed, before attempting to file the
awakened message into the target mailbox.This document extends the definition of the
":specialuse" tagged argument
so that it can be used with the snooze action.If the optional ":specialuse" argument is specified with
snooze, 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 awakened message is filed
into the special-use mailbox. Otherwise, the awakened message
is filed into the target mailbox.If both the optional ":specialuse" and ":create"
arguments are specified with snooze, the Sieve interpreter
is instructed to create the target mailbox per Section 4.1
of , if needed.This document extends the definition of the
":mailboxid"
tagged argument so that it can be used with the snooze action.If the optional ":mailboxid" argument is specified with
snooze, it instructs the Sieve interpreter to check whether
a mailbox exists in the user's
personal namespace with the
specified MAILBOXID.
If such a mailbox exists, the awakened message is filed
into that mailbox. Otherwise, the awakened message
is filed into the target mailbox.It is an error to specify both ":mailboxid" and
":specialuse" in the same snooze action.< RFC Editor: before publication please remove this section
and the reference to >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 . 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.According to ,
"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".The open source Cyrus Server 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
Computing Services at Carnegie Mellon University.Security considerations are discussed in
, ,
, and .
It is believed that this extension doesn't introduce any
additional security concerns.It is believed that this extension doesn't introduce any
privacy considerations beyond those in .This document defines the following new Sieve extension
to be added to the registry defined in
Section 6.2 of and located here:
IANA are requested to add a capability to the Sieve
Extensions registry:
To: iana@iana.orgSubject: Registration of new Sieve extensionCapability name: snoozeDescription: Adds the "snooze" action command to
postpone delivery of a message into a target mailbox until
a later point in time.RFC number: RFC XXXXContact address: The Sieve discussion list
<sieve@ietf.org>This document defines the following new Sieve action
to be added to the registry defined in
Section 3.1 of .
IANA are requested to add an action to the Sieve Action
registry:
Name: snoozeDescription: Postpone delivery of a message into a
target mailbox until a later point in time.References: RFC XXXX, ,
, ,
Capabilities: "snooze", "imap4flags", "mailbox",
"special-use", "mailboxid".Interactions: Is not compatible with the reject or
ereject actions.Cancels Implicit Keep?: YUse with IMAP Events?: YComments: Requires a special "snoozed" mailbox in the
mailstore.This document defines the following new IMAP mailbox name
attribute to be added to the registry defined in
Section 6.2 of and located here:
IANA are requested to add an attribute to the IMAP Mailbox
Name Attribute registry:
To: iana@iana.orgSubject: Registration of new IMAP Mailbox Name AttributeAttribute name: SnoozedDescription: Messages that have been snoozed.Reference: RFC XXXXThe authors would like to thank the following individuals for
contributing their ideas and support for writing this
specification: Ned Freed, Barry Leiba, and Alexey Melnikov.Time Zone DatabaseInternet Assigned Numbers AuthorityChanges since draft-ietf-extra-sieve-snooze-04:
Miscellaneous editorial changes.Changes since draft-ietf-extra-sieve-snooze-03:
Added "snooze" to the Sieve Actions Registry.Changes since draft-ietf-extra-sieve-snooze-02:
Updated :mailboxid reference to RFC9042.Added an informative reference to RFC8621.Miscellaneous editorial changes.Changes since draft-ietf-extra-sieve-snooze-01:
Miscellaneous editorial changes.Changes since draft-ietf-extra-sieve-snooze-00:
Disallow both :mailboxid and :specialuse in the same snooze
action.Updated :mailboxid reference to
draft-ietf-extra-sieve-mailboxidSpecified that snooze cancels implicit keep.Specified that implementations MUST use a "snoozed" mailbox.Added registration of \Snoozed Special-Use Attribute.Added example of manipulating IMAP flags at both snooze
time and awaken time.Miscellaneous editorial changes.