Network Working Group S. Bosch
Internet-Draft Dovecot Oy
Intended status: Standards Track May 16, 2019
Expires: November 17, 2019
Internet Message Access Protocol (IMAP) - FILTER=SIEVE Extension
draft-bosch-imap-filter-sieve-00
Abstract
This document adds a new capability called "FILTER=SIEVE" to the
Internet Message Access Protocol (IMAP). [FIXME]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bosch Expires November 17, 2019 [Page 1]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3
3.1. General Considerations . . . . . . . . . . . . . . . . . 3
3.2. FILTER and UID FILTER Commands . . . . . . . . . . . . . 3
3.3. FILTERED Untagged Response . . . . . . . . . . . . . . . 6
3.4. FILTER Untagged Response . . . . . . . . . . . . . . . . 8
4. Semantics of Sieve Actions . . . . . . . . . . . . . . . . . 9
4.1. The "keep" Action . . . . . . . . . . . . . . . . . . . . 9
4.2. The "fileinto" Action . . . . . . . . . . . . . . . . . . 10
4.3. The "redirect" Action . . . . . . . . . . . . . . . . . . 10
4.4. The "discard" Action . . . . . . . . . . . . . . . . . . 10
4.5. The "notify" Action . . . . . . . . . . . . . . . . . . . 11
4.6. The "addheader" and "deleteheader" Actions . . . . . . . 11
4.7. The "setflag", "deleteflag", and "removeflag" Actions . . 11
4.8. MIME Part Tests and Replacement . . . . . . . . . . . . . 11
4.9. The "imapsieve" extension . . . . . . . . . . . . . . . . 11
4.10. Ignored Actions . . . . . . . . . . . . . . . . . . . . . 12
4.11. Future Sieve Actions . . . . . . . . . . . . . . . . . . 12
5. Semantics of Sieve Tests . . . . . . . . . . . . . . . . . . 12
5.1. The "hasflag" Test . . . . . . . . . . . . . . . . . . . 13
5.2. The "spamtest" and "virustest" tests . . . . . . . . . . 13
5.3. The "duplicate" test . . . . . . . . . . . . . . . . . . 13
5.4. Future Sieve Tests . . . . . . . . . . . . . . . . . . . 13
6. Interaction with Sieve Environment . . . . . . . . . . . . . 13
6.1. Base Sieve Environment Items: location and phase . . . . 13
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Currently, Sieve filters [SIEVE] can either be applied at initial
mail delivery [SIEVE] or triggered by certain events in the Internet
Message Access Protocol (IMAP) [IMAPSIEVE]. The user can configure
which Sieve scripts to run at these instances, but it is not possible
to trigger the execution of Sieve scripts manually. However, this
could be very useful; e.g, to test new Sieve rules and to re-filter
messages that were erroneously handled by an earlier version of the
Sieve scripts involved.
This document extends IMAP [IMAP4rev1] with a new capability called
"FILTER=SIEVE". This adds a new generic "FILTER" command that allows
Bosch Expires November 17, 2019 [Page 2]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
applying a mail filter on a set of messages that match the specified
searching criteria. Although this command is defined such that it
can be extended for use with any (future) mail filter language, this
specification only adds support for invoking the "FILTER" command
with Sieve filters.
2. Conventions Used in This Document
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
3. IMAP Protocol Changes
3.1. General Considerations
[FIXME]
3.2. FILTER and UID FILTER Commands
The FILTER=SIEVE extension adds the FILTER and UID FILTER commands.
These allow clients to apply message filters to messages in the
selected mailbox that match the given searching criteria. These
commands are only available in the selected state [IMAP4rev1].
Arguments: filter specification
OPTIONAL [CHARSET] specification
searching criteria (one or more)
Responses: REQUIRED untagged response: FILTERED
Result: OK - filter completed
NO - command failure: can't search that [CHARSET] or
criteria, or filter failed
BAD - command arguments invalid
The filter specification describes the filter that is to be applied
to all matching messages. It consists of an identifier for the
filter type, followed by arguments specific to that filter type.
This specification defines only the "SIEVE" filter type, which uses
the Sieve Email Filtering Language [SIEVE]. The arguments of this
filter are one of the following. Refer to the Formal Syntax section
for the precise syntactic definitions of the arguments.
Bosch Expires November 17, 2019 [Page 3]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
DELIVERY
The Sieve filtering normally applied at delivery is applied to the
matching messages. This allows e.g. re-filtering messages that
were handled wrong at actual delivery. This at least means that
the "active script" as configured through [MANAGESIEVE] is run for
the matching messages. Some installations apply certain Sieve
rules in addition to (before or after) the user's active script
which are outside the user's control. These MAY also be applied
for DELIVERY filtering.
PERSONAL <script-name>
The Sieve script with the specified name that is stored in the
user's own personal (private) Sieve repository is applied to the
matching messages. Implementations that support ManageSieve
[MANAGESIEVE] can use the PUTSCRIPT command to store named scripts
in the personal repository. This is the same repository from
which the Sieve "include" control structure [SIEVE-INCLUDE]
retrieves ":personal" scripts. Implementations MUST restrict
script names according to [MANAGESIEVE], Section 1.6.
GLOBAL <script-name>
The Sieve script with the specified name that is stored in the
global (site-wide) Sieve repository is applied to the matching
messages. This the same repository from which the Sieve "include"
control structure [SIEVE-INCLUDE] retrieves ":global" scripts.
Implementations MUST restrict script names according to
[MANAGESIEVE], Section 1.6.
SCRIPT <script>
The Sieve script provided in the string argument is compiled and
executed for all the matching messages. This is e.g. useful to
test an individual Sieve rule, or apply a new rule to already
delivered messages. The argument MUST be a valid Sieve script
[SIEVE].
The server MAY refuse support for any of these filter specification
types by returning a tagged "NO" response, which MAY include an
appropriate response code, such as "NOPERM" [IMAP-RESPCODES].
The purpose of the [CHARSET] specification and the searching criteria
is essentially identical to corresponding arguments of the IMAP
SEARCH command [IMAP4rev1]. The specified message filter is applied
to all messages that match the provided searching criteria.
The server first checks whether it can initialize the specified
filter. For the "SIEVE" filter type, the initialization would
typically consist of retrieving and compiling the specified or
implied Sieve script or scripts. If this process fails, the FILTER
Bosch Expires November 17, 2019 [Page 4]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
command returns a tagged NO response. In that case, the server
SHOULD issue an untagged FILTER response first to provide a human-
readable description of the filter problem. Refer to Section 3.4 for
details.
Same as for the SEARCH command, if the server does not support the
specified [CHARSET], it MUST return a tagged NO response (not a BAD).
This response SHOULD contain the BADCHARSET response code, which MAY
list the [CHARSET]s supported by theserver. Note that the server
MUST NOT send an untagged FILTER response in this case, because this
failure is not related to filter processing.
Once the filter is initialized successfully, the filter is applied to
each matching message. An untagged FILTERED response is sent by the
server for each of the messages for which a significant action was
performed. This means any user visible action, such as a flag change
or moving the mail to another mailbox. It is also sent for messages
where the filter resulted in errors or warnings. Refer to
Section 3.3 for details.
The (implicit) "keep" action of the Sieve filter [SIEVE] leaves the
message in the mailbox it currently resides (the source mailbox).
When the implicit keep is canceled (e.g., "discard", "redirect" or
"fileinto" is executed) and the message is not explicitly stored into
the source mailbox, it is marked with the \Deleted flag in the source
mailbox. Refer to Section 4 for details.
[FIXME: Describe UID FILTER command
[FIXME: Describe untagged FETCH responses
Example:
C: A001 FILTER SIEVE DELIVERY
SINCE 1-Mar-2017 TO "hendrik@example.com"
S: * 3 FILTERED (TAG "A001") OK
S: * 16 FILTERED (TAG "A001") OK
S: * 21 FILTERED (TAG "A001") ERRORS {54}
S: line 15: number of actions exceeds the limit.
S:
S: * 35 FILTERED (TAG "A001") OK
S: * 39 FILTERED (TAG "A001") ERRORS {56}
S: line 36: mailbox does not exist: lists/ietf/art
S:
S: A001 OK FILTER completed
Bosch Expires November 17, 2019 [Page 5]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
Example:
C: A002 UID FILTER SIEVE PERSONAL "new" NEW
S: * 116 FILTERED (TAG "A002") UID 3321 OK
S: * 117 FILTERED (TAG "A002") UID 3322 OK
S: * 118 FILTERED (TAG "A002") UID 3323 WARNINGS {57}
S: line 113: saved to unsubscribed mailbox: Info
S:
S: A002 OK FILTER completed
Example:
C: A003 UID FILTER SIEVE SCRIPT {73+}
C: if subject :contains "Male Enhancement" {
C: discard;
C: stop;
C: }
C:
C:
C: ALL
S: * FILTER (TAG "A003")
ERROR "line 1: unknown test command `subject'"
S: A003 NO Sieve filter failed to compile
Example:
C: A004 UID FILTER SIEVE SCRIPT {85+}
C: if header :contains "subject"
C: "Male Enhancement" {
C: discard;
C: stop;
C: }
C:
C:
C: ALL
S: * 1 FETCH (UID 41 FLAGS (\Deleted \Seen))
S: * 1 FILTERED (TAG "A004") UID 41 OK
S: * 2 FETCH (UID 45 FLAGS (\Deleted))
S: * 2 FILTERED (TAG "A004") UID 45 OK
S: * 3 FILTERED (TAG "A004") UID 80 OK
S: * 4 FILTERED (TAG "A004") UID 81 OK
S: * 5 FETCH (UID 94 FLAGS (\Deleted \Seen))
S: * 5 FILTERED (TAG "A004") UID 94 OK
S: * 6 FILTERED (TAG "A004") UID 116 OK
S: A004 OK FILTER completed
3.3. FILTERED Untagged Response
Contents: filter command correlator
OPTIONAL message unique identifier (required for UID
FILTER)
Bosch Expires November 17, 2019 [Page 6]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
per-message filter result
The untagged FILTERED response may be sent as a result of a
successful, partially successful, or unsuccessful FILTER or UID
FILTER command specified in Section 3.2. It is sent for each message
that matched the searching criteria of the corresponding FILTER
command and that the filter successfully changed in some way. It is
also sent for messages where the filter resulted in errors or
warnings. This success/failure result is indicated in the reply.
The FILTERED response starts with a message number. Just like the
untagged FETCH response, the message number is always a message
sequence number, not a unique identifier [IMAP4rev1], even when the
response is sent for a UID FILTER command.
The message number is followed by the "FILTERED" label, which in turn
is followed by a filter command correlator. This contains the tag of
the command that caused the response to be returned. This can be
used by a client to match a FILTERED response against a corresponding
FILTER/UID FILTER command.
When the FILTERED response is sent by the server in response to a UID
FILTER command, the filter command correlator MUST be followed by the
word "UID" followed by the unique identifier of the filtered message.
This part of the response is optional when responding to a FILTER
command.
The FILTERED response ends with the filter result. This indicates
whether the filter was successfully applied to the message. This
specification defines the following results.
OK
The filter was applied successfully.
WARNINGS <warnings>
The filter was applied successfully, but there were one or more
warnings produced by the filter, which likely indicates behavior
not intended by the script writer. The word "WARNINGS" is
followed by a human-readable descriptive text listing the produced
warnings. A client seeing this filter result SHOULD present the
returned warning text to the user.
ERRORS <errors>
Application of the filter failed for some reason. The message is
left in its original state (as if only the "keep" action was
executed). The word "ERRORS" is followed by a human-readable
descriptive text listing the encountered errors.
Bosch Expires November 17, 2019 [Page 7]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
3.4. FILTER Untagged Response
Contents: filter command correlator
general filter problem
The untagged FILTER response may be sent as the result of a
successful, partially successful, or unsuccessful FILTER or UID
FILTER command specified in Section 3.2. This response is used to
provide filter error or warning details that are not specific to a
particular message being filtered; e.g., errors or warnings occurring
while the Sieve script is being compiled. Implementations SHOULD
avoid duplicating such output across all per-message FILTERED
responses and issue a single FILTER response instead. The server
MUST NOT send more than a single FILTER response. This untagged
response MUST only be sent for problems that concern the filter
processing.
The FILTER response starts with the "FILTER" label, which is followed
by a filter command correlator. This contains the tag of the command
that caused the response to be returned. This can be used by a
client to match a FILTER response against a corresponding FILTER/UID
FILTER command.
The FILTER response ends with a description of the problem that the
filter encountered. This specification defines the following
problems.
WARNINGS <warnings>
The filter can be applied successfully (individual FILTERED
responses provide per-message details), but there were one or more
general warnings produced by the filter, which likely indicates
behavior not intended by the script writer. The word "WARNINGS"
is followed by a human-readable descriptive text listing the
produced warnings. A client seeing this FILTER response SHOULD
present the returned warning text to the user.
ERRORS <errors>
Application of the filter failed completely for some reason. This
MUST mean that no messages are affected by this filter command,
which implies that no FILTERED responses are issued for this
command. Since filtering failed, the FILTER command MUST end in
an tagged NO response when a FILTER ERROR response is issued. The
word "ERRORS" is followed by a human-readable descriptive text
listing the encountered errors.
Bosch Expires November 17, 2019 [Page 8]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
4. Semantics of Sieve Actions
Sieve is normally executed during message delivery and some Sieve
actions therefore relate specifically to this context. Much like the
IMAPSIEVE capability [IMAPSIEVE], the FILTER=SIEVE capability allows
executing Sieve scripts in IMAP for messages that are already
delivered. However, unlike the IMAPSIEVE capability, these are
(parts of) the same Sieve scripts that are run at delivery, meaning
that the execution of Sieve scripts for the FILTER=SIEVE capability
needs to be very similar to execution during message delivery. This
means that Sieve scripts that are successfully executed during
message delivery MUST also finish successfully when executed in the
context of FILTER=SIEVE.
One problem is that the SMTP envelope information required for some
of the actions and tests is not or only partially available in IMAP.
This will need to be reconstructed from the message and any envelope
metadata that may be available in the message store.
Additionally, it makes no sense to send response messages to the
original sender when Sieve scripts are executed in IMAP, which may
happen a long time after the message was originally delivered.
Therefore, Sieve scripts executed by the FILTER=SIEVE script MUST NOT
send any such responses. Instead, the execution of such actions MUST
silently be ignored or at least the submission of the response
message MUST be inhibited. Note that this explicitly MUST NOT
trigger a runtime error, as explained above.
This section describes how actions in the base Sieve specification,
and those in extensions known at the time of this writing, relate to
this specification.
In addition to what is specified here, interactions noted in the
individual specifications apply and must be considered.
4.1. The "keep" Action
Much like what normally happens during Sieve execution at delivery,
the (implicit) "keep" action means that the message is treated as it
would have been if no Sieve script were run. For FILTER=SIEVE, this
means that the message is left in the mailbox. If actions have been
taken that change the message, a new modified message is appended and
the original message is marked as deleted.
Bosch Expires November 17, 2019 [Page 9]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
4.2. The "fileinto" Action
If the Sieve implementation supports the "fileinto" action, that
action is executed in FILTER=SIEVE context very much like it normally
would be during message delivery. The message is COPIED into the
fileinto mailbox, without removing the original. In all cases,
fileinto always creates a new message, separate from the original.
If the "copy" extension [SIEVE-COPY] is available and the ":copy"
option is specified, the implicit keep is retained; otherwise,
"fileinto" cancels the implicit keep, as specified in the base Sieve
specification [IMAPSIEVE].
If a "keep" action is not also in effect, the original message is
then marked with the \Deleted flag.
4.3. The "redirect" Action
The "redirect" action is executed in FILTER=SIEVE context very much
like it normally would be during message delivery. It causes the
message to be sent, as specified in the base Sieve specification
[IMAPSIEVE], to the designated address. If the "copy" extension
[SIEVE-COPY] is available and the ":copy" option is specified, the
implicit keep is retained; otherwise, redirect cancels the implicit
keep, as specified in the base Sieve specification.
It is possible that a message processed in this way does not have the
information necessary to be redirected properly. It may lack
necessary header information, and there may not be appropriate
information for the MAIL FROM command. In such cases, the "redirect"
action uses message submission [SUBMISSION], and it is up to the
Sieve engine to supply the missing information. The redirect address
is, of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be
set to the address of the owner of the mailbox. The message
submission server is allowed, according to the message submission
protocol, to perform necessary fix-up to the message (see Section 8
of RFC 6409). It can also reject the submission attempt if the
message is too ill-formed for submission.
If a "keep" action is not also in effect, the original message is
then marked with the \Deleted flag.
4.4. The "discard" Action
The "discard" action is executed in FILTER=SIEVE context very much
like it normally would be during message delivery. If an explicit
"keep" action is also in effect, the "discard" action does nothing.
Otherwise, the original message is marked with the \Deleted flag.
Bosch Expires November 17, 2019 [Page 10]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
4.5. The "notify" Action
If the Sieve "enotify" extension [SIEVE-ENOTIFY] is available, the
"notify" action is executed as normal in FILTER=SIEVE context. The
result is that the requested notification is sent and that the
message is otherwise handled as it would normally have been.
4.6. The "addheader" and "deleteheader" Actions
If the "editheader" extension [SIEVE-EDITHEADER] is available, it can
be used to make transient changes to header fields, which aren't
saved in place, such as for "redirect" or "fileinto" actions.
Because messages in IMAP mailboxes are immutable, such changes are
not applicable for the "keep" action (explicit or implicit). See
Section 4.1.
4.7. The "setflag", "deleteflag", and "removeflag" Actions
If the "imap4flags" extension [SIEVE-IMAP4FLAGS] is available, its
actions are executed in FILTER=SIEVE context very much like these
normally would be executed during message delivery. However, since
the message is already stored in a mailbox, the initial state of the
internal flags variable is the list of currently assigned flags
rather than the empty string.
4.8. MIME Part Tests and Replacement
If the MIME Part Tests extension [SIEVE-MIME] is available, all of
its functions can be used in scripts executed in FILTER=SIEVE
context, but any changes made to the message, using the "replace" or
"enclose" action, MUST be considered transient and are only
applicable with actions such as "redirect" and "fileinto". If the
"keep" action (explicit or implicit) is used, the editheader results
in appending a new modified message and marking the original message
deleted. See Section 4.1.
4.9. The "imapsieve" extension
Since the Sieve scripts for FILTER=SIEVE are not triggered as part of
an IMAP event, the "imapsieve" extension [IMAPSIEVE] MUST not be
available in FILTER=SIEVE context. Using this extension in the
"require" command MUST cause a compile error in FILTER=SIEVE context,
just like it would for scripts compiled for message delivery.
Bosch Expires November 17, 2019 [Page 11]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
4.10. Ignored Actions
The following actions are always ignored when the Sieve script is
executed in FILTER=SIEVE context, because they are specifically
designed to respond to delivery of a new email message:
reject [IMAPSIEVE]
ereject [SIEVE-REJECT]
vacation [SIEVE-VACATION]
Future extensions that are specifically designed to respond to
delivery of a new email message will likewise need to be ignored.
4.11. Future Sieve Actions
As noted above, future extensions that are specifically designed to
respond to delivery of a new email message will be ignored, because
the FILTER=SIEVE capability does not involve acting at new-message
delivery time.
In general, future extensions to Sieve that define new actions MUST
specify what behavioral differences there are when executing in
FILTER=SIEVE context (if any).
5. Semantics of Sieve Tests
Any tests against message envelope information, including the
"envelope" test in the Sieve base specification, as well as any such
test defined in extensions, can have serious interoperability issues
when performed at other than message delivery time. Therefore,
envelope information SHOULD be reconstructed as good as possible, so
that the tests yield the same results in FILTER=SIEVE context as
these would during message delivery. Since this cannot be guaranteed
for all implementations of FILTER=SIEVE, the Sieve script author
SHOULD account for possible differences explicitly using the
"environment" extension (See Section 6).
Executing in FILTER=SIEVE context does not affect the operation of
other tests or comparisons in the Sieve base specification.
The remainder of this section describes how tests in extensions known
at the time of this writing relate to this specification.
Bosch Expires November 17, 2019 [Page 12]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
5.1. The "hasflag" Test
If the "imap4flags" extension [SIEVE-IMAP4FLAGS] is available, its
"hasflag" test is executed in FILTER=SIEVE context very much like it
normally would be executed during message delivery. However, since
the message is already stored in a mailbox, the initial state of the
internal flags variable is the list of currently assigned flags
rather than the empty string.
5.2. The "spamtest" and "virustest" tests
If the "spamtest" and "virustest" extensions [SIEVE-SPAMVIRUSTEST]
are available, the associated tests are executed in FILTER=SIEVE
context exactly as these normally would be executed during message
delivery.
5.3. The "duplicate" test
If the "duplicate" extension [SIEVE-DUPLICATE] is available, the
associated test is executed in FILTER=SIEVE context exactly as it
normally would be executed during message delivery.
5.4. Future Sieve Tests
Future extensions to Sieve that define new tests MUST specify what
behavioral differences there are when executing in FILTER=SIEVE
context (if any).
6. Interaction with Sieve Environment
The Sieve "environment" extension [SIEVE-ENVIRONMENT] can be used to
evaluate properties of the environment in which the Sieve script is
executing. When the FILTER=SIEVE capability is involved, this can be
used by the script author to detect whether the script is executing
at message delivery or at some later time in FILTER=SIEVE context.
6.1. Base Sieve Environment Items: location and phase
The Sieve Environment extension defines a set of standard environment
items ([SIEVE-ENVIRONMENT], Section 4.1). Two of those items are
affected when the script is invoked in FILTER=SIEVE context.
The value of "location" is set to "MS" -- evaluation is being
performed by a Message Store.
The value of "phase" is set to "post" -- processing is taking place
after final delivery.
Bosch Expires November 17, 2019 [Page 13]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
7. Formal Syntax
The following syntax specification augments the grammar specified in
[IMAP4rev1]. It uses the Augmented Backus-Naur Form (ABNF) notation
as specified in [ABNF]. Non-terminals not defined in this document
can be found in [IMAP4rev1] and [IMAPABNF].
capability =/ "FILTER=SIEVE"
command-select =/ filter
filter = "FILTER" SP filter-spec
[SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument MUST be registered with IANA
filter-spec = "SIEVE" SP "DELIVERY" /
"SIEVE" SP "PERSONAL" SP sieve-name /
"SIEVE" SP "GLOBAL" SP sieve-name /
"SIEVE" SP "SCRIPT" SP sieve-literal
filter-correlator = "(" "TAG" SP tag-string ")"
filter-problem = "WARNINGS" string /
"ERRORS" string
filter-result = "OK" / filter-problem
filter-data = "FILTER" SP filter-correlator SP filter-problem
message-data =/ nz-number SP "FILTERED" SP filter-correlator
[SP "UID" SP uniqueid] SP filter-result
response-payload =/ filter-data
sieve-literal = string
; value conforms to Sieve script syntax defined
; in [SIEVE], Section 8.2
sieve-name = astring
; value conforms to Sieve script name syntax
; defined in [IMAPSIEVE], Section 1.6
8. Security Considerations
The FILTER=SIEVE capability offers the means to execute named or
literal Sieve scripts directly, without there being a trigger of some
kind. If users already have ManageSieve access, this does not add
Bosch Expires November 17, 2019 [Page 14]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
any obvious security concerns. However, when ManageSieve is not
available to users, the literal script could be used to access
functionality that is normally not accessible by users. For example,
users could run a literal Sieve script that executes actions that are
not available using the (web) UI that the user normally uses to
configure mail filtering. When this is a concern, the server MUST
either refuse filter specification types other than "SIEVE DELIVERY"
or limit the available Sieve functionality within the context of the
FILTER command.
Other security considerations are discussed in IMAP [IMAP4rev1] and
Sieve [SIEVE], as well as in some of the other extension documents.
9. IANA Considerations
The IANA is requested to add "FILTER=SIEVE" to the "IMAP
Capabilities" registry located at <http://www.iana.org/assignments/
imap-capabilities>.
10. Acknowledgements
Thanks to Timo Sirainen for reviews and suggestions.
[FIXME: acknowledge text borrowed from other documents: IMAPSIEVE,
CONVERT]
More reviews are appreciated.
11. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[IMAP-RESPCODES]
Gulbrandsen, A., "IMAP Response Codes", RFC 5530, May
2009.
[IMAP4rev1]
Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAPABNF]
Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
Bosch Expires November 17, 2019 [Page 15]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
[IMAPSIEVE]
Leiba, B., "Support for Internet Message Access Protocol
(IMAP) Events in Sieve", RFC 6785, November 2012.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MANAGESIEVE]
Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
July 2010, <https://www.rfc-editor.org/info/rfc5804>.
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
January 2008, <https://www.rfc-editor.org/info/rfc5228>.
[SIEVE-COPY]
Degener, J., "Sieve Extension: Copying Without Side
Effects", RFC 3894, DOI 10.17487/RFC3894, October 2004,
<https://www.rfc-editor.org/info/rfc3894>.
[SIEVE-DUPLICATE]
Bosch, S., "Sieve Email Filtering: Detecting Duplicate
Deliveries", RFC 7352, DOI 10.17487/RFC7352, September
2014, <https://www.rfc-editor.org/info/rfc7352>.
[SIEVE-EDITHEADER]
Degener, J. and P. Guenther, "Sieve Email Filtering:
Editheader Extension", RFC 5293, DOI 10.17487/RFC5293,
August 2008, <https://www.rfc-editor.org/info/rfc5293>.
[SIEVE-ENOTIFY]
Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
Martin, "Sieve Email Filtering: Extension for
Notifications", RFC 5435, DOI 10.17487/RFC5435, January
2009, <https://www.rfc-editor.org/info/rfc5435>.
[SIEVE-ENVIRONMENT]
Freed, N., "Sieve Email Filtering: Environment Extension",
RFC 5183, DOI 10.17487/RFC5183, May 2008,
<https://www.rfc-editor.org/info/rfc5183>.
[SIEVE-IMAP4FLAGS]
Melnikov, A., "Sieve Email Filtering: Imap4flags
Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008,
<https://www.rfc-editor.org/info/rfc5232>.
Bosch Expires November 17, 2019 [Page 16]
Internet-Draft IMAP - FILTER=SIEVE Extension May 2019
[SIEVE-INCLUDE]
Daboo, C. and A. Stone, "Sieve Email Filtering: Include
Extension", RFC 6609, May 2012.
[SIEVE-MIME]
Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, DOI 10.17487/RFC5703, October 2009,
<https://www.rfc-editor.org/info/rfc5703>.
[SIEVE-REJECT]
Stone, A., Ed., "Sieve Email Filtering: Reject and
Extended Reject Extensions", RFC 5429,
DOI 10.17487/RFC5429, March 2009,
<https://www.rfc-editor.org/info/rfc5429>.
[SIEVE-SPAMVIRUSTEST]
Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extensions", RFC 5235, DOI 10.17487/RFC5235, January 2008,
<https://www.rfc-editor.org/info/rfc5235>.
[SIEVE-VACATION]
Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008.
[SUBMISSION]
Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
Author's Address
Stephan Bosch
Dovecot Oy
Lars Sonckin Kaari 12
Espoo 02600
Finland
Email: stephan.bosch@dovecot.fi
Bosch Expires November 17, 2019 [Page 17]
distrib
>
Mageia
>
7
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
ce3b10d260cfc443e0747a4e4d3c7cab
>
files
>
127
