7
Internet Engineering Task Force (IETF) A. Melnikov, Ed.
8
Request for Comments: 5804 Isode Limited
9
Category: Standards Track T. Martin
10
ISSN: 2070-1721 BeThereBeSquare, Inc.
14
A Protocol for Remotely Managing Sieve Scripts
18
Sieve scripts allow users to filter incoming email. Message stores
19
are commonly sealed servers so users cannot log into them, yet users
20
must be able to update their scripts on them. This document
21
describes a protocol "ManageSieve" for securely managing Sieve
22
scripts on a remote server. This protocol allows a user to have
23
multiple scripts, and also alerts a user to syntactically flawed
28
This is an Internet Standards Track document.
30
This document is a product of the Internet Engineering Task Force
31
(IETF). It represents the consensus of the IETF community. It has
32
received public review and has been approved for publication by the
33
Internet Engineering Steering Group (IESG). Further information on
34
Internet Standards is available in Section 2 of RFC 5741.
36
Information about the current status of this document, any errata,
37
and how to provide feedback on it may be obtained at
38
http://www.rfc-editor.org/info/rfc5804.
42
Copyright (c) 2010 IETF Trust and the persons identified as the
43
document authors. All rights reserved.
45
This document is subject to BCP 78 and the IETF Trust's Legal
46
Provisions Relating to IETF Documents
47
(http://trustee.ietf.org/license-info) in effect on the date of
48
publication of this document. Please review these documents
49
carefully, as they describe your rights and restrictions with respect
50
to this document. Code Components extracted from this document must
51
include Simplified BSD License text as described in Section 4.e of
52
the Trust Legal Provisions and are provided without warranty as
53
described in the Simplified BSD License.
58
Melnikov & Martin Standards Track [Page 1]
60
RFC 5804 ManageSieve July 2010
65
1. Introduction ....................................................3
66
1.1. Commands and Responses .....................................3
67
1.2. Syntax .....................................................3
68
1.3. Response Codes .............................................3
69
1.4. Active Script ..............................................6
70
1.5. Quotas .....................................................6
71
1.6. Script Names ...............................................6
72
1.7. Capabilities ...............................................7
73
1.8. Transport ..................................................9
74
1.9. Conventions Used in This Document .........................10
75
2. Commands .......................................................10
76
2.1. AUTHENTICATE Command ......................................11
77
2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
78
2.2. STARTTLS Command ..........................................16
79
2.2.1. Server Identity Check ..............................17
80
2.3. LOGOUT Command ............................................20
81
2.4. CAPABILITY Command ........................................20
82
2.5. HAVESPACE Command .........................................20
83
2.6. PUTSCRIPT Command .........................................21
84
2.7. LISTSCRIPTS Command .......................................23
85
2.8. SETACTIVE Command .........................................24
86
2.9. GETSCRIPT Command .........................................25
87
2.10. DELETESCRIPT Command .....................................25
88
2.11. RENAMESCRIPT Command .....................................26
89
2.12. CHECKSCRIPT Command ......................................27
90
2.13. NOOP Command .............................................28
91
2.14. Recommended Extensions ...................................28
92
2.14.1. UNAUTHENTICATE Command ............................28
93
3. Sieve URL Scheme ...............................................29
94
4. Formal Syntax ..................................................31
95
5. Security Considerations ........................................37
96
6. IANA Considerations ............................................38
97
6.1. ManageSieve Capability Registration Template ..............39
98
6.2. Registration of Initial ManageSieve Capabilities ..........39
99
6.3. ManageSieve Response Code Registration Template ...........41
100
6.4. Registration of Initial ManageSieve Response Codes ........41
101
7. Internationalization Considerations ............................46
102
8. Acknowledgements ...............................................46
103
9. References .....................................................47
104
9.1. Normative References ......................................47
105
9.2. Informative References ....................................48
114
Melnikov & Martin Standards Track [Page 2]
116
RFC 5804 ManageSieve July 2010
121
1.1. Commands and Responses
123
A ManageSieve connection consists of the establishment of a client/
124
server network connection, an initial greeting from the server, and
125
client/server interactions. These client/server interactions consist
126
of a client command, server data, and a server completion result
129
All interactions transmitted by client and server are in the form of
130
lines, that is, strings that end with a CRLF. The protocol receiver
131
of a ManageSieve client or server is either reading a line or reading
132
a sequence of octets with a known count followed by a line.
136
ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP],
137
which runs over TCP. There are three data types: atoms, numbers and
138
strings. Strings may be quoted or literal. See [ACAP] for detailed
139
descriptions of these types.
141
Each command consists of an atom (the command name) followed by zero
142
or more strings and numbers terminated by CRLF.
144
All client queries are replied to with either an OK, NO, or BYE
145
response. Each response may be followed by a response code (see
146
Section 1.3) and by a string consisting of human-readable text in the
147
local language (as returned by the LANGUAGE capability; see
148
Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string
149
SHOULD be shown to the user ,and implementations MUST NOT attempt to
150
parse the message for meaning.
152
The BYE response SHOULD be used if the server wishes to close the
153
connection. A server may wish to do this because the client was idle
154
for too long or there were too many failed authentication attempts.
155
This response can be issued at any time and should be immediately
156
followed by a server hang-up of the connection. If a server has an
157
inactivity timeout resulting in client autologout, it MUST be no less
158
than 30 minutes after successful authentication. The inactivity
159
timeout MAY be less before authentication.
163
An OK, NO, or BYE response from the server MAY contain a response
164
code to describe the event in a more detailed machine-parsable
165
fashion. A response code consists of data inside parentheses in the
166
form of an atom, possibly followed by a space and arguments.
170
Melnikov & Martin Standards Track [Page 3]
172
RFC 5804 ManageSieve July 2010
175
Response codes are defined when there is a specific action that a
176
client can take based upon the additional information. In order to
177
support future extension, the response code is represented as a
178
slash-separated (Solidus, %x2F) hierarchy with each level of
179
hierarchy representing increasing detail about the error. Response
180
codes MUST NOT start with the Solidus character. Clients MUST
181
tolerate additional hierarchical response code detail that they don't
182
understand. For example, if the client supports the "QUOTA" response
183
code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it
184
should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
186
Client implementations MUST tolerate (ignore) response codes that
187
they do not recognize.
189
The currently defined response codes are the following:
193
This response code is returned in the NO or BYE response from an
194
AUTHENTICATE command. It indicates that site security policy forbids
195
the use of the requested mechanism for the specified authentication
200
This response code is returned in the NO or BYE response from an
201
AUTHENTICATE command. It indicates that site security policy
202
requires the use of a strong encryption mechanism for the specified
203
authentication identity and mechanism.
207
If this response code is returned in the NO/BYE response, it means
208
that the command would have placed the user above the site-defined
209
quota constraints. If this response code is returned in the OK
210
response, it can mean that the user's storage is near its quota, or
211
it can mean that the account exceeded its quota but that the
212
condition is being allowed by the server (the server supports
213
so-called soft quotas). The QUOTA response code has two more
214
detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user
215
scripts) and "QUOTA/MAXSIZE" (the maximum script size).
219
This response code may be returned with a BYE result from any
220
command, and includes a mandatory parameter that indicates what
221
server to access to manage this user's Sieve scripts. The server
222
will be specified by a Sieve URL (see Section 3). The scriptname
226
Melnikov & Martin Standards Track [Page 4]
228
RFC 5804 ManageSieve July 2010
231
portion of the URL MUST NOT be specified. The client should
232
authenticate to the specified server and use it for all further
233
commands in the current session.
237
This response code can occur in the OK response to a successful
238
AUTHENTICATE command and includes the optional final server response
239
data from the server as specified by [SASL].
243
This response code occurs in a NO response of an AUTHENTICATE
244
command. It indicates that the user name is valid, but the entry in
245
the authentication database needs to be updated in order to permit
246
authentication with the specified mechanism. This is typically done
247
by establishing a secure channel using TLS, verifying server identity
248
as specified in Section 2.2.1, and finally authenticating once using
249
the [PLAIN] authentication mechanism. The selected mechanism SHOULD
250
then work for authentications in subsequent sessions.
252
This condition can happen if a user has an entry in a system
253
authentication database such as Unix /etc/passwd, but does not have
254
credentials suitable for use by the specified mechanism.
258
A command failed due to a temporary server failure. The client MAY
259
continue using local information and try the command later. This
260
response code only makes sense when returned in a NO/BYE response.
264
A command failed because it is not allowed on the active script, for
265
example, DELETESCRIPT on the active script. This response code only
266
makes sense when returned in a NO/BYE response.
270
A command failed because the referenced script name doesn't exist.
271
This response code only makes sense when returned in a NO/BYE
276
A command failed because the referenced script name already exists.
277
This response code only makes sense when returned in a NO/BYE
282
Melnikov & Martin Standards Track [Page 5]
284
RFC 5804 ManageSieve July 2010
289
This response code name is followed by a string specified in the
290
command. See Section 2.13 for a possible use case.
294
This response code MAY be returned by the server in the OK response
295
(but it might be returned with the NO/BYE response as well) and
296
signals the client that even though the script is syntactically
297
valid, it might contain errors not intended by the script writer.
298
This response code is typically returned in response to PUTSCRIPT
299
and/or CHECKSCRIPT commands. A client seeing such response code
300
SHOULD present the returned warning text to the user.
304
A user may have multiple Sieve scripts on the server, yet only one
305
script may be used for filtering of incoming messages. This is the
306
active script. Users may have zero or one active script and MUST use
307
the SETACTIVE command described below for changing the active script
308
or disabling Sieve processing. For example, users may have an
309
everyday script they normally use and a special script they use when
310
they go on vacation. Users can change which script is being used
311
without having to download and upload a script stored somewhere else.
315
Servers SHOULD impose quotas to prevent malicious users from
316
overflowing available storage. If a command would place a user over
317
a quota setting, servers that impose such quotas MUST reply with a NO
318
response containing the QUOTA response code. Client implementations
319
MUST be able to handle commands failing because of quota
324
A Sieve script name is a sequence of Unicode characters encoded in
325
UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition
326
(Section 2 of [NET-UNICODE]), with the additional restriction of
327
prohibiting the following Unicode characters:
329
o 0000-001F; [CONTROL CHARACTERS]
333
o 0080-009F; [CONTROL CHARACTERS]
338
Melnikov & Martin Standards Track [Page 6]
340
RFC 5804 ManageSieve July 2010
343
o 2028; LINE SEPARATOR
345
o 2029; PARAGRAPH SEPARATOR
347
Sieve script names MUST be at least one octet (and hence Unicode
348
character) long. Zero octets script name has a special meaning (see
349
Section 2.8). Servers MUST allow names of up to 128 Unicode
350
characters in length (which can take up to 512 bytes when encoded in
351
UTF-8, not counting the terminating NUL), and MAY allow longer names.
352
A server that receives a script name longer than its internal limit
353
MUST reject the corresponding operation, in particular it MUST NOT
354
truncate the script name.
358
Server capabilities are sent automatically by the server upon a
359
client connection, or after successful STARTTLS and AUTHENTICATE
360
(which establishes a Simple Authentication and Security Layer (SASL))
361
commands. Capabilities may change immediately after a successfully
362
completed STARTTLS command, and/or immediately after a successfully
363
completed AUTHENTICATE command, and/or after a successfully completed
364
UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST
365
remain static at all other times.
367
Clients MAY request the capabilities at a later time by issuing the
368
CAPABILITY command described later. The capabilities consist of a
369
series of lines each with one or two strings. The first string is
370
the name of the capability, which is case-insensitive. The second
371
optional string is the value associated with that capability. Order
372
of capabilities is arbitrary, but each capability name can appear at
375
The following capabilities are defined in this document:
377
IMPLEMENTATION - Name of implementation and version. This capability
378
MUST always be returned by the server.
380
SASL - List of SASL mechanisms supported by the server, each
381
separated by a space. This list can be empty if and only if STARTTLS
382
is also advertised. This means that the client must negotiate TLS
383
encryption with STARTTLS first, at which point the SASL capability
384
will list a non-empty list of SASL mechanisms.
386
SIEVE - List of space-separated Sieve extensions (as listed in Sieve
387
"require" action [SIEVE]) supported by the Sieve engine. This
388
capability MUST always be returned by the server.
394
Melnikov & Martin Standards Track [Page 7]
396
RFC 5804 ManageSieve July 2010
399
STARTTLS - If TLS [TLS] is supported by this implementation. Before
400
advertising this capability a server MUST verify to the best of its
401
ability that TLS can be successfully negotiated by a client with
402
common cipher suites. Specifically, a server should verify that a
403
server certificate has been installed and that the TLS subsystem has
404
successfully initialized. This capability SHOULD NOT be advertised
405
once STARTTLS or AUTHENTICATE command completes successfully. Client
406
and server implementations MUST implement the STARTTLS extension.
408
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
409
actions a script can perform during a single evaluation. Note that
410
this is different from the total number of "redirect" actions a
411
script can contain. The value is a non-negative number represented
412
as a ManageSieve string.
414
NOTIFY - A space-separated list of URI schema parts for supported
415
notification methods. This capability MUST be specified if the Sieve
416
implementation supports the "enotify" extension [NOTIFY].
418
LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently
419
used for human-readable error messages. If this capability is not
420
returned, the "i-default" [RFC2277] language is assumed. Note that
421
the current language MAY be per-user configurable (i.e., it MAY
422
change after authentication).
424
OWNER - The canonical name of the logged-in user (SASL "authorization
425
identity") encoded in UTF-8. This capability MUST NOT be returned in
426
unauthenticated state and SHOULD be returned once the AUTHENTICATE
429
VERSION - This capability MUST be returned by servers compliant with
430
this document or its successor. For servers compliant with this
431
document, the capability value is the string "1.0". Lack of this
432
capability means that the server predates this specification and thus
433
doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT,
436
Section 2.14 defines some additional ManageSieve extensions and their
437
respective capabilities.
439
A server implementation MUST return SIEVE, IMPLEMENTATION, and
440
VERSION capabilities.
442
A client implementation MUST ignore any listed capabilities that it
450
Melnikov & Martin Standards Track [Page 8]
452
RFC 5804 ManageSieve July 2010
457
S: "IMPlemENTATION" "Example1 ManageSieved v001"
458
S: "SASl" "DIGEST-MD5 GSSAPI"
459
S: "SIeVE" "fileinto vacation"
461
S: "NOTIFY" "xmpp mailto"
462
S: "MAXREdIRECTS" "5"
466
After successful authentication, this might look like this:
470
S: "IMPlemENTATION" "Example1 ManageSieved v001"
471
S: "SASl" "DIGEST-MD5 GSSAPI"
472
S: "SIeVE" "fileinto vacation"
473
S: "NOTIFY" "xmpp mailto"
474
S: "OWNER" "alexey@example.com"
475
S: "MAXREdIRECTS" "5"
481
The ManageSieve protocol assumes a reliable data stream such as that
482
provided by TCP. When TCP is used, a ManageSieve server typically
483
listens on port 4190.
485
Before opening the TCP connection, the ManageSieve client first MUST
486
resolve the Domain Name System (DNS) hostname associated with the
487
receiving entity and determine the appropriate TCP port for
488
communication with the receiving entity. The process is as follows:
490
1. Attempt to resolve the hostname using a [DNS-SRV] Service of
491
"sieve" and a Proto of "tcp" for the target domain (e.g.,
492
"example.net"), resulting in resource records such as
493
"_sieve._tcp.example.net.". The result of the SRV lookup, if
494
successful, will be one or more combinations of a port and
495
hostname; the ManageSieve client MUST resolve the returned
496
hostnames to IPv4/IPv6 addresses according to returned SRV record
497
weight. IP addresses from the first successfully resolved
498
hostname (with the corresponding port number returned by SRV
499
lookup) are used to connect to the server. If connection using
500
one of the IP addresses fails, the next resolved IP address is
506
Melnikov & Martin Standards Track [Page 9]
508
RFC 5804 ManageSieve July 2010
511
used to connect. If connection to all resolved IP addresses
512
fails, then the resolution/connect is repeated for the next
513
hostname returned by SRV lookup.
515
2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
516
IPv6 address record resolution to determine the IP address, where
517
the port used is the default ManageSieve port of 4190.
519
1.9. Conventions Used in This Document
521
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
522
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
523
document are to be interpreted as described in [KEYWORDS].
525
In examples, "C:" and "S:" indicate lines sent by the client and
526
server respectively. Line breaks that do not start a new "C:" or
527
"S:" exist for editorial reasons.
529
Examples of authentication in this document are using DIGEST-MD5
530
[DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
534
This section and its subsections describe valid ManageSieve commands.
535
Upon initial connection to the server, the client's session is in
536
non-authenticated state. Prior to successful authentication, only
537
the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section
538
2.13) commands are valid. ManageSieve extensions MAY define other
539
commands that are valid in non-authenticated state. Servers MUST
540
reject all other commands with a NO response. Clients may pipeline
541
commands (send more than one command at a time without waiting for
542
completion of the first command). However, a group of commands sent
543
together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a
544
HAVESPACE command anywhere but the last command in the list.
546
(*) - The only exception to this rule is when the AUTHENTICATE
547
command contains an initial response for a SASL mechanism that allows
548
clients to send data first, the mechanism is known to complete in one
549
round trip, and the mechanism doesn't negotiate a SASL security
550
layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and
562
Melnikov & Martin Standards Track [Page 10]
564
RFC 5804 ManageSieve July 2010
567
2.1. AUTHENTICATE Command
569
Arguments: String - mechanism
570
String - initial data (optional)
572
The AUTHENTICATE command indicates a SASL [SASL] authentication
573
mechanism to the server. If the server supports the requested
574
authentication mechanism, it performs an authentication protocol
575
exchange to identify and authenticate the user. Optionally, it also
576
negotiates a security layer for subsequent protocol interactions. If
577
the requested authentication mechanism is not supported, the server
578
rejects the AUTHENTICATE command by sending the NO response.
580
The authentication protocol exchange consists of a series of server
581
challenges and client responses that are specific to the selected
582
authentication mechanism. A server challenge consists of a string
583
(quoted or literal) followed by a CRLF. The contents of the string
584
is a base-64 encoding [BASE64] of the SASL data. A client response
585
consists of a string (quoted or literal) with the base-64 encoding of
586
the SASL data followed by a CRLF. If the client wishes to cancel the
587
authentication exchange, it issues a string containing a single "*".
588
If the server receives such a response, it MUST reject the
589
AUTHENTICATE command by sending a NO reply.
591
Note that an empty challenge/response is sent as an empty string. If
592
the mechanism dictates that the final response is sent by the server,
593
this data MAY be placed within the data portion of the SASL response
594
code to save a round trip.
596
The optional initial-response argument to the AUTHENTICATE command is
597
used to save a round trip when using authentication mechanisms that
598
are defined to send no data in the initial challenge. When the
599
initial-response argument is used with such a mechanism, the initial
600
empty challenge is not sent to the client and the server uses the
601
data in the initial-response argument as if it were sent in response
602
to the empty challenge. If the initial-response argument to the
603
AUTHENTICATE command is used with a mechanism that sends data in the
604
initial challenge, the server MUST reject the AUTHENTICATE command by
605
sending the NO response.
607
The service name specified by this protocol's profile of SASL is
610
Reauthentication is not supported by ManageSieve protocol's profile
611
of SASL. That is, after a successfully completed AUTHENTICATE
612
command, no more AUTHENTICATE commands may be issued in the same
613
session. After a successful AUTHENTICATE command completes, a server
614
MUST reject any further AUTHENTICATE commands with a NO reply.
618
Melnikov & Martin Standards Track [Page 11]
620
RFC 5804 ManageSieve July 2010
623
However, note that a server may implement the UNAUTHENTICATE
624
extension described in Section 2.14.1.
626
If a security layer is negotiated through the SASL authentication
627
exchange, it takes effect immediately following the CRLF that
628
concludes the successful authentication exchange for the client, and
629
the CRLF of the OK response for the server.
631
When a security layer takes effect, the ManageSieve protocol is reset
632
to the initial state (the state in ManageSieve after a client has
633
connected to the server). The server MUST discard any knowledge
634
obtained from the client that was not obtained from the SASL (or TLS)
635
negotiation itself. Likewise, the client MUST discard any knowledge
636
obtained from the server, such as the list of ManageSieve extensions,
637
that was not obtained from the SASL (and/or TLS) negotiation itself.
638
(Note that a client MAY compare the advertised SASL mechanisms before
639
and after authentication in order to detect an active down-
640
negotiation attack. See below.)
642
Once a SASL security layer is established, the server MUST re-issue
643
the capability results, followed by an OK response. This is
644
necessary to protect against man-in-the-middle attacks that alter the
645
capabilities list prior to SASL negotiation. The capability results
646
MUST include all SASL mechanisms the server was capable of
647
negotiating with that client. This is done in order to allow the
648
client to detect an active down-negotiation attack. If a user-
649
oriented client detects such a down-negotiation attack, it SHOULD
650
either notify the user (it MAY give the user the opportunity to
651
continue with the ManageSieve session in this case) or close the
652
transport connection and indicate that a down-negotiation attack
653
might be in progress. If an automated client detects a down-
654
negotiation attack, it SHOULD return or log an error indicating that
655
a possible attack might be in progress and/or SHOULD close the
656
transport connection.
658
When both [TLS] and SASL security layers are in effect, the TLS
659
encoding MUST be applied (when sending data) after the SASL encoding.
661
Server implementations SHOULD support SASL proxy authentication so
662
that an administrator can administer a user's scripts. Proxy
663
authentication is when a user authenticates as herself/himself but
664
requests the server to act (authorize) as another user.
666
The authorization identity generated by this [SASL] exchange is a
667
"simple username" (in the sense defined in [SASLprep]), and both
668
client and server MUST use the [SASLprep] profile of the [StringPrep]
669
algorithm to prepare these names for transmission or comparison. If
670
preparation of the authorization identity fails or results in an
674
Melnikov & Martin Standards Track [Page 12]
676
RFC 5804 ManageSieve July 2010
679
empty string (unless it was transmitted as the empty string), the
680
server MUST fail the authentication.
682
If an AUTHENTICATE command fails with a NO response, the client MAY
683
try another authentication mechanism by issuing another AUTHENTICATE
684
command. In other words, the client may request authentication types
685
in decreasing order of preference.
687
Note that a failed (NO) response to the AUTHENTICATE command may
688
contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
689
NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed
690
description of the relevant conditions.
692
To ensure interoperability, both client and server implementations of
693
the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL
694
mechanism, as well as [PLAIN] over [TLS].
696
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
697
other email-related protocols; however, a longer-term goal is to
698
migrate email-related protocols from using PLAIN over TLS to SCRAM-
701
Examples (Note that long lines are folded for readability and are not
702
part of protocol exchange):
704
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
705
S: "SASL" "DIGEST-MD5 GSSAPI"
706
S: "SIEVE" "fileinto vacation"
710
C: Authenticate "DIGEST-MD5"
711
S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
712
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
713
cyxjaGFyc2V0PXV0Zi04"
714
C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
715
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
716
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
717
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
718
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
720
S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
730
Melnikov & Martin Standards Track [Page 13]
732
RFC 5804 ManageSieve July 2010
735
A slightly different variant of the same authentication exchange is:
737
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
738
S: "SASL" "DIGEST-MD5 GSSAPI"
739
S: "SIEVE" "fileinto vacation"
743
C: Authenticate "DIGEST-MD5"
745
S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
746
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
749
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
750
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
751
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
752
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
753
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
756
S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
786
Melnikov & Martin Standards Track [Page 14]
788
RFC 5804 ManageSieve July 2010
791
Another example demonstrating use of SASL PLAIN mechanism under TLS
792
follows. This example also demonstrate use of SASL "initial
793
response" (the second parameter to the Authenticate command):
795
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
798
S: "SIEVE" "fileinto vacation"
803
<TLS negotiation, further commands are under TLS layer>
804
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
807
S: "SIEVE" "fileinto vacation"
809
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
811
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
813
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
814
S: BYE "Too many failed authentication attempts"
815
<Server closes connection>
842
Melnikov & Martin Standards Track [Page 15]
844
RFC 5804 ManageSieve July 2010
847
The following example demonstrates use of SASL "initial response".
848
It also demonstrates that an empty response can be sent as a literal
849
and that negotiating a SASL security layer results in the server
850
re-issuing server capabilities:
852
C: AUTHENTICATE "GSSAPI" {1488+}
853
C: YIIE[...1480 octets here ...]dA==
855
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
856
[...114 octets here ...]
857
/yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
861
S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
863
C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
865
<Further commands/responses are under SASL security layer>
866
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
868
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
869
S: "SIEVE" "fileinto vacation"
871
S: "MAXREDIRECTS" "3"
874
2.1.1. Use of SASL PLAIN Mechanism over TLS
876
This section is normative for ManageSieve client implementations that
877
support SASL [PLAIN] over [TLS].
879
If a ManageSieve client is willing to use SASL PLAIN over TLS to
880
authenticate to the ManageSieve server, the client MUST verify the
881
server identity (see Section 2.2.1). If the server identity can't be
882
verified (e.g., the server has not provided any certificate, or if
883
the certificate verification fails), the client MUST NOT attempt to
884
authenticate using the SASL PLAIN mechanism.
886
2.2. STARTTLS Command
888
Support for STARTTLS command in servers is optional. Its
889
availability is advertised with "STARTTLS" capability as described in
892
The STARTTLS command requests commencement of a TLS [TLS]
893
negotiation. The negotiation begins immediately after the CRLF in
894
the OK response. After a client issues a STARTTLS command, it MUST
898
Melnikov & Martin Standards Track [Page 16]
900
RFC 5804 ManageSieve July 2010
903
NOT issue further commands until a server response is seen and the
904
TLS negotiation is complete.
906
The STARTTLS command is only valid in non-authenticated state. The
907
server remains in non-authenticated state, even if client credentials
908
are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL
909
mechanism MAY be used to authenticate once TLS client credentials are
910
successfully exchanged, but servers supporting the STARTTLS command
911
are not required to support the EXTERNAL mechanism.
913
After the TLS layer is established, the server MUST re-issue the
914
capability results, followed by an OK response. This is necessary to
915
protect against man-in-the-middle attacks that alter the capabilities
916
list prior to STARTTLS. This capability result MUST NOT include the
919
The client MUST discard cached capability information and replace it
920
with the new information. The server MAY advertise different
921
capabilities after STARTTLS.
927
<TLS negotiation, further commands are under TLS layer>
928
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
929
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
930
S: "SIEVE" "fileinto vacation"
935
2.2.1. Server Identity Check
937
During the TLS negotiation, the ManageSieve client MUST check its
938
understanding of the server hostname/IP address against the server's
939
identity as presented in the server Certificate message, in order to
940
prevent man-in-the-middle attacks. In this section, the client's
941
understanding of the server's identity is called the "reference
944
Checking is performed according to the following rules:
946
o If the reference identity is a hostname:
948
1. If a subjectAltName extension of the SRVName [X509-SRV],
949
dNSName [X509] (in that order of preference) type is present
950
in the server's certificate, then it SHOULD be used as the
954
Melnikov & Martin Standards Track [Page 17]
956
RFC 5804 ManageSieve July 2010
959
source of the server's identity. Matching is performed as
960
described in Section 2.2.1.1, with the exception that no
961
wildcard matching is allowed for SRVName type. If the
962
certificate contains multiple names (e.g., more than one
963
dNSName field), then a match with any one of the fields is
964
considered acceptable.
966
2. The client MAY use other types of subjectAltName for
967
performing comparison.
969
3. The server's identity MAY also be verified by comparing the
970
reference identity to the Common Name (CN) [RFC4519] value in
971
the leaf Relative Distinguished Name (RDN) of the subjectName
972
field of the server's certificate. This comparison is
973
performed using the rules for comparison of DNS names in
974
Section 2.2.1.1, below. Although the use of the Common Name
975
value is existing practice, it is deprecated, and
976
Certification Authorities are encouraged to provide
977
subjectAltName values instead. Note that the TLS
978
implementation may represent DNs in certificates according to
979
X.500 or other conventions. For example, some X.500
980
implementations order the RDNs in a DN using a left-to-right
981
(most significant to least significant) convention instead of
982
LDAP's right-to-left convention.
984
o When the reference identity is an IP address, the iPAddress
985
subjectAltName SHOULD be used by the client for comparison. The
986
comparison is performed as described in Section 2.2.1.2.
988
If the server identity check fails, user-oriented clients SHOULD
989
either notify the user (clients MAY give the user the opportunity to
990
continue with the ManageSieve session in this case) or close the
991
transport connection and indicate that the server's identity is
992
suspect. Automated clients SHOULD return or log an error indicating
993
that the server's identity is suspect and/or SHOULD close the
994
transport connection. Automated clients MAY provide a configuration
995
setting that disables this check, but MUST provide a setting that
998
Beyond the server identity check described in this section, clients
999
should be prepared to do further checking to ensure that the server
1000
is authorized to provide the service it is requested to provide. The
1001
client may need to make use of local policy information in making
1010
Melnikov & Martin Standards Track [Page 18]
1012
RFC 5804 ManageSieve July 2010
1015
2.2.1.1. Comparison of DNS Names
1017
If the reference identity is an internationalized domain name,
1018
conforming implementations MUST convert it to the ASCII Compatible
1019
Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
1020
before comparison with subjectAltName values of type dNSName.
1021
Specifically, conforming implementations MUST perform the conversion
1022
operation specified in Section 4 of [RFC3490] as follows:
1024
o in step 1, the domain name SHALL be considered a "stored string";
1026
o in step 3, set the flag called "UseSTD3ASCIIRules";
1028
o in step 4, process each label with the "ToASCII" operation; and
1030
o in step 5, change all label separators to U+002E (full stop).
1032
After performing the "to-ASCII" conversion, the DNS labels and names
1033
MUST be compared for equality according to the rules specified in
1034
Section 3 of [RFC3490]; i.e., once all label separators are replaced
1035
with U+002E (dot) they are compared in the case-insensitive manner.
1037
The '*' (ASCII 42) wildcard character is allowed in subjectAltName
1038
values of type dNSName, and then only as the left-most (least
1039
significant) DNS label in that value. This wildcard matches any
1040
left-most DNS label in the server name. That is, the subject
1041
*.example.com matches the server names a.example.com and
1042
b.example.com, but does not match example.com or a.b.example.com.
1044
2.2.1.2. Comparison of IP Addresses
1046
When the reference identity is an IP address, the identity MUST be
1047
converted to the "network byte order" octet string representation
1048
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
1049
octet string will contain exactly four octets. For IP Version 6, as
1050
specified in RFC 2460, the octet string will contain exactly sixteen
1051
octets. This octet string is then compared against subjectAltName
1052
values of type iPAddress. A match occurs if the reference identity
1053
octet string and value octet strings are identical.
1055
2.2.1.3. Comparison of Other subjectName Types
1057
Client implementations MAY support matching against subjectAltName
1058
values of other types as described in other documents.
1066
Melnikov & Martin Standards Track [Page 19]
1068
RFC 5804 ManageSieve July 2010
1073
The client sends the LOGOUT command when it is finished with a
1074
connection and wishes to terminate it. The server MUST reply with an
1075
OK response. The server MUST ignore commands issued by the client
1076
after the LOGOUT command.
1078
The client SHOULD wait for the OK response before closing the
1079
connection. This avoids the TCP connection going into the TIME_WAIT
1080
state on the server. In order to avoid going into the TIME_WAIT TCP
1081
state, the server MAY wait for a short while for the client to close
1082
the TCP connection first. Whether or not the server waits for the
1083
client to close the connection, it MUST then close the connection
1090
<connection is terminated>
1092
2.4. CAPABILITY Command
1094
The CAPABILITY command requests the server capabilities as described
1095
earlier in this document. It has no parameters.
1100
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
1102
S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
1103
S: "SIEVE" "fileinto vacation"
1107
2.5. HAVESPACE Command
1109
Arguments: String - name
1110
Number - script size
1112
The HAVESPACE command is used to query the server for available
1113
space. Clients specify the name they wish to save the script as and
1114
its size in octets. Both parameters can be used by the server to see
1115
if the script with the specified name and size is within a user's
1116
quota(s). For example, the server MAY use the script name to check
1117
if a script would be replaced or a new one would be created. Servers
1118
respond with a NO if storing a script with that name and size would
1122
Melnikov & Martin Standards Track [Page 20]
1124
RFC 5804 ManageSieve July 2010
1127
fail or OK otherwise. Clients SHOULD issue this command before
1128
attempting to place a script on the server.
1130
Note that the OK response from the HAVESPACE command does not
1131
constitute a guarantee of success as server disk space conditions
1132
could change between the client issuing the HAVESPACE and the client
1133
issuing the PUTSCRIPT commands. A QUOTA response code (see
1134
Section 1.3) remains a possible (albeit unlikely) response to a
1135
subsequent PUTSCRIPT with the same name and size.
1139
C: HAVESPACE "myscript" 999999
1140
S: NO (QUOTA/MAXSIZE) "Quota exceeded"
1142
C: HAVESPACE "foobar" 435
1145
2.6. PUTSCRIPT Command
1147
Arguments: String - Script name
1148
String - Script content
1150
The PUTSCRIPT command is used by the client to submit a Sieve script
1153
If the script already exists, upon success the old script will be
1154
overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
1155
fails in any way. A script of zero length SHOULD be disallowed.
1157
This command places the script on the server. It does not affect
1158
whether the script is processed on incoming mail, unless it replaces
1159
the script that is already active. The SETACTIVE command is used to
1160
mark a script as active.
1162
When submitting large scripts, clients SHOULD use the HAVESPACE
1163
command beforehand to query if the server is willing to accept a
1164
script of that size.
1166
The server MUST check the submitted script for validity, which
1167
includes checking that the script complies with the Sieve grammar
1168
[SIEVE] and that all Sieve extensions mentioned in the script's
1169
"require" statement(s) are supported by the Sieve interpreter. (Note
1170
that if the Sieve interpreter supports the Sieve "ihave" extension
1171
[I-HAVE], any unrecognized/unsupported extension mentioned in the
1172
"ihave" test MUST NOT cause the validation failure.) Other checks
1173
such as validating the supplied command arguments for each command
1174
MAY be performed. Essentially, the performed validation SHOULD be
1178
Melnikov & Martin Standards Track [Page 21]
1180
RFC 5804 ManageSieve July 2010
1183
the same as performed when compiling the script for execution.
1184
Implementations that use a binary representation to store compiled
1185
scripts can extend the validation to a full compilation, in order to
1186
avoid validating uploaded scripts multiple times.
1188
If the script fails the validation, the server MUST reply with a NO
1189
response. Any script that fails the validity test MUST NOT be stored
1190
on the server. The message given with a NO response MUST be human
1191
readable and SHOULD contain a specific error message giving the line
1192
number of the first error. Implementors should strive to produce
1193
helpful error messages similar to those given by programming language
1194
compilers. Client implementations should note that this may be a
1195
multiline literal string with more than one error message separated
1196
by CRLFs. The human-readable message is in the language returned in
1197
the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1198
encoded in UTF-8 [UTF-8].
1200
An OK response MAY contain the WARNINGS response code. In such a
1201
case the human-readable message that follows the OK response SHOULD
1202
contain a specific warning message (or messages) giving the line
1203
number(s) in the script that might contain errors not intended by the
1204
script writer. The human-readable message is in the language
1205
returned in the latest LANGUAGE capability (or in "i-default"; see
1206
Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
1207
response code SHOULD present the message to the user.
1234
Melnikov & Martin Standards Track [Page 22]
1236
RFC 5804 ManageSieve July 2010
1241
C: Putscript "foo" {31+}
1243
C: InvalidSieveCommand
1245
S: NO "line 2: Syntax error"
1247
C: Putscript "mysievescript" {110+}
1248
C: require ["fileinto"];
1250
C: if envelope :contains "to" "tmartin+sent" {
1251
C: fileinto "INBOX.sent";
1255
C: Putscript "myforwards" {190+}
1256
C: redirect "111@example.net";
1258
C: if size :under 10k {
1259
C: redirect "mobile@cell.example.com";
1262
C: if envelope :contains "to" "tmartin+lists" {
1263
C: redirect "lists@groups.example.com";
1265
S: OK (WARNINGS) "line 8: server redirect action
1266
limit is 2, this redirect might be ignored"
1268
2.7. LISTSCRIPTS Command
1270
This command lists the scripts the user has on the server. Upon
1271
success, a list of CRLF-separated script names (each represented as a
1272
quoted or literal string) is returned followed by an OK response. If
1273
there exists an active script, the atom ACTIVE is appended to the
1274
corresponding script name. The atom ACTIVE MUST NOT appear on more
1275
than one response line.
1290
Melnikov & Martin Standards Track [Page 23]
1292
RFC 5804 ManageSieve July 2010
1299
S: "vacation_script"
1302
S: "main_script" ACTIVE
1307
S: "main_script" active
1310
2.8. SETACTIVE Command
1312
Arguments: String - script name
1314
This command sets a script active. If the script name is the empty
1315
string (i.e., ""), then any active script is disabled. Disabling an
1316
active script when there is no script active is not an error and MUST
1317
result in an OK reply.
1319
If the script does not exist on the server, then the server MUST
1320
reply with a NO response. Such a reply SHOULD contain the
1321
NONEXISTENT response code.
1325
C: Setactive "vacationscript"
1332
S: No (NONEXISTENT) "There is no script by that name"
1335
S: No (NONEXISTENT) {31}
1336
S: There is no script by that name
1346
Melnikov & Martin Standards Track [Page 24]
1348
RFC 5804 ManageSieve July 2010
1351
2.9. GETSCRIPT Command
1353
Arguments: String - script name
1355
This command gets the contents of the specified script. If the
1356
script does not exist, the server MUST reply with a NO response.
1357
Such a reply SHOULD contain the NONEXISTENT response code.
1359
Upon success, a string with the contents of the script is returned
1360
followed by an OK response.
1364
C: Getscript "myscript"
1366
S: #this is my wonderful script
1367
S: reject "I reject all";
1371
2.10. DELETESCRIPT Command
1373
Arguments: String - script name
1375
This command is used to delete a user's Sieve script. Servers MUST
1376
reply with a NO response if the script does not exist. Such
1377
responses SHOULD include the NONEXISTENT response code.
1379
The server MUST NOT allow the client to delete an active script, so
1380
the server MUST reply with a NO response if attempted. Such a
1381
response SHOULD contain the ACTIVE response code. If a client wishes
1382
to delete an active script, it should use the SETACTIVE command to
1383
disable the script first.
1387
C: Deletescript "foo"
1390
C: Deletescript "baz"
1391
S: No (ACTIVE) "You may not delete an active script"
1402
Melnikov & Martin Standards Track [Page 25]
1404
RFC 5804 ManageSieve July 2010
1407
2.11. RENAMESCRIPT Command
1409
Arguments: String - Old Script name
1410
String - New Script name
1412
This command is used to rename a user's Sieve script. Servers MUST
1413
reply with a NO response if the old script does not exist (in which
1414
case the NONEXISTENT response code SHOULD be included), or a script
1415
with the new name already exists (in which case the ALREADYEXISTS
1416
response code SHOULD be included). Renaming the active script is
1417
allowed; the renamed script remains active.
1421
C: Renamescript "foo" "bar"
1424
C: Renamescript "baz" "bar"
1425
S: No "bar already exists"
1427
If the server doesn't support the RENAMESCRIPT command, the client
1428
can emulate it by performing the following steps:
1430
1. List available scripts with LISTSCRIPTS. If the script with the
1431
new script name exists, then the client should ask the user
1432
whether to abort the operation, to replace the script (by issuing
1433
the DELETESCRIPT <newname> after that), or to choose a different
1436
2. Download the old script with GETSCRIPT <oldname>.
1438
3. Upload the old script with the new name: PUTSCRIPT <newname>.
1440
4. If the old script was active (as reported by LISTSCRIPTS in step
1441
1), then make the new script active: SETACTIVE <newname>.
1443
5. Delete the old script: DELETESCRIPT <oldname>.
1445
Note that these steps don't describe how to handle various other
1446
error conditions (for example, NO response containing QUOTA response
1447
code in step 3). Error handling is left as an exercise for the
1458
Melnikov & Martin Standards Track [Page 26]
1460
RFC 5804 ManageSieve July 2010
1463
2.12. CHECKSCRIPT Command
1465
Arguments: String - Script content
1467
The CHECKSCRIPT command is used by the client to verify Sieve script
1468
validity without storing the script on the server.
1470
The server MUST check the submitted script for syntactic validity,
1471
which includes checking that all Sieve extensions mentioned in Sieve
1472
script "require" statement(s) are supported by the Sieve interpreter.
1473
(Note that if the Sieve interpreter supports the Sieve "ihave"
1474
extension [I-HAVE], any unrecognized/unsupported extension mentioned
1475
in the "ihave" test MUST NOT cause the syntactic validation failure.)
1476
If the script fails this test, the server MUST reply with a NO
1477
response. The message given with a NO response MUST be human
1478
readable and SHOULD contain a specific error message giving the line
1479
number of the first error. Implementors should strive to produce
1480
helpful error messages similar to those given by programming language
1481
compilers. Client implementations should note that this may be a
1482
multiline literal string with more than one error message separated
1483
by CRLFs. The human-readable message is in the language returned in
1484
the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1485
encoded in UTF-8 [UTF-8].
1489
C: CheckScript {31+}
1491
C: InvalidSieveCommand
1493
S: NO "line 2: Syntax error"
1495
A ManageSieve server supporting this command MUST NOT check if the
1496
script will put the current user over its quota limit.
1498
An OK response MAY contain the WARNINGS response code. In such a
1499
case, the human-readable message that follows the OK response SHOULD
1500
contain a specific warning message (or messages) giving the line
1501
number(s) in the script that might contain errors not intended by the
1502
script writer. The human-readable message is in the language
1503
returned in the latest LANGUAGE capability (or in "i-default"; see
1504
Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
1505
response code SHOULD present the message to the user.
1514
Melnikov & Martin Standards Track [Page 27]
1516
RFC 5804 ManageSieve July 2010
1521
Arguments: String - tag to echo back (optional)
1523
The NOOP command does nothing, beyond returning a response to the
1524
client. It may be used by clients for protocol re-synchronization or
1525
to reset any inactivity auto-logout timer on the server.
1527
The response to the NOOP command is always OK, followed by the TAG
1528
response code together with the supplied string. If no string was
1529
supplied in the NOOP command, the TAG response code MUST NOT be
1535
S: OK "NOOP completed"
1537
C: NOOP "STARTTLS-SYNC-42"
1539
S: STARTTLS-SYNC-42) "Done"
1541
2.14. Recommended Extensions
1543
The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
1544
capability with no parameters) defines a new UNAUTHENTICATE command,
1545
which allows a client to return the server to non-authenticated
1546
state. Support for this extension is RECOMMENDED.
1548
2.14.1. UNAUTHENTICATE Command
1550
The UNAUTHENTICATE command returns the server to the
1551
non-authenticated state. It doesn't affect any previously
1552
established TLS [TLS] or SASL (Section 2.1) security layer.
1554
The UNAUTHENTICATE command is only valid in authenticated state. If
1555
issued in a wrong state, the server MUST reject it with a NO
1558
The UNAUTHENTICATE command has no parameters.
1560
When issued in the authenticated state, the UNAUTHENTICATE command
1561
MUST NOT fail (i.e., it must never return anything other than OK or
1570
Melnikov & Martin Standards Track [Page 28]
1572
RFC 5804 ManageSieve July 2010
1577
URI scheme name: sieve
1581
URI scheme syntax: Described using ABNF [ABNF]. Some ABNF
1582
productions not defined below are from [URI-GEN].
1584
sieveurl = sieveurl-server / sieveurl-list-scripts /
1587
sieveurl-server = "sieve://" authority
1589
sieveurl-list-scripts = "sieve://" authority ["/"]
1591
sieveurl-script = "sieve://" authority "/"
1592
[owner "/"] scriptname
1594
authority = <defined in [URI-GEN]>
1597
;; %-encoded version of [SASL] authorization
1598
;; identity (script owner) or "userid".
1600
;; Empty owner is used to reference
1603
;; Note that ASCII characters such as " ", ";",
1604
;; "&", "=", "/" and "?" must be %-encoded
1605
;; as per rule specified in [URI-GEN].
1607
scriptname = 1*ochar
1608
;; %-encoded version of UTF-8 representation
1609
;; of the script name.
1610
;; Note that ASCII characters such as " ", ";",
1611
;; "&", "=", "/" and "?" must be %-encoded
1612
;; as per rule specified in [URI-GEN].
1614
ochar = unreserved / pct-encoded / sub-delims-sh /
1616
;; Same as [URI-GEN] 'pchar',
1617
;; but without ";", "&" and "=".
1619
unreserved = <defined in [URI-GEN]>
1621
pct-encoded = <defined in [URI-GEN]>
1626
Melnikov & Martin Standards Track [Page 29]
1628
RFC 5804 ManageSieve July 2010
1631
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
1633
;; Same as [URI-GEN] sub-delims,
1634
;; but without ";", "&" and "=".
1636
URI scheme semantics:
1638
A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
1639
server. The latter form is associated with the application/sieve
1640
MIME type defined in [SIEVE]. There is no MIME type associated
1641
with the former form of Sieve URI.
1643
The server form is used in the REFERRAL response code (see Section
1644
1.3) in order to designate another server where the client should
1645
perform its operations.
1647
The script form allows to retrieve (GETSCRIPT), update
1648
(PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the
1649
named script; however, the most typical action would be to
1650
retrieve the script. If the script name is empty (omitted), the
1651
URI requests that the client lists available scripts using the
1652
LISTSCRIPTS command.
1654
Encoding considerations:
1656
The script name and/or the owner, if present, is in UTF-8. Non--
1657
US-ASCII UTF-8 octets MUST be percent-encoded as described in
1658
[URI-GEN]. US-ASCII characters such as " " (space), ";", "&",
1659
"=", "/" and "?" MUST be %-encoded as described in [URI-GEN].
1660
Note that "&" and "?" are in this list in order to allow for
1663
Note that the empty owner (e.g., sieve://example.com//script) is
1664
different from the missing owner (e.g.,
1665
sieve://example.com/script) and is reserved for referencing global
1668
The user name (in the "authority" part), if present, is in UTF-8.
1669
Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
1672
Applications/protocols that use this URI scheme name:
1673
ManageSieve [RFC5804] clients and servers. Clients that can store
1674
user preferences in protocols such as [LDAP] or [ACAP].
1676
Interoperability considerations: None.
1682
Melnikov & Martin Standards Track [Page 30]
1684
RFC 5804 ManageSieve July 2010
1687
Security considerations:
1688
The <scriptname> part of a ManageSieve URL might potentially disclose
1689
some confidential information about the author of the script or,
1690
depending on a ManageSieve implementation, about configuration of the
1691
mail system. The latter might be used to prepare for a more complex
1692
attack on the mail system.
1694
Clients resolving ManageSieve URLs that wish to achieve data
1695
confidentiality and/or integrity SHOULD use the STARTTLS command (if
1696
supported by the server) before starting authentication, or use a
1697
SASL mechanism, such as GSSAPI, that provides a confidentiality
1700
Contact: Alexey Melnikov <alexey.melnikov@isode.com>
1702
Author/Change controller: IESG.
1704
References: This document and RFC 5228 [SIEVE].
1708
The following syntax specification uses the Augmented Backus-Naur
1709
Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
1710
rules as specified in Appendix A of the ABNF specification [ABNF].
1711
"UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
1713
Except as noted otherwise, all alphabetic characters are case-
1714
insensitive. The use of upper- or lowercase characters to define
1715
token strings is for editorial clarity only. Implementations MUST
1716
accept these strings in a case-insensitive fashion.
1718
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
1720
;; any TEXT-CHAR except QUOTED-SPECIALS
1722
QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
1724
QUOTED-SPECIALS = DQUOTE / "\"
1726
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
1727
;; <UTF8-2>, <UTF8-3>, and <UTF8-4>
1728
;; are defined in [UTF-8].
1730
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
1731
;; Any CHAR except ATOM-SPECIALS
1733
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
1738
Melnikov & Martin Standards Track [Page 31]
1740
RFC 5804 ManageSieve July 2010
1746
atom = 1*1024ATOM-CHAR
1749
;; MUST be registered with IANA
1751
auth-type = DQUOTE auth-type-name DQUOTE
1753
auth-type-name = iana-token
1754
;; as defined in SASL [SASL]
1756
command = (command-any / command-auth /
1757
command-nonauth) CRLF
1758
;; Modal based on state
1760
command-any = command-capability / command-logout /
1762
;; Valid in all states
1764
command-auth = command-getscript / command-setactive /
1765
command-listscripts / command-deletescript /
1766
command-putscript / command-checkscript /
1768
command-renamescript /
1769
command-unauthenticate
1770
;; Valid only in Authenticated state
1772
command-nonauth = command-authenticate / command-starttls
1773
;; Valid only when in Non-Authenticated
1776
command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
1779
command-capability = "CAPABILITY"
1781
command-deletescript = "DELETESCRIPT" SP sieve-name
1783
command-getscript = "GETSCRIPT" SP sieve-name
1785
command-havespace = "HAVESPACE" SP sieve-name SP number
1787
command-listscripts = "LISTSCRIPTS"
1789
command-noop = "NOOP" [SP string]
1794
Melnikov & Martin Standards Track [Page 32]
1796
RFC 5804 ManageSieve July 2010
1799
command-logout = "LOGOUT"
1801
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
1803
command-checkscript = "CHECKSCRIPT" SP sieve-script
1805
sieve-script = string
1807
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
1810
old-sieve-name = sieve-name
1812
new-sieve-name = sieve-name
1814
command-setactive = "SETACTIVE" SP active-sieve-name
1816
command-starttls = "STARTTLS"
1818
command-unauthenticate= "UNAUTHENTICATE"
1821
;; MUST be defined by a Standards Track or
1822
;; IESG-approved experimental protocol
1825
extension-data = extension-item *(SP extension-item)
1827
extension-item = extend-token / string / number /
1828
"(" [extension-data] ")"
1830
literal-c2s = "{" number "+}" CRLF *OCTET
1831
;; The number represents the number of
1833
;; This type of literal can only be sent
1834
;; from the client to the server.
1836
literal-s2c = "{" number "}" CRLF *OCTET
1837
;; Almost identical to literal-c2s,
1838
;; but with no '+' character.
1839
;; The number represents the number of
1841
;; This type of literal can only be sent
1842
;; from the server to the client.
1850
Melnikov & Martin Standards Track [Page 33]
1852
RFC 5804 ManageSieve July 2010
1855
number = (NZDIGIT *DIGIT) / "0"
1856
;; A 32-bit unsigned number
1857
;; with no extra leading zeros.
1858
;; (0 <= n < 4,294,967,296)
1861
;; <number> encoded as a <string>.
1863
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
1864
;; limited to 1024 octets between the <">s
1866
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
1867
["/" ("MAXSCRIPTS" / "MAXSIZE")] /
1869
resp-code-referral /
1870
"TRANSITION-NEEDED" / "TRYLATER" /
1871
"ACTIVE" / "NONEXISTENT" /
1872
"ALREADYEXISTS" / "WARNINGS" /
1876
resp-code-referral = "REFERRAL" SP sieveurl
1878
resp-code-sasl = "SASL" SP string
1880
resp-code-name = iana-token
1881
;; The response code name is hierarchical,
1882
;; separated by '/'.
1883
;; The response code name MUST NOT start
1886
resp-code-ext = resp-code-name [SP extension-data]
1887
;; unknown response codes MUST be tolerated
1890
response = response-authenticate /
1892
response-getscript /
1893
response-setactive /
1894
response-listscripts /
1895
response-deletescript /
1896
response-putscript /
1897
response-checkscript /
1898
response-capability /
1899
response-havespace /
1901
response-renamescript /
1906
Melnikov & Martin Standards Track [Page 34]
1908
RFC 5804 ManageSieve July 2010
1911
response-unauthenticate
1913
response-authenticate = *(string CRLF)
1914
((response-ok [response-capability]) /
1916
;; <response-capability> is REQUIRED if a
1917
;; SASL security layer was negotiated and
1918
;; MUST be omitted otherwise.
1920
response-capability = *(single-capability) response-oknobye
1922
single-capability = capability-name [SP string] CRLF
1924
capability-name = string
1926
;; Note that literal-s2c is allowed.
1928
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
1929
DQUOTE "SASL" DQUOTE SP sasl-mechs /
1930
DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
1931
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
1932
DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
1933
DQUOTE "STARTTLS" DQUOTE /
1934
DQUOTE "LANGUAGE" DQUOTE SP language /
1935
DQUOTE "VERSION" DQUOTE SP version /
1936
DQUOTE "OWNER" DQUOTE SP string
1937
;; Each capability conforms to
1938
;; the syntax for single-capability.
1939
;; Also, note that the capability name
1940
;; can be returned as either literal-s2c
1941
;; or quoted, even though only "quoted"
1942
;; string is shown above.
1944
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
1946
version-ext = DQUOTE ver-major "." ver-minor DQUOTE
1947
; Future versions specified in updates
1948
; to this document. An increment to
1949
; the ver-major means a backward-incompatible
1950
; change to the protocol, e.g., "3.5" (ver-major "3")
1951
; is not backward-compatible with any "2.X" version.
1952
; Any version "Z.W" MUST be backward compatible
1953
; with any version "Z.Q", where Q < W.
1954
; For example, version "2.4" is backward compatible
1955
; with version "2.0", "2.1", "2.2", and "2.3".
1962
Melnikov & Martin Standards Track [Page 35]
1964
RFC 5804 ManageSieve July 2010
1970
; Space-separated list of SASL mechanisms,
1971
; each SASL mechanism name complies with rules
1972
; specified in [SASL].
1975
sieve-extensions = string
1976
; Space-separated list of supported SIEVE extensions.
1980
; Contains <Language-Tag> from [RFC5646].
1983
notify-mechs = string
1984
; Space-separated list of URI schema parts
1985
; for supported notification [NOTIFY] methods.
1986
; MUST NOT be empty.
1988
response-deletescript = response-oknobye
1990
response-getscript = (sieve-script CRLF response-ok) /
1993
response-havespace = response-oknobye
1995
response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
1997
;; ACTIVE may only occur with one sieve-name
1999
response-logout = response-oknobye
2001
response-unauthenticate= response-oknobye
2002
;; "NO" response can only be returned when
2003
;; the command is issued in a wrong state
2004
;; or has a wrong number of parameters
2006
response-ok = "OK" [SP "(" resp-code ")"]
2008
;; The string contains human-readable text
2009
;; encoded as UTF-8.
2011
response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
2013
;; The string contains human-readable text
2014
;; encoded as UTF-8.
2018
Melnikov & Martin Standards Track [Page 36]
2020
RFC 5804 ManageSieve July 2010
2023
response-oknobye = response-ok / response-nobye
2025
response-noop = response-ok
2027
response-putscript = response-oknobye
2029
response-checkscript = response-oknobye
2031
response-renamescript = response-oknobye
2033
response-setactive = response-oknobye
2035
response-starttls = (response-ok response-capability) /
2039
;; See Section 1.6 for the full list of
2040
;; prohibited characters.
2041
;; Empty string is not allowed.
2043
active-sieve-name = string
2044
;; See Section 1.6 for the full list of
2045
;; prohibited characters.
2046
;; This is similar to <sieve-name>, but
2047
;; empty string is allowed and has a special
2050
string = quoted / literal-c2s / literal-s2c
2051
;; literal-c2s is only allowed when sent
2052
;; from the client to the server.
2053
;; literal-s2c is only allowed when sent
2054
;; from the server to the client.
2055
;; quoted is allowed in either direction.
2057
5. Security Considerations
2059
The AUTHENTICATE command uses SASL [SASL] to provide authentication
2060
and authorization services. Integrity and privacy services can be
2061
provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the
2062
security considerations for that mechanism apply.
2064
This protocol's transactions are susceptible to passive observers or
2065
man-in-the-middle attacks that alter the data, unless the optional
2066
encryption and integrity services of the SASL (via the AUTHENTICATE
2067
command) and/or [TLS] (via the STARTTLS command) are enabled, or an
2068
external security mechanism is used for protection. It may be useful
2069
to allow configuration of both clients and servers to refuse to
2070
transfer sensitive information in the absence of strong encryption.
2074
Melnikov & Martin Standards Track [Page 37]
2076
RFC 5804 ManageSieve July 2010
2079
If an implementation supports SASL mechanisms that are vulnerable to
2080
passive eavesdropping attacks (such as [PLAIN]), then the
2081
implementation MUST support at least one configuration where these
2082
SASL mechanisms are not advertised or used without the presence of an
2083
external security layer such as [TLS].
2085
Some response codes returned on failed AUTHENTICATE command may
2086
disclose whether or not the username is valid (e.g., TRANSITION-
2087
NEEDED), so server implementations SHOULD provide the ability to
2088
disable these features (or make them not conditional on a per-user
2089
basis) for sites concerned about such disclosure. In the case of
2090
ENCRYPT-NEEDED, if it is applied to all identities then no extra
2091
information is disclosed, but if it is applied on a per-user basis it
2092
can disclose information.
2094
A compromised or malicious server can use the TRANSITION-NEEDED
2095
response code to force the client that is configured to use a
2096
mechanism that does not disclose the user's password to the server
2097
(e.g., Kerberos), to send the bare password to the server. Clients
2098
SHOULD have the ability to disable the password transition feature,
2099
or disclose that risk to the user and offer the user an option of how
2102
6. IANA Considerations
2104
IANA has reserved TCP port number 4190 for use with the ManageSieve
2105
protocol described in this document.
2107
IANA has registered the "sieve" URI scheme defined in Section 3 of
2110
IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service
2113
IANA has created a new registry for ManageSieve capabilities. The
2114
registration template for ManageSieve capabilities is specified in
2115
Section 6.1. ManageSieve protocol capabilities MUST be specified in
2116
a Standards-Track or IESG-approved Experimental RFC.
2118
IANA has created a new registry for ManageSieve response codes. The
2119
registration template for ManageSieve response codes is specified in
2120
Section 6.3. ManageSieve protocol response codes MUST be specified
2121
in a Standards-Track or IESG-approved Experimental RFC.
2130
Melnikov & Martin Standards Track [Page 38]
2132
RFC 5804 ManageSieve July 2010
2135
6.1. ManageSieve Capability Registration Template
2138
Subject: ManageSieve Capability Registration
2140
Please register the following ManageSieve capability:
2144
Relevant publications:
2145
Person & email address to contact for further information:
2146
Author/Change controller:
2148
6.2. Registration of Initial ManageSieve Capabilities
2151
Subject: ManageSieve Capability Registration
2153
Please register the following ManageSieve capabilities:
2155
Capability name: IMPLEMENTATION
2156
Description: Its value contains the name of the server
2157
implementation and its version.
2158
Relevant publications: this RFC, Section 1.7.
2159
Person & email address to contact for further information:
2160
Alexey Melnikov <alexey.melnikov@isode.com>
2161
Author/Change controller: IESG.
2163
Capability name: SASL
2164
Description: Its value contains a space-separated list of SASL
2165
mechanisms supported by the server.
2166
Relevant publications: this RFC, Sections 1.7 and 2.1.
2167
Person & email address to contact for further information:
2168
Alexey Melnikov <alexey.melnikov@isode.com>
2169
Author/Change controller: IESG.
2171
Capability name: SIEVE
2172
Description: Its value contains a space-separated list of supported
2174
Relevant publications: this RFC, Section 1.7. Also [SIEVE].
2175
Person & email address to contact for further information:
2176
Alexey Melnikov <alexey.melnikov@isode.com>
2177
Author/Change controller: IESG.
2186
Melnikov & Martin Standards Track [Page 39]
2188
RFC 5804 ManageSieve July 2010
2191
Capability name: STARTTLS
2192
Description: This capability is returned if the server supports TLS
2194
Relevant publications: this RFC, Sections 1.7 and 2.2.
2195
Person & email address to contact for further information:
2196
Alexey Melnikov <alexey.melnikov@isode.com>
2197
Author/Change controller: IESG.
2199
Capability name: NOTIFY
2200
Description: This capability is returned if the server supports the
2201
'enotify' [NOTIFY] Sieve extension.
2202
Relevant publications: this RFC, Section 1.7.
2203
Person & email address to contact for further information:
2204
Alexey Melnikov <alexey.melnikov@isode.com>
2205
Author/Change controller: IESG.
2207
Capability name: MAXREDIRECTS
2208
Description: This capability returns the limit on the number of
2209
Sieve "redirect" actions a script can perform during a
2210
single evaluation. The value is a non-negative number
2211
represented as a ManageSieve string.
2212
Relevant publications: this RFC, Section 1.7.
2213
Person & email address to contact for further information:
2214
Alexey Melnikov <alexey.melnikov@isode.com>
2215
Author/Change controller: IESG.
2217
Capability name: LANGUAGE
2218
Description: The language (<Language-Tag> from [RFC5646]) currently
2219
used for human-readable error messages.
2220
Relevant publications: this RFC, Section 1.7.
2221
Person & email address to contact for further information:
2222
Alexey Melnikov <alexey.melnikov@isode.com>
2223
Author/Change controller: IESG.
2225
Capability name: OWNER
2226
Description: Its value contains the UTF-8-encoded name of the
2227
currently logged-in user ("authorization identity"
2228
according to RFC 4422).
2229
Relevant publications: this RFC, Section 1.7.
2230
Person & email address to contact for further information:
2231
Alexey Melnikov <alexey.melnikov@isode.com>
2232
Author/Change controller: IESG.
2242
Melnikov & Martin Standards Track [Page 40]
2244
RFC 5804 ManageSieve July 2010
2247
Capability name: VERSION
2248
Description: This capability is returned if the server is compliant
2249
with RFC 5804; i.e., that it supports RENAMESCRIPT,
2250
CHECKSCRIPT, and NOOP commands.
2251
Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13.
2252
Person & email address to contact for further information:
2253
Alexey Melnikov <alexey.melnikov@isode.com>
2254
Author/Change controller: IESG.
2256
6.3. ManageSieve Response Code Registration Template
2259
Subject: ManageSieve Response Code Registration
2261
Please register the following ManageSieve response code:
2264
Arguments (use ABNF to specify syntax, or the word NONE if none
2267
Published Specification(s):
2268
Person & email address to contact for further information:
2269
Author/Change controller:
2271
6.4. Registration of Initial ManageSieve Response Codes
2274
Subject: ManageSieve Response Code Registration
2276
Please register the following ManageSieve response codes:
2278
Response Code: AUTH-TOO-WEAK
2279
Arguments (use ABNF to specify syntax, or the word NONE if none can
2281
Purpose: This response code is returned in the NO response from
2282
an AUTHENTICATE command. It indicates that site
2283
security policy forbids the use of the requested
2284
mechanism for the specified authentication identity.
2285
Published Specification(s): [RFC5804]
2286
Person & email address to contact for further information:
2287
Alexey Melnikov <alexey.melnikov@isode.com>
2288
Author/Change controller: IESG.
2298
Melnikov & Martin Standards Track [Page 41]
2300
RFC 5804 ManageSieve July 2010
2303
Response Code: ENCRYPT-NEEDED
2304
Arguments (use ABNF to specify syntax, or the word NONE if none can
2306
Purpose: This response code is returned in the NO response from
2307
an AUTHENTICATE command. It indicates that site
2308
security policy requires the use of a strong
2309
encryption mechanism for the specified authentication
2310
identity and mechanism.
2311
Published Specification(s): [RFC5804]
2312
Person & email address to contact for further information:
2313
Alexey Melnikov <alexey.melnikov@isode.com>
2314
Author/Change controller: IESG.
2316
Response Code: QUOTA
2317
Arguments (use ABNF to specify syntax, or the word NONE if none can
2319
Purpose: If this response code is returned in the NO/BYE
2320
response, it means that the command would have placed
2321
the user above the site-defined quota constraints. If
2322
this response code is returned in the OK response, it
2323
can mean that the user is near its quota or that the
2324
user exceeded its quota, but the server supports soft
2326
Published Specification(s): [RFC5804]
2327
Person & email address to contact for further information:
2328
Alexey Melnikov <alexey.melnikov@isode.com>
2329
Author/Change controller: IESG.
2331
Response Code: QUOTA/MAXSCRIPTS
2332
Arguments (use ABNF to specify syntax, or the word NONE if none can
2334
Purpose: If this response code is returned in the NO/BYE
2335
response, it means that the command would have placed
2336
the user above the site-defined limit on the number of
2337
Sieve scripts. If this response code is returned in
2338
the OK response, it can mean that the user is near its
2339
quota or that the user exceeded its quota, but the
2340
server supports soft quotas. This response code is a
2341
more specific version of the QUOTA response code.
2342
Published Specification(s): [RFC5804]
2343
Person & email address to contact for further information:
2344
Alexey Melnikov <alexey.melnikov@isode.com>
2345
Author/Change controller: IESG.
2354
Melnikov & Martin Standards Track [Page 42]
2356
RFC 5804 ManageSieve July 2010
2359
Response Code: QUOTA/MAXSIZE
2360
Arguments (use ABNF to specify syntax, or the word NONE if none can
2362
Purpose: If this response code is returned in the NO/BYE
2363
response, it means that the command would have placed
2364
the user above the site-defined maximum script size.
2365
If this response code is returned in the OK response,
2366
it can mean that the user is near its quota or that
2367
the user exceeded its quota, but the server supports
2368
soft quotas. This response code is a more specific
2369
version of the QUOTA response code.
2370
Published Specification(s): [RFC5804]
2371
Person & email address to contact for further information:
2372
Alexey Melnikov <alexey.melnikov@isode.com>
2373
Author/Change controller: IESG.
2375
Response Code: REFERRAL
2376
Arguments (use ABNF to specify syntax, or the word NONE if none can
2377
be specified): <sieveurl>
2378
Purpose: This response code may be returned with a BYE result
2379
from any command, and includes a mandatory parameter
2380
that indicates what server to access to manage this
2381
user's Sieve scripts. The server will be specified by
2382
a Sieve URL (see Section 3). The scriptname portion
2383
of the URL MUST NOT be specified. The client should
2384
authenticate to the specified server and use it for
2385
all further commands in the current session.
2386
Published Specification(s): [RFC5804]
2387
Person & email address to contact for further information:
2388
Alexey Melnikov <alexey.melnikov@isode.com>
2389
Author/Change controller: IESG.
2392
Arguments (use ABNF to specify syntax, or the word NONE if none can
2393
be specified): <string>
2394
Purpose: This response code can occur in the OK response to a
2395
successful AUTHENTICATE command and includes the
2396
optional final server response data from the server as
2397
specified by [SASL].
2398
Published Specification(s): [RFC5804]
2399
Person & email address to contact for further information:
2400
Alexey Melnikov <alexey.melnikov@isode.com>
2401
Author/Change controller: IESG.
2410
Melnikov & Martin Standards Track [Page 43]
2412
RFC 5804 ManageSieve July 2010
2415
Response Code: TRANSITION-NEEDED
2416
Arguments (use ABNF to specify syntax, or the word NONE if none can
2418
Purpose: This response code occurs in a NO response of an
2419
AUTHENTICATE command. It indicates that the user name
2420
is valid, but the entry in the authentication database
2421
needs to be updated in order to permit authentication
2422
with the specified mechanism. This is typically done
2423
by establishing a secure channel using TLS, followed
2424
by authenticating once using the [PLAIN]
2425
authentication mechanism. The selected mechanism
2426
SHOULD then work for authentications in subsequent
2428
Published Specification(s): [RFC5804]
2429
Person & email address to contact for further information:
2430
Alexey Melnikov <alexey.melnikov@isode.com>
2431
Author/Change controller: IESG.
2433
Response Code: TRYLATER
2434
Arguments (use ABNF to specify syntax, or the word NONE if none can
2436
Purpose: A command failed due to a temporary server failure.
2437
The client MAY continue using local information and
2438
try the command later. This response code only make
2439
sense when returned in a NO/BYE response.
2440
Published Specification(s): [RFC5804]
2441
Person & email address to contact for further information:
2442
Alexey Melnikov <alexey.melnikov@isode.com>
2443
Author/Change controller: IESG.
2445
Response Code: ACTIVE
2446
Arguments (use ABNF to specify syntax, or the word NONE if none can
2448
Purpose: A command failed because it is not allowed on the
2449
active script, for example, DELETESCRIPT on the active
2450
script. This response code only makes sense when
2451
returned in a NO/BYE response.
2452
Published Specification(s): [RFC5804]
2453
Person & email address to contact for further information:
2454
Alexey Melnikov <alexey.melnikov@isode.com>
2455
Author/Change controller: IESG.
2466
Melnikov & Martin Standards Track [Page 44]
2468
RFC 5804 ManageSieve July 2010
2471
Response Code: NONEXISTENT
2472
Arguments (use ABNF to specify syntax, or the word NONE if none can
2474
Purpose: A command failed because the referenced script name
2475
doesn't exist. This response code only makes sense
2476
when returned in a NO/BYE response.
2477
Published Specification(s): [RFC5804]
2478
Person & email address to contact for further information:
2479
Alexey Melnikov <alexey.melnikov@isode.com>
2480
Author/Change controller: IESG.
2482
Response Code: ALREADYEXISTS
2483
Arguments (use ABNF to specify syntax, or the word NONE if none can
2485
Purpose: A command failed because the referenced script name
2486
already exists. This response code only makes sense
2487
when returned in a NO/BYE response.
2488
Published Specification(s): [RFC5804]
2489
Person & email address to contact for further information:
2490
Alexey Melnikov <alexey.melnikov@isode.com>
2491
Author/Change controller: IESG.
2493
Response Code: WARNINGS
2494
Arguments (use ABNF to specify syntax, or the word NONE if none can
2496
Purpose: This response code MAY be returned by the server in
2497
the OK response (but it might be returned with the NO/
2498
BYE response as well) and signals the client that even
2499
though the script is syntactically valid, it might
2500
contain errors not intended by the script writer.
2501
Published Specification(s): [RFC5804]
2502
Person & email address to contact for further information:
2503
Alexey Melnikov <alexey.melnikov@isode.com>
2504
Author/Change controller: IESG.
2507
Arguments (use ABNF to specify syntax, or the word NONE if none can
2508
be specified): string
2509
Purpose: This response code name is followed by a string
2510
specified in the command that caused this response.
2511
It is typically used for client state synchronization.
2512
Published Specification(s): [RFC5804]
2513
Person & email address to contact for further information:
2514
Alexey Melnikov <alexey.melnikov@isode.com>
2515
Author/Change controller: IESG.
2522
Melnikov & Martin Standards Track [Page 45]
2524
RFC 5804 ManageSieve July 2010
2527
7. Internationalization Considerations
2529
The LANGUAGE capability (see Section 1.7) allows a client to discover
2530
the current language used in all human-readable responses that might
2531
be returned at the end of any OK/NO/BYE response. Human-readable
2532
text in OK responses typically doesn't need to be shown to the user,
2533
unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT
2534
command that also contains the WARNINGS response code (Section 1.3).
2535
Human-readable text from NO/BYE responses is intended be shown to the
2536
user, unless the client can automatically handle failure of the
2537
command that caused such a response. Clients SHOULD use response
2538
codes (Section 1.3) for automatic error handling. Response codes MAY
2539
also be used by the client to present error messages in a language
2540
understood by the user, for example, if the LANGUAGE capability
2541
doesn't return a language understood by the user.
2543
Note that the human-readable text from OK (WARNINGS) or NO/BYE
2544
responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
2545
users that understand Sieve language. Such advanced users are often
2546
sophisticated enough to be able to handle whatever language the
2547
server is using, even if it is not their preferred language, and will
2548
want to see error/warning text no matter what language the server
2551
A client that generates Sieve script automatically, for example, if
2552
the script is generated without user intervention or from a UI that
2553
presents an abstract list of conditions and corresponding actions,
2554
SHOULD NOT present warning/error messages to the user, because the
2555
user might not even be aware that the client is using Sieve
2556
underneath. However, if the client has a debugging mode, such
2557
warnings/errors SHOULD be available in the debugging mode.
2559
Note that this document doesn't provide a way to modify the currently
2560
used language. It is expected that a future extension will address
2565
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
2566
Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
2567
Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
2568
Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
2569
Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
2570
Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus
2571
Westerlund, Tim Polk, and Julien Coloos for help with this document.
2572
Special thank you to Phil Pennock for providing text for the NOOP
2573
command, as well as finding various bugs in the document.
2578
Melnikov & Martin Standards Track [Page 46]
2580
RFC 5804 ManageSieve July 2010
2585
9.1. Normative References
2587
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2588
Specifications: ABNF", STD 68, RFC 5234, January 2008.
2590
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
2591
Configuration Access Protocol", RFC 2244, November
2594
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
2595
Encodings", RFC 4648, October 2006.
2597
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
2598
for specifying the location of services (DNS SRV)",
2599
RFC 2782, February 2000.
2601
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
2602
Requirement Levels", BCP 14, RFC 2119, March 1997.
2604
[NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for
2605
Network Interchange", RFC 5198, March 2008.
2607
[NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
2608
"Sieve Email Filtering: Extension for Notifications",
2609
RFC 5435, January 2009.
2611
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
2612
Languages", BCP 18, RFC 2277, January 1998.
2614
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
2615
6 (IPv6) Specification", RFC 2460, December 1998.
2617
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
2618
"Internationalizing Domain Names in Applications
2619
(IDNA)", RFC 3490, March 2003.
2621
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
2622
(LDAP): Schema for User Applications", RFC 4519, June
2625
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
2626
Languages", BCP 47, RFC 5646, September 2009.
2628
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
2634
Melnikov & Martin Standards Track [Page 47]
2636
RFC 5804 ManageSieve July 2010
2639
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
2640
and Security Layer (SASL)", RFC 4422, June 2006.
2642
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
2643
Names and Passwords", RFC 4013, February 2005.
2645
[SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N.
2646
Williams, "Salted Challenge Response Authentication
2647
Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC
2650
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
2651
Filtering Language", RFC 5228, January 2008.
2653
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
2654
Internationalized Strings ("stringprep")", RFC 3454,
2657
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
2658
Security (TLS) Protocol Version 1.2", RFC 5246, August
2661
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter,
2662
"Uniform Resource Identifier (URI): Generic Syntax",
2663
STD 66, RFC 3986, January 2005.
2665
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
2666
10646", STD 63, RFC 3629, November 2003.
2668
[X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2669
Housley, R., and W. Polk, "Internet X.509 Public Key
2670
Infrastructure Certificate and Certificate Revocation
2671
List (CRL) Profile", RFC 5280, May 2008.
2673
[X509-SRV] Santesson, S., "Internet X.509 Public Key
2674
Infrastructure Subject Alternative Name for Expression
2675
of Service Name", RFC 4985, August 2007.
2677
9.2. Informative References
2679
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication
2680
as a SASL Mechanism", RFC 2831, May 2000.
2682
[GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
2683
Authentication and Security Layer (SASL) Mechanism",
2684
RFC 4752, November 2006.
2690
Melnikov & Martin Standards Track [Page 48]
2692
RFC 5804 ManageSieve July 2010
2695
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
2696
RFC 5463, March 2009.
2698
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
2699
VERSION 4rev1", RFC 3501, March 2003.
2701
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
2702
(LDAP): Technical Specification Road Map", RFC 4510,
2705
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
2706
Security Layer (SASL) Mechanism", RFC 4616, August
2711
Alexey Melnikov (editor)
2713
5 Castle Business Village
2715
Hampton, Middlesex TW12 2BX
2718
EMail: Alexey.Melnikov@isode.com
2722
BeThereBeSquare, Inc.
2724
San Francisco, CA 94117
2727
Phone: +1 510 260-4175
2728
EMail: timmartin@alumni.cmu.edu
2746
Melnikov & Martin Standards Track [Page 49]
added
removed
pigeonhole/doc/rfc/managesieve.rfc5804.txt
