idnits 2.17.1 draft-ietf-sieve-managesieve-09.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 17, 2009) is 5577 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 1324, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 2101, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 2247, 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 21, 2009 BeThereBeSquare Inc. 6 January 17, 2009 8 A Protocol for Remotely Managing Sieve Scripts 9 draft-ietf-sieve-managesieve-09 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 21, 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 . . . . . . . . . . . . . . . . . . . . 25 80 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 25 81 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 26 82 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 26 83 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 27 84 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 28 85 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 29 86 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 29 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 . . . . . 40 97 6.3. ManageSieve Response Code Registration Template . . . . . 42 98 6.4. Registration of Initial ManageSieve Response Codes . . . . 43 100 7. Internationalization Considerations . . . . . . . . . . . 48 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 49 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . 49 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 49 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 51 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. The server MUST ignore commands issued by the client 862 after the LOGOUT command. 864 The client SHOULD wait for the OK response before closing the 865 connection. This avoids the TCP connection going into the TIME_WAIT 866 state on the server. In order to avoid going into the the TIME_WAIT 867 TCP state the server MAY wait for a short while for the client to 868 close the TCP connection first. Whether or not the server waits for 869 the client to close the connection, it MUST then close the connection 870 itself. 872 Example: 874 C: Logout 875 S: Ok 876 878 2.4. CAPABILITY Command 880 The CAPABILITY command requests the server capabilities as described 881 earlier in this document. It has no parameters. 883 Example: 885 C: CAPABILITY 886 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 887 S: "VERSION" "1.0" 888 S: "SASL" "PLAIN OTP GSSAPI" 889 S: "SIEVE" "fileinto vacation" 890 S: "STARTTLS" 891 S: OK 893 2.5. HAVESPACE Command 895 Arguments: String - name 896 Number - script size 898 The HAVESPACE command is used to query the server for available 899 space. Clients specify the name they wish to save the script as and 900 its size in octets. Both parameters can be used by the server to see 901 if the script with the specified name and size is within user's 902 quota(s), for example the server MAY use the script name to check if 903 a script would be replaced or a new one would be created. Servers 904 respond with an NO if storing a script with that name and size would 905 fail or OK otherwise. Clients SHOULD issue this command before 906 attempting to place a script on the server. 908 Note that the OK response from the HAVESPACE command does not 909 constitute a guarantee of success as server disk space conditions 910 could change between the client issuing the HAVESPACE and the client 911 issuing the PUTSCRIPT commands. A QUOTA response code (see 912 Section 1.4) remains a possible (albeit unlikely) response to a 913 subsequent PUTSCRIPT with the same name and size. 915 Example: 917 C: HAVESPACE "myscript" 999999 918 S: NO (QUOTA/MAXSIZE) "Quota exceeded" 920 C: HAVESPACE "foobar" 435 921 S: OK 923 2.6. PUTSCRIPT Command 925 Arguments: String - Script name 926 String - Script content 928 The PUTSCRIPT command is used by the client to submit a Sieve script 929 to the server. 931 If the script already exists, upon success the old script will be 932 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 933 fails in any way. A script of zero length SHOULD be disallowed. 935 This command places the script on the server. It does not affect 936 whether the script is processed on incoming mail, unless it replaces 937 the script which is already active. The SETACTIVE command is used to 938 mark a script as active. 940 When submitting large scripts clients SHOULD use the HAVESPACE 941 command beforehand to query if the server is willing to accept a 942 script of that size. 944 The server MUST check the submitted script for validity, which 945 includes checking that the script complies with the Sieve grammar 946 [SIEVE], and that all Sieve extensions mentioned in script's 947 "require" statement(s) are supported by the Sieve interpreter. (Note 948 that if the Sieve interpreter supports the Sieve "ihave" extension 949 [I-HAVE], any unrecognized/unsupported extension mentioned in the 950 "ihave" test MUST NOT cause the validation failure.) Other checks 951 such as validating the supplied command arguments for each command 952 MAY be performed. Essentially, the performed validation SHOULD be 953 the same as performed when compiling the script for execution. 954 Implementations that use a binary representation to store compiled 955 scripts can extend the validation to a full compilation, in order to 956 avoid validating uploaded scripts multiple times. 958 If the script fails the validation the server MUST reply with a NO 959 response. Any script that fails the validity test MUST NOT be stored 960 on the server. The message given with a NO response MUST be human 961 readable and SHOULD contain a specific error message giving the line 962 number of the first error. Implementors should strive to produce 963 helpful error messages similar to those given by programming language 964 compilers. Client implementations should note that this may be a 965 multiline literal string with more than one error message separated 966 by CRLFs. The human readable message is in the language returned in 967 the latest LANGUAGE capability (or in "i-default", see Section 1.8), 968 encoded in UTF-8 [UTF-8]. 970 An OK response MAY contain the WARNINGS response code. In such case 971 the human readable message that follows the OK response SHOULD 972 contain a specific warning message (or messages) giving the line 973 number(s) in the script that might contain errors not intended by the 974 script writer. The human readable message is in the language 975 returned in the latest LANGUAGE capability (or in "i-default", see 976 Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response 977 code SHOULD present the message to the user. 979 Examples: 981 C: Putscript "foo" {31+} 982 C: #comment 983 C: InvalidSieveCommand 984 C: 985 S: NO "line 2: Syntax error" 987 C: Putscript "mysievescript" {110+} 988 C: require ["fileinto"]; 989 C: 990 C: if envelope :contains "to" "tmartin+sent" { 991 C: fileinto "INBOX.sent"; 992 C: } 993 S: OK 995 C: Putscript "myforwards" {190+} 996 C: redirect "111@example.net"; 997 C: 998 C: if size :under 10k { 999 C: redirect "mobile@cell.example.com"; 1000 C: } 1001 C: 1002 C: if envelope :contains "to" "tmartin+lists" { 1003 C: redirect "lists@groups.example.com"; 1004 C: } 1005 S: OK (WARNINGS) "line 8: server redirect action 1006 limit is 2, this redirect might be ignored" 1008 2.7. LISTSCRIPTS Command 1010 This command lists the scripts the user has on the server. Upon 1011 success a list of CRLF separated script names (each represented as a 1012 quoted or literal string) is returned followed by an OK response. If 1013 there exists an active script the atom ACTIVE is appended to the 1014 corresponding script name. The atom ACTIVE MUST NOT appear on more 1015 than one response line. 1017 Example: 1019 C: Listscripts 1020 S: "summer_script" 1021 S: "vacation_script" 1022 S: {13} 1023 S: clever"script 1024 S: "main_script" ACTIVE 1025 S: OK 1027 C: listscripts 1028 S: "summer_script" 1029 S: "main_script" active 1030 S: OK 1032 2.8. SETACTIVE Command 1034 Arguments: String - script name 1036 This command sets a script active. If the script name is the empty 1037 string (i.e. "") then any active script is disabled. Disabling an 1038 active script when there is no script active is not an error and MUST 1039 result in OK reply. 1041 If the script does not exist on the server then the server MUST reply 1042 with a NO response. Such reply SHOULD contain the NONEXISTENT 1043 response code. 1045 Examples: 1047 C: Setactive "vacationscript" 1048 S: Ok 1050 C: Setactive "" 1051 S: Ok 1053 C: Setactive "baz" 1054 S: No (NONEXISTENT) "There is no script by that name" 1056 C: Setactive "baz" 1057 S: No (NONEXISTENT) {31} 1058 S: There is no script by that name 1060 2.9. GETSCRIPT Command 1061 Arguments: String - script name 1063 This command gets the contents of the specified script. If the 1064 script does not exist the server MUST reply with a NO response. Such 1065 reply SHOULD contain the NONEXISTENT response code. 1067 Upon success a string with the contents of the script is returned 1068 followed by a OK response. 1070 Example: 1072 C: Getscript "myscript" 1073 S: {54} 1074 S: #this is my wonderful script 1075 S: reject "I reject all"; 1076 S: 1077 S: OK 1079 2.10. DELETESCRIPT Command 1081 Arguments: String - script name 1083 This command is used to delete a user's Sieve script. Servers MUST 1084 reply with a NO response if the script does not exist. Such 1085 responses SHOULD include the NONEXISTENT response code. 1087 The server MUST NOT allow the client to delete an active script, so 1088 the server MUST reply with a NO response if attempted. Such response 1089 SHOULD contain the ACTIVE response code. If a client wishes to 1090 delete an active script it should use the SETACTIVE command to 1091 disable the script first. 1093 Example: 1095 C: Deletescript "foo" 1096 S: Ok 1098 C: Deletescript "baz" 1099 S: No (ACTIVE) "You may not delete an active script" 1101 2.11. RENAMESCRIPT Command 1103 Arguments: String - Old Script name 1104 String - New Script name 1106 This command is used to rename a user's Sieve script. Servers MUST 1107 reply with a NO response if the old script does not exist (in which 1108 case the NONEXISTENT response code SHOULD be included), or a script 1109 with the new name already exists (in which case the ALREADYEXISTS 1110 response code SHOULD be included). Renaming the active script is 1111 allowed, the renamed script remains active. 1113 Example: 1115 C: Renamescript "foo" "bar" 1116 S: Ok 1118 C: Renamescript "baz" "bar" 1119 S: No "bar already exists" 1121 If the server doesn't support the RENAMESCRIPT command, the client 1122 can emulate it by performing the following steps: 1124 1. List available scripts with LISTSCRIPTS. If the script with the 1125 new script name exists, then the client should ask the user 1126 whether to abort the operation, to replace the script (by issuing 1127 the DELETESCRIPT after that) or to chose a different 1128 name. 1130 2. Download the old script with GETSCRIPT . 1132 3. Upload the old script with the new name: PUTSCRIPT . 1134 4. If the old script was active (as reported by LISTSCRIPTS in step 1135 1), then make the new script active: SETACTIVE 1137 5. Delete the old script: DELETESCRIPT 1139 Note that these steps don't describe how to handle various other 1140 error conditions (for example NO response containing QUOTA response 1141 code in step 3). Error handling is left as an excercise for the 1142 reader. 1144 2.12. CHECKSCRIPT Command 1146 Arguments: String - Script content 1148 The CHECKSCRIPT command is used by the client to verify Sieve script 1149 validity without storing the script on the server. 1151 The server MUST check the submitted script for syntactic validity, 1152 which includes checking that all Sieve extensions mentioned in Sieve 1153 script "require" statement(s) are supported by the Sieve interpreter. 1154 (Note that if the Sieve interpreter supports the Sieve "ihave" 1155 extension [I-HAVE], any unrecognized/unsupported extension mentioned 1156 in the "ihave" test MUST NOT cause the syntactic validation failure.) 1157 If the script fails this test the server MUST reply with a NO 1158 response. The message given with a NO response MUST be human 1159 readable and SHOULD contain a specific error message giving the line 1160 number of the first error. Implementors should strive to produce 1161 helpful error messages similar to those given by programming language 1162 compilers. Client implementations should note that this may be a 1163 multiline literal string with more than one error message separated 1164 by CRLFs. The human readable message is in the language returned in 1165 the latest LANGUAGE capability (or in "i-default", see Section 1.8), 1166 encoded in UTF-8 [UTF-8]. 1168 Examples: 1170 C: CheckScript {31+} 1171 C: #comment 1172 C: InvalidSieveCommand 1173 C: 1174 S: NO "line 2: Syntax error" 1176 A ManageSieve server supporting this command MUST NOT check if the 1177 script will put the current user over its quota limit. 1179 An OK response MAY contain the WARNINGS response code. In such case 1180 the human readable message that follows the OK response SHOULD 1181 contain a specific warning message (or messages) giving the line 1182 number(s) in the script that might contain errors not intended by the 1183 script writer. The human readable message is in the language 1184 returned in the latest LANGUAGE capability (or in "i-default", see 1185 Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response 1186 code SHOULD present the message to the user. 1188 2.13. NOOP Command 1190 Arguments: String - tag to echo back (optional) 1192 The NOOP command does nothing, beyond returning a response to the 1193 client. It may be used by clients for protocol re-synchronisation or 1194 to reset any inactivity auto-logout timer on the server. 1196 The response to the NOOP command is always OK, followed by the TAG 1197 response code together with the supplied string; if no string was 1198 supplied in the NOOP command, the TAG response code MUST NOT be 1199 included. 1201 Examples: 1203 C: NOOP 1204 S: OK "NOOP completed" 1206 C: NOOP "STARTTLS-SYNC-42" 1207 S: OK (TAG {16} 1208 S: STARTTLS-SYNC-42) "Done" 1210 2.14. Recommended extensions 1212 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" 1213 capability with no parameters) defines a new UNAUTHENTICATE command, 1214 which allows a client to return the server to non-authenticated 1215 state. Support for this extension is RECOMMENDED. 1217 2.14.1. UNAUTHENTICATE Command 1219 The UNAUTHENTICATE command returns the server to the non- 1220 authenticated state. It doesn't affect any previously established 1221 TLS [TLS] or SASL (Section 2.1) security layer. 1223 The UNAUTHENTICATE command is only valid in authenticated state. If 1224 issued in a wrong state, the server MUST reject it with a NO 1225 response. 1227 The UNAUTHENTICATE command has no parameters. 1229 When issued in the authenticated state, the UNAUTHENTICATE command 1230 MUST NOT fail (i.e. it must never return anything other than OK or 1231 BYE) 1233 3. Sieve URL Scheme 1235 URI scheme name: sieve 1237 Status: permanent 1239 URI scheme syntax: 1241 Described using ABNF [ABNF]. Some ABNF productions not defined 1242 below are from [URI-GEN]. 1244 sieveurl = sieveurl-server / sieveurl-list-scripts / 1245 sieveurl-script 1247 sieveurl-server = "sieve://" authority 1249 sieveurl-list-scripts = "sieve://" authority ["/"] 1251 sieveurl-script = "sieve://" authority "/" 1252 [owner "/"] scriptname 1254 authority = 1256 owner = *ochar 1257 ;; %-encoded version of [SASL] authorization 1258 ;; identity (script owner) or "userid". 1259 ;; 1260 ;; Empty owner is used to reference 1261 ;; global scripts. 1262 ;; 1263 ;; Note that ASCII characters such as " ", ";", 1264 ;; "&", "=", "/" and "?" must be %-encoded 1265 ;; as per rule specified in [URI-GEN]. 1267 scriptname = 1*ochar 1268 ;; %-encoded version of UTF-8 representation 1269 ;; of the script name. 1270 ;; Note that ASCII characters such as " ", ";", 1271 ;; "&", "=", "/" and "?" must be %-encoded 1272 ;; as per rule specified in [URI-GEN]. 1274 ochar = unreserved / pct-encoded / sub-delims-sh / 1275 ":" / "@" 1276 ;; Same as [URI-GEN] 'pchar' 1277 ;; but without ";", "&" and "=". 1279 unreserved = 1281 pct-encoded = 1283 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 1284 "*" / "+" / "," 1285 ;; Same as [URI-GEN] sub-delims, 1286 ;; but without ";", "&" and "=". 1288 URI scheme semantics: 1290 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve 1291 server. The latter form is associated with the application/sieve 1292 MIME type defined in [SIEVE]. There is no MIME type associated 1293 with the former form of Sieve URI. 1295 The server form is used in the REFERRAL response code (see 1296 Section 1.4 in order to designate another server where the client 1297 should perform its operations. 1299 The script form allows to retrieve (GETSCRIPT), update 1300 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the 1301 named script, however the most typical action would be to retrieve 1302 the script. If the script name is empty (omitted), the URI 1303 requests that the client lists available scripts using the 1304 LISTSCRIPTS command. 1306 Encoding considerations: 1308 The script name and/or the owner, if present, is in UTF-8. Non- 1309 US-ASCII UTF-8 octets MUST be percent-encoded as described in 1310 [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", 1311 "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. 1312 Note that "&" and "?" are in this list in order to allow for 1313 future extensions. 1315 Note that the empty owner (e.g. sieve://example.com//script) is 1316 different from the missing owner (e.g. sieve://example.com/script) 1317 and is reserved for referencing global scripts. 1319 The user name (in the "authority" part), if present, is in UTF-8. 1320 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1321 [URI-GEN]. 1323 Applications/protocols that use this URI scheme name: 1324 ManageSieve [RFC XXXX] clients and servers. Clients that can store 1325 user preferences in protocols such as [LDAP] or [ACAP]. 1327 Interoperability considerations: None. 1329 Security considerations: 1330 The part of a ManageSieve URL might potentially disclose 1331 some confidential information about the author of the script or, 1332 depending on a ManageSieve implementation, about configuration of the 1333 mail system. The latter might be used to prepare for a more complex 1334 attack on the mail system. 1336 Clients resolving ManageSieve URLs that wish to achieve data 1337 confidentiality and/or integrity SHOULD use the STARTTLS command (if 1338 supported by the server) before starting authentication, or use a 1339 SASL mechanism, such as GSSAPI, that provides a confidentiality 1340 security layer. 1342 Contact: Alexey Melnikov 1344 Author/Change controller: IESG. 1346 References: This document and RFC 5228 [SIEVE]. 1348 4. Formal Syntax 1350 The following syntax specification uses the augmented Backus-Naur 1351 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 1352 rules as specified in Appendix A of the ABNF specification [ABNF]. 1353 "UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8]. 1355 Except as noted otherwise, all alphabetic characters are case- 1356 insensitive. The use of upper or lower case characters to define 1357 token strings is for editorial clarity only. Implementations MUST 1358 accept these strings in a case-insensitive fashion. 1360 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 1361 %x5D-7F 1362 ;; any TEXT-CHAR except QUOTED-SPECIALS 1364 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 1366 QUOTED-SPECIALS = DQUOTE / "\" 1368 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 1369 ;; , and 1370 ;; are defined in [UTF-8] 1372 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E 1373 ;; Any CHAR except ATOM-SPECIALS 1375 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / 1376 QUOTED-SPECIALS 1378 NZDIGIT = %x31-39 1379 ;; 1-9 1381 atom = 1*1024ATOM-CHAR 1382 iana-token = atom 1383 ;; MUST be registered with IANA 1385 auth-type = DQUOTE auth-type-name DQUOTE 1387 auth-type-name = iana-token 1388 ;; as defined in SASL [SASL] 1390 command = (command-any / command-auth / 1391 command-nonauth) CRLF 1392 ;; Modal based on state 1394 command-any = command-capability / command-logout / 1395 command-noop 1396 ;; Valid in all states 1398 command-auth = command-getscript / command-setactive / 1399 command-listscripts / command-deletescript / 1400 command-putscript / command-checkscript / 1401 command-havespace / 1402 command-renamescript / 1403 command-unauthenticate 1404 ;; Valid only in Authenticated state 1406 command-nonauth = command-authenticate / command-starttls 1407 ;; Valid only when in Non-Authenticated 1408 ;; state 1410 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 1411 *(CRLF string) 1413 command-capability = "CAPABILITY" 1415 command-deletescript = "DELETESCRIPT" SP sieve-name 1417 command-getscript = "GETSCRIPT" SP sieve-name 1419 command-havespace = "HAVESPACE" SP sieve-name SP number 1421 command-listscripts = "LISTSCRIPTS" 1423 command-noop = "NOOP" [SP string] 1425 command-logout = "LOGOUT" 1427 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script 1429 command-checkscript = "CHECKSCRIPT" SP sieve-script 1430 sieve-script = string 1432 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP 1433 new-sieve-name 1435 old-sieve-name = sieve-name 1437 new-sieve-name = sieve-name 1439 command-setactive = "SETACTIVE" SP active-sieve-name 1441 command-starttls = "STARTTLS" 1443 command-unauthenticate= "UNAUTHENTICATE" 1445 extend-token = atom 1446 ;; MUST be defined by a standards track or 1447 ;; IESG approved experimental protocol 1448 ;; extension 1450 extension-data = extension-item *(SP extension-item) 1452 extension-item = extend-token / string / number / 1453 "(" [extension-data] ")" 1455 literal-c2s = "{" number "+}" CRLF *OCTET 1456 ;; The number represents the number of 1457 ;; octets. 1458 ;; This type of literal can only be sent 1459 ;; from the client to the server. 1461 literal-s2c = "{" number "}" CRLF *OCTET 1462 ;; Almost identical to literal-c2s, 1463 ;; but with no '+' character. 1464 ;; The number represents the number of 1465 ;; octets. 1466 ;; This type of literal can only be sent 1467 ;; from the server to the client. 1469 number = (NZDIGIT *DIGIT) / "0" 1470 ;; A 32-bit unsigned number 1471 ;; with no extra leading zeros. 1472 ;; (0 <= n < 4,294,967,296) 1474 number-str = string 1475 ;; encoded as a . 1477 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1478 ;; limited to 1024 octets between the <">s 1480 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1481 "QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] / 1482 resp-code-sasl / 1483 resp-code-referral / 1484 "TRANSITION-NEEDED" / "TRYLATER" / 1485 "ACTIVE" / "NONEXISTENT" / 1486 "ALREADYEXISTS" / "WARNINGS" / 1487 "TAG" SP string / 1488 resp-code-ext 1490 resp-code-referral = "REFERRAL" SP sieveurl 1492 resp-code-sasl = "SASL" SP string 1494 resp-code-name = iana-token 1495 ;; The response code name is hierarchical, 1496 ;; separated by '/'. 1497 ;; The response code name MUST NOT start 1498 ;; with '/'. 1500 resp-code-ext = resp-code-name [SP extension-data] 1501 ;; unknown response codes MUST be tolerated 1502 ;; by the client. 1504 response = response-authenticate / 1505 response-logout / 1506 response-getscript / 1507 response-setactive / 1508 response-listscripts / 1509 response-deletescript / 1510 response-putscript / 1511 response-checkscript / 1512 response-capability / 1513 response-havespace / 1514 response-starttls / 1515 response-renamescript / 1516 response-noop / 1517 response-unauthenticate 1519 response-authenticate = *(string CRLF) 1520 ((response-ok [response-capability]) / 1521 response-nobye) 1522 ;; is REQUIRED if a 1523 ;; SASL security layer was negotiated and 1524 ;; MUST be omitted otherwise. 1526 response-capability = *(single-capability) response-oknobye 1528 single-capability = capability-name [SP string] CRLF 1530 capability-name = string 1531 ;; Note that literal-s2c is allowed. 1533 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1534 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1535 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1536 DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / 1537 DQUOTE "NOTIFY" DQUOTE SP notify-mechs / 1538 DQUOTE "STARTTLS" DQUOTE / 1539 DQUOTE "LANGUAGE" DQUOTE SP language / 1540 DQUOTE "VERSION" DQUOTE SP version / 1541 DQUOTE "OWNER" DQUOTE SP string 1542 ;; Each capability conforms to 1543 ;; the syntax for single-capability. 1544 ;; Also note that the capability name 1545 ;; can be returned as either literal-s2c 1546 ;; or quoted, even though only "quoted" 1547 ;; string is shown above. 1549 version = ( DQUOTE "1.0" DQUOTE ) / version-ext 1551 version-ext = DQUOTE ver-major "." ver-minor DQUOTE 1552 ; Future versions specified in updates 1553 ; to this document. An increment to 1554 ; the ver-major means a backward-incompatible 1555 ; change to the protocol, e.g. "3.5" (ver-major "3") 1556 ; is not backward-compatible with any "2.X" version. 1557 ; Any version "Z.W" MUST be backward compatible 1558 ; with any version "Z.Q", where Q < W. 1559 ; E.g. version "2.4" is backward-compatible 1560 ; with version "2.0", "2.1", "2.2" and "2.3". 1562 ver-major = number 1564 ver-minor = number 1566 sasl-mechs = string 1567 ; space separated list of SASL mechanisms, 1568 ; each SASL mechanism name complies with rules 1569 ; specified in [SASL]. 1570 ; Can be empty. 1572 sieve-extensions = string 1573 ; space separated list of supported SIEVE extensions, 1574 ; can be empty. 1576 language = string 1577 ; Contains from [RFC4646]. 1579 notify-mechs = string 1580 ; space separated list of URI schema parts 1581 ; for supported notification [NOTIFY] methods. 1582 ; MUST NOT be empty. 1584 response-deletescript = response-oknobye 1586 response-getscript = (sieve-script CRLF response-ok) / 1587 response-nobye 1589 response-havespace = response-oknobye 1591 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1592 response-oknobye 1593 ;; ACTIVE may only occur with one sieve-name 1595 response-logout = response-oknobye 1597 response-unauthenticate= response-oknobye 1598 ;; "NO" response can only be returned when 1599 ;; the command is issued in a wrong state 1600 ;; or has a wrong number of parameters 1602 response-ok = "OK" [SP "(" resp-code ")"] 1603 [SP string] CRLF 1604 ;; The string contains human readable text 1605 ;; encoded as UTF-8. 1607 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1608 [SP string] CRLF 1609 ;; The string contains human readable text 1610 ;; encoded as UTF-8. 1612 response-oknobye = response-ok / response-nobye 1614 response-noop = response-ok 1616 response-putscript = response-oknobye 1618 response-checkscript = response-oknobye 1620 response-renamescript = response-oknobye 1621 response-setactive = response-oknobye 1623 response-starttls = (response-ok response-capability) / 1624 response-nobye 1626 sieve-name = string 1627 ;; See Section 1.6 for the full list of 1628 ;; prohibited characters. 1629 ;; Empty string is not allowed. 1631 active-sieve-name = string 1632 ;; See Section 1.6 for the full list of 1633 ;; prohibited characters. 1634 ;; This is similar to , but 1635 ;; empty string is allowed and has a special 1636 ;; meaning. 1638 string = quoted / literal-c2s / literal-s2c 1639 ;; literal-c2s is only allowed when sent 1640 ;; from the client to the server. 1641 ;; literal-s2c is only allowed when sent 1642 ;; from the server to the client. 1643 ;; quoted is allowed in either direction. 1645 5. Security Considerations 1647 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1648 and authorization services. Integrity and privacy services can be 1649 provided by [SASL] and/or [TLS]. When a SASL mechanism is used the 1650 security considerations for that mechanism apply. 1652 This protocol's transactions are susceptible to passive observers or 1653 man in the middle attacks which alter the data, unless the optional 1654 encryption and integrity services of the SASL (via the AUTHENTICATE 1655 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1656 external security mechanism is used for protection. It may be useful 1657 to allow configuration of both clients and servers to refuse to 1658 transfer sensitive information in the absence of strong encryption. 1660 If an implementation supports SASL mechanisms that are vulnerable to 1661 passive eavesdropping attacks (such as [PLAIN]), then the 1662 implementation MUST support at least one configuration where these 1663 SASL mechanisms are not advertised or used without the presence of an 1664 external security layer such as [TLS]. 1666 Some response codes returned on failed AUTHENTICATE command may 1667 disclose whether or not the username is valid (e.g. TRANSITION- 1668 NEEDED), so server implementations SHOULD provide the ability to 1669 disable these features (or make them not conditional on a per-user 1670 basis) for sites concerned about such disclosure. In the case of 1671 ENCRYPT-NEEDED, if it is applied to all identities then no extra 1672 information is disclosed, but if it is applied on a per-user basis it 1673 can disclose information. 1675 A compromised or malicious server can use the TRANSITION-NEEDED 1676 response code to force the client which is configured to use a 1677 mechanism that does not disclose the user's password to the server 1678 (e.g., Kerberos), to send the bare password to the server. Clients 1679 SHOULD have the ability to disable the password transition feature, 1680 or disclose that risk to the user and offer the user an option how to 1681 proceed. 1683 6. IANA Considerations 1685 IANA is requested to reserve a TCP port number for use with the 1686 ManageSieve protocol described in this document. 1688 IANA is requested to register the "sieve" URI scheme defined in 1689 Section 3 of this document. 1691 IANA is requested to register "sieve" in the "GSSAPI/Kerberos/SASL 1692 Service Names" registry. 1694 IANA is requested to create a new registry for ManageSieve 1695 capabilities. The registration template for ManageSieve capabilities 1696 is specified in Section 6.1. ManageSieve protocol capabilities MUST 1697 be specified in a standards track or IESG approved experimental RFC. 1699 IANA is requested to create a new registry for ManageSieve response 1700 codes. The registration template for ManageSieve response codes is 1701 specified in Section 6.3. ManageSieve protocol response codes MUST 1702 be specified in a standards track or IESG approved experimental RFC. 1704 6.1. ManageSieve Capability Registration Template 1706 To: iana@iana.org 1707 Subject: ManageSieve Capability Registration 1709 Please register the following ManageSieve Capability: 1710 Capability name: 1711 Description: 1712 Relevant publications: 1713 Person & email address to contact for further information: 1714 Author/Change controller: 1716 6.2. Registration of Initial ManageSieve capabilities 1718 To: iana@iana.org 1719 Subject: ManageSieve Capability Registration 1721 Please register the following ManageSieve Capabilities: 1723 Capability name: IMPLEMENTATION 1725 Description: Its value contains name of server implementation and 1726 its version. 1728 Relevant publications: this RFC, Section 1.8. 1730 Person & email address to contact for further information: Alexey 1731 Melnikov 1733 Author/Change controller: IESG. 1735 Capability name: SASL 1737 Description: Its value contains a space separated list of SASL 1738 mechanisms supported by server. 1740 Relevant publications: this RFC, Section 1.8 and Section 2.1. 1742 Person & email address to contact for further information: Alexey 1743 Melnikov 1745 Author/Change controller: IESG. 1747 Capability name: SIEVE 1749 Description: Its value contains a space separated list of 1750 supported SIEVE extensions 1752 Relevant publications: this RFC, Section 1.8. Also [SIEVE]. 1754 Person & email address to contact for further information: Alexey 1755 Melnikov 1757 Author/Change controller: IESG. 1759 Capability name: STARTTLS 1761 Description: This capability is returned if server supports TLS 1762 (STARTTLS command). 1764 Relevant publications: this RFC, Section 1.8 and Section 2.2. 1766 Person & email address to contact for further information: Alexey 1767 Melnikov 1769 Author/Change controller: IESG. 1771 Capability name: NOTIFY 1773 Description: This capability is returned if server supports 1774 'enotify' [NOTIFY] Sieve extension. 1776 Relevant publications: this RFC, Section 1.8. 1778 Person & email address to contact for further information: Alexey 1779 Melnikov 1781 Author/Change controller: IESG. 1783 Capability name: MAXREDIRECTS 1785 Description: This capability returns the limit on the number of 1786 Sieve "redirect" actions a script can perform during a single 1787 evaluation. The value is a non-negative number represented as a 1788 ManageSieve string. 1790 Relevant publications: this RFC, Section 1.8. 1792 Person & email address to contact for further information: Alexey 1793 Melnikov 1795 Author/Change controller: IESG. 1797 Capability name: LANGUAGE 1799 Description: The language ( from [RFC4646]) 1800 currently used for human readable error messages. 1802 Relevant publications: this RFC, Section 1.8. 1804 Person & email address to contact for further information: Alexey 1805 Melnikov 1807 Author/Change controller: IESG. 1809 Capability name: OWNER 1810 Description: Its value contains UTF-8 encoded name of the 1811 currently logged in user ("authorization identity" according to 1812 RFC 4422). 1814 Relevant publications: this RFC, Section 1.8. 1816 Person & email address to contact for further information: Alexey 1817 Melnikov 1819 Author/Change controller: IESG. 1821 Capability name: VERSION 1823 Description: This capability is returned if the server is 1824 compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT, 1825 CHECKSCRIPT and NOOP commands. 1827 Relevant publications: this RFC, Section 2.11. 1829 Person & email address to contact for further information: Alexey 1830 Melnikov 1832 Author/Change controller: IESG. 1834 6.3. ManageSieve Response Code Registration Template 1836 To: iana@iana.org 1837 Subject: ManageSieve Response Code Registration 1839 Please register the following ManageSieve Response Code: 1841 Response Code: 1843 Arguments (use ABNF to specify syntax, or the word NONE if none 1844 can be specified): 1846 Purpose: 1848 Published Specification(s): 1850 Person & email address to contact for further information: 1852 Author/Change controller: 1854 6.4. Registration of Initial ManageSieve Response Codes 1856 To: iana@iana.org 1857 Subject: ManageSieve Response Code Registration 1859 Please register the following ManageSieve Response Codes: 1861 Response Code: AUTH-TOO-WEAK 1863 Arguments (use ABNF to specify syntax, or the word NONE if none 1864 can be specified): NONE 1866 Purpose: This response code is returned in the NO response from an 1867 AUTHENTICATE command. It indicates that site security policy 1868 forbids the use of the requested mechanism for the specified 1869 authentication identity. 1871 Published Specification(s): [RFCXXXX] 1873 Person & email address to contact for further information: Alexey 1874 Melnikov 1876 Author/Change controller: IESG. 1878 Response Code: ENCRYPT-NEEDED 1880 Arguments (use ABNF to specify syntax, or the word NONE if none 1881 can be specified): NONE 1883 Purpose: This response code is returned in the NO response from an 1884 AUTHENTICATE command. It indicates that site security policy 1885 requires the use of a strong encryption mechanism for the 1886 specified authentication identity and mechanism. 1888 Published Specification(s): [RFCXXXX] 1890 Person & email address to contact for further information: Alexey 1891 Melnikov 1893 Author/Change controller: IESG. 1895 Response Code: QUOTA 1897 Arguments (use ABNF to specify syntax, or the word NONE if none 1898 can be specified): NONE 1900 Purpose: If this response code is returned in the NO/BYE response, 1901 it means that the command would have placed the user above the 1902 site-defined quota constraints. If this response code is returned 1903 in the OK response, it can mean that the user is near its quota or 1904 that the user exceeded its quota, but the server supports soft 1905 quotas. 1907 Published Specification(s): [RFCXXXX] 1909 Person & email address to contact for further information: Alexey 1910 Melnikov 1912 Author/Change controller: IESG. 1914 Response Code: QUOTA/MAXSCRIPTS 1916 Arguments (use ABNF to specify syntax, or the word NONE if none 1917 can be specified): NONE 1919 Purpose: If this response code is returned in the NO/BYE response, 1920 it means that the command would have placed the user above the 1921 site-defined limit on the number of Sieve scripts. If this 1922 response code is returned in the OK response, it can mean that the 1923 user is near its quota or that the user exceeded its quota, but 1924 the server supports soft quotas. This response code is a more 1925 specific version of the QUOTA response code. 1927 Published Specification(s): [RFCXXXX] 1929 Person & email address to contact for further information: Alexey 1930 Melnikov 1932 Author/Change controller: IESG. 1934 Response Code: QUOTA/MAXSIZE 1936 Arguments (use ABNF to specify syntax, or the word NONE if none 1937 can be specified): NONE 1939 Purpose: If this response code is returned in the NO/BYE response, 1940 it means that the command would have placed the user above the 1941 site-defined maximum script size. If this response code is 1942 returned in the OK response, it can mean that the user is near its 1943 quota or that the user exceeded its quota, but the server supports 1944 soft quotas. This response code is a more specific version of the 1945 QUOTA response code. 1947 Published Specification(s): [RFCXXXX] 1948 Person & email address to contact for further information: Alexey 1949 Melnikov 1951 Author/Change controller: IESG. 1953 Response Code: REFERRAL 1955 Arguments (use ABNF to specify syntax, or the word NONE if none 1956 can be specified): 1958 Purpose: This response code may be returned with a BYE result from 1959 any command, and includes a mandatory parameter that indicates 1960 what server to access to manage this user's sieve scripts. The 1961 server will be specified by a Sieve URL (see Section 3). The 1962 scriptname portion of the URL MUST NOT be specified. The client 1963 should authenticate to the specified server and use it for all 1964 further commands in the current session. 1966 Published Specification(s): [RFCXXXX] 1968 Person & email address to contact for further information: Alexey 1969 Melnikov 1971 Author/Change controller: IESG. 1973 Response Code: SASL 1975 Arguments (use ABNF to specify syntax, or the word NONE if none 1976 can be specified): 1978 Purpose: This response code can occur in the OK response to a 1979 successful AUTHENTICATE command and includes the optional final 1980 server response data from the server as specified by [SASL]. 1982 Published Specification(s): [RFCXXXX] 1984 Person & email address to contact for further information: Alexey 1985 Melnikov 1987 Author/Change controller: IESG. 1989 Response Code: TRANSITION-NEEDED 1991 Arguments (use ABNF to specify syntax, or the word NONE if none 1992 can be specified): NONE 1994 Purpose: This response code occurs in a NO response of an 1995 AUTHENTICATE command. It indicates that the user name is valid, 1996 but the entry in the authentication database needs to be updated 1997 in order to permit authentication with the specified mechanism. 1998 This is typically done by establishing a secure channel using TLS, 1999 followed by authenticating once using the [PLAIN] authentication 2000 mechanism. The selected mechanism SHOULD then work for 2001 authentications in subsequent sessions. 2003 Published Specification(s): [RFCXXXX] 2005 Person & email address to contact for further information: Alexey 2006 Melnikov 2008 Author/Change controller: IESG. 2010 Response Code: TRYLATER 2012 Arguments (use ABNF to specify syntax, or the word NONE if none 2013 can be specified): NONE 2015 Purpose: A command failed due to a temporary server failure. The 2016 client MAY continue using local information and try the command 2017 later. This response code only make sense when returned in a NO/ 2018 BYE response. 2020 Published Specification(s): [RFCXXXX] 2022 Person & email address to contact for further information: Alexey 2023 Melnikov 2025 Author/Change controller: IESG. 2027 Response Code: ACTIVE 2029 Arguments (use ABNF to specify syntax, or the word NONE if none 2030 can be specified): NONE 2032 Purpose: A command failed because it is not allowed on the active 2033 script. For example DELETESCRIPT on the active script. This 2034 response code only makes sense when returned in a NO/BYE response. 2036 Published Specification(s): [RFCXXXX] 2038 Person & email address to contact for further information: Alexey 2039 Melnikov 2041 Author/Change controller: IESG. 2043 Response Code: NONEXISTENT 2045 Arguments (use ABNF to specify syntax, or the word NONE if none 2046 can be specified): NONE 2048 Purpose: A command failed because the referenced script name 2049 doesn't exist. This response code only makes sense when returned 2050 in a NO/BYE response. 2052 Published Specification(s): [RFCXXXX] 2054 Person & email address to contact for further information: Alexey 2055 Melnikov 2057 Author/Change controller: IESG. 2059 Response Code: ALREADYEXISTS 2061 Arguments (use ABNF to specify syntax, or the word NONE if none 2062 can be specified): NONE 2064 Purpose: A command failed because the referenced script name 2065 already exists. This response code only makes sense when returned 2066 in a NO/BYE response. 2068 Published Specification(s): [RFCXXXX] 2070 Person & email address to contact for further information: Alexey 2071 Melnikov 2073 Author/Change controller: IESG. 2075 Response Code: WARNINGS 2077 Arguments (use ABNF to specify syntax, or the word NONE if none 2078 can be specified): NONE 2080 Purpose: This response code MAY be returned by the server in the 2081 OK response (but it might be returned with the NO/BYE response as 2082 well) and signals the client that even though the script is 2083 syntactically valid, it might contain errors not intended by the 2084 script writer. 2086 Published Specification(s): [RFCXXXX] 2088 Person & email address to contact for further information: Alexey 2089 Melnikov 2090 Author/Change controller: IESG. 2092 Response Code: TAG 2094 Arguments (use ABNF to specify syntax, or the word NONE if none 2095 can be specified): string 2097 Purpose: This response code name is followed by a string specified 2098 in the command that caused this response. It is typically used 2099 for client state synchronization. 2101 Published Specification(s): [RFCXXXX] 2103 Person & email address to contact for further information: Alexey 2104 Melnikov 2106 Author/Change controller: IESG. 2108 7. Internationalization Considerations 2110 The LANGUAGE capability (see Section 1.8) allows a client to discover 2111 the current language used in all human readable responses that might 2112 be returned at the end of any OK/NO/BYE response. Human readable 2113 text in OK responses typically doesn't need to be shown to the user, 2114 unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command 2115 that also contain the WARNINGS response code Section 1.4. Human 2116 readable text from NO/BYE responses is intended be shown to the user, 2117 unless the client can automatically handle failure of the command 2118 that caused such response. Clients SHOULD use response codes 2119 (Section 1.4) for automatic error handling. Response codes MAY also 2120 be used by the client to present error messages in a language 2121 understood by the user, for example if the LANGUAGE capability 2122 doesn't return a language understood by the user. 2124 Note that the human readable text from OK (WARNINGS) or NO/BYE 2125 responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced 2126 users that understand Sieve language. Such advanced users are often 2127 sophisticated enough to be able to handle whatever language the 2128 server is using, even if it is not their preferred language, and will 2129 want to see error/warning text no matter what language the server 2130 puts it in. 2132 A client that generates Sieve script automatically, for example if 2133 the script is generated without user intervention or from a UI that 2134 presents an abstract list of conditions and corresponding actions, 2135 SHOULD NOT present warning/error messages to the user, because the 2136 user might not even be aware that the client is using Sieve 2137 underneath. However if the client has a debugging mode, such 2138 warnings/errors SHOULD be available in the debugging mode. 2140 Note that this document doesn't provide a way to modify the currently 2141 used language. It is expected that a future extension will address 2142 that. 2144 8. Acknowledgements 2146 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 2147 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, 2148 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil 2149 Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan 2150 Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick 2151 Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus 2152 Westerlund and Tim Polk for help with this document. Special thank 2153 you to Phil Pennock for providing text for the NOOP command, as well 2154 as finding various bugs in the document. 2156 9. References 2158 9.1. Normative References 2160 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2161 Specifications: ABNF", RFC 5234, January 2008. 2163 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 2164 Configuration Access Protocol", RFC 2244, November 1997. 2166 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 2167 Encodings", RFC 4648, October 2006. 2169 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2170 specifying the location of services (DNS SRV)", RFC 2782, 2171 February 2000. 2173 [KEYWORDS] 2174 Bradner, S., "Key words for use in RFCs to Indicate 2175 Requirement Levels", RFC 2119, March 1997. 2177 [NET-UNICODE] 2178 Klensin, J. and M. Padlipsky, "Unicode Format for Network 2179 Interchange", RFC 5198, March 2008. 2181 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 2182 Martin, "Sieve Extension: Notifications", 2183 draft-ietf-sieve-notify-12 (work in progress), 2184 December 2007. 2186 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2187 Languages", RFC 2277, January 1998. 2189 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2190 (IPv6) Specification", RFC 2460, December 1998. 2192 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2193 "Internationalizing Domain Names in Applications (IDNA)", 2194 RFC 3490, March 2003. 2196 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2197 (LDAP): Schema for User Applications", RFC 4519, 2198 June 2006. 2200 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 2201 Languages", RFC 4646, September 2006. 2203 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 2205 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2206 Security Layer (SASL)", RFC 4422, June 2006. 2208 [SASLprep] 2209 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 2210 and Passwords", RFC 4013, February 2005. 2212 [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge 2213 Response Authentication Mechanism (SCRAM)", 2214 draft-newman-auth-scram-07.txt (work in progress), 2215 November 2008. 2217 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 2218 Filtering Language", RFC 5228, January 2008. 2220 [StringPrep] 2221 Hoffman, P. and M. Blanchet, "Preparation of 2222 Internationalized Strings ("stringprep")", RFC 3454, 2223 December 2002. 2225 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2226 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2228 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2229 Resource Identifier (URI): Generic Syntax", STD 66, 2230 RFC 3986, January 2005. 2232 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2233 10646", STD 63, RFC 3629, November 2003. 2235 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2236 X.509 Public Key Infrastructure Certificate and 2237 Certificate Revocation List (CRL) Profile", RFC 5280, 2238 May 2008. 2240 [X509-SRV] 2241 Santesson, S., "Internet X.509 Public Key Infrastructure 2242 Subject Alternative Name for Expression of Service Name", 2243 RFC 4985, August 2007. 2245 9.2. Informative References 2247 [DIGEST-MD5] 2248 Leach, P. and C. Newman, "Using Digest Authentication as a 2249 SASL Mechanism", RFC 2831, May 2000. 2251 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", 2252 draft-freed-sieve-ihave-03.txt (work in progress), 2253 October 2008. 2255 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2256 4rev1", RFC 3501, March 2003. 2258 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 2259 (LDAP): Technical Specification Road Map", RFC 4510, 2260 June 2006. 2262 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 2263 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 2265 Authors' Addresses 2267 Alexey Melnikov (editor) 2268 Isode Limited 2269 5 Castle Business Village 2270 36 Station Road 2271 Hampton, Middlesex TW12 2BX 2272 UK 2274 Email: Alexey.Melnikov@isode.com 2275 Tim Martin 2276 BeThereBeSquare Inc. 2277 672 Haight st. 2278 San Francisco, CA 94117 2279 US 2281 Phone: +1 510 260-4175 2282 Email: timmartin@alumni.cmu.edu