4
Sieve Working Group A. Melnikov, Ed.
5
Internet-Draft Isode Limited
6
Intended status: Standards Track T. Martin
7
Expires: July 21, 2009 BeThereBeSquare Inc.
11
A Protocol for Remotely Managing Sieve Scripts
12
draft-ietf-sieve-managesieve-09
16
This Internet-Draft is submitted to IETF in full conformance with the
17
provisions of BCP 78 and BCP 79.
19
Internet-Drafts are working documents of the Internet Engineering
20
Task Force (IETF), its areas, and its working groups. Note that
21
other groups may also distribute working documents as Internet-
24
Internet-Drafts are draft documents valid for a maximum of six months
25
and may be updated, replaced, or obsoleted by other documents at any
26
time. It is inappropriate to use Internet-Drafts as reference
27
material or to cite them other than as "work in progress."
29
The list of current Internet-Drafts can be accessed at
30
http://www.ietf.org/ietf/1id-abstracts.txt.
32
The list of Internet-Draft Shadow Directories can be accessed at
33
http://www.ietf.org/shadow.html.
35
This Internet-Draft will expire on July 21, 2009.
39
Copyright (c) 2009 IETF Trust and the persons identified as the
40
document authors. All rights reserved.
42
This document is subject to BCP 78 and the IETF Trust's Legal
43
Provisions Relating to IETF Documents
44
(http://trustee.ietf.org/license-info) in effect on the date of
45
publication of this document. Please review these documents
46
carefully, as they describe your rights and restrictions with respect
51
Sieve scripts allow users to filter incoming email. Message stores
55
Melnikov & Martin Expires July 21, 2009 [Page 1]
57
Internet-Draft ManageSieve January 2009
60
are commonly sealed servers so users cannot log into them, yet users
61
must be able to update their scripts on them. This document
62
describes a protocol "ManageSieve" for securely managing Sieve
63
scripts on a remote server. This protocol allows a user to have
64
multiple scripts, and also alerts a user to syntactically flawed
111
Melnikov & Martin Expires July 21, 2009 [Page 2]
113
Internet-Draft ManageSieve January 2009
118
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
119
1.1. Conventions used in this document . . . . . . . . . . . . 5
120
1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5
121
1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
122
1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6
123
1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8
124
1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8
125
1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9
126
1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9
127
1.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
129
2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12
130
2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12
131
2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17
132
2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17
133
2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18
134
2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21
135
2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21
136
2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21
137
2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22
138
2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 24
139
2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 25
140
2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 25
141
2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
142
2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
143
2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 27
144
2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 28
145
2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 29
146
2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 29
148
3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29
150
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32
152
5. Security Considerations . . . . . . . . . . . . . . . . . 38
154
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
155
6.1. ManageSieve Capability Registration Template . . . . . . . 39
156
6.2. Registration of Initial ManageSieve capabilities . . . . . 40
157
6.3. ManageSieve Response Code Registration Template . . . . . 42
158
6.4. Registration of Initial ManageSieve Response Codes . . . . 43
160
7. Internationalization Considerations . . . . . . . . . . . 48
162
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 49
167
Melnikov & Martin Expires July 21, 2009 [Page 3]
169
Internet-Draft ManageSieve January 2009
172
9. References . . . . . . . . . . . . . . . . . . . . . . . . 49
173
9.1. Normative References . . . . . . . . . . . . . . . . . . . 49
174
9.2. Informative References . . . . . . . . . . . . . . . . . . 51
176
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 51
223
Melnikov & Martin Expires July 21, 2009 [Page 4]
225
Internet-Draft ManageSieve January 2009
230
1.1. Conventions used in this document
232
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
233
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
234
document are to be interpreted as described in [KEYWORDS].
236
In examples, "C:" and "S:" indicate lines sent by the client and
237
server respectively. Line breaks that do not start a new "C:" or
238
"S:" exist for editorial reasons.
240
1.2. Commands and Responses
242
A ManageSieve connection consists of the establishment of a client/
243
server network connection, an initial greeting from the server, and
244
client/server interactions. These client/server interactions consist
245
of a client command, server data, and a server completion result
248
All interactions transmitted by client and server are in the form of
249
lines, that is, strings that end with a CRLF. The protocol receiver
250
of a ManageSieve client or server is either reading a line, or is
251
reading a sequence of octets with a known count followed by a line.
255
ManageSieve is a line oriented protocol much like [IMAP] or [ACAP],
256
which runs over TCP. There are three data types: atoms, numbers and
257
strings. Strings may be quoted or literal. See [ACAP] for detailed
258
descriptions of these types.
260
Each command consists of an atom (the command name) followed by zero
261
or more strings and numbers terminated by CRLF.
263
All client queries are replied to with either an OK, NO, or BYE
264
response. Each response may be followed by a response code (see
265
Section 1.4) and by a string consisting of human readable text in the
266
local language (as returned by the LANGUAGE capability, see
267
Section 1.8), encoded in [UTF-8]. The contents of the string SHOULD
268
be shown to the user and implementations MUST NOT attempt to parse
269
the message for meaning.
271
The BYE response SHOULD be used if the server wishes to close the
272
connection. A server may wish to do this because the client was idle
273
for too long or there were too many failed authentication attempts.
274
This response can be issued at any time and should be immediately
275
followed by a server hang-up of the connection. If a server has an
279
Melnikov & Martin Expires July 21, 2009 [Page 5]
281
Internet-Draft ManageSieve January 2009
284
inactivity timeout resulting in client autologout it MUST be no less
285
than 30 minutes after successful authentication. The inactivity
286
timeout MAY be less before authentication.
290
An OK, NO, or BYE response from the server MAY contain a response
291
code to describe the event in a more detailed machine parsable
292
fashion. A response code consists of data inside parentheses in the
293
form of an atom, possibly followed by a space and arguments.
294
Response codes are defined when there is a specific action that a
295
client can take based upon the additional information. In order to
296
support future extension, the response code is represented as a
297
slash-separated (Solidus, %x2F) hierarchy with each level of
298
hierarchy representing increasing detail about the error. Response
299
codes MUST NOT start with the Solidus character. Clients MUST
300
tolerate additional hierarchical response code detail which they
301
don't understand. For example, if the client supports the "QUOTA"
302
response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response
303
code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
305
Client implementations MUST tolerate (ignore) response codes that
306
they do not recognize.
308
The currently defined response codes are:
312
This response code is returned in the NO or BYE response from an
313
AUTHENTICATE command. It indicates that site security policy forbids
314
the use of the requested mechanism for the specified authentication
319
This response code is returned in the NO or BYE response from an
320
AUTHENTICATE command. It indicates that site security policy
321
requires the use of a strong encryption mechanism for the specified
322
authentication identity and mechanism.
326
If this response code is returned in the NO/BYE response, it means
327
that the command would have placed the user above the site-defined
328
quota constraints. If this response code is returned in the OK
329
response, it can mean that the user's storage is near its quota, or
330
it can mean that the account exceeded its quota but that that
331
condition is being allowed by the server (the server supports so
335
Melnikov & Martin Expires July 21, 2009 [Page 6]
337
Internet-Draft ManageSieve January 2009
340
called "soft quotas"). The QUOTA response code has 2 more detailed
341
variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts)
342
and "QUOTA/MAXSIZE" (the maximum script size).
346
This response code may be returned with a BYE result from any
347
command, and includes a mandatory parameter that indicates what
348
server to access to manage this user's sieve scripts. The server
349
will be specified by a Sieve URL (see Section 3). The scriptname
350
portion of the URL MUST NOT be specified. The client should
351
authenticate to the specified server and use it for all further
352
commands in the current session.
356
This response code can occur in the OK response to a successful
357
AUTHENTICATE command and includes the optional final server response
358
data from the server as specified by [SASL].
362
This response code occurs in a NO response of an AUTHENTICATE
363
command. It indicates that the user name is valid, but the entry in
364
the authentication database needs to be updated in order to permit
365
authentication with the specified mechanism. This is typically done
366
by establishing a secure channel using TLS, verifying server identity
367
as specified in Section 2.2.1, and finally authenticating once using
368
the [PLAIN] authentication mechanism. The selected mechanism SHOULD
369
then work for authentications in subsequent sessions.
371
This condition can happen if a user has an entry in a system
372
authentication database such as Unix /etc/passwd, but does not have
373
credentials suitable for use by the specified mechanism.
377
A command failed due to a temporary server failure. The client MAY
378
continue using local information and try the command later. This
379
response code only makes sense when returned in a NO/BYE response.
383
A command failed because it is not allowed on the active script. For
384
example DELETESCRIPT on the active script. This response code only
385
makes sense when returned in a NO/BYE response.
391
Melnikov & Martin Expires July 21, 2009 [Page 7]
393
Internet-Draft ManageSieve January 2009
396
A command failed because the referenced script name doesn't exist.
397
This response code only makes sense when returned in a NO/BYE
402
A command failed because the referenced script name already exists.
403
This response code only makes sense when returned in a NO/BYE
408
This response code name is followed by a string specified in the
409
command. See Section 2.13 for a possible use case.
413
This response code MAY be returned by the server in the OK response
414
(but it might be returned with the NO/BYE response as well) and
415
signals the client that even though the script is syntactically
416
valid, it might contain errors not intended by the script writer.
417
This response code is typically returned in response to PUTSCRIPT
418
and/or CHECKSCRIPT commands. A client seeing such response code
419
SHOULD present the returned warning text to the user.
423
A user may have multiple Sieve scripts on the server, yet only one
424
script may be used for filtering of incoming messages. This is the
425
active script. Users may have zero or one active scripts and MUST
426
use the SETACTIVE command described below for changing the active
427
script or disabling Sieve processing. For example, a user may have
428
an everyday script they normally use and a special script they use
429
when they go on vacation. Users can change which script is being
430
used without having to download and upload a script stored somewhere
435
Servers SHOULD impose quotas to prevent malicious users from
436
overflowing available storage. If a command would place a user over
437
a quota setting, servers that impose such quotas MUST reply with a NO
438
response containing the QUOTA response code. Client implementations
439
MUST be able to handle commands failing because of quota
447
Melnikov & Martin Expires July 21, 2009 [Page 8]
449
Internet-Draft ManageSieve January 2009
454
A Sieve script name is a sequence of Unicode characters encoded in
455
UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition
456
(Section 2 of [NET-UNICODE]), with the additional restriction of
457
prohibiting the following Unicode characters:
459
o 0000-001F; [CONTROL CHARACTERS]
463
o 0080-009F; [CONTROL CHARACTERS]
465
o 2028; LINE SEPARATOR
467
o 2029; PARAGRAPH SEPARATOR
469
Sieve script names MUST be at least one octet (and hense Unicode
470
character) long. Zero octets script name has a special meaning (see
471
Section 2.8). Servers MUST allow names of up to 128 Unicode
472
characters in length (which can take up to 512 bytes when encoded in
473
UTF-8, not counting the terminating NUL), and MAY allow longer names.
474
A server that receives a script name longer than its internal limit
475
MUST reject the corresponding operation, in particular it MUST NOT
476
truncate the script name.
480
Server capabilities are sent automatically by the server upon a
481
client connection, or after successful STARTTLS and AUTHENTICATE
482
(which establishes a SASL security layer) commands. Capabilities may
483
change immediately after a successfully completed STARTTLS command,
484
and/or immediately after a successfully completed AUTHENTICATE
485
command, and/or after a successfully completed UNAUTHENTICATE command
486
(see Section 2.14.1). Capabilities MUST remain static at all other
489
Clients MAY request the capabilities at a later time by issuing the
490
CAPABILITY command described later. The capabilities consist of a
491
series of lines each with one or two strings. The first string is
492
the name of the capability, which is case-insensitive. The second
493
optional string is the value associated with that capability. Order
494
of capabilities is arbitrary, but each capability name can appear at
497
The following capabilities are defined in this document:
499
IMPLEMENTATION - Name of implementation and version. This capability
503
Melnikov & Martin Expires July 21, 2009 [Page 9]
505
Internet-Draft ManageSieve January 2009
508
MUST always be returned by the server.
510
SASL - List of SASL mechanisms supported by the server, each
511
separated by a space. This list can be empty if and only if STARTTLS
512
is also advertised. This means that the client must negotiate TLS
513
encryption with STARTTLS first, at which point the SASL capability
514
will list a non empty list of SASL mechanisms.
516
SIEVE - List of space separated Sieve extensions (as listed in Sieve
517
"require" action [SIEVE]) supported by the Sieve engine. This
518
capability MUST always be returned by the server.
520
STARTTLS - If TLS [TLS] is supported by this implementation. Before
521
advertising this capability a server MUST verify to the best of its
522
ability that TLS can be successfully negotiated by a client with
523
common cipher suites. Specifically, a server should verify that a
524
server certificate has been installed and that the TLS subsystem has
525
successfully initialized. This capability SHOULD NOT be advertised
526
once STARTTLS or AUTHENTICATE command completes successfully. Client
527
and server implementations MUST implement the STARTTLS extension.
529
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
530
actions a script can perform during a single evaluation. Note, that
531
this is different from the total number of "redirect" actions a
532
script can contain. The value is a non-negative number represented
533
as a ManageSieve string.
535
NOTIFY - A space separated list of URI schema parts for supported
536
notification methods. This capability MUST be specified if the Sieve
537
implementation supports the "enotify" extension [NOTIFY].
539
LANGUAGE - The language (<Language-Tag> from [RFC4646]) currently
540
used for human readable error messages. If this capability is not
541
returned, the "i-default" [RFC2277] language is assumed. Note that
542
the current language MAY be per-user configurable (i.e. it MAY change
543
after authentication).
545
OWNER - The canonical name of the logged in user (SASL "authorization
546
identity") encoded in UTF-8. This capability MUST NOT be returned in
547
unauthenticated state and SHOULD be returned once the AUTHENTICATE
550
VERSION - This capability MUST be returned by servers compliant with
551
this document or its successor. For servers compliant with this
552
document the capability value is the string "1.0". Lack of this
553
capability means that the server predates this specification and thus
554
doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT and
559
Melnikov & Martin Expires July 21, 2009 [Page 10]
561
Internet-Draft ManageSieve January 2009
564
Section 2.14 defines some additional ManageSieve extensions and their
565
respective capabilities.
567
A server implementation MUST return SIEVE, IMPLEMENTATION and VERSION
570
A client implementation MUST ignore any listed capabilities that it
575
S: "IMPlemENTATION" "Example1 ManageSieved v001"
576
S: "SASl" "DIGEST-MD5 GSSAPI"
577
S: "SIeVE" "fileinto vacation"
579
S: "NOTIFY" "xmpp mailto"
580
S: "MAXREdIRECTS" "5"
584
After successful authentication this might look like this:
588
S: "IMPlemENTATION" "Example1 ManageSieved v001"
589
S: "SASl" "DIGEST-MD5 GSSAPI"
590
S: "SIeVE" "fileinto vacation"
591
S: "NOTIFY" "xmpp mailto"
592
S: "OWNER" "alexey@example.com"
593
S: "MAXREdIRECTS" "5"
599
The ManageSieve protocol assumes a reliable data stream such as that
600
provided by TCP. When TCP is used, a ManageSieve server typically
601
listens on port [[anchor7: To-be-assigned by IANA]].
603
Before opening the TCP connection, the ManageSieve client first MUST
604
resolve the Domain Name System (DNS) hostname associated with the
605
receiving entity and determine the appropriate TCP port for
606
communication with the receiving entity. The process is as follows:
608
1. Attempt to resolve the hostname using a [DNS-SRV] Service of
609
"sieve" and a Proto of "tcp" for the target domain (e.g.
610
"example.net"), resulting in resource records such as
611
"_sieve._tcp.example.net.". The result of the SRV lookup, if
615
Melnikov & Martin Expires July 21, 2009 [Page 11]
617
Internet-Draft ManageSieve January 2009
620
successful, will be one or more combinations of a port and
621
hostname; the ManageSieve client MUST resolve the returned
622
hostnames to IPv4/IPv6 addresses according to returned SRV record
623
weight. IP addresses from the first successfully resolved
624
hostname (with the corresponding port number returned by SRV
625
lookup) are used to connect to the server. If connection using
626
one of the IP addresses fails, the next resolved IP address is
627
used to connect. If connection to all resolved IP addresses
628
fails, then the resolution/connect is repeated for the next
629
hostname returned by SRV lookup.
631
2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
632
IPv6 address record resolution to determine the IP address, where
633
the port used is the default ManageSieve port of [[anchor8: To-
634
be-assigned by IANA]].
639
This section and its subsections describes valid ManageSieve
640
commands. Upon initial connection to the server the client's session
641
is in non-authenticated state. Prior to successful authentication
642
only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see
643
Section 2.13) commands are valid. ManageSieve extensions MAY define
644
other commands which are valid in non-authenticated state. Servers
645
MUST reject all other commands with a NO response. Clients may
646
pipeline commands (send more than one command at a time without
647
waiting for completion of the first command ). However, a group of
648
commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS
649
or a HAVESPACE command anywhere but the last command in the list.
651
(*) - The only exception to this rule is when the AUTHENTICATE
652
command contains an initial response for a SASL mechanism that allows
653
clients to send data first, the mechanism is known to complete in one
654
round-trip and the mechanism doesn't negotiate a SASL security layer.
655
Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL
658
2.1. AUTHENTICATE Command
660
Arguments: String - mechanism
661
String - initial data (optional)
663
The AUTHENTICATE command indicates a SASL [SASL] authentication
664
mechanism to the server. If the server supports the requested
665
authentication mechanism, it performs an authentication protocol
666
exchange to identify and authenticate the user. Optionally, it also
667
negotiates a security layer for subsequent protocol interactions. If
671
Melnikov & Martin Expires July 21, 2009 [Page 12]
673
Internet-Draft ManageSieve January 2009
676
the requested authentication mechanism is not supported, the server
677
rejects the AUTHENTICATE command by sending the NO response.
679
The authentication protocol exchange consists of a series of server
680
challenges and client responses that are specific to the selected
681
authentication mechanism. A server challenge consists of a string
682
(quoted or literal) followed by a CRLF. The contents of the string
683
is a base-64 encoding [BASE64] of the SASL data. A client response
684
consists of a string (quoted or literal) with the base-64 encoding of
685
the SASL data followed by a CRLF. If the client wishes to cancel the
686
authentication exchange, it issues a string containing a single "*".
687
If the server receives such a response, it MUST reject the
688
AUTHENTICATE command by sending an NO reply.
690
Note that an empty challenge/response is sent as an empty string. If
691
the mechanism dictates that the final response is sent by the server
692
this data MAY be placed within the data portion of the SASL response
693
code to save a round trip.
695
The optional initial-response argument to the AUTHENTICATE command is
696
used to save a round trip when using authentication mechanisms that
697
are defined to send no data in the initial challenge. When the
698
initial-response argument is used with such a mechanism, the initial
699
empty challenge is not sent to the client and the server uses the
700
data in the initial-response argument as if it were sent in response
701
to the empty challenge. If the initial-response argument to the
702
AUTHENTICATE command is used with a mechanism that sends data in the
703
initial challenge, the server MUST reject the AUTHENTICATE command by
704
sending the NO response.
706
The service name specified by this protocol's profile of SASL is
709
Reauthentication is not supported by ManageSieve protocol's profile
710
of SASL. I.e. after a successfully completed AUTHENTICATE command,
711
no more AUTHENTICATE commands may be issued in the same session.
712
After a successful AUTHENTICATE command completes, a server MUST
713
reject any further AUTHENTICATE commands with a NO reply. However
714
note that a server may implement UNAUTHENTICATE extension described
717
If a security layer is negotiated through the SASL authentication
718
exchange, it takes effect immediately following the CRLF that
719
concludes the successful authentication exchange for the client, and
720
the CRLF of the OK response for the server.
722
When a security layer takes effect, the ManageSieve protocol is reset
723
to the initial state (the state in ManageSieve after a client has
727
Melnikov & Martin Expires July 21, 2009 [Page 13]
729
Internet-Draft ManageSieve January 2009
732
connected to the server). The server MUST discard any knowledge
733
obtained from the client which was not obtained from the SASL (or
734
TLS) negotiation itself. Likewise, the client MUST discard any
735
knowledge obtained from the server, such as the list of ManageSieve
736
extensions, which was not obtained from the SASL (and/or TLS)
737
negotiation itself. (Note that a client MAY compare the advertised
738
SASL mechanisms before and after authentication in order to detect an
739
active down-negotiation attack. See below.)
741
Once a SASL security layer is established, the server MUST re-issue
742
the capability results, followed by an OK response. This is
743
necessary to protect against man-in-the-middle attacks which alter
744
the capabilities list prior to SASL negotiation. The capability
745
results MUST include all SASL mechanisms the server was capable of
746
negotiating with that client. This is done in order to allow the
747
client to detect active down-negotiation attack. If a user-oriented
748
client detects such down-negotiation attack, it SHOULD either notify
749
the user (it MAY give the user the opportunity to continue with the
750
ManageSieve session in this case) or close the transport connection
751
and indicate that a down-negotiation attack might be in progress. If
752
an automated client detects down-negotiation attack, it SHOULD return
753
or log an error indicating that a possible attack might be in
754
progress and/or SHOULD close the transport connection.
756
When both [TLS] and SASL security layers are in effect, the TLS
757
encoding MUST be applied (when sending data) after the SASL encoding.
759
Server implementations SHOULD support SASL proxy authentication so
760
that an administrator can administer a user's scripts. Proxy
761
authentication is when a user authenticates as herself/himself but
762
requests the server to act (authorize) as another user.
764
The authorization identity generated by this [SASL] exchange is a
765
"simple username" (in the sense defined in [SASLprep]), and both
766
client and server MUST use the [SASLprep] profile of the [StringPrep]
767
algorithm to prepare these names for transmission or comparison. If
768
preparation of the authorization identity fails or results in an
769
empty string (unless it was transmitted as the empty string), the
770
server MUST fail the authentication.
772
If an AUTHENTICATE command fails with a NO response, the client MAY
773
try another authentication mechanism by issuing another AUTHENTICATE
774
command. In other words, the client may request authentication types
775
in decreasing order of preference.
777
Note that a failed (NO) response to the AUTHENTICATE command may
778
contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
779
NEEDED or TRANSITION-NEEDED. See Section 1.4 for detailed
783
Melnikov & Martin Expires July 21, 2009 [Page 14]
785
Internet-Draft ManageSieve January 2009
788
description of the relevant conditions.
790
To ensure interoperability, both client and server implementations of
791
the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM]
792
SASL mechanism, as well as [PLAIN] over [TLS].
794
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
795
other email related protocols, however a longer term goal is to
796
migrate email related protocols from using PLAIN over TLS to SCRAM-
797
HMAC-SHA-1 mechanism.
799
Examples (Note that long lines are folded for readability and are not
800
part of protocol exchange):
802
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
803
S: "SASL" "DIGEST-MD5 GSSAPI"
804
S: "SIEVE" "fileinto vacation"
808
C: Authenticate "DIGEST-MD5"
809
S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
810
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
811
cyxjaGFyc2V0PXV0Zi04"
812
C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
813
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
814
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
815
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
816
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
818
S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
821
A slightly different variant of the same authentication exchange:
839
Melnikov & Martin Expires July 21, 2009 [Page 15]
841
Internet-Draft ManageSieve January 2009
844
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
845
S: "SASL" "DIGEST-MD5 GSSAPI"
846
S: "SIEVE" "fileinto vacation"
850
C: Authenticate "DIGEST-MD5"
852
S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
853
9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
856
C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
857
QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
858
aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
859
N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
860
ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
863
S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
867
Another example demonstrating use of SASL PLAIN mechanism under TLS.
868
This example also demonstrate use of SASL "initial response" (the
869
second parameter to the Authenticate command):
871
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
874
S: "SIEVE" "fileinto vacation"
879
<TLS negotiation, further commands are under TLS layer>
880
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
883
S: "SIEVE" "fileinto vacation"
885
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
887
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
889
C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
890
S: BYE "Too many failed authentication attempts"
891
<Server closes connection>
895
Melnikov & Martin Expires July 21, 2009 [Page 16]
897
Internet-Draft ManageSieve January 2009
900
The following example demonstrates use of SASL "initial response".
901
It also demonstrates that an empty response can be sent as a literal,
902
and that negotiation a SASL security layer results in the server
903
reissuing server capabilities:
905
C: AUTHENTICATE "GSSAPI" {1488+}
906
C: YIIE[...1480 octets here ...]dA==
908
S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
909
[...114 octets here ...]
910
/yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
914
S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
916
C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
918
<Further commands/responses are under SASL security layer>
919
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
921
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
922
S: "SIEVE" "fileinto vacation"
924
S: "MAXREDIRECTS" "3"
927
2.1.1. Use of SASL PLAIN mechanism over TLS
929
This section is normative for ManageSieve client implementations that
930
support SASL [PLAIN] over [TLS].
932
If a ManageSieve client is willing to use SASL PLAIN over TLS to
933
authenticate to the ManageSieve server, the client MUST verify the
934
server identity (see Section 2.2.1). If the server identity can't be
935
verified (e.g. the server has not provided any certificate, or if the
936
certificate verification fails) the client MUST NOT attempt to
937
authenticate using the SASL PLAIN mechanism.
939
2.2. STARTTLS Command
941
Support for STARTTLS command in servers is optional. Its
942
availability is advertised with "STARTTLS" capability as described in
945
The STARTTLS command requests commencement of a TLS [TLS]
946
negotiation. The negotiation begins immediately after the CRLF in
947
the OK response. After a client issues a STARTTLS command, it MUST
951
Melnikov & Martin Expires July 21, 2009 [Page 17]
953
Internet-Draft ManageSieve January 2009
956
NOT issue further commands until a server response is seen and the
957
TLS negotiation is complete.
959
The STARTTLS command is only valid in non-authenticated state. The
960
server remains in non-authenticated state, even if client credentials
961
are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL
962
mechanism MAY be used to authenticate once TLS client credentials are
963
successfully exchanged, but servers supporting the STARTTLS command
964
are not required to support the EXTERNAL mechanism.
966
After the TLS layer is established, the server MUST re-issue the
967
capability results, followed by an OK response. This is necessary to
968
protect against man-in-the-middle attacks which alter the
969
capabilities list prior to STARTTLS. This capability result MUST NOT
970
include the STARTTLS capability.
972
The client MUST discard cached capability information and replace it
973
with the new information. The server MAY advertise different
974
capabilities after STARTTLS.
980
<TLS negotiation, further commands are under TLS layer>
981
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
982
S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
983
S: "SIEVE" "fileinto vacation"
988
2.2.1. Server Identity Check
990
During the TLS negotiation, the ManageSieve client MUST check its
991
understanding of the server hostname/IP address against the server's
992
identity as presented in the server Certificate message, in order to
993
prevent man-in-the-middle attacks. In this section, the client's
994
understanding of the server's identity is called the "reference
997
Checking is performed according to the following rules:
999
o If the reference identity is a hostname:
1001
1. If a subjectAltName extension of the SRVName [X509-SRV],
1002
dNSName [X509] (in that order of preference) type is present
1003
in the server's certificate, then it SHOULD be used as the
1007
Melnikov & Martin Expires July 21, 2009 [Page 18]
1009
Internet-Draft ManageSieve January 2009
1012
source of the server's identity. Matching is performed as
1013
described in Section 2.2.1.1, with the exception that no
1014
wildcard matching is allowed for SRVName type. If the
1015
certificate contains multiple names (e.g., more than one
1016
dNSName field), then a match with any one of the fields is
1017
considered acceptable.
1019
2. The client MAY use other types of subjectAltName for
1020
performing comparison.
1022
3. The server's identity MAY also be verified by comparing the
1023
reference identity to the Common Name (CN) [RFC4519] value in
1024
the leaf Relative Distinguished Name (RDN) of the subjectName
1025
field of the server's certificate. This comparison is
1026
performed using the rules for comparison of DNS names in
1027
Section 2.2.1.1, below. Although the use of the Common Name
1028
value is existing practice, it is deprecated, and
1029
Certification Authorities are encouraged to provide
1030
subjectAltName values instead. Note that the TLS
1031
implementation may represent DNs in certificates according to
1032
X.500 or other conventions. For example, some X.500
1033
implementations order the RDNs in a DN using a left-to-right
1034
(most significant to least significant) convention instead of
1035
LDAP's right- to-left convention.
1037
o When the reference identity is an IP address, the iPAddress
1038
subjectAltName SHOULD be used by the client for comparison. The
1039
comparison is performed as described in Section 2.2.1.2.
1041
If the server identity check fails, user-oriented clients SHOULD
1042
either notify the user (clients MAY give the user the opportunity to
1043
continue with the ManageSieve session in this case) or close the
1044
transport connection and indicate that the server's identity is
1045
suspect. Automated clients SHOULD return or log an error indicating
1046
that the server's identity is suspect and/or SHOULD close the
1047
transport connection. Automated clients MAY provide a configuration
1048
setting that disables this check, but MUST provide a setting which
1051
Beyond the server identity check described in this section, clients
1052
should be prepared to do further checking to ensure that the server
1053
is authorized to provide the service it is requested to provide. The
1054
client may need to make use of local policy information in making
1063
Melnikov & Martin Expires July 21, 2009 [Page 19]
1065
Internet-Draft ManageSieve January 2009
1068
2.2.1.1. Comparison of DNS Names
1070
If the reference identity is an internationalized domain name,
1071
conforming implementations MUST convert it to the ASCII Compatible
1072
Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
1073
before comparison with subjectAltName values of type dNSName.
1074
Specifically, conforming implementations MUST perform the conversion
1075
operation specified in Section 4 of [RFC3490] as follows:
1077
o in step 1, the domain name SHALL be considered a "stored string";
1079
o in step 3, set the flag called "UseSTD3ASCIIRules";
1081
o in step 4, process each label with the "ToASCII" operation; and
1083
o in step 5, change all label separators to U+002E (full stop).
1085
After performing the "to-ASCII" conversion, the DNS labels and names
1086
MUST be compared for equality according to the rules specified in
1087
Section 3 of [RFC3490], i.e. once all label separators are replaced
1088
with U+002E (dot) they are compared in the case-insensitive manner.
1090
The '*' (ASCII 42) wildcard character is allowed in subjectAltName
1091
values of type dNSName, and then only as the left-most (least
1092
significant) DNS label in that value. This wildcard matches any
1093
left-most DNS label in the server name. That is, the subject
1094
*.example.com matches the server names a.example.com and
1095
b.example.com, but does not match example.com or a.b.example.com.
1097
2.2.1.2. Comparison of IP Addresses
1099
When the reference identity is an IP address, the identity MUST be
1100
converted to the "network byte order" octet string representation
1101
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
1102
octet string will contain exactly four octets. For IP Version 6, as
1103
specified in RFC 2460, the octet string will contain exactly sixteen
1104
octets. This octet string is then compared against subjectAltName
1105
values of type iPAddress. A match occurs if the reference identity
1106
octet string and value octet strings are identical.
1108
2.2.1.3. Comparison of Other subjectName Types
1110
Client implementations MAY support matching against subjectAltName
1111
values of other types as described in other documents.
1119
Melnikov & Martin Expires July 21, 2009 [Page 20]
1121
Internet-Draft ManageSieve January 2009
1126
The client sends the LOGOUT command when it is finished with a
1127
connection and wishes to terminate it. The server MUST reply with an
1128
OK response. The server MUST ignore commands issued by the client
1129
after the LOGOUT command.
1131
The client SHOULD wait for the OK response before closing the
1132
connection. This avoids the TCP connection going into the TIME_WAIT
1133
state on the server. In order to avoid going into the the TIME_WAIT
1134
TCP state the server MAY wait for a short while for the client to
1135
close the TCP connection first. Whether or not the server waits for
1136
the client to close the connection, it MUST then close the connection
1143
<connection is terminated>
1145
2.4. CAPABILITY Command
1147
The CAPABILITY command requests the server capabilities as described
1148
earlier in this document. It has no parameters.
1153
S: "IMPLEMENTATION" "Example1 ManageSieved v001"
1155
S: "SASL" "PLAIN OTP GSSAPI"
1156
S: "SIEVE" "fileinto vacation"
1160
2.5. HAVESPACE Command
1162
Arguments: String - name
1163
Number - script size
1165
The HAVESPACE command is used to query the server for available
1166
space. Clients specify the name they wish to save the script as and
1167
its size in octets. Both parameters can be used by the server to see
1168
if the script with the specified name and size is within user's
1169
quota(s), for example the server MAY use the script name to check if
1170
a script would be replaced or a new one would be created. Servers
1171
respond with an NO if storing a script with that name and size would
1175
Melnikov & Martin Expires July 21, 2009 [Page 21]
1177
Internet-Draft ManageSieve January 2009
1180
fail or OK otherwise. Clients SHOULD issue this command before
1181
attempting to place a script on the server.
1183
Note that the OK response from the HAVESPACE command does not
1184
constitute a guarantee of success as server disk space conditions
1185
could change between the client issuing the HAVESPACE and the client
1186
issuing the PUTSCRIPT commands. A QUOTA response code (see
1187
Section 1.4) remains a possible (albeit unlikely) response to a
1188
subsequent PUTSCRIPT with the same name and size.
1192
C: HAVESPACE "myscript" 999999
1193
S: NO (QUOTA/MAXSIZE) "Quota exceeded"
1195
C: HAVESPACE "foobar" 435
1198
2.6. PUTSCRIPT Command
1200
Arguments: String - Script name
1201
String - Script content
1203
The PUTSCRIPT command is used by the client to submit a Sieve script
1206
If the script already exists, upon success the old script will be
1207
overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
1208
fails in any way. A script of zero length SHOULD be disallowed.
1210
This command places the script on the server. It does not affect
1211
whether the script is processed on incoming mail, unless it replaces
1212
the script which is already active. The SETACTIVE command is used to
1213
mark a script as active.
1215
When submitting large scripts clients SHOULD use the HAVESPACE
1216
command beforehand to query if the server is willing to accept a
1217
script of that size.
1219
The server MUST check the submitted script for validity, which
1220
includes checking that the script complies with the Sieve grammar
1221
[SIEVE], and that all Sieve extensions mentioned in script's
1222
"require" statement(s) are supported by the Sieve interpreter. (Note
1223
that if the Sieve interpreter supports the Sieve "ihave" extension
1224
[I-HAVE], any unrecognized/unsupported extension mentioned in the
1225
"ihave" test MUST NOT cause the validation failure.) Other checks
1226
such as validating the supplied command arguments for each command
1227
MAY be performed. Essentially, the performed validation SHOULD be
1231
Melnikov & Martin Expires July 21, 2009 [Page 22]
1233
Internet-Draft ManageSieve January 2009
1236
the same as performed when compiling the script for execution.
1237
Implementations that use a binary representation to store compiled
1238
scripts can extend the validation to a full compilation, in order to
1239
avoid validating uploaded scripts multiple times.
1241
If the script fails the validation the server MUST reply with a NO
1242
response. Any script that fails the validity test MUST NOT be stored
1243
on the server. The message given with a NO response MUST be human
1244
readable and SHOULD contain a specific error message giving the line
1245
number of the first error. Implementors should strive to produce
1246
helpful error messages similar to those given by programming language
1247
compilers. Client implementations should note that this may be a
1248
multiline literal string with more than one error message separated
1249
by CRLFs. The human readable message is in the language returned in
1250
the latest LANGUAGE capability (or in "i-default", see Section 1.8),
1251
encoded in UTF-8 [UTF-8].
1253
An OK response MAY contain the WARNINGS response code. In such case
1254
the human readable message that follows the OK response SHOULD
1255
contain a specific warning message (or messages) giving the line
1256
number(s) in the script that might contain errors not intended by the
1257
script writer. The human readable message is in the language
1258
returned in the latest LANGUAGE capability (or in "i-default", see
1259
Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response
1260
code SHOULD present the message to the user.
1287
Melnikov & Martin Expires July 21, 2009 [Page 23]
1289
Internet-Draft ManageSieve January 2009
1294
C: Putscript "foo" {31+}
1296
C: InvalidSieveCommand
1298
S: NO "line 2: Syntax error"
1300
C: Putscript "mysievescript" {110+}
1301
C: require ["fileinto"];
1303
C: if envelope :contains "to" "tmartin+sent" {
1304
C: fileinto "INBOX.sent";
1308
C: Putscript "myforwards" {190+}
1309
C: redirect "111@example.net";
1311
C: if size :under 10k {
1312
C: redirect "mobile@cell.example.com";
1315
C: if envelope :contains "to" "tmartin+lists" {
1316
C: redirect "lists@groups.example.com";
1318
S: OK (WARNINGS) "line 8: server redirect action
1319
limit is 2, this redirect might be ignored"
1321
2.7. LISTSCRIPTS Command
1323
This command lists the scripts the user has on the server. Upon
1324
success a list of CRLF separated script names (each represented as a
1325
quoted or literal string) is returned followed by an OK response. If
1326
there exists an active script the atom ACTIVE is appended to the
1327
corresponding script name. The atom ACTIVE MUST NOT appear on more
1328
than one response line.
1343
Melnikov & Martin Expires July 21, 2009 [Page 24]
1345
Internet-Draft ManageSieve January 2009
1352
S: "vacation_script"
1355
S: "main_script" ACTIVE
1360
S: "main_script" active
1363
2.8. SETACTIVE Command
1365
Arguments: String - script name
1367
This command sets a script active. If the script name is the empty
1368
string (i.e. "") then any active script is disabled. Disabling an
1369
active script when there is no script active is not an error and MUST
1372
If the script does not exist on the server then the server MUST reply
1373
with a NO response. Such reply SHOULD contain the NONEXISTENT
1378
C: Setactive "vacationscript"
1385
S: No (NONEXISTENT) "There is no script by that name"
1388
S: No (NONEXISTENT) {31}
1389
S: There is no script by that name
1391
2.9. GETSCRIPT Command
1399
Melnikov & Martin Expires July 21, 2009 [Page 25]
1401
Internet-Draft ManageSieve January 2009
1404
Arguments: String - script name
1406
This command gets the contents of the specified script. If the
1407
script does not exist the server MUST reply with a NO response. Such
1408
reply SHOULD contain the NONEXISTENT response code.
1410
Upon success a string with the contents of the script is returned
1411
followed by a OK response.
1415
C: Getscript "myscript"
1417
S: #this is my wonderful script
1418
S: reject "I reject all";
1422
2.10. DELETESCRIPT Command
1424
Arguments: String - script name
1426
This command is used to delete a user's Sieve script. Servers MUST
1427
reply with a NO response if the script does not exist. Such
1428
responses SHOULD include the NONEXISTENT response code.
1430
The server MUST NOT allow the client to delete an active script, so
1431
the server MUST reply with a NO response if attempted. Such response
1432
SHOULD contain the ACTIVE response code. If a client wishes to
1433
delete an active script it should use the SETACTIVE command to
1434
disable the script first.
1438
C: Deletescript "foo"
1441
C: Deletescript "baz"
1442
S: No (ACTIVE) "You may not delete an active script"
1444
2.11. RENAMESCRIPT Command
1446
Arguments: String - Old Script name
1447
String - New Script name
1449
This command is used to rename a user's Sieve script. Servers MUST
1450
reply with a NO response if the old script does not exist (in which
1451
case the NONEXISTENT response code SHOULD be included), or a script
1455
Melnikov & Martin Expires July 21, 2009 [Page 26]
1457
Internet-Draft ManageSieve January 2009
1460
with the new name already exists (in which case the ALREADYEXISTS
1461
response code SHOULD be included). Renaming the active script is
1462
allowed, the renamed script remains active.
1466
C: Renamescript "foo" "bar"
1469
C: Renamescript "baz" "bar"
1470
S: No "bar already exists"
1472
If the server doesn't support the RENAMESCRIPT command, the client
1473
can emulate it by performing the following steps:
1475
1. List available scripts with LISTSCRIPTS. If the script with the
1476
new script name exists, then the client should ask the user
1477
whether to abort the operation, to replace the script (by issuing
1478
the DELETESCRIPT <newname> after that) or to chose a different
1481
2. Download the old script with GETSCRIPT <oldname>.
1483
3. Upload the old script with the new name: PUTSCRIPT <newname>.
1485
4. If the old script was active (as reported by LISTSCRIPTS in step
1486
1), then make the new script active: SETACTIVE <newname>
1488
5. Delete the old script: DELETESCRIPT <oldname>
1490
Note that these steps don't describe how to handle various other
1491
error conditions (for example NO response containing QUOTA response
1492
code in step 3). Error handling is left as an excercise for the
1495
2.12. CHECKSCRIPT Command
1497
Arguments: String - Script content
1499
The CHECKSCRIPT command is used by the client to verify Sieve script
1500
validity without storing the script on the server.
1502
The server MUST check the submitted script for syntactic validity,
1503
which includes checking that all Sieve extensions mentioned in Sieve
1504
script "require" statement(s) are supported by the Sieve interpreter.
1505
(Note that if the Sieve interpreter supports the Sieve "ihave"
1506
extension [I-HAVE], any unrecognized/unsupported extension mentioned
1507
in the "ihave" test MUST NOT cause the syntactic validation failure.)
1511
Melnikov & Martin Expires July 21, 2009 [Page 27]
1513
Internet-Draft ManageSieve January 2009
1516
If the script fails this test the server MUST reply with a NO
1517
response. The message given with a NO response MUST be human
1518
readable and SHOULD contain a specific error message giving the line
1519
number of the first error. Implementors should strive to produce
1520
helpful error messages similar to those given by programming language
1521
compilers. Client implementations should note that this may be a
1522
multiline literal string with more than one error message separated
1523
by CRLFs. The human readable message is in the language returned in
1524
the latest LANGUAGE capability (or in "i-default", see Section 1.8),
1525
encoded in UTF-8 [UTF-8].
1529
C: CheckScript {31+}
1531
C: InvalidSieveCommand
1533
S: NO "line 2: Syntax error"
1535
A ManageSieve server supporting this command MUST NOT check if the
1536
script will put the current user over its quota limit.
1538
An OK response MAY contain the WARNINGS response code. In such case
1539
the human readable message that follows the OK response SHOULD
1540
contain a specific warning message (or messages) giving the line
1541
number(s) in the script that might contain errors not intended by the
1542
script writer. The human readable message is in the language
1543
returned in the latest LANGUAGE capability (or in "i-default", see
1544
Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response
1545
code SHOULD present the message to the user.
1549
Arguments: String - tag to echo back (optional)
1551
The NOOP command does nothing, beyond returning a response to the
1552
client. It may be used by clients for protocol re-synchronisation or
1553
to reset any inactivity auto-logout timer on the server.
1555
The response to the NOOP command is always OK, followed by the TAG
1556
response code together with the supplied string; if no string was
1557
supplied in the NOOP command, the TAG response code MUST NOT be
1567
Melnikov & Martin Expires July 21, 2009 [Page 28]
1569
Internet-Draft ManageSieve January 2009
1575
S: OK "NOOP completed"
1577
C: NOOP "STARTTLS-SYNC-42"
1579
S: STARTTLS-SYNC-42) "Done"
1581
2.14. Recommended extensions
1583
The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
1584
capability with no parameters) defines a new UNAUTHENTICATE command,
1585
which allows a client to return the server to non-authenticated
1586
state. Support for this extension is RECOMMENDED.
1588
2.14.1. UNAUTHENTICATE Command
1590
The UNAUTHENTICATE command returns the server to the non-
1591
authenticated state. It doesn't affect any previously established
1592
TLS [TLS] or SASL (Section 2.1) security layer.
1594
The UNAUTHENTICATE command is only valid in authenticated state. If
1595
issued in a wrong state, the server MUST reject it with a NO
1598
The UNAUTHENTICATE command has no parameters.
1600
When issued in the authenticated state, the UNAUTHENTICATE command
1601
MUST NOT fail (i.e. it must never return anything other than OK or
1607
URI scheme name: sieve
1623
Melnikov & Martin Expires July 21, 2009 [Page 29]
1625
Internet-Draft ManageSieve January 2009
1628
Described using ABNF [ABNF]. Some ABNF productions not defined
1629
below are from [URI-GEN].
1632
sieveurl = sieveurl-server / sieveurl-list-scripts /
1635
sieveurl-server = "sieve://" authority
1637
sieveurl-list-scripts = "sieve://" authority ["/"]
1639
sieveurl-script = "sieve://" authority "/"
1640
[owner "/"] scriptname
1642
authority = <defined in [URI-GEN]>
1645
;; %-encoded version of [SASL] authorization
1646
;; identity (script owner) or "userid".
1648
;; Empty owner is used to reference
1651
;; Note that ASCII characters such as " ", ";",
1652
;; "&", "=", "/" and "?" must be %-encoded
1653
;; as per rule specified in [URI-GEN].
1655
scriptname = 1*ochar
1656
;; %-encoded version of UTF-8 representation
1657
;; of the script name.
1658
;; Note that ASCII characters such as " ", ";",
1659
;; "&", "=", "/" and "?" must be %-encoded
1660
;; as per rule specified in [URI-GEN].
1662
ochar = unreserved / pct-encoded / sub-delims-sh /
1664
;; Same as [URI-GEN] 'pchar'
1665
;; but without ";", "&" and "=".
1667
unreserved = <defined in [URI-GEN]>
1669
pct-encoded = <defined in [URI-GEN]>
1671
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
1673
;; Same as [URI-GEN] sub-delims,
1674
;; but without ";", "&" and "=".
1679
Melnikov & Martin Expires July 21, 2009 [Page 30]
1681
Internet-Draft ManageSieve January 2009
1684
URI scheme semantics:
1686
A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
1687
server. The latter form is associated with the application/sieve
1688
MIME type defined in [SIEVE]. There is no MIME type associated
1689
with the former form of Sieve URI.
1691
The server form is used in the REFERRAL response code (see
1692
Section 1.4 in order to designate another server where the client
1693
should perform its operations.
1695
The script form allows to retrieve (GETSCRIPT), update
1696
(PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the
1697
named script, however the most typical action would be to retrieve
1698
the script. If the script name is empty (omitted), the URI
1699
requests that the client lists available scripts using the
1700
LISTSCRIPTS command.
1702
Encoding considerations:
1704
The script name and/or the owner, if present, is in UTF-8. Non-
1705
US-ASCII UTF-8 octets MUST be percent-encoded as described in
1706
[URI-GEN]. US-ASCII characters such as " " (space), ";", "&",
1707
"=", "/" and "?" MUST be %-encoded as described in [URI-GEN].
1708
Note that "&" and "?" are in this list in order to allow for
1711
Note that the empty owner (e.g. sieve://example.com//script) is
1712
different from the missing owner (e.g. sieve://example.com/script)
1713
and is reserved for referencing global scripts.
1715
The user name (in the "authority" part), if present, is in UTF-8.
1716
Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
1719
Applications/protocols that use this URI scheme name:
1720
ManageSieve [RFC XXXX] clients and servers. Clients that can store
1721
user preferences in protocols such as [LDAP] or [ACAP].
1723
Interoperability considerations: None.
1725
Security considerations:
1726
The <scriptname> part of a ManageSieve URL might potentially disclose
1727
some confidential information about the author of the script or,
1728
depending on a ManageSieve implementation, about configuration of the
1729
mail system. The latter might be used to prepare for a more complex
1730
attack on the mail system.
1735
Melnikov & Martin Expires July 21, 2009 [Page 31]
1737
Internet-Draft ManageSieve January 2009
1740
Clients resolving ManageSieve URLs that wish to achieve data
1741
confidentiality and/or integrity SHOULD use the STARTTLS command (if
1742
supported by the server) before starting authentication, or use a
1743
SASL mechanism, such as GSSAPI, that provides a confidentiality
1746
Contact: Alexey Melnikov <alexey.melnikov@isode.com>
1748
Author/Change controller: IESG.
1750
References: This document and RFC 5228 [SIEVE].
1755
The following syntax specification uses the augmented Backus-Naur
1756
Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
1757
rules as specified in Appendix A of the ABNF specification [ABNF].
1758
"UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8].
1760
Except as noted otherwise, all alphabetic characters are case-
1761
insensitive. The use of upper or lower case characters to define
1762
token strings is for editorial clarity only. Implementations MUST
1763
accept these strings in a case-insensitive fashion.
1765
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
1767
;; any TEXT-CHAR except QUOTED-SPECIALS
1769
QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS
1771
QUOTED-SPECIALS = DQUOTE / "\"
1773
SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
1774
;; <UTF8-2>, <UTF8-3> and <UTF8-4>
1775
;; are defined in [UTF-8]
1777
ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
1778
;; Any CHAR except ATOM-SPECIALS
1780
ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL /
1786
atom = 1*1024ATOM-CHAR
1791
Melnikov & Martin Expires July 21, 2009 [Page 32]
1793
Internet-Draft ManageSieve January 2009
1797
;; MUST be registered with IANA
1799
auth-type = DQUOTE auth-type-name DQUOTE
1801
auth-type-name = iana-token
1802
;; as defined in SASL [SASL]
1804
command = (command-any / command-auth /
1805
command-nonauth) CRLF
1806
;; Modal based on state
1808
command-any = command-capability / command-logout /
1810
;; Valid in all states
1812
command-auth = command-getscript / command-setactive /
1813
command-listscripts / command-deletescript /
1814
command-putscript / command-checkscript /
1816
command-renamescript /
1817
command-unauthenticate
1818
;; Valid only in Authenticated state
1820
command-nonauth = command-authenticate / command-starttls
1821
;; Valid only when in Non-Authenticated
1824
command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
1827
command-capability = "CAPABILITY"
1829
command-deletescript = "DELETESCRIPT" SP sieve-name
1831
command-getscript = "GETSCRIPT" SP sieve-name
1833
command-havespace = "HAVESPACE" SP sieve-name SP number
1835
command-listscripts = "LISTSCRIPTS"
1837
command-noop = "NOOP" [SP string]
1839
command-logout = "LOGOUT"
1841
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
1843
command-checkscript = "CHECKSCRIPT" SP sieve-script
1847
Melnikov & Martin Expires July 21, 2009 [Page 33]
1849
Internet-Draft ManageSieve January 2009
1852
sieve-script = string
1854
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
1857
old-sieve-name = sieve-name
1859
new-sieve-name = sieve-name
1861
command-setactive = "SETACTIVE" SP active-sieve-name
1863
command-starttls = "STARTTLS"
1865
command-unauthenticate= "UNAUTHENTICATE"
1868
;; MUST be defined by a standards track or
1869
;; IESG approved experimental protocol
1872
extension-data = extension-item *(SP extension-item)
1874
extension-item = extend-token / string / number /
1875
"(" [extension-data] ")"
1877
literal-c2s = "{" number "+}" CRLF *OCTET
1878
;; The number represents the number of
1880
;; This type of literal can only be sent
1881
;; from the client to the server.
1883
literal-s2c = "{" number "}" CRLF *OCTET
1884
;; Almost identical to literal-c2s,
1885
;; but with no '+' character.
1886
;; The number represents the number of
1888
;; This type of literal can only be sent
1889
;; from the server to the client.
1891
number = (NZDIGIT *DIGIT) / "0"
1892
;; A 32-bit unsigned number
1893
;; with no extra leading zeros.
1894
;; (0 <= n < 4,294,967,296)
1897
;; <number> encoded as a <string>.
1899
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
1903
Melnikov & Martin Expires July 21, 2009 [Page 34]
1905
Internet-Draft ManageSieve January 2009
1908
;; limited to 1024 octets between the <">s
1910
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" /
1911
"QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
1913
resp-code-referral /
1914
"TRANSITION-NEEDED" / "TRYLATER" /
1915
"ACTIVE" / "NONEXISTENT" /
1916
"ALREADYEXISTS" / "WARNINGS" /
1920
resp-code-referral = "REFERRAL" SP sieveurl
1922
resp-code-sasl = "SASL" SP string
1924
resp-code-name = iana-token
1925
;; The response code name is hierarchical,
1926
;; separated by '/'.
1927
;; The response code name MUST NOT start
1930
resp-code-ext = resp-code-name [SP extension-data]
1931
;; unknown response codes MUST be tolerated
1934
response = response-authenticate /
1936
response-getscript /
1937
response-setactive /
1938
response-listscripts /
1939
response-deletescript /
1940
response-putscript /
1941
response-checkscript /
1942
response-capability /
1943
response-havespace /
1945
response-renamescript /
1947
response-unauthenticate
1949
response-authenticate = *(string CRLF)
1950
((response-ok [response-capability]) /
1952
;; <response-capability> is REQUIRED if a
1953
;; SASL security layer was negotiated and
1954
;; MUST be omitted otherwise.
1959
Melnikov & Martin Expires July 21, 2009 [Page 35]
1961
Internet-Draft ManageSieve January 2009
1964
response-capability = *(single-capability) response-oknobye
1966
single-capability = capability-name [SP string] CRLF
1968
capability-name = string
1969
;; Note that literal-s2c is allowed.
1971
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
1972
DQUOTE "SASL" DQUOTE SP sasl-mechs /
1973
DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
1974
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
1975
DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
1976
DQUOTE "STARTTLS" DQUOTE /
1977
DQUOTE "LANGUAGE" DQUOTE SP language /
1978
DQUOTE "VERSION" DQUOTE SP version /
1979
DQUOTE "OWNER" DQUOTE SP string
1980
;; Each capability conforms to
1981
;; the syntax for single-capability.
1982
;; Also note that the capability name
1983
;; can be returned as either literal-s2c
1984
;; or quoted, even though only "quoted"
1985
;; string is shown above.
1987
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
1989
version-ext = DQUOTE ver-major "." ver-minor DQUOTE
1990
; Future versions specified in updates
1991
; to this document. An increment to
1992
; the ver-major means a backward-incompatible
1993
; change to the protocol, e.g. "3.5" (ver-major "3")
1994
; is not backward-compatible with any "2.X" version.
1995
; Any version "Z.W" MUST be backward compatible
1996
; with any version "Z.Q", where Q < W.
1997
; E.g. version "2.4" is backward-compatible
1998
; with version "2.0", "2.1", "2.2" and "2.3".
2005
; space separated list of SASL mechanisms,
2006
; each SASL mechanism name complies with rules
2007
; specified in [SASL].
2010
sieve-extensions = string
2011
; space separated list of supported SIEVE extensions,
2015
Melnikov & Martin Expires July 21, 2009 [Page 36]
2017
Internet-Draft ManageSieve January 2009
2023
; Contains <Language-Tag> from [RFC4646].
2025
notify-mechs = string
2026
; space separated list of URI schema parts
2027
; for supported notification [NOTIFY] methods.
2028
; MUST NOT be empty.
2030
response-deletescript = response-oknobye
2032
response-getscript = (sieve-script CRLF response-ok) /
2035
response-havespace = response-oknobye
2037
response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
2039
;; ACTIVE may only occur with one sieve-name
2041
response-logout = response-oknobye
2043
response-unauthenticate= response-oknobye
2044
;; "NO" response can only be returned when
2045
;; the command is issued in a wrong state
2046
;; or has a wrong number of parameters
2048
response-ok = "OK" [SP "(" resp-code ")"]
2050
;; The string contains human readable text
2051
;; encoded as UTF-8.
2053
response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
2055
;; The string contains human readable text
2056
;; encoded as UTF-8.
2058
response-oknobye = response-ok / response-nobye
2060
response-noop = response-ok
2062
response-putscript = response-oknobye
2064
response-checkscript = response-oknobye
2066
response-renamescript = response-oknobye
2071
Melnikov & Martin Expires July 21, 2009 [Page 37]
2073
Internet-Draft ManageSieve January 2009
2076
response-setactive = response-oknobye
2078
response-starttls = (response-ok response-capability) /
2082
;; See Section 1.6 for the full list of
2083
;; prohibited characters.
2084
;; Empty string is not allowed.
2086
active-sieve-name = string
2087
;; See Section 1.6 for the full list of
2088
;; prohibited characters.
2089
;; This is similar to <sieve-name>, but
2090
;; empty string is allowed and has a special
2093
string = quoted / literal-c2s / literal-s2c
2094
;; literal-c2s is only allowed when sent
2095
;; from the client to the server.
2096
;; literal-s2c is only allowed when sent
2097
;; from the server to the client.
2098
;; quoted is allowed in either direction.
2101
5. Security Considerations
2103
The AUTHENTICATE command uses SASL [SASL] to provide authentication
2104
and authorization services. Integrity and privacy services can be
2105
provided by [SASL] and/or [TLS]. When a SASL mechanism is used the
2106
security considerations for that mechanism apply.
2108
This protocol's transactions are susceptible to passive observers or
2109
man in the middle attacks which alter the data, unless the optional
2110
encryption and integrity services of the SASL (via the AUTHENTICATE
2111
command) and/or [TLS] (via the STARTTLS command) are enabled, or an
2112
external security mechanism is used for protection. It may be useful
2113
to allow configuration of both clients and servers to refuse to
2114
transfer sensitive information in the absence of strong encryption.
2116
If an implementation supports SASL mechanisms that are vulnerable to
2117
passive eavesdropping attacks (such as [PLAIN]), then the
2118
implementation MUST support at least one configuration where these
2119
SASL mechanisms are not advertised or used without the presence of an
2120
external security layer such as [TLS].
2122
Some response codes returned on failed AUTHENTICATE command may
2123
disclose whether or not the username is valid (e.g. TRANSITION-
2127
Melnikov & Martin Expires July 21, 2009 [Page 38]
2129
Internet-Draft ManageSieve January 2009
2132
NEEDED), so server implementations SHOULD provide the ability to
2133
disable these features (or make them not conditional on a per-user
2134
basis) for sites concerned about such disclosure. In the case of
2135
ENCRYPT-NEEDED, if it is applied to all identities then no extra
2136
information is disclosed, but if it is applied on a per-user basis it
2137
can disclose information.
2139
A compromised or malicious server can use the TRANSITION-NEEDED
2140
response code to force the client which is configured to use a
2141
mechanism that does not disclose the user's password to the server
2142
(e.g., Kerberos), to send the bare password to the server. Clients
2143
SHOULD have the ability to disable the password transition feature,
2144
or disclose that risk to the user and offer the user an option how to
2148
6. IANA Considerations
2150
IANA is requested to reserve a TCP port number for use with the
2151
ManageSieve protocol described in this document.
2153
IANA is requested to register the "sieve" URI scheme defined in
2154
Section 3 of this document.
2156
IANA is requested to register "sieve" in the "GSSAPI/Kerberos/SASL
2157
Service Names" registry.
2159
IANA is requested to create a new registry for ManageSieve
2160
capabilities. The registration template for ManageSieve capabilities
2161
is specified in Section 6.1. ManageSieve protocol capabilities MUST
2162
be specified in a standards track or IESG approved experimental RFC.
2164
IANA is requested to create a new registry for ManageSieve response
2165
codes. The registration template for ManageSieve response codes is
2166
specified in Section 6.3. ManageSieve protocol response codes MUST
2167
be specified in a standards track or IESG approved experimental RFC.
2169
6.1. ManageSieve Capability Registration Template
2172
Subject: ManageSieve Capability Registration
2174
Please register the following ManageSieve Capability:
2177
Relevant publications:
2178
Person & email address to contact for further information:
2179
Author/Change controller:
2183
Melnikov & Martin Expires July 21, 2009 [Page 39]
2185
Internet-Draft ManageSieve January 2009
2188
6.2. Registration of Initial ManageSieve capabilities
2191
Subject: ManageSieve Capability Registration
2193
Please register the following ManageSieve Capabilities:
2195
Capability name: IMPLEMENTATION
2197
Description: Its value contains name of server implementation and
2200
Relevant publications: this RFC, Section 1.8.
2202
Person & email address to contact for further information: Alexey
2203
Melnikov <alexey.melnikov@isode.com>
2205
Author/Change controller: IESG.
2207
Capability name: SASL
2209
Description: Its value contains a space separated list of SASL
2210
mechanisms supported by server.
2212
Relevant publications: this RFC, Section 1.8 and Section 2.1.
2214
Person & email address to contact for further information: Alexey
2215
Melnikov <alexey.melnikov@isode.com>
2217
Author/Change controller: IESG.
2219
Capability name: SIEVE
2221
Description: Its value contains a space separated list of
2222
supported SIEVE extensions
2224
Relevant publications: this RFC, Section 1.8. Also [SIEVE].
2226
Person & email address to contact for further information: Alexey
2227
Melnikov <alexey.melnikov@isode.com>
2229
Author/Change controller: IESG.
2231
Capability name: STARTTLS
2233
Description: This capability is returned if server supports TLS
2239
Melnikov & Martin Expires July 21, 2009 [Page 40]
2241
Internet-Draft ManageSieve January 2009
2244
Relevant publications: this RFC, Section 1.8 and Section 2.2.
2246
Person & email address to contact for further information: Alexey
2247
Melnikov <alexey.melnikov@isode.com>
2249
Author/Change controller: IESG.
2251
Capability name: NOTIFY
2253
Description: This capability is returned if server supports
2254
'enotify' [NOTIFY] Sieve extension.
2256
Relevant publications: this RFC, Section 1.8.
2258
Person & email address to contact for further information: Alexey
2259
Melnikov <alexey.melnikov@isode.com>
2261
Author/Change controller: IESG.
2263
Capability name: MAXREDIRECTS
2265
Description: This capability returns the limit on the number of
2266
Sieve "redirect" actions a script can perform during a single
2267
evaluation. The value is a non-negative number represented as a
2270
Relevant publications: this RFC, Section 1.8.
2272
Person & email address to contact for further information: Alexey
2273
Melnikov <alexey.melnikov@isode.com>
2275
Author/Change controller: IESG.
2277
Capability name: LANGUAGE
2279
Description: The language (<Language-Tag> from [RFC4646])
2280
currently used for human readable error messages.
2282
Relevant publications: this RFC, Section 1.8.
2284
Person & email address to contact for further information: Alexey
2285
Melnikov <alexey.melnikov@isode.com>
2287
Author/Change controller: IESG.
2289
Capability name: OWNER
2295
Melnikov & Martin Expires July 21, 2009 [Page 41]
2297
Internet-Draft ManageSieve January 2009
2300
Description: Its value contains UTF-8 encoded name of the
2301
currently logged in user ("authorization identity" according to
2304
Relevant publications: this RFC, Section 1.8.
2306
Person & email address to contact for further information: Alexey
2307
Melnikov <alexey.melnikov@isode.com>
2309
Author/Change controller: IESG.
2311
Capability name: VERSION
2313
Description: This capability is returned if the server is
2314
compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT,
2315
CHECKSCRIPT and NOOP commands.
2317
Relevant publications: this RFC, Section 2.11.
2319
Person & email address to contact for further information: Alexey
2320
Melnikov <alexey.melnikov@isode.com>
2322
Author/Change controller: IESG.
2324
6.3. ManageSieve Response Code Registration Template
2327
Subject: ManageSieve Response Code Registration
2329
Please register the following ManageSieve Response Code:
2333
Arguments (use ABNF to specify syntax, or the word NONE if none
2338
Published Specification(s):
2340
Person & email address to contact for further information:
2342
Author/Change controller:
2351
Melnikov & Martin Expires July 21, 2009 [Page 42]
2353
Internet-Draft ManageSieve January 2009
2356
6.4. Registration of Initial ManageSieve Response Codes
2359
Subject: ManageSieve Response Code Registration
2361
Please register the following ManageSieve Response Codes:
2363
Response Code: AUTH-TOO-WEAK
2365
Arguments (use ABNF to specify syntax, or the word NONE if none
2366
can be specified): NONE
2368
Purpose: This response code is returned in the NO response from an
2369
AUTHENTICATE command. It indicates that site security policy
2370
forbids the use of the requested mechanism for the specified
2371
authentication identity.
2373
Published Specification(s): [RFCXXXX]
2375
Person & email address to contact for further information: Alexey
2376
Melnikov <alexey.melnikov@isode.com>
2378
Author/Change controller: IESG.
2380
Response Code: ENCRYPT-NEEDED
2382
Arguments (use ABNF to specify syntax, or the word NONE if none
2383
can be specified): NONE
2385
Purpose: This response code is returned in the NO response from an
2386
AUTHENTICATE command. It indicates that site security policy
2387
requires the use of a strong encryption mechanism for the
2388
specified authentication identity and mechanism.
2390
Published Specification(s): [RFCXXXX]
2392
Person & email address to contact for further information: Alexey
2393
Melnikov <alexey.melnikov@isode.com>
2395
Author/Change controller: IESG.
2397
Response Code: QUOTA
2399
Arguments (use ABNF to specify syntax, or the word NONE if none
2400
can be specified): NONE
2402
Purpose: If this response code is returned in the NO/BYE response,
2403
it means that the command would have placed the user above the
2407
Melnikov & Martin Expires July 21, 2009 [Page 43]
2409
Internet-Draft ManageSieve January 2009
2412
site-defined quota constraints. If this response code is returned
2413
in the OK response, it can mean that the user is near its quota or
2414
that the user exceeded its quota, but the server supports soft
2417
Published Specification(s): [RFCXXXX]
2419
Person & email address to contact for further information: Alexey
2420
Melnikov <alexey.melnikov@isode.com>
2422
Author/Change controller: IESG.
2424
Response Code: QUOTA/MAXSCRIPTS
2426
Arguments (use ABNF to specify syntax, or the word NONE if none
2427
can be specified): NONE
2429
Purpose: If this response code is returned in the NO/BYE response,
2430
it means that the command would have placed the user above the
2431
site-defined limit on the number of Sieve scripts. If this
2432
response code is returned in the OK response, it can mean that the
2433
user is near its quota or that the user exceeded its quota, but
2434
the server supports soft quotas. This response code is a more
2435
specific version of the QUOTA response code.
2437
Published Specification(s): [RFCXXXX]
2439
Person & email address to contact for further information: Alexey
2440
Melnikov <alexey.melnikov@isode.com>
2442
Author/Change controller: IESG.
2444
Response Code: QUOTA/MAXSIZE
2446
Arguments (use ABNF to specify syntax, or the word NONE if none
2447
can be specified): NONE
2449
Purpose: If this response code is returned in the NO/BYE response,
2450
it means that the command would have placed the user above the
2451
site-defined maximum script size. If this response code is
2452
returned in the OK response, it can mean that the user is near its
2453
quota or that the user exceeded its quota, but the server supports
2454
soft quotas. This response code is a more specific version of the
2455
QUOTA response code.
2457
Published Specification(s): [RFCXXXX]
2463
Melnikov & Martin Expires July 21, 2009 [Page 44]
2465
Internet-Draft ManageSieve January 2009
2468
Person & email address to contact for further information: Alexey
2469
Melnikov <alexey.melnikov@isode.com>
2471
Author/Change controller: IESG.
2473
Response Code: REFERRAL
2475
Arguments (use ABNF to specify syntax, or the word NONE if none
2476
can be specified): <sieveurl>
2478
Purpose: This response code may be returned with a BYE result from
2479
any command, and includes a mandatory parameter that indicates
2480
what server to access to manage this user's sieve scripts. The
2481
server will be specified by a Sieve URL (see Section 3). The
2482
scriptname portion of the URL MUST NOT be specified. The client
2483
should authenticate to the specified server and use it for all
2484
further commands in the current session.
2486
Published Specification(s): [RFCXXXX]
2488
Person & email address to contact for further information: Alexey
2489
Melnikov <alexey.melnikov@isode.com>
2491
Author/Change controller: IESG.
2495
Arguments (use ABNF to specify syntax, or the word NONE if none
2496
can be specified): <string>
2498
Purpose: This response code can occur in the OK response to a
2499
successful AUTHENTICATE command and includes the optional final
2500
server response data from the server as specified by [SASL].
2502
Published Specification(s): [RFCXXXX]
2504
Person & email address to contact for further information: Alexey
2505
Melnikov <alexey.melnikov@isode.com>
2507
Author/Change controller: IESG.
2509
Response Code: TRANSITION-NEEDED
2511
Arguments (use ABNF to specify syntax, or the word NONE if none
2512
can be specified): NONE
2514
Purpose: This response code occurs in a NO response of an
2515
AUTHENTICATE command. It indicates that the user name is valid,
2519
Melnikov & Martin Expires July 21, 2009 [Page 45]
2521
Internet-Draft ManageSieve January 2009
2524
but the entry in the authentication database needs to be updated
2525
in order to permit authentication with the specified mechanism.
2526
This is typically done by establishing a secure channel using TLS,
2527
followed by authenticating once using the [PLAIN] authentication
2528
mechanism. The selected mechanism SHOULD then work for
2529
authentications in subsequent sessions.
2531
Published Specification(s): [RFCXXXX]
2533
Person & email address to contact for further information: Alexey
2534
Melnikov <alexey.melnikov@isode.com>
2536
Author/Change controller: IESG.
2538
Response Code: TRYLATER
2540
Arguments (use ABNF to specify syntax, or the word NONE if none
2541
can be specified): NONE
2543
Purpose: A command failed due to a temporary server failure. The
2544
client MAY continue using local information and try the command
2545
later. This response code only make sense when returned in a NO/
2548
Published Specification(s): [RFCXXXX]
2550
Person & email address to contact for further information: Alexey
2551
Melnikov <alexey.melnikov@isode.com>
2553
Author/Change controller: IESG.
2555
Response Code: ACTIVE
2557
Arguments (use ABNF to specify syntax, or the word NONE if none
2558
can be specified): NONE
2560
Purpose: A command failed because it is not allowed on the active
2561
script. For example DELETESCRIPT on the active script. This
2562
response code only makes sense when returned in a NO/BYE response.
2564
Published Specification(s): [RFCXXXX]
2566
Person & email address to contact for further information: Alexey
2567
Melnikov <alexey.melnikov@isode.com>
2569
Author/Change controller: IESG.
2575
Melnikov & Martin Expires July 21, 2009 [Page 46]
2577
Internet-Draft ManageSieve January 2009
2580
Response Code: NONEXISTENT
2582
Arguments (use ABNF to specify syntax, or the word NONE if none
2583
can be specified): NONE
2585
Purpose: A command failed because the referenced script name
2586
doesn't exist. This response code only makes sense when returned
2587
in a NO/BYE response.
2589
Published Specification(s): [RFCXXXX]
2591
Person & email address to contact for further information: Alexey
2592
Melnikov <alexey.melnikov@isode.com>
2594
Author/Change controller: IESG.
2596
Response Code: ALREADYEXISTS
2598
Arguments (use ABNF to specify syntax, or the word NONE if none
2599
can be specified): NONE
2601
Purpose: A command failed because the referenced script name
2602
already exists. This response code only makes sense when returned
2603
in a NO/BYE response.
2605
Published Specification(s): [RFCXXXX]
2607
Person & email address to contact for further information: Alexey
2608
Melnikov <alexey.melnikov@isode.com>
2610
Author/Change controller: IESG.
2612
Response Code: WARNINGS
2614
Arguments (use ABNF to specify syntax, or the word NONE if none
2615
can be specified): NONE
2617
Purpose: This response code MAY be returned by the server in the
2618
OK response (but it might be returned with the NO/BYE response as
2619
well) and signals the client that even though the script is
2620
syntactically valid, it might contain errors not intended by the
2623
Published Specification(s): [RFCXXXX]
2625
Person & email address to contact for further information: Alexey
2626
Melnikov <alexey.melnikov@isode.com>
2631
Melnikov & Martin Expires July 21, 2009 [Page 47]
2633
Internet-Draft ManageSieve January 2009
2636
Author/Change controller: IESG.
2640
Arguments (use ABNF to specify syntax, or the word NONE if none
2641
can be specified): string
2643
Purpose: This response code name is followed by a string specified
2644
in the command that caused this response. It is typically used
2645
for client state synchronization.
2647
Published Specification(s): [RFCXXXX]
2649
Person & email address to contact for further information: Alexey
2650
Melnikov <alexey.melnikov@isode.com>
2652
Author/Change controller: IESG.
2655
7. Internationalization Considerations
2657
The LANGUAGE capability (see Section 1.8) allows a client to discover
2658
the current language used in all human readable responses that might
2659
be returned at the end of any OK/NO/BYE response. Human readable
2660
text in OK responses typically doesn't need to be shown to the user,
2661
unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command
2662
that also contain the WARNINGS response code Section 1.4. Human
2663
readable text from NO/BYE responses is intended be shown to the user,
2664
unless the client can automatically handle failure of the command
2665
that caused such response. Clients SHOULD use response codes
2666
(Section 1.4) for automatic error handling. Response codes MAY also
2667
be used by the client to present error messages in a language
2668
understood by the user, for example if the LANGUAGE capability
2669
doesn't return a language understood by the user.
2671
Note that the human readable text from OK (WARNINGS) or NO/BYE
2672
responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
2673
users that understand Sieve language. Such advanced users are often
2674
sophisticated enough to be able to handle whatever language the
2675
server is using, even if it is not their preferred language, and will
2676
want to see error/warning text no matter what language the server
2679
A client that generates Sieve script automatically, for example if
2680
the script is generated without user intervention or from a UI that
2681
presents an abstract list of conditions and corresponding actions,
2682
SHOULD NOT present warning/error messages to the user, because the
2683
user might not even be aware that the client is using Sieve
2687
Melnikov & Martin Expires July 21, 2009 [Page 48]
2689
Internet-Draft ManageSieve January 2009
2692
underneath. However if the client has a debugging mode, such
2693
warnings/errors SHOULD be available in the debugging mode.
2695
Note that this document doesn't provide a way to modify the currently
2696
used language. It is expected that a future extension will address
2702
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
2703
Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
2704
Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
2705
Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
2706
Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
2707
Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus
2708
Westerlund and Tim Polk for help with this document. Special thank
2709
you to Phil Pennock for providing text for the NOOP command, as well
2710
as finding various bugs in the document.
2715
9.1. Normative References
2717
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2718
Specifications: ABNF", RFC 5234, January 2008.
2720
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
2721
Configuration Access Protocol", RFC 2244, November 1997.
2723
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
2724
Encodings", RFC 4648, October 2006.
2726
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
2727
specifying the location of services (DNS SRV)", RFC 2782,
2731
Bradner, S., "Key words for use in RFCs to Indicate
2732
Requirement Levels", RFC 2119, March 1997.
2735
Klensin, J. and M. Padlipsky, "Unicode Format for Network
2736
Interchange", RFC 5198, March 2008.
2738
[NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
2739
Martin, "Sieve Extension: Notifications",
2743
Melnikov & Martin Expires July 21, 2009 [Page 49]
2745
Internet-Draft ManageSieve January 2009
2748
draft-ietf-sieve-notify-12 (work in progress),
2751
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
2752
Languages", RFC 2277, January 1998.
2754
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
2755
(IPv6) Specification", RFC 2460, December 1998.
2757
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
2758
"Internationalizing Domain Names in Applications (IDNA)",
2759
RFC 3490, March 2003.
2761
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
2762
(LDAP): Schema for User Applications", RFC 4519,
2765
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
2766
Languages", RFC 4646, September 2006.
2768
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
2770
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
2771
Security Layer (SASL)", RFC 4422, June 2006.
2774
Zeilenga, K., "SASLprep: Stringprep Profile for User Names
2775
and Passwords", RFC 4013, February 2005.
2777
[SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge
2778
Response Authentication Mechanism (SCRAM)",
2779
draft-newman-auth-scram-07.txt (work in progress),
2782
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
2783
Filtering Language", RFC 5228, January 2008.
2786
Hoffman, P. and M. Blanchet, "Preparation of
2787
Internationalized Strings ("stringprep")", RFC 3454,
2790
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
2791
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
2793
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2794
Resource Identifier (URI): Generic Syntax", STD 66,
2795
RFC 3986, January 2005.
2799
Melnikov & Martin Expires July 21, 2009 [Page 50]
2801
Internet-Draft ManageSieve January 2009
2804
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
2805
10646", STD 63, RFC 3629, November 2003.
2807
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
2808
X.509 Public Key Infrastructure Certificate and
2809
Certificate Revocation List (CRL) Profile", RFC 5280,
2813
Santesson, S., "Internet X.509 Public Key Infrastructure
2814
Subject Alternative Name for Expression of Service Name",
2815
RFC 4985, August 2007.
2817
9.2. Informative References
2820
Leach, P. and C. Newman, "Using Digest Authentication as a
2821
SASL Mechanism", RFC 2831, May 2000.
2823
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
2824
draft-freed-sieve-ihave-03.txt (work in progress),
2827
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
2828
4rev1", RFC 3501, March 2003.
2830
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
2831
(LDAP): Technical Specification Road Map", RFC 4510,
2834
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
2835
Security Layer (SASL) Mechanism", RFC 4616, August 2006.
2840
Alexey Melnikov (editor)
2842
5 Castle Business Village
2844
Hampton, Middlesex TW12 2BX
2847
Email: Alexey.Melnikov@isode.com
2855
Melnikov & Martin Expires July 21, 2009 [Page 51]
2857
Internet-Draft ManageSieve January 2009
2861
BeThereBeSquare Inc.
2863
San Francisco, CA 94117
2866
Phone: +1 510 260-4175
2867
Email: timmartin@alumni.cmu.edu
2911
Melnikov & Martin Expires July 21, 2009 [Page 52]
added
removed
managesieve/doc/rfc/draft-ietf-sieve-managesieve-09.txt
