idnits 2.17.1 draft-ietf-sieve-managesieve-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 15, 2009) is 5552 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CONTROL CHARACTERS' is mentioned on line 310, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1317, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 2078, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 2218, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 4013 (ref. 'SASLprep') (Obsoleted by RFC 7613) == Outdated reference: A later version (-13) exists of draft-newman-auth-scram-07 ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) == Outdated reference: A later version (-04) exists of draft-freed-sieve-ihave-03 -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Intended status: Standards Track T. Martin 5 Expires: July 19, 2009 BeThereBeSquare Inc. 6 January 15, 2009 8 A Protocol for Remotely Managing Sieve Scripts 9 draft-ietf-sieve-managesieve-08 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 19, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 Sieve scripts allow users to filter incoming email. Message stores 49 are commonly sealed servers so users cannot log into them, yet users 50 must be able to update their scripts on them. This document 51 describes a protocol "ManageSieve" for securely managing Sieve 52 scripts on a remote server. This protocol allows a user to have 53 multiple scripts, and also alerts a user to syntactically flawed 54 scripts. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1. Conventions used in this document . . . . . . . . . . . . 5 60 1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5 61 1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6 63 1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8 64 1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9 66 1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9 67 1.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 69 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12 71 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17 72 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17 73 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18 74 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21 75 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21 76 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21 77 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22 78 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 24 79 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 24 80 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 25 81 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 25 82 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 26 83 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 27 84 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 28 85 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 28 86 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 28 88 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29 90 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32 92 5. Security Considerations . . . . . . . . . . . . . . . . . 38 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 39 95 6.1. ManageSieve Capability Registration Template . . . . . . . 39 96 6.2. Registration of Initial ManageSieve capabilities . . . . . 39 97 6.3. ManageSieve Response Code Registration Template . . . . . 42 98 6.4. Registration of Initial ManageSieve Response Codes . . . . 42 100 7. Internationalization Considerations . . . . . . . . . . . 48 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . 49 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 49 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 50 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 51 109 1. Introduction 111 1.1. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [KEYWORDS]. 117 In examples, "C:" and "S:" indicate lines sent by the client and 118 server respectively. Line breaks that do not start a new "C:" or 119 "S:" exist for editorial reasons. 121 1.2. 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 127 response. 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 is 132 reading a sequence of octets with a known count followed by a line. 134 1.3. Syntax 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.4) and by a string consisting of human readable text in the 147 local language (as returned by the LANGUAGE capability, see 148 Section 1.8), encoded in [UTF-8]. The contents of the string SHOULD 149 be shown to the user and implementations MUST NOT attempt to parse 150 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. 161 1.4. Response Codes 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. 167 Response codes are defined when there is a specific action that a 168 client can take based upon the additional information. In order to 169 support future extension, the response code is represented as a 170 slash-separated (Solidus, %x2F) hierarchy with each level of 171 hierarchy representing increasing detail about the error. Response 172 codes MUST NOT start with the Solidus character. Clients MUST 173 tolerate additional hierarchical response code detail which they 174 don't understand. For example, if the client supports the "QUOTA" 175 response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response 176 code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA". 178 Client implementations MUST tolerate (ignore) response codes that 179 they do not recognize. 181 The currently defined response codes are: 183 AUTH-TOO-WEAK 185 This response code is returned in the NO or BYE response from an 186 AUTHENTICATE command. It indicates that site security policy forbids 187 the use of the requested mechanism for the specified authentication 188 identity. 190 ENCRYPT-NEEDED 192 This response code is returned in the NO or BYE response from an 193 AUTHENTICATE command. It indicates that site security policy 194 requires the use of a strong encryption mechanism for the specified 195 authentication identity and mechanism. 197 QUOTA 199 If this response code is returned in the NO/BYE response, it means 200 that the command would have placed the user above the site-defined 201 quota constraints. If this response code is returned in the OK 202 response, it can mean that the user's storage is near its quota, or 203 it can mean that the account exceeded its quota but that that 204 condition is being allowed by the server (the server supports so 205 called "soft quotas"). The QUOTA response code has 2 more detailed 206 variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts) 207 and "QUOTA/MAXSIZE" (the maximum script size). 209 REFERRAL 211 This response code may be returned with a BYE result from any 212 command, and includes a mandatory parameter that indicates what 213 server to access to manage this user's sieve scripts. The server 214 will be specified by a Sieve URL (see Section 3). The scriptname 215 portion of the URL MUST NOT be specified. The client should 216 authenticate to the specified server and use it for all further 217 commands in the current session. 219 SASL 221 This response code can occur in the OK response to a successful 222 AUTHENTICATE command and includes the optional final server response 223 data from the server as specified by [SASL]. 225 TRANSITION-NEEDED 227 This response code occurs in a NO response of an AUTHENTICATE 228 command. It indicates that the user name is valid, but the entry in 229 the authentication database needs to be updated in order to permit 230 authentication with the specified mechanism. This is typically done 231 by establishing a secure channel using TLS, verifying server identity 232 as specified in Section 2.2.1, and finally authenticating once using 233 the [PLAIN] authentication mechanism. The selected mechanism SHOULD 234 then work for authentications in subsequent sessions. 236 This condition can happen if a user has an entry in a system 237 authentication database such as Unix /etc/passwd, but does not have 238 credentials suitable for use by the specified mechanism. 240 TRYLATER 242 A command failed due to a temporary server failure. The client MAY 243 continue using local information and try the command later. This 244 response code only makes sense when returned in a NO/BYE response. 246 ACTIVE 248 A command failed because it is not allowed on the active script. For 249 example DELETESCRIPT on the active script. This response code only 250 makes sense when returned in a NO/BYE response. 252 NONEXISTENT 253 A command failed because the referenced script name doesn't exist. 254 This response code only makes sense when returned in a NO/BYE 255 response. 257 ALREADYEXISTS 259 A command failed because the referenced script name already exists. 260 This response code only makes sense when returned in a NO/BYE 261 response. 263 TAG 265 This response code name is followed by a string specified in the 266 command. See Section 2.13 for a possible use case. 268 WARNINGS 270 This response code MAY be returned by the server in the OK response 271 (but it might be returned with the NO/BYE response as well) and 272 signals the client that even though the script is syntactically 273 valid, it might contain errors not intended by the script writer. 274 This response code is typically returned in response to PUTSCRIPT 275 and/or CHECKSCRIPT commands. A client seeing such response code 276 SHOULD present the returned warning text to the user. 278 1.5. Active Script 280 A user may have multiple Sieve scripts on the server, yet only one 281 script may be used for filtering of incoming messages. This is the 282 active script. Users may have zero or one active scripts and MUST 283 use the SETACTIVE command described below for changing the active 284 script or disabling Sieve processing. For example, a user may have 285 an everyday script they normally use and a special script they use 286 when they go on vacation. Users can change which script is being 287 used without having to download and upload a script stored somewhere 288 else. 290 1.6. Quotas 292 Servers SHOULD impose quotas to prevent malicious users from 293 overflowing available storage. If a command would place a user over 294 a quota setting, servers that impose such quotas MUST reply with a NO 295 response containing the QUOTA response code. Client implementations 296 MUST be able to handle commands failing because of quota 297 restrictions. 299 1.7. Script Names 301 A Sieve script name is a sequence of Unicode characters encoded in 302 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition 303 (Section 2 of [NET-UNICODE]), with the additional restriction of 304 prohibiting the following Unicode characters: 306 o 0000-001F; [CONTROL CHARACTERS] 308 o 007F; DELETE 310 o 0080-009F; [CONTROL CHARACTERS] 312 o 2028; LINE SEPARATOR 314 o 2029; PARAGRAPH SEPARATOR 316 Sieve script names MUST be at least one octet (and hense Unicode 317 character) long. Zero octets script name has a special meaning (see 318 Section 2.8). Servers MUST allow names of up to 128 Unicode 319 characters in length (which can take up to 512 bytes when encoded in 320 UTF-8, not counting the terminating NUL), and MAY allow longer names. 321 A server that receives a script name longer than its internal limit 322 MUST reject the corresponding operation, in particular it MUST NOT 323 truncate the script name. 325 1.8. Capabilities 327 Server capabilities are sent automatically by the server upon a 328 client connection, or after successful STARTTLS and AUTHENTICATE 329 (which establishes a SASL security layer) commands. Capabilities may 330 change immediately after a successfully completed STARTTLS command, 331 and/or immediately after a successfully completed AUTHENTICATE 332 command, and/or after a successfully completed UNAUTHENTICATE command 333 (see Section 2.14.1). Capabilities MUST remain static at all other 334 times. 336 Clients MAY request the capabilities at a later time by issuing the 337 CAPABILITY command described later. The capabilities consist of a 338 series of lines each with one or two strings. The first string is 339 the name of the capability, which is case-insensitive. The second 340 optional string is the value associated with that capability. Order 341 of capabilities is arbitrary, but each capability name can appear at 342 most once. 344 The following capabilities are defined in this document: 346 IMPLEMENTATION - Name of implementation and version. This capability 347 MUST always be returned by the server. 349 SASL - List of SASL mechanisms supported by the server, each 350 separated by a space. This list can be empty if and only if STARTTLS 351 is also advertised. This means that the client must negotiate TLS 352 encryption with STARTTLS first, at which point the SASL capability 353 will list a non empty list of SASL mechanisms. 355 SIEVE - List of space separated Sieve extensions (as listed in Sieve 356 "require" action [SIEVE]) supported by the Sieve engine. This 357 capability MUST always be returned by the server. 359 STARTTLS - If TLS [TLS] is supported by this implementation. Before 360 advertising this capability a server MUST verify to the best of its 361 ability that TLS can be successfully negotiated by a client with 362 common cipher suites. Specifically, a server should verify that a 363 server certificate has been installed and that the TLS subsystem has 364 successfully initialized. This capability SHOULD NOT be advertised 365 once STARTTLS or AUTHENTICATE command completes successfully. Client 366 and server implementations MUST implement the STARTTLS extension. 368 MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" 369 actions a script can perform during a single evaluation. Note, that 370 this is different from the total number of "redirect" actions a 371 script can contain. The value is a non-negative number represented 372 as a ManageSieve string. 374 NOTIFY - A space separated list of URI schema parts for supported 375 notification methods. This capability MUST be specified if the Sieve 376 implementation supports the "enotify" extension [NOTIFY]. 378 LANGUAGE - The language ( from [RFC4646]) currently 379 used for human readable error messages. If this capability is not 380 returned, the "i-default" [RFC2277] language is assumed. Note that 381 the current language MAY be per-user configurable (i.e. it MAY change 382 after authentication). 384 OWNER - The canonical name of the logged in user (SASL "authorization 385 identity") encoded in UTF-8. This capability MUST NOT be returned in 386 unauthenticated state and SHOULD be returned once the AUTHENTICATE 387 command succeeds. 389 VERSION - This capability MUST be returned by servers compliant with 390 this document or its successor. For servers compliant with this 391 document the capability value is the string "1.0". Lack of this 392 capability means that the server predates this specification and thus 393 doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT and 394 NOOP. 396 Section 2.14 defines some additional ManageSieve extensions and their 397 respective capabilities. 399 A server implementation MUST return SIEVE, IMPLEMENTATION and VERSION 400 capabilities. 402 A client implementation MUST ignore any listed capabilities that it 403 does not understand. 405 Example: 407 S: "IMPlemENTATION" "Example1 ManageSieved v001" 408 S: "SASl" "DIGEST-MD5 GSSAPI" 409 S: "SIeVE" "fileinto vacation" 410 S: "StaRTTLS" 411 S: "NOTIFY" "xmpp mailto" 412 S: "MAXREdIRECTS" "5" 413 S: "VERSION" "1.0" 414 S: OK 416 After successful authentication this might look like this: 418 Example: 420 S: "IMPlemENTATION" "Example1 ManageSieved v001" 421 S: "SASl" "DIGEST-MD5 GSSAPI" 422 S: "SIeVE" "fileinto vacation" 423 S: "NOTIFY" "xmpp mailto" 424 S: "OWNER" "alexey@example.com" 425 S: "MAXREdIRECTS" "5" 426 S: "VERSION" "1.0" 427 S: OK 429 1.9. Transport 431 The ManageSieve protocol assumes a reliable data stream such as that 432 provided by TCP. When TCP is used, a ManageSieve server typically 433 listens on port [[anchor7: To-be-assigned by IANA]]. 435 Before opening the TCP connection, the ManageSieve client first MUST 436 resolve the Domain Name System (DNS) hostname associated with the 437 receiving entity and determine the appropriate TCP port for 438 communication with the receiving entity. The process is as follows: 440 1. Attempt to resolve the hostname using a [DNS-SRV] Service of 441 "sieve" and a Proto of "tcp" for the target domain (e.g. 442 "example.net"), resulting in resource records such as 443 "_sieve._tcp.example.net.". The result of the SRV lookup, if 444 successful, will be one or more combinations of a port and 445 hostname; the ManageSieve client MUST resolve the returned 446 hostnames to IPv4/IPv6 addresses according to returned SRV record 447 weight. IP addresses from the first successfully resolved 448 hostname (with the corresponding port number returned by SRV 449 lookup) are used to connect to the server. If connection using 450 one of the IP addresses fails, the next resolved IP address is 451 used to connect. If connection to all resolved IP addresses 452 fails, then the resolution/connect is repeated for the next 453 hostname returned by SRV lookup. 455 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or 456 IPv6 address record resolution to determine the IP address, where 457 the port used is the default ManageSieve port of [[anchor8: To- 458 be-assigned by IANA]]. 460 2. Commands 462 This section and its subsections describes valid ManageSieve 463 commands. Upon initial connection to the server the client's session 464 is in non-authenticated state. Prior to successful authentication 465 only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see 466 Section 2.13) commands are valid. ManageSieve extensions MAY define 467 other commands which are valid in non-authenticated state. Servers 468 MUST reject all other commands with a NO response. Clients may 469 pipeline commands (send more than one command at a time without 470 waiting for completion of the first command ). However, a group of 471 commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS 472 or a HAVESPACE command anywhere but the last command in the list. 474 (*) - The only exception to this rule is when the AUTHENTICATE 475 command contains an initial response for a SASL mechanism that allows 476 clients to send data first, the mechanism is known to complete in one 477 round-trip and the mechanism doesn't negotiate a SASL security layer. 478 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL 479 [SASL]. 481 2.1. AUTHENTICATE Command 483 Arguments: String - mechanism 484 String - initial data (optional) 486 The AUTHENTICATE command indicates a SASL [SASL] authentication 487 mechanism to the server. If the server supports the requested 488 authentication mechanism, it performs an authentication protocol 489 exchange to identify and authenticate the user. Optionally, it also 490 negotiates a security layer for subsequent protocol interactions. If 491 the requested authentication mechanism is not supported, the server 492 rejects the AUTHENTICATE command by sending the NO response. 494 The authentication protocol exchange consists of a series of server 495 challenges and client responses that are specific to the selected 496 authentication mechanism. A server challenge consists of a string 497 (quoted or literal) followed by a CRLF. The contents of the string 498 is a base-64 encoding [BASE64] of the SASL data. A client response 499 consists of a string (quoted or literal) with the base-64 encoding of 500 the SASL data followed by a CRLF. If the client wishes to cancel the 501 authentication exchange, it issues a string containing a single "*". 502 If the server receives such a response, it MUST reject the 503 AUTHENTICATE command by sending an NO reply. 505 Note that an empty challenge/response is sent as an empty string. If 506 the mechanism dictates that the final response is sent by the server 507 this data MAY be placed within the data portion of the SASL response 508 code to save a round trip. 510 The optional initial-response argument to the AUTHENTICATE command is 511 used to save a round trip when using authentication mechanisms that 512 are defined to send no data in the initial challenge. When the 513 initial-response argument is used with such a mechanism, the initial 514 empty challenge is not sent to the client and the server uses the 515 data in the initial-response argument as if it were sent in response 516 to the empty challenge. If the initial-response argument to the 517 AUTHENTICATE command is used with a mechanism that sends data in the 518 initial challenge, the server MUST reject the AUTHENTICATE command by 519 sending the NO response. 521 The service name specified by this protocol's profile of SASL is 522 "sieve". 524 Reauthentication is not supported by ManageSieve protocol's profile 525 of SASL. I.e. after a successfully completed AUTHENTICATE command, 526 no more AUTHENTICATE commands may be issued in the same session. 527 After a successful AUTHENTICATE command completes, a server MUST 528 reject any further AUTHENTICATE commands with a NO reply. However 529 note that a server may implement UNAUTHENTICATE extension described 530 in Section 2.14.1. 532 If a security layer is negotiated through the SASL authentication 533 exchange, it takes effect immediately following the CRLF that 534 concludes the successful authentication exchange for the client, and 535 the CRLF of the OK response for the server. 537 When a security layer takes effect, the ManageSieve protocol is reset 538 to the initial state (the state in ManageSieve after a client has 539 connected to the server). The server MUST discard any knowledge 540 obtained from the client which was not obtained from the SASL (or 541 TLS) negotiation itself. Likewise, the client MUST discard any 542 knowledge obtained from the server, such as the list of ManageSieve 543 extensions, which was not obtained from the SASL (and/or TLS) 544 negotiation itself. (Note that a client MAY compare the advertised 545 SASL mechanisms before and after authentication in order to detect an 546 active down-negotiation attack. See below.) 548 Once a SASL security layer is established, the server MUST re-issue 549 the capability results, followed by an OK response. This is 550 necessary to protect against man-in-the-middle attacks which alter 551 the capabilities list prior to SASL negotiation. The capability 552 results MUST include all SASL mechanisms the server was capable of 553 negotiating with that client. This is done in order to allow the 554 client to detect active down-negotiation attack. If a user-oriented 555 client detects such down-negotiation attack, it SHOULD either notify 556 the user (it MAY give the user the opportunity to continue with the 557 ManageSieve session in this case) or close the transport connection 558 and indicate that a down-negotiation attack might be in progress. If 559 an automated client detects down-negotiation attack, it SHOULD return 560 or log an error indicating that a possible attack might be in 561 progress and/or SHOULD close the transport connection. 563 When both [TLS] and SASL security layers are in effect, the TLS 564 encoding MUST be applied (when sending data) after the SASL encoding. 566 Server implementations SHOULD support SASL proxy authentication so 567 that an administrator can administer a user's scripts. Proxy 568 authentication is when a user authenticates as herself/himself but 569 requests the server to act (authorize) as another user. 571 The authorization identity generated by this [SASL] exchange is a 572 "simple username" (in the sense defined in [SASLprep]), and both 573 client and server MUST use the [SASLprep] profile of the [StringPrep] 574 algorithm to prepare these names for transmission or comparison. If 575 preparation of the authorization identity fails or results in an 576 empty string (unless it was transmitted as the empty string), the 577 server MUST fail the authentication. 579 If an AUTHENTICATE command fails with a NO response, the client MAY 580 try another authentication mechanism by issuing another AUTHENTICATE 581 command. In other words, the client may request authentication types 582 in decreasing order of preference. 584 Note that a failed (NO) response to the AUTHENTICATE command may 585 contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- 586 NEEDED or TRANSITION-NEEDED. See Section 1.4 for detailed 587 description of the relevant conditions. 589 To ensure interoperability, both client and server implementations of 590 the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM] 591 SASL mechanism, as well as [PLAIN] over [TLS]. 593 Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in 594 other email related protocols, however a longer term goal is to 595 migrate email related protocols from using PLAIN over TLS to SCRAM- 596 HMAC-SHA-1 mechanism. 598 Examples (Note that long lines are folded for readability and are not 599 part of protocol exchange): 601 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 602 S: "SASL" "DIGEST-MD5 GSSAPI" 603 S: "SIEVE" "fileinto vacation" 604 S: "STARTTLS" 605 S: "VERSION" "1.0" 606 S: OK 607 C: Authenticate "DIGEST-MD5" 608 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 609 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 610 cyxjaGFyc2V0PXV0Zi04" 611 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 612 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 613 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 614 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 615 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 616 A9YXV0aA==" 617 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ 618 mZmZA==") 620 A slightly different variant of the same authentication exchange: 622 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 623 S: "SASL" "DIGEST-MD5 GSSAPI" 624 S: "SIEVE" "fileinto vacation" 625 S: "VERSION" "1.0" 626 S: "STARTTLS" 627 S: OK 628 C: Authenticate "DIGEST-MD5" 629 S: {136} 630 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 631 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 632 cyxjaGFyc2V0PXV0Zi04 633 C: {300+} 634 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 635 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 636 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 637 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 638 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 639 A9YXV0aA== 640 S: {56} 641 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 642 C: "" 643 S: OK 645 Another example demonstrating use of SASL PLAIN mechanism under TLS. 646 This example also demonstrate use of SASL "initial response" (the 647 second parameter to the Authenticate command): 649 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 650 S: "VERSION" "1.0" 651 S: "SASL" "" 652 S: "SIEVE" "fileinto vacation" 653 S: "STARTTLS" 654 S: OK 655 C: STARTTLS 656 S: OK 657 658 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 659 S: "VERSION" "1.0" 660 S: "SASL" "PLAIN" 661 S: "SIEVE" "fileinto vacation" 662 S: OK 663 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" 664 S: NO 665 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" 666 S: NO 667 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" 668 S: BYE "Too many failed authentication attempts" 669 671 The following example demonstrates use of SASL "initial response". 672 It also demonstrates that an empty response can be sent as a literal, 673 and that negotiation a SASL security layer results in the server 674 reissuing server capabilities: 676 C: AUTHENTICATE "GSSAPI" {1488+} 677 C: YIIE[...1480 octets here ...]dA== 678 S: {208} 679 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic 680 [...114 octets here ...] 681 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 682 C: {0+} 683 C: 684 S: {44} 685 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= 686 C: {44+} 687 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= 688 S: OK 689 690 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 691 S: "VERSION" "1.0" 692 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 693 S: "SIEVE" "fileinto vacation" 694 S: "LANGUAGE" "ru" 695 S: "MAXREDIRECTS" "3" 696 S: ok 698 2.1.1. Use of SASL PLAIN mechanism over TLS 700 This section is normative for ManageSieve client implementations that 701 support SASL [PLAIN] over [TLS]. 703 If a ManageSieve client is willing to use SASL PLAIN over TLS to 704 authenticate to the ManageSieve server, the client MUST verify the 705 server identity (see Section 2.2.1). If the server identity can't be 706 verified (e.g. the server has not provided any certificate, or if the 707 certificate verification fails) the client MUST NOT attempt to 708 authenticate using the SASL PLAIN mechanism. 710 2.2. STARTTLS Command 712 Support for STARTTLS command in servers is optional. Its 713 availability is advertised with "STARTTLS" capability as described in 714 Section 1.8. 716 The STARTTLS command requests commencement of a TLS [TLS] 717 negotiation. The negotiation begins immediately after the CRLF in 718 the OK response. After a client issues a STARTTLS command, it MUST 719 NOT issue further commands until a server response is seen and the 720 TLS negotiation is complete. 722 The STARTTLS command is only valid in non-authenticated state. The 723 server remains in non-authenticated state, even if client credentials 724 are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL 725 mechanism MAY be used to authenticate once TLS client credentials are 726 successfully exchanged, but servers supporting the STARTTLS command 727 are not required to support the EXTERNAL mechanism. 729 After the TLS layer is established, the server MUST re-issue the 730 capability results, followed by an OK response. This is necessary to 731 protect against man-in-the-middle attacks which alter the 732 capabilities list prior to STARTTLS. This capability result MUST NOT 733 include the STARTTLS capability. 735 The client MUST discard cached capability information and replace it 736 with the new information. The server MAY advertise different 737 capabilities after STARTTLS. 739 Example: 741 C: StartTls 742 S: oK 743 744 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 745 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 746 S: "SIEVE" "fileinto vacation" 747 S: "VERSION" "1.0" 748 S: "LANGUAGE" "fr" 749 S: ok 751 2.2.1. Server Identity Check 753 During the TLS negotiation, the ManageSieve client MUST check its 754 understanding of the server hostname/IP address against the server's 755 identity as presented in the server Certificate message, in order to 756 prevent man-in-the-middle attacks. In this section, the client's 757 understanding of the server's identity is called the "reference 758 identity". 760 Checking is performed according to the following rules: 762 o If the reference identity is a hostname: 764 1. If a subjectAltName extension of the SRVName [X509-SRV], 765 dNSName [X509] (in that order of preference) type is present 766 in the server's certificate, then it SHOULD be used as the 767 source of the server's identity. Matching is performed as 768 described in Section 2.2.1.1, with the exception that no 769 wildcard matching is allowed for SRVName type. If the 770 certificate contains multiple names (e.g., more than one 771 dNSName field), then a match with any one of the fields is 772 considered acceptable. 774 2. The client MAY use other types of subjectAltName for 775 performing comparison. 777 3. The server's identity MAY also be verified by comparing the 778 reference identity to the Common Name (CN) [RFC4519] value in 779 the leaf Relative Distinguished Name (RDN) of the subjectName 780 field of the server's certificate. This comparison is 781 performed using the rules for comparison of DNS names in 782 Section 2.2.1.1, below. Although the use of the Common Name 783 value is existing practice, it is deprecated, and 784 Certification Authorities are encouraged to provide 785 subjectAltName values instead. Note that the TLS 786 implementation may represent DNs in certificates according to 787 X.500 or other conventions. For example, some X.500 788 implementations order the RDNs in a DN using a left-to-right 789 (most significant to least significant) convention instead of 790 LDAP's right- to-left convention. 792 o When the reference identity is an IP address, the iPAddress 793 subjectAltName SHOULD be used by the client for comparison. The 794 comparison is performed as described in Section 2.2.1.2. 796 If the server identity check fails, user-oriented clients SHOULD 797 either notify the user (clients MAY give the user the opportunity to 798 continue with the ManageSieve session in this case) or close the 799 transport connection and indicate that the server's identity is 800 suspect. Automated clients SHOULD return or log an error indicating 801 that the server's identity is suspect and/or SHOULD close the 802 transport connection. Automated clients MAY provide a configuration 803 setting that disables this check, but MUST provide a setting which 804 enables it. 806 Beyond the server identity check described in this section, clients 807 should be prepared to do further checking to ensure that the server 808 is authorized to provide the service it is requested to provide. The 809 client may need to make use of local policy information in making 810 this determination. 812 2.2.1.1. Comparison of DNS Names 814 If the reference identity is an internationalized domain name, 815 conforming implementations MUST convert it to the ASCII Compatible 816 Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] 817 before comparison with subjectAltName values of type dNSName. 818 Specifically, conforming implementations MUST perform the conversion 819 operation specified in Section 4 of [RFC3490] as follows: 821 o in step 1, the domain name SHALL be considered a "stored string"; 823 o in step 3, set the flag called "UseSTD3ASCIIRules"; 825 o in step 4, process each label with the "ToASCII" operation; and 827 o in step 5, change all label separators to U+002E (full stop). 829 After performing the "to-ASCII" conversion, the DNS labels and names 830 MUST be compared for equality according to the rules specified in 831 Section 3 of [RFC3490], i.e. once all label separators are replaced 832 with U+002E (dot) they are compared in the case-insensitive manner. 834 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 835 values of type dNSName, and then only as the left-most (least 836 significant) DNS label in that value. This wildcard matches any 837 left-most DNS label in the server name. That is, the subject 838 *.example.com matches the server names a.example.com and 839 b.example.com, but does not match example.com or a.b.example.com. 841 2.2.1.2. Comparison of IP Addresses 843 When the reference identity is an IP address, the identity MUST be 844 converted to the "network byte order" octet string representation 845 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 846 octet string will contain exactly four octets. For IP Version 6, as 847 specified in RFC 2460, the octet string will contain exactly sixteen 848 octets. This octet string is then compared against subjectAltName 849 values of type iPAddress. A match occurs if the reference identity 850 octet string and value octet strings are identical. 852 2.2.1.3. Comparison of Other subjectName Types 854 Client implementations MAY support matching against subjectAltName 855 values of other types as described in other documents. 857 2.3. LOGOUT Command 859 The client sends the LOGOUT command when it is finished with a 860 connection and wishes to terminate it. The server MUST reply with an 861 OK response and terminate the connection. The server MUST ignore 862 commands issued by the client after the LOGOUT command. 864 Example: 866 C: Logout 867 S: Ok 868 870 2.4. CAPABILITY Command 872 The CAPABILITY command requests the server capabilities as described 873 earlier in this document. It has no parameters. 875 Example: 877 C: CAPABILITY 878 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 879 S: "VERSION" "1.0" 880 S: "SASL" "PLAIN OTP GSSAPI" 881 S: "SIEVE" "fileinto vacation" 882 S: "STARTTLS" 883 S: OK 885 2.5. HAVESPACE Command 887 Arguments: String - name 888 Number - script size 890 The HAVESPACE command is used to query the server for available 891 space. Clients specify the name they wish to save the script as and 892 its size in octets. Both parameters can be used by the server to see 893 if the script with the specified name and size is within user's 894 quota(s), for example the server MAY use the script name to check if 895 a script would be replaced or a new one would be created. Servers 896 respond with an NO if storing a script with that name and size would 897 fail or OK otherwise. Clients SHOULD issue this command before 898 attempting to place a script on the server. 900 Note that the OK response from the HAVESPACE command does not 901 constitute a guarantee of success as server disk space conditions 902 could change between the client issuing the HAVESPACE and the client 903 issuing the PUTSCRIPT commands. A QUOTA response code (see 904 Section 1.4) remains a possible (albeit unlikely) response to a 905 subsequent PUTSCRIPT with the same name and size. 907 Example: 909 C: HAVESPACE "myscript" 999999 910 S: NO (QUOTA/MAXSIZE) "Quota exceeded" 912 C: HAVESPACE "foobar" 435 913 S: OK 915 2.6. PUTSCRIPT Command 917 Arguments: String - Script name 918 String - Script content 920 The PUTSCRIPT command is used by the client to submit a Sieve script 921 to the server. 923 If the script already exists, upon success the old script will be 924 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 925 fails in any way. A script of zero length SHOULD be disallowed. 927 This command places the script on the server. It does not affect 928 whether the script is processed on incoming mail, unless it replaces 929 the script which is already active. The SETACTIVE command is used to 930 mark a script as active. 932 When submitting large scripts clients SHOULD use the HAVESPACE 933 command beforehand to query if the server is willing to accept a 934 script of that size. 936 The server MUST check the submitted script for validity, which 937 includes checking that the script complies with the Sieve grammar 938 [SIEVE], and that all Sieve extensions mentioned in script's 939 "require" statement(s) are supported by the Sieve interpreter. (Note 940 that if the Sieve interpreter supports the Sieve "ihave" extension 941 [I-HAVE], any unrecognized/unsupported extension mentioned in the 942 "ihave" test MUST NOT cause the validation failure.) Other checks 943 such as validating the supplied command arguments for each command 944 MAY be performed. Essentially, the performed validation SHOULD be 945 the same as performed when compiling the script for execution. 946 Implementations that use a binary representation to store compiled 947 scripts can extend the validation to a full compilation, in order to 948 avoid validating uploaded scripts multiple times. 950 If the script fails the validation the server MUST reply with a NO 951 response. Any script that fails the validity test MUST NOT be stored 952 on the server. The message given with a NO response MUST be human 953 readable and SHOULD contain a specific error message giving the line 954 number of the first error. Implementors should strive to produce 955 helpful error messages similar to those given by programming language 956 compilers. Client implementations should note that this may be a 957 multiline literal string with more than one error message separated 958 by CRLFs. The human readable message is in the language returned in 959 the latest LANGUAGE capability (or in "i-default", see Section 1.8), 960 encoded in UTF-8 [UTF-8]. 962 An OK response MAY contain the WARNINGS response code. In such case 963 the human readable message that follows the OK response SHOULD 964 contain a specific warning message (or messages) giving the line 965 number(s) in the script that might contain errors not intended by the 966 script writer. The human readable message is in the language 967 returned in the latest LANGUAGE capability (or in "i-default", see 968 Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response 969 code SHOULD present the message to the user. 971 Examples: 973 C: Putscript "foo" {31+} 974 C: #comment 975 C: InvalidSieveCommand 976 C: 977 S: NO "line 2: Syntax error" 979 C: Putscript "mysievescript" {110+} 980 C: require ["fileinto"]; 981 C: 982 C: if envelope :contains "to" "tmartin+sent" { 983 C: fileinto "INBOX.sent"; 984 C: } 985 S: OK 987 C: Putscript "myforwards" {190+} 988 C: redirect "111@example.net"; 989 C: 990 C: if size :under 10k { 991 C: redirect "mobile@cell.example.com"; 992 C: } 993 C: 994 C: if envelope :contains "to" "tmartin+lists" { 995 C: redirect "lists@groups.example.com"; 996 C: } 997 S: OK (WARNINGS) "line 8: server redirect action 998 limit is 2, this redirect might be ignored" 1000 2.7. LISTSCRIPTS Command 1002 This command lists the scripts the user has on the server. Upon 1003 success a list of CRLF separated script names (each represented as a 1004 quoted or literal string) is returned followed by an OK response. If 1005 there exists an active script the atom ACTIVE is appended to the 1006 corresponding script name. The atom ACTIVE MUST NOT appear on more 1007 than one response line. 1009 Example: 1011 C: Listscripts 1012 S: "summer_script" 1013 S: "vacation_script" 1014 S: {13} 1015 S: clever"script 1016 S: "main_script" ACTIVE 1017 S: OK 1019 C: listscripts 1020 S: "summer_script" 1021 S: "main_script" active 1022 S: OK 1024 2.8. SETACTIVE Command 1026 Arguments: String - script name 1028 This command sets a script active. If the script name is the empty 1029 string (i.e. "") then any active script is disabled. Disabling an 1030 active script when there is no script active is not an error and MUST 1031 result in OK reply. 1033 If the script does not exist on the server then the server MUST reply 1034 with a NO response. Such reply SHOULD contain the NONEXISTENT 1035 response code. 1037 Examples: 1039 C: Setactive "vacationscript" 1040 S: Ok 1042 C: Setactive "" 1043 S: Ok 1045 C: Setactive "baz" 1046 S: No (NONEXISTENT) "There is no script by that name" 1048 C: Setactive "baz" 1049 S: No (NONEXISTENT) {31} 1050 S: There is no script by that name 1052 2.9. GETSCRIPT Command 1054 Arguments: String - script name 1056 This command gets the contents of the specified script. If the 1057 script does not exist the server MUST reply with a NO response. Such 1058 reply SHOULD contain the NONEXISTENT response code. 1060 Upon success a string with the contents of the script is returned 1061 followed by a OK response. 1063 Example: 1065 C: Getscript "myscript" 1066 S: {54} 1067 S: #this is my wonderful script 1068 S: reject "I reject all"; 1069 S: 1070 S: OK 1072 2.10. DELETESCRIPT Command 1074 Arguments: String - script name 1076 This command is used to delete a user's Sieve script. Servers MUST 1077 reply with a NO response if the script does not exist. Such 1078 responses SHOULD include the NONEXISTENT response code. 1080 The server MUST NOT allow the client to delete an active script, so 1081 the server MUST reply with a NO response if attempted. Such response 1082 SHOULD contain the ACTIVE response code. If a client wishes to 1083 delete an active script it should use the SETACTIVE command to 1084 disable the script first. 1086 Example: 1088 C: Deletescript "foo" 1089 S: Ok 1091 C: Deletescript "baz" 1092 S: No (ACTIVE) "You may not delete an active script" 1094 2.11. RENAMESCRIPT Command 1096 Arguments: String - Old Script name 1097 String - New Script name 1099 This command is used to rename a user's Sieve script. Servers MUST 1100 reply with a NO response if the old script does not exist (in which 1101 case the NONEXISTENT response code SHOULD be included), or a script 1102 with the new name already exists (in which case the ALREADYEXISTS 1103 response code SHOULD be included). Renaming the active script is 1104 allowed, the renamed script remains active. 1106 Example: 1108 C: Renamescript "foo" "bar" 1109 S: Ok 1111 C: Renamescript "baz" "bar" 1112 S: No "bar already exists" 1114 If the server doesn't support the RENAMESCRIPT command, the client 1115 can emulate it by performing the following steps: 1117 1. List available scripts with LISTSCRIPTS. If the script with the 1118 new script name exists, then the client should ask the user 1119 whether to abort the operation, to replace the script (by issuing 1120 the DELETESCRIPT after that) or to chose a different 1121 name. 1123 2. Download the old script with GETSCRIPT . 1125 3. Upload the old script with the new name: PUTSCRIPT . 1127 4. If the old script was active (as reported by LISTSCRIPTS in step 1128 1), then make the new script active: SETACTIVE 1130 5. Delete the old script: DELETESCRIPT 1132 Note that these steps don't describe how to handle various other 1133 error conditions (for example NO response containing QUOTA response 1134 code in step 3). Error handling is left as an excercise for the 1135 reader. 1137 2.12. CHECKSCRIPT Command 1139 Arguments: String - Script content 1141 The CHECKSCRIPT command is used by the client to verify Sieve script 1142 validity without storing the script on the server. 1144 The server MUST check the submitted script for syntactic validity, 1145 which includes checking that all Sieve extensions mentioned in Sieve 1146 script "require" statement(s) are supported by the Sieve interpreter. 1147 (Note that if the Sieve interpreter supports the Sieve "ihave" 1148 extension [I-HAVE], any unrecognized/unsupported extension mentioned 1149 in the "ihave" test MUST NOT cause the syntactic validation failure.) 1150 If the script fails this test the server MUST reply with a NO 1151 response. The message given with a NO response MUST be human 1152 readable and SHOULD contain a specific error message giving the line 1153 number of the first error. Implementors should strive to produce 1154 helpful error messages similar to those given by programming language 1155 compilers. Client implementations should note that this may be a 1156 multiline literal string with more than one error message separated 1157 by CRLFs. The human readable message is in the language returned in 1158 the latest LANGUAGE capability (or in "i-default", see Section 1.8), 1159 encoded in UTF-8 [UTF-8]. 1161 Examples: 1163 C: CheckScript {31+} 1164 C: #comment 1165 C: InvalidSieveCommand 1166 C: 1167 S: NO "line 2: Syntax error" 1169 A ManageSieve server supporting this command MUST NOT check if the 1170 script will put the current user over its quota limit. 1172 An OK response MAY contain the WARNINGS response code. In such case 1173 the human readable message that follows the OK response SHOULD 1174 contain a specific warning message (or messages) giving the line 1175 number(s) in the script that might contain errors not intended by the 1176 script writer. The human readable message is in the language 1177 returned in the latest LANGUAGE capability (or in "i-default", see 1178 Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response 1179 code SHOULD present the message to the user. 1181 2.13. NOOP Command 1183 Arguments: String - tag to echo back (optional) 1185 The NOOP command does nothing, beyond returning a response to the 1186 client. It may be used by clients for protocol re-synchronisation or 1187 to reset any inactivity auto-logout timer on the server. 1189 The response to the NOOP command is always OK, followed by the TAG 1190 response code together with the supplied string; if no string was 1191 supplied in the NOOP command, the TAG response code MUST NOT be 1192 included. 1194 Examples: 1196 C: NOOP 1197 S: OK "NOOP completed" 1199 C: NOOP "STARTTLS-SYNC-42" 1200 S: OK (TAG {16} 1201 S: STARTTLS-SYNC-42) "Done" 1203 2.14. Recommended extensions 1205 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" 1206 capability with no parameters) defines a new UNAUTHENTICATE command, 1207 which allows a client to return the server to non-authenticated 1208 state. Support for this extension is RECOMMENDED. 1210 2.14.1. UNAUTHENTICATE Command 1212 The UNAUTHENTICATE command returns the server to the non- 1213 authenticated state. It doesn't affect any previously established 1214 TLS [TLS] or SASL (Section 2.1) security layer. 1216 The UNAUTHENTICATE command is only valid in authenticated state. If 1217 issued in a wrong state, the server MUST reject it with a NO 1218 response. 1220 The UNAUTHENTICATE command has no parameters. 1222 When issued in the authenticated state, the UNAUTHENTICATE command 1223 MUST NOT fail (i.e. it must never return anything other than OK or 1224 BYE) 1226 3. Sieve URL Scheme 1228 URI scheme name: sieve 1230 Status: permanent 1232 URI scheme syntax: 1234 Described using ABNF [ABNF]. Some ABNF productions not defined 1235 below are from [URI-GEN]. 1237 sieveurl = sieveurl-server / sieveurl-list-scripts / 1238 sieveurl-script 1240 sieveurl-server = "sieve://" authority 1242 sieveurl-list-scripts = "sieve://" authority ["/"] 1244 sieveurl-script = "sieve://" authority "/" 1245 [owner "/"] scriptname 1247 authority = 1249 owner = *ochar 1250 ;; %-encoded version of [SASL] authorization 1251 ;; identity (script owner) or "userid". 1252 ;; 1253 ;; Empty owner is used to reference 1254 ;; global scripts. 1255 ;; 1256 ;; Note that ASCII characters such as " ", ";", 1257 ;; "&", "=", "/" and "?" must be %-encoded 1258 ;; as per rule specified in [URI-GEN]. 1260 scriptname = 1*ochar 1261 ;; %-encoded version of UTF-8 representation 1262 ;; of the script name. 1263 ;; Note that ASCII characters such as " ", ";", 1264 ;; "&", "=", "/" and "?" must be %-encoded 1265 ;; as per rule specified in [URI-GEN]. 1267 ochar = unreserved / pct-encoded / sub-delims-sh / 1268 ":" / "@" 1269 ;; Same as [URI-GEN] 'pchar' 1270 ;; but without ";", "&" and "=". 1272 unreserved = 1274 pct-encoded = 1276 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 1277 "*" / "+" / "," 1278 ;; Same as [URI-GEN] sub-delims, 1279 ;; but without ";", "&" and "=". 1281 URI scheme semantics: 1283 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve 1284 server. The latter form is associated with the application/sieve 1285 MIME type defined in [SIEVE]. There is no MIME type associated 1286 with the former form of Sieve URI. 1288 The server form is used in the REFERRAL response code (see 1289 Section 1.4 in order to designate another server where the client 1290 should perform its operations. 1292 The script form allows to retrieve (GETSCRIPT), update 1293 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the 1294 named script, however the most typical action would be to retrieve 1295 the script. If the script name is empty (omitted), the URI 1296 requests that the client lists available scripts using the 1297 LISTSCRIPTS command. 1299 Encoding considerations: 1301 The script name and/or the owner, if present, is in UTF-8. Non- 1302 US-ASCII UTF-8 octets MUST be percent-encoded as described in 1303 [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", 1304 "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. 1305 Note that "&" and "?" are in this list in order to allow for 1306 future extensions. 1308 Note that the empty owner (e.g. sieve://example.com//script) is 1309 different from the missing owner (e.g. sieve://example.com/script) 1310 and is reserved for referencing global scripts. 1312 The user name (in the "authority" part), if present, is in UTF-8. 1313 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1314 [URI-GEN]. 1316 Applications/protocols that use this URI scheme name: 1317 ManageSieve [RFC XXXX] clients and servers. Clients that can store 1318 user preferences in protocols such as [LDAP] or [ACAP]. 1320 Interoperability considerations: None. 1322 Security considerations: 1323 The part of a ManageSieve URL might potentially disclose 1324 some confidential information about the author of the script or, 1325 depending on a ManageSieve implementation, about configuration of the 1326 mail system. The latter might be used to prepare for a more complex 1327 attack on the mail system. 1329 Clients resolving ManageSieve URLs that wish to achieve data 1330 confidentiality and/or integrity SHOULD use the STARTTLS command (if 1331 supported by the server) before starting authentication, or use a 1332 SASL mechanism, such as GSSAPI, that provides a confidentiality 1333 security layer. 1335 Contact: Alexey Melnikov 1337 Author/Change controller: IESG. 1339 References: This document and RFC 5228 [SIEVE]. 1341 4. Formal Syntax 1343 The following syntax specification uses the augmented Backus-Naur 1344 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 1345 rules as specified in Appendix A of the ABNF specification [ABNF]. 1346 "UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8]. 1348 Except as noted otherwise, all alphabetic characters are case- 1349 insensitive. The use of upper or lower case characters to define 1350 token strings is for editorial clarity only. Implementations MUST 1351 accept these strings in a case-insensitive fashion. 1353 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 1354 %x5D-7F 1355 ;; any TEXT-CHAR except QUOTED-SPECIALS 1357 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 1359 QUOTED-SPECIALS = DQUOTE / "\" 1361 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 1362 ;; , and 1363 ;; are defined in [UTF-8] 1365 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E 1366 ;; Any CHAR except ATOM-SPECIALS 1368 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / 1369 QUOTED-SPECIALS 1371 atom = 1*1024ATOM-CHAR 1373 iana-token = atom 1374 ;; MUST be registered with IANA 1376 auth-type = DQUOTE auth-type-name DQUOTE 1378 auth-type-name = iana-token 1379 ;; as defined in SASL [SASL] 1381 command = (command-any / command-auth / 1382 command-nonauth) CRLF 1383 ;; Modal based on state 1385 command-any = command-capability / command-logout / 1386 command-noop 1387 ;; Valid in all states 1389 command-auth = command-getscript / command-setactive / 1390 command-listscripts / command-deletescript / 1391 command-putscript / command-checkscript / 1392 command-havespace / 1393 command-renamescript / 1394 command-unauthenticate 1395 ;; Valid only in Authenticated state 1397 command-nonauth = command-authenticate / command-starttls 1398 ;; Valid only when in Non-Authenticated 1399 ;; state 1401 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 1402 *(CRLF string) 1404 command-capability = "CAPABILITY" 1406 command-deletescript = "DELETESCRIPT" SP sieve-name 1408 command-getscript = "GETSCRIPT" SP sieve-name 1410 command-havespace = "HAVESPACE" SP sieve-name SP number 1412 command-listscripts = "LISTSCRIPTS" 1414 command-noop = "NOOP" [SP string] 1416 command-logout = "LOGOUT" 1418 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script 1420 command-checkscript = "CHECKSCRIPT" SP sieve-script 1422 sieve-script = string 1423 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP 1424 new-sieve-name 1426 old-sieve-name = sieve-name 1428 new-sieve-name = sieve-name 1430 command-setactive = "SETACTIVE" SP active-sieve-name 1432 command-starttls = "STARTTLS" 1434 command-unauthenticate= "UNAUTHENTICATE" 1436 extend-token = atom 1437 ;; MUST be defined by a standards track or 1438 ;; IESG approved experimental protocol 1439 ;; extension 1441 extension-data = extension-item *(SP extension-item) 1443 extension-item = extend-token / string / number / 1444 "(" [extension-data] ")" 1446 literal-c2s = "{" number "+}" CRLF *OCTET 1447 ;; The number represents the number of 1448 ;; octets. 1449 ;; This type of literal can only be sent 1450 ;; from the client to the server. 1452 literal-s2c = "{" number "}" CRLF *OCTET 1453 ;; Almost identical to literal-c2s, 1454 ;; but with no '+' character. 1455 ;; The number represents the number of 1456 ;; octets. 1457 ;; This type of literal can only be sent 1458 ;; from the server to the client. 1460 number = 1*DIGIT 1461 ;; A 32-bit unsigned number 1462 ;; with no extra leading zeros. 1463 ;; (0 <= n < 4,294,967,296) 1465 number-str = string 1466 ;; encoded as a . 1468 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1469 ;; limited to 1024 octets between the <">s 1471 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1472 "QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] / 1473 resp-code-sasl / 1474 resp-code-referral / 1475 "TRANSITION-NEEDED" / "TRYLATER" / 1476 "ACTIVE" / "NONEXISTENT" / 1477 "ALREADYEXISTS" / "WARNINGS" / 1478 "TAG" SP string / 1479 resp-code-ext 1481 resp-code-referral = "REFERRAL" SP sieveurl 1483 resp-code-sasl = "SASL" SP string 1485 resp-code-name = iana-token 1486 ;; The response code name is hierarchical, 1487 ;; separated by '/'. 1488 ;; The response code name MUST NOT start 1489 ;; with '/'. 1491 resp-code-ext = resp-code-name [SP extension-data] 1492 ;; unknown response codes MUST be tolerated 1493 ;; by the client. 1495 response = response-authenticate / 1496 response-logout / 1497 response-getscript / 1498 response-setactive / 1499 response-listscripts / 1500 response-deletescript / 1501 response-putscript / 1502 response-checkscript / 1503 response-capability / 1504 response-havespace / 1505 response-starttls / 1506 response-renamescript / 1507 response-noop / 1508 response-unauthenticate 1510 response-authenticate = *(string CRLF) 1511 ((response-ok [response-capability]) / 1512 response-nobye) 1513 ;; is REQUIRED if a 1514 ;; SASL security layer was negotiated and 1515 ;; MUST be omitted otherwise. 1517 response-capability = *(single-capability) response-oknobye 1518 single-capability = capability-name [SP string] CRLF 1520 capability-name = string 1521 ;; Note that literal-s2c is allowed. 1523 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1524 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1525 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1526 DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / 1527 DQUOTE "NOTIFY" DQUOTE SP notify-mechs / 1528 DQUOTE "STARTTLS" DQUOTE / 1529 DQUOTE "LANGUAGE" DQUOTE SP language / 1530 DQUOTE "VERSION" DQUOTE SP version / 1531 DQUOTE "OWNER" DQUOTE SP string 1532 ;; Each capability conforms to 1533 ;; the syntax for single-capability. 1534 ;; Also note that the capability name 1535 ;; can be returned as either literal-s2c 1536 ;; or quoted, even though only "quoted" 1537 ;; string is shown above. 1539 version = ( DQUOTE "1.0" DQUOTE ) / version-ext 1541 version-ext = DQUOTE number "." number DQUOTE 1543 sasl-mechs = string 1544 ; space separated list of SASL mechanisms, 1545 ; each SASL mechanism name complies with rules 1546 ; specified in [SASL]. 1547 ; Can be empty. 1549 sieve-extensions = string 1550 ; space separated list of supported SIEVE extensions, 1551 ; can be empty. 1553 language = string 1554 ; Contains from [RFC4646]. 1556 notify-mechs = string 1557 ; space separated list of URI schema parts 1558 ; for supported notification [NOTIFY] methods. 1559 ; MUST NOT be empty. 1561 response-deletescript = response-oknobye 1563 response-getscript = (sieve-script CRLF response-ok) / 1564 response-nobye 1566 response-havespace = response-oknobye 1568 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1569 response-oknobye 1570 ;; ACTIVE may only occur with one sieve-name 1572 response-logout = response-oknobye 1574 response-unauthenticate= response-oknobye 1575 ;; "NO" response can only be returned when 1576 ;; the command is issued in a wrong state 1577 ;; or has a wrong number of parameters 1579 response-ok = "OK" [SP "(" resp-code ")"] 1580 [SP string] CRLF 1581 ;; The string contains human readable text 1582 ;; encoded as UTF-8. 1584 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1585 [SP string] CRLF 1586 ;; The string contains human readable text 1587 ;; encoded as UTF-8. 1589 response-oknobye = response-ok / response-nobye 1591 response-noop = response-ok 1593 response-putscript = response-oknobye 1595 response-checkscript = response-oknobye 1597 response-renamescript = response-oknobye 1599 response-setactive = response-oknobye 1601 response-starttls = (response-ok response-capability) / 1602 response-nobye 1604 sieve-name = string 1605 ;; See Section 1.6 for the full list of 1606 ;; prohibited characters. 1607 ;; Empty string is not allowed. 1609 active-sieve-name = string 1610 ;; See Section 1.6 for the full list of 1611 ;; prohibited characters. 1612 ;; This is similar to , but 1613 ;; empty string is allowed and has a special 1614 ;; meaning. 1616 string = quoted / literal-c2s / literal-s2c 1617 ;; literal-c2s is only allowed when sent 1618 ;; from the client to the server. 1619 ;; literal-s2c is only allowed when sent 1620 ;; from the server to the client. 1621 ;; quoted is allowed in either direction. 1623 5. Security Considerations 1625 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1626 and authorization services. Integrity and privacy services can be 1627 provided by [SASL] and/or [TLS]. When a SASL mechanism is used the 1628 security considerations for that mechanism apply. 1630 This protocol's transactions are susceptible to passive observers or 1631 man in the middle attacks which alter the data, unless the optional 1632 encryption and integrity services of the SASL (via the AUTHENTICATE 1633 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1634 external security mechanism is used for protection. It may be useful 1635 to allow configuration of both clients and servers to refuse to 1636 transfer sensitive information in the absence of strong encryption. 1638 If an implementation supports SASL mechanisms that are vulnerable to 1639 passive eavesdropping attacks (such as [PLAIN]), then the 1640 implementation MUST support at least one configuration where these 1641 SASL mechanisms are not advertised or used without the presence of an 1642 external security layer such as [TLS]. 1644 Some response codes returned on failed AUTHENTICATE command may 1645 disclose whether or not the username is valid (e.g. TRANSITION- 1646 NEEDED), so server implementations SHOULD provide the ability to 1647 disable these features (or make them not conditional on a per-user 1648 basis) for sites concerned about such disclosure. In the case of 1649 ENCRYPT-NEEDED, if it is applied to all identities then no extra 1650 information is disclosed, but if it is applied on a per-user basis it 1651 can disclose information. 1653 A compromised or malicious server can use the TRANSITION-NEEDED 1654 response code to force the client which is configured to use a 1655 mechanism that does not disclose the user's password to the server 1656 (e.g., Kerberos), to send the bare password to the server. Clients 1657 SHOULD have the ability to disable the password transition feature, 1658 or disclose that risk to the user and offer the user an option how to 1659 proceed. 1661 6. IANA Considerations 1663 IANA is requested to reserve a TCP port number for use with the 1664 ManageSieve protocol described in this document. 1666 IANA is requested to register the "sieve" URI scheme defined in 1667 Section 3 of this document. 1669 IANA is requested to register "sieve" in the "GSSAPI/Kerberos/SASL 1670 Service Names" registry. 1672 IANA is requested to create a new registry for ManageSieve 1673 capabilities. The registration template for ManageSieve capabilities 1674 is specified in Section 6.1. ManageSieve protocol capabilities MUST 1675 be specified in a standards track or IESG approved experimental RFC. 1677 IANA is requested to create a new registry for ManageSieve response 1678 codes. The registration template for ManageSieve response codes is 1679 specified in Section 6.3. ManageSieve protocol response codes MUST 1680 be specified in a standards track or IESG approved experimental RFC. 1682 6.1. ManageSieve Capability Registration Template 1684 To: iana@iana.org 1685 Subject: ManageSieve Capability Registration 1687 Please register the following ManageSieve Capability: 1688 Capability name: 1689 Description: 1690 Relevant publications: 1691 Person & email address to contact for further information: 1692 Author/Change controller: 1694 6.2. Registration of Initial ManageSieve capabilities 1696 To: iana@iana.org 1697 Subject: ManageSieve Capability Registration 1699 Please register the following ManageSieve Capabilities: 1701 Capability name: IMPLEMENTATION 1703 Description: Its value contains name of server implementation and 1704 its version. 1706 Relevant publications: this RFC, Section 1.8. 1708 Person & email address to contact for further information: Alexey 1709 Melnikov 1711 Author/Change controller: IESG. 1713 Capability name: SASL 1715 Description: Its value contains a space separated list of SASL 1716 mechanisms supported by server. 1718 Relevant publications: this RFC, Section 1.8 and Section 2.1. 1720 Person & email address to contact for further information: Alexey 1721 Melnikov 1723 Author/Change controller: IESG. 1725 Capability name: SIEVE 1727 Description: Its value contains a space separated list of 1728 supported SIEVE extensions 1730 Relevant publications: this RFC, Section 1.8. Also [SIEVE]. 1732 Person & email address to contact for further information: Alexey 1733 Melnikov 1735 Author/Change controller: IESG. 1737 Capability name: STARTTLS 1739 Description: This capability is returned if server supports TLS 1740 (STARTTLS command). 1742 Relevant publications: this RFC, Section 1.8 and Section 2.2. 1744 Person & email address to contact for further information: Alexey 1745 Melnikov 1747 Author/Change controller: IESG. 1749 Capability name: NOTIFY 1751 Description: This capability is returned if server supports 1752 'enotify' [NOTIFY] Sieve extension. 1754 Relevant publications: this RFC, Section 1.8. 1756 Person & email address to contact for further information: Alexey 1757 Melnikov 1759 Author/Change controller: IESG. 1761 Capability name: MAXREDIRECTS 1763 Description: This capability returns the limit on the number of 1764 Sieve "redirect" actions a script can perform during a single 1765 evaluation. The value is a non-negative number represented as a 1766 ManageSieve string. 1768 Relevant publications: this RFC, Section 1.8. 1770 Person & email address to contact for further information: Alexey 1771 Melnikov 1773 Author/Change controller: IESG. 1775 Capability name: LANGUAGE 1777 Description: The language ( from [RFC4646]) 1778 currently used for human readable error messages. 1780 Relevant publications: this RFC, Section 1.8. 1782 Person & email address to contact for further information: Alexey 1783 Melnikov 1785 Author/Change controller: IESG. 1787 Capability name: OWNER 1789 Description: Its value contains UTF-8 encoded name of the 1790 currently logged in user ("authorization identity" according to 1791 RFC 4422). 1793 Relevant publications: this RFC, Section 1.8. 1795 Person & email address to contact for further information: Alexey 1796 Melnikov 1798 Author/Change controller: IESG. 1800 Capability name: VERSION 1802 Description: This capability is returned if the server is 1803 compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT, 1804 CHECKSCRIPT and NOOP commands. 1806 Relevant publications: this RFC, Section 2.11. 1808 Person & email address to contact for further information: Alexey 1809 Melnikov 1811 Author/Change controller: IESG. 1813 6.3. ManageSieve Response Code Registration Template 1815 To: iana@iana.org 1816 Subject: ManageSieve Response Code Registration 1818 Please register the following ManageSieve Response Code: 1820 Response Code: 1822 Arguments (use ABNF to specify syntax, or the word NONE if none 1823 can be specified): 1825 Purpose: 1827 Published Specification(s): 1829 Person & email address to contact for further information: 1831 Author/Change controller: 1833 6.4. Registration of Initial ManageSieve Response Codes 1835 To: iana@iana.org 1836 Subject: ManageSieve Response Code Registration 1838 Please register the following ManageSieve Response Codes: 1840 Response Code: AUTH-TOO-WEAK 1842 Arguments (use ABNF to specify syntax, or the word NONE if none 1843 can be specified): NONE 1845 Purpose: This response code is returned in the NO response from an 1846 AUTHENTICATE command. It indicates that site security policy 1847 forbids the use of the requested mechanism for the specified 1848 authentication identity. 1850 Published Specification(s): [RFCXXXX] 1851 Person & email address to contact for further information: Alexey 1852 Melnikov 1854 Author/Change controller: IESG. 1856 Response Code: ENCRYPT-NEEDED 1858 Arguments (use ABNF to specify syntax, or the word NONE if none 1859 can be specified): NONE 1861 Purpose: This response code is returned in the NO response from an 1862 AUTHENTICATE command. It indicates that site security policy 1863 requires the use of a strong encryption mechanism for the 1864 specified authentication identity and mechanism. 1866 Published Specification(s): [RFCXXXX] 1868 Person & email address to contact for further information: Alexey 1869 Melnikov 1871 Author/Change controller: IESG. 1873 Response Code: QUOTA 1875 Arguments (use ABNF to specify syntax, or the word NONE if none 1876 can be specified): NONE 1878 Purpose: If this response code is returned in the NO/BYE response, 1879 it means that the command would have placed the user above the 1880 site-defined quota constraints. If this response code is returned 1881 in the OK response, it can mean that the user is near its quota or 1882 that the user exceeded its quota, but the server supports soft 1883 quotas. 1885 Published Specification(s): [RFCXXXX] 1887 Person & email address to contact for further information: Alexey 1888 Melnikov 1890 Author/Change controller: IESG. 1892 Response Code: QUOTA/MAXSCRIPTS 1894 Arguments (use ABNF to specify syntax, or the word NONE if none 1895 can be specified): NONE 1897 Purpose: If this response code is returned in the NO/BYE response, 1898 it means that the command would have placed the user above the 1899 site-defined limit on the number of Sieve scripts. If this 1900 response code is returned in the OK response, it can mean that the 1901 user is near its quota or that the user exceeded its quota, but 1902 the server supports soft quotas. This response code is a more 1903 specific version of the QUOTA response code. 1905 Published Specification(s): [RFCXXXX] 1907 Person & email address to contact for further information: Alexey 1908 Melnikov 1910 Author/Change controller: IESG. 1912 Response Code: QUOTA/MAXSIZE 1914 Arguments (use ABNF to specify syntax, or the word NONE if none 1915 can be specified): NONE 1917 Purpose: If this response code is returned in the NO/BYE response, 1918 it means that the command would have placed the user above the 1919 site-defined maximum script size. If this response code is 1920 returned in the OK response, it can mean that the user is near its 1921 quota or that the user exceeded its quota, but the server supports 1922 soft quotas. This response code is a more specific version of the 1923 QUOTA response code. 1925 Published Specification(s): [RFCXXXX] 1927 Person & email address to contact for further information: Alexey 1928 Melnikov 1930 Author/Change controller: IESG. 1932 Response Code: REFERRAL 1934 Arguments (use ABNF to specify syntax, or the word NONE if none 1935 can be specified): 1937 Purpose: This response code may be returned with a BYE result from 1938 any command, and includes a mandatory parameter that indicates 1939 what server to access to manage this user's sieve scripts. The 1940 server will be specified by a Sieve URL (see Section 3). The 1941 scriptname portion of the URL MUST NOT be specified. The client 1942 should authenticate to the specified server and use it for all 1943 further commands in the current session. 1945 Published Specification(s): [RFCXXXX] 1946 Person & email address to contact for further information: Alexey 1947 Melnikov 1949 Author/Change controller: IESG. 1951 Response Code: SASL 1953 Arguments (use ABNF to specify syntax, or the word NONE if none 1954 can be specified): 1956 Purpose: This response code can occur in the OK response to a 1957 successful AUTHENTICATE command and includes the optional final 1958 server response data from the server as specified by [SASL]. 1960 Published Specification(s): [RFCXXXX] 1962 Person & email address to contact for further information: Alexey 1963 Melnikov 1965 Author/Change controller: IESG. 1967 Response Code: TRANSITION-NEEDED 1969 Arguments (use ABNF to specify syntax, or the word NONE if none 1970 can be specified): NONE 1972 Purpose: This response code occurs in a NO response of an 1973 AUTHENTICATE command. It indicates that the user name is valid, 1974 but the entry in the authentication database needs to be updated 1975 in order to permit authentication with the specified mechanism. 1976 This is typically done by establishing a secure channel using TLS, 1977 followed by authenticating once using the [PLAIN] authentication 1978 mechanism. The selected mechanism SHOULD then work for 1979 authentications in subsequent sessions. 1981 Published Specification(s): [RFCXXXX] 1983 Person & email address to contact for further information: Alexey 1984 Melnikov 1986 Author/Change controller: IESG. 1988 Response Code: TRYLATER 1990 Arguments (use ABNF to specify syntax, or the word NONE if none 1991 can be specified): NONE 1992 Purpose: A command failed due to a temporary server failure. The 1993 client MAY continue using local information and try the command 1994 later. This response code only make sense when returned in a NO/ 1995 BYE response. 1997 Published Specification(s): [RFCXXXX] 1999 Person & email address to contact for further information: Alexey 2000 Melnikov 2002 Author/Change controller: IESG. 2004 Response Code: ACTIVE 2006 Arguments (use ABNF to specify syntax, or the word NONE if none 2007 can be specified): NONE 2009 Purpose: A command failed because it is not allowed on the active 2010 script. For example DELETESCRIPT on the active script. This 2011 response code only makes sense when returned in a NO/BYE response. 2013 Published Specification(s): [RFCXXXX] 2015 Person & email address to contact for further information: Alexey 2016 Melnikov 2018 Author/Change controller: IESG. 2020 Response Code: NONEXISTENT 2022 Arguments (use ABNF to specify syntax, or the word NONE if none 2023 can be specified): NONE 2025 Purpose: A command failed because the referenced script name 2026 doesn't exist. This response code only makes sense when returned 2027 in a NO/BYE response. 2029 Published Specification(s): [RFCXXXX] 2031 Person & email address to contact for further information: Alexey 2032 Melnikov 2034 Author/Change controller: IESG. 2036 Response Code: ALREADYEXISTS 2038 Arguments (use ABNF to specify syntax, or the word NONE if none 2039 can be specified): NONE 2040 Purpose: A command failed because the referenced script name 2041 already exists. This response code only makes sense when returned 2042 in a NO/BYE response. 2044 Published Specification(s): [RFCXXXX] 2046 Person & email address to contact for further information: Alexey 2047 Melnikov 2049 Author/Change controller: IESG. 2051 Response Code: WARNINGS 2053 Arguments (use ABNF to specify syntax, or the word NONE if none 2054 can be specified): NONE 2056 Purpose: This response code MAY be returned by the server in the 2057 OK response (but it might be returned with the NO/BYE response as 2058 well) and signals the client that even though the script is 2059 syntactically valid, it might contain errors not intended by the 2060 script writer. 2062 Published Specification(s): [RFCXXXX] 2064 Person & email address to contact for further information: Alexey 2065 Melnikov 2067 Author/Change controller: IESG. 2069 Response Code: TAG 2071 Arguments (use ABNF to specify syntax, or the word NONE if none 2072 can be specified): string 2074 Purpose: This response code name is followed by a string specified 2075 in the command that caused this response. It is typically used 2076 for client state synchronization. 2078 Published Specification(s): [RFCXXXX] 2080 Person & email address to contact for further information: Alexey 2081 Melnikov 2083 Author/Change controller: IESG. 2085 7. Internationalization Considerations 2087 The LANGUAGE capability (see Section 1.8) allows a client to discover 2088 the current language used in all human readable responses that might 2089 be returned at the end of any OK/NO/BYE response. Human readable 2090 text in OK responses typically doesn't need to be shown to the user, 2091 unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command 2092 that also contain the WARNINGS response code Section 1.4. Human 2093 readable text from NO/BYE responses is intended be shown to the user, 2094 unless the client can automatically handle failure of the command 2095 that caused such response. Clients SHOULD use response codes 2096 (Section 1.4) for automatic error handling. Response codes MAY also 2097 be used by the client to present error messages in a language 2098 understood by the user, for example if the LANGUAGE capability 2099 doesn't return a language understood by the user. 2101 Note that the human readable text from OK (WARNINGS) or NO/BYE 2102 responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced 2103 users that understand Sieve language. Such advanced users are often 2104 sophisticated enough to be able to handle whatever language the 2105 server is using, even if it is not their preferred language, and will 2106 want to see error/warning text no matter what language the server 2107 puts it in. 2109 A client that generates Sieve script automatically, for example if 2110 the script is generated without user intervention or from a UI that 2111 presents an abstract list of conditions and corresponding actions, 2112 SHOULD NOT present warning/error messages to the user, because the 2113 user might not even be aware that the client is using Sieve 2114 underneath. However if the client has a debugging mode, such 2115 warnings/errors SHOULD be available in the debugging mode. 2117 8. Acknowledgements 2119 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 2120 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, 2121 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil 2122 Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan 2123 Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick 2124 Ben Koetter, Bjoern Hoehrmann and Martin Duerst for help with this 2125 document. Special thank you to Phil Pennock for providing text for 2126 the NOOP command, as well as finding various bugs in the document. 2128 9. References 2129 9.1. Normative References 2131 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2132 Specifications: ABNF", RFC 5234, January 2008. 2134 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 2135 Configuration Access Protocol", RFC 2244, November 1997. 2137 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 2138 Encodings", RFC 4648, October 2006. 2140 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2141 specifying the location of services (DNS SRV)", RFC 2782, 2142 February 2000. 2144 [KEYWORDS] 2145 Bradner, S., "Key words for use in RFCs to Indicate 2146 Requirement Levels", RFC 2119, March 1997. 2148 [NET-UNICODE] 2149 Klensin, J. and M. Padlipsky, "Unicode Format for Network 2150 Interchange", RFC 5198, March 2008. 2152 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 2153 Martin, "Sieve Extension: Notifications", 2154 draft-ietf-sieve-notify-12 (work in progress), 2155 December 2007. 2157 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2158 Languages", RFC 2277, January 1998. 2160 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2161 (IPv6) Specification", RFC 2460, December 1998. 2163 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2164 "Internationalizing Domain Names in Applications (IDNA)", 2165 RFC 3490, March 2003. 2167 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2168 (LDAP): Schema for User Applications", RFC 4519, 2169 June 2006. 2171 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 2172 Languages", RFC 4646, September 2006. 2174 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 2176 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2177 Security Layer (SASL)", RFC 4422, June 2006. 2179 [SASLprep] 2180 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 2181 and Passwords", RFC 4013, February 2005. 2183 [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge 2184 Response Authentication Mechanism (SCRAM)", 2185 draft-newman-auth-scram-07.txt (work in progress), 2186 November 2008. 2188 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 2189 Filtering Language", RFC 5228, January 2008. 2191 [StringPrep] 2192 Hoffman, P. and M. Blanchet, "Preparation of 2193 Internationalized Strings ("stringprep")", RFC 3454, 2194 December 2002. 2196 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2197 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2199 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2200 Resource Identifier (URI): Generic Syntax", STD 66, 2201 RFC 3986, January 2005. 2203 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2204 10646", STD 63, RFC 3629, November 2003. 2206 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2207 X.509 Public Key Infrastructure Certificate and 2208 Certificate Revocation List (CRL) Profile", RFC 5280, 2209 May 2008. 2211 [X509-SRV] 2212 Santesson, S., "Internet X.509 Public Key Infrastructure 2213 Subject Alternative Name for Expression of Service Name", 2214 RFC 4985, August 2007. 2216 9.2. Informative References 2218 [DIGEST-MD5] 2219 Leach, P. and C. Newman, "Using Digest Authentication as a 2220 SASL Mechanism", RFC 2831, May 2000. 2222 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", 2223 draft-freed-sieve-ihave-03.txt (work in progress), 2224 October 2008. 2226 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2227 4rev1", RFC 3501, March 2003. 2229 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 2230 (LDAP): Technical Specification Road Map", RFC 4510, 2231 June 2006. 2233 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 2234 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 2236 Authors' Addresses 2238 Alexey Melnikov (editor) 2239 Isode Limited 2240 5 Castle Business Village 2241 36 Station Road 2242 Hampton, Middlesex TW12 2BX 2243 UK 2245 Email: Alexey.Melnikov@isode.com 2247 Tim Martin 2248 BeThereBeSquare Inc. 2249 672 Haight st. 2250 San Francisco, CA 94117 2251 US 2253 Phone: +1 510 260-4175 2254 Email: timmartin@alumni.cmu.edu