idnits 2.17.1 draft-ietf-sieve-managesieve-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2218. 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 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 (December 1, 2008) is 5626 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 286, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1304, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 2025, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 2137, but no explicit reference was found in the text == Unused Reference: 'IANA-GUIDELINES' is defined on line 2145, 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 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC 5280) -- 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 5226 (ref. 'IANA-GUIDELINES') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: June 4, 2009 BeThereBeSquare Inc. 6 December 1, 2008 8 A Protocol for Remotely Managing Sieve Scripts 9 draft-ietf-sieve-managesieve-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 4, 2009. 36 Abstract 38 Sieve scripts allow users to filter incoming email. Message stores 39 are commonly sealed servers so users cannot log into them, yet users 40 must be able to update their scripts on them. This document 41 describes a protocol "ManageSieve" for securely managing Sieve 42 scripts on a remote server. This protocol allows a user to have 43 multiple scripts, and also alerts a user to syntactically flawed 44 scripts. 46 Changes since draft-martin-managesieve-09 47 o TBD. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Conventions used in this document . . . . . . . . . . . . 4 53 1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.3. Response Codes . . . . . . . . . . . . . . . . . . . . . . 4 55 1.4. Active Script . . . . . . . . . . . . . . . . . . . . . . 7 56 1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7 58 1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 59 1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 10 61 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 11 63 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 16 64 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 16 65 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 17 66 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 20 67 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 20 68 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 20 69 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 21 70 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 23 71 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 23 72 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 24 73 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 24 74 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 25 75 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 26 76 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 27 77 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 27 78 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 27 80 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 28 82 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 31 84 5. Security Considerations . . . . . . . . . . . . . . . . . 37 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 37 87 6.1. ManageSieve Capability Registration Template . . . . . . . 38 88 6.2. Registration of Initial ManageSieve capabilities . . . . . 38 89 6.3. ManageSieve Response Code Registration Template . . . . . 40 90 6.4. Registration of Initial ManageSieve Response Codes . . . . 40 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . 46 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 46 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 48 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 98 Intellectual Property and Copyright Statements . . . . . . 50 100 1. Introduction 102 1.1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [KEYWORDS]. 108 In examples, "C:" and "S:" indicate lines sent by the client and 109 server respectively. Line breaks that do not start a new "C:" or 110 "S:" exist for editorial reasons. 112 1.2. Syntax 114 This a line oriented protocol much like [IMAP] or [ACAP]. There are 115 three data types: atoms, numbers and strings. Strings may be quoted 116 or literal. See [ACAP] for detailed descriptions of these types. 118 Each command consists of an atom (the command name) followed by zero 119 or more strings and numbers terminated by CRLF. 121 All client queries are replied to with either an OK, NO, or BYE 122 response. Each response may be followed by a response code (see 123 Section 1.3) and by a string consisting of human readable text in the 124 local language, encoded in [UTF-8]. The contents of the string 125 SHOULD be shown to the user and implementations MUST NOT attempt to 126 parse the message for meaning. 128 The BYE response SHOULD be used if the server wishes to close the 129 connection. A server may wish to do this because the client was idle 130 for too long or there were too many failed authentication attempts. 131 This response can be issued at any time and should be immediately 132 followed by a server hang-up of the connection. If a server has an 133 inactivity timeout resulting in client autologout it MUST be no less 134 than 30 minutes after successful authentication. The inactivity 135 timeout MAY be less before authentication. 137 1.3. Response Codes 139 An OK, NO, or BYE response from the server MAY contain a response 140 code to describe the event in a more detailed machine parsable 141 fashion. A response code consists of data inside parentheses in the 142 form of an atom, possibly followed by a space and arguments. 143 Response codes are defined when there is a specific action that a 144 client can take based upon the additional information. In order to 145 support future extension, the response code is represented as a 146 slash-separated (Solidus, %x2F) hierarchy with each level of 147 hierarchy representing increasing detail about the error. Response 148 codes MUST NOT start with the Solidus character. Clients MUST 149 tolerate additional hierarchical response code detail which they 150 don't understand. For example, if the client supports the "QUOTA" 151 response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response 152 code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA". 154 Client implementations MUST tolerate (ignore) response codes that 155 they do not recognize. 157 The currently defined response codes are: 159 AUTH-TOO-WEAK 161 This response code is returned in the NO or BYE response from an 162 AUTHENTICATE command. It indicates that site security policy forbids 163 the use of the requested mechanism for the specified authentication 164 identity. 166 ENCRYPT-NEEDED 168 This response code is returned in the NO or BYE response from an 169 AUTHENTICATE command. It indicates that site security policy 170 requires the use of a strong encryption mechanism for the specified 171 authentication identity and mechanism. 173 QUOTA 175 If this response code is returned in the NO/BYE response, it means 176 that the command would have placed the user above the site-defined 177 quota constraints. If this response code is returned in the OK 178 response, it can mean that the user's storage is near its quota, or 179 it can mean that the account exceeded its quota but that that 180 condition is being allowed by the server (the server supports so 181 called "soft quotas"). The QUOTA response code has 2 more detailed 182 variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts) 183 and "QUOTA/MAXSIZE" (the maximum script size). 185 REFERRAL 187 This response code may be returned with a BYE result from any 188 command, and includes a mandatory parameter that indicates what 189 server to access to manage this user's sieve scripts. The server 190 will be specified by a Sieve URL (see Section 3). The scriptname 191 portion of the URL MUST NOT be specified. The client should 192 authenticate to the specified server and use it for all further 193 commands in the current session. 195 SASL 196 This response code can occur in the OK response to a successful 197 AUTHENTICATE command and includes the optional final server response 198 data from the server as specified by [SASL]. 200 TRANSITION-NEEDED 202 This response code occurs in a NO response of an AUTHENTICATE 203 command. It indicates that the user name is valid, but the entry in 204 the authentication database needs to be updated in order to permit 205 authentication with the specified mechanism. This is typically done 206 by establishing a secure channel using TLS, verifying server identity 207 as specified in Section 2.2.1, and finally authenticating once using 208 the [PLAIN] authentication mechanism. The selected mechanism SHOULD 209 then work for authentications in subsequent sessions. 211 This condition can happen if a user has an entry in a system 212 authentication database such as Unix /etc/passwd, but does not have 213 credentials suitable for use by the specified mechanism. 215 TRYLATER 217 A command failed due to a temporary server failure. The client MAY 218 continue using local information and try the command later. This 219 response code only makes sense when returned in a NO/BYE response. 221 ACTIVE 223 A command failed because it is not allowed on the active script. For 224 example DELETESCRIPT on the active script. This response code only 225 makes sense when returned in a NO/BYE response. 227 NONEXISTENT 229 A command failed because the referenced script name doesn't exist. 230 This response code only makes sense when returned in a NO/BYE 231 response. 233 ALREADYEXISTS 235 A command failed because the referenced script name already exists. 236 This response code only makes sense when returned in a NO/BYE 237 response. 239 TAG 241 This response code name is followed by a string specified in the 242 command. See Section 2.13 for a possible use case. 244 WARNINGS 246 This response code MAY be returned by the server in the OK response 247 (but it might be returned with the NO/BYE response as well) and 248 signals the client that even though the script is syntactically 249 valid, it might contain errors not intended by the script writer. 250 This response code is typically returned in response to PUTSCRIPT 251 and/or CHECKSCRIPT commands. A client seeing such response code 252 SHOULD present the returned warning text to the user. 254 1.4. Active Script 256 A user may have multiple Sieve scripts on the server, yet only one 257 script may be used for filtering of incoming messages. This is the 258 active script. Users may have zero or one active scripts and MUST 259 use the SETACTIVE command described below for changing the active 260 script or disabling Sieve processing. For example, a user may have 261 an everyday script they normally use and a special script they use 262 when they go on vacation. Users can change which script is being 263 used without having to download and upload a script stored somewhere 264 else. 266 1.5. Quotas 268 Servers SHOULD impose quotas to prevent malicious users from 269 overflowing available storage. If a command would place a user over 270 a quota setting, servers that impose such quotas MUST reply with a NO 271 response containing the QUOTA response code. Client implementations 272 MUST be able to handle commands failing because of quota 273 restrictions. 275 1.6. Script Names 277 A Sieve script name is a sequence of Unicode characters encoded in 278 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition 279 (Section 2 of [NET-UNICODE]), with the additional restriction of 280 prohibiting the following Unicode characters: 282 o 0000-001F; [CONTROL CHARACTERS] 284 o 007F; DELETE 286 o 0080-009F; [CONTROL CHARACTERS] 288 o 2028; LINE SEPARATOR 290 o 2029; PARAGRAPH SEPARATOR 291 Sieve script names MUST be at least one octet (and hense Unicode 292 character) long. Zero octets script name has a special meaning (see 293 Section 2.8). Servers MUST allow names of up to 128 Unicode 294 characters in length (which can take up to 512 bytes when encoded in 295 UTF-8, not counting the terminating NUL), and MAY allow longer names. 296 A server that receives a script name longer than its internal limit 297 MUST rejects the corresponding operation, in particular it MUST NOT 298 truncate the script name. 300 1.7. Capabilities 302 Server capabilities are sent automatically by the server upon a 303 client connection, or after successful STARTTLS and AUTHENTICATE 304 (which establishes a SASL security layer) commands. Capabilities may 305 change immediately after a successfully completed STARTTLS command, 306 and/or immediately after a successfully completed AUTHENTICATE 307 command, and/or after a successfully completed UNAUTHENTICATE command 308 (see Section 2.14.1). Capabilities MUST remain static at all other 309 times. 311 Clients MAY request the capabilities at a later time by issuing the 312 CAPABILITY command described later. The capabilities consist of a 313 series of lines each with one or two strings. The first string is 314 the name of the capability, which is case-insensitive. The second 315 optional string is the value associated with that capability. Order 316 of capabilities is arbitrary, but each capability name can appear at 317 most once. 319 The following capabilities are defined in this document: 321 IMPLEMENTATION - Name of implementation and version. This capability 322 MUST always be returned by the server. 324 SASL - List of SASL mechanisms supported by the server, each 325 separated by a space. This list can be empty if and only if STARTTLS 326 is also advertised. This means that the client must negotiate TLS 327 encryption with STARTTLS first, at which point the SASL capability 328 will list a non empty list of SASL mechanisms. 330 SIEVE - List of space separated Sieve extensions (as listed in Sieve 331 "require" action [SIEVE]) supported by the Sieve engine. This 332 capability MUST always be returned by the server. 334 STARTTLS - If TLS [TLS] is supported by this implementation. Before 335 advertising this capability a server MUST verify to the best of its 336 ability that TLS can be successfully negotiated by a client with 337 common cipher suites. Specifically, a server should verify that a 338 server certificate has been installed and that the TLS subsystem has 339 successfully initialized. This capability SHOULD NOT be advertised 340 once STARTTLS or AUTHENTICATE command completes successfully. 342 MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" 343 actions a script can perform during a single evaluation. Note, that 344 this is different from the total number of "redirect" actions a 345 script can contain. The value is a non-negative number represented 346 as a ManageSieve string. 348 NOTIFY - A space separated list of URI schema parts for supported 349 notification methods. This capability MUST be specified if the Sieve 350 implementation supports the "enotify" extension [NOTIFY]. 352 LANGUAGE - The language ( from [RFC4646]) currently 353 used for human readable error messages. If this capability is not 354 returned, the "i-default" [RFC2277] language is assumed. Note that 355 the current language MAY be per-user configurable (i.e. it MAY change 356 after authentication). 358 OWNER - The canonical name of the logged in user (SASL "authorization 359 identity") encoded in UTF-8. This capability MUST NOT be returned in 360 unauthenticated state and SHOULD be returned once the AUTHENTICATE 361 command succeeds. 363 VERSION - This capability MUST be returned by servers compliant with 364 this document or its successor. For servers compliant with this 365 document the capability value is the string "1.0". Lack of this 366 capability means that the server predates this specification and thus 367 doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT and 368 NOOP. 370 Section 2.14 defines some additional ManageSieve extensions and their 371 respective capabilities. 373 A server implementation MUST return SIEVE, IMPLEMENTATION and VERSION 374 capabilities. 376 A client implementation MUST ignore any listed capabilities that it 377 does not understand. 379 Example: 381 S: "IMPlemENTATION" "Example1 ManageSieved v001" 382 S: "SASl" "DIGEST-MD5 GSSAPI" 383 S: "SIeVE" "fileinto vacation" 384 S: "StaRTTLS" 385 S: "NOTIFY" "xmpp mailto" 386 S: "MAXREdIRECTS" "5" 387 S: "VERSION" "1.0" 388 S: OK 390 After successful authentication this might look like this: 392 Example: 394 S: "IMPlemENTATION" "Example1 ManageSieved v001" 395 S: "SASl" "DIGEST-MD5 GSSAPI" 396 S: "SIeVE" "fileinto vacation" 397 S: "NOTIFY" "xmpp mailto" 398 S: "OWNER" "alexey@example.com" 399 S: "MAXREdIRECTS" "5" 400 S: "VERSION" "1.0" 401 S: OK 403 1.8. Link Level 405 The ManageSieve protocol assumes a reliable data stream such as that 406 provided by TCP. When TCP is used, a ManageSieve server typically 407 listens on port 2000. [[anchor6: IANA registration of port 2000 is 408 pending.]] 410 Before opening the TCP connection, the ManageSieve client first MUST 411 resolve the Domain Name System (DNS) hostname associated with the 412 receiving entity and determine the appropriate TCP port for 413 communication with the receiving entity. The process is as follows: 415 1. Attempt to resolve the hostname using a [DNS-SRV] Service of 416 "sieve" and a Proto of "tcp" for the target domain (e.g. 417 "example.net"), resulting in resource records such as 418 "_sieve._tcp.example.net.". The result of the SRV lookup, if 419 successful, will be one or more combinations of a port and 420 hostname; the ManageSieve client MUST resolve the returned 421 hostnames to IPv4/IPv6 addresses according to returned SRV record 422 weight. IP addresses from the first successfully resolved 423 hostname (with the corresponding port number returned by SRV 424 lookup) are used to connect to the server. If connection using 425 one of the IP addresses fails, the next resolved IP address is 426 used to connect. If connection to all resolved IP addresses 427 fails, then the resolution/connect is repeated for the next 428 hostname returned by SRV lookup. 430 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or 431 IPv6 address record resolution to determine the IP address, where 432 the port used is the default ManageSieve port of 2000. 434 2. Commands 436 This section and its subsections describes valid ManageSieve 437 commands. Upon initial connection to the server the client's session 438 is in non-authenticated state. Prior to successful authentication 439 only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see 440 Section 2.13) commands are valid. ManageSieve extensions MAY define 441 other commands which are valid in non-authenticated state. Servers 442 MUST reject all other commands with a NO response. Clients may 443 pipeline commands (send more than one command at a time without 444 waiting for completion of the first command ). However, a group of 445 commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS 446 or a HAVESPACE command anywhere but the last command in the list. 448 (*) - The only exception to this rule is when the AUTHENTICATE 449 command contains an initial response for a SASL mechanism that allows 450 clients to send data first, the mechanism is known to complete in one 451 round-trip and the mechanism doesn't negotiate a SASL security layer. 452 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL 453 [SASL]. 455 2.1. AUTHENTICATE Command 457 Arguments: String - mechanism 458 String - initial data (optional) 460 The AUTHENTICATE command indicates a SASL [SASL] authentication 461 mechanism to the server. If the server supports the requested 462 authentication mechanism, it performs an authentication protocol 463 exchange to identify and authenticate the user. Optionally, it also 464 negotiates a security layer for subsequent protocol interactions. If 465 the requested authentication mechanism is not supported, the server 466 rejects the AUTHENTICATE command by sending the NO response. 468 The authentication protocol exchange consists of a series of server 469 challenges and client responses that are specific to the selected 470 authentication mechanism. A server challenge consists of a string 471 (quoted or literal) followed by a CRLF. The contents of the string 472 is a base-64 encoding [BASE64] of the SASL data. A client response 473 consists of a string (quoted or literal) with the base-64 encoding of 474 the SASL data followed by a CRLF. If the client wishes to cancel the 475 authentication exchange, it issues a string containing a single "*". 476 If the server receives such a response, it MUST reject the 477 AUTHENTICATE command by sending an NO reply. 479 Note that an empty challenge/response is sent as an empty string. If 480 the mechanism dictates that the final response is sent by the server 481 this data MAY be placed within the data portion of the SASL response 482 code to save a round trip. 484 The optional initial-response argument to the AUTHENTICATE command is 485 used to save a round trip when using authentication mechanisms that 486 are defined to send no data in the initial challenge. When the 487 initial-response argument is used with such a mechanism, the initial 488 empty challenge is not sent to the client and the server uses the 489 data in the initial-response argument as if it were sent in response 490 to the empty challenge. If the initial-response argument to the 491 AUTHENTICATE command is used with a mechanism that sends data in the 492 initial challenge, the server MUST reject the AUTHENTICATE command by 493 sending the NO response. 495 The service name specified by this protocol's profile of SASL is 496 "sieve". 498 Reauthentication is not supported by ManageSieve protocol's profile 499 of SASL. I.e. after a successfully completed AUTHENTICATE command, 500 no more AUTHENTICATE commands may be issued in the same session. 501 After a successful AUTHENTICATE command completes, a server MUST 502 reject any further AUTHENTICATE commands with a NO reply. However 503 note that a server may implement UNAUTHENTICATE extension described 504 in Section 2.14.1. 506 If a security layer is negotiated through the SASL authentication 507 exchange, it takes effect immediately following the CRLF that 508 concludes the successful authentication exchange for the client, and 509 the CRLF of the OK response for the server. 511 When a security layer takes effect, the ManageSieve protocol is reset 512 to the initial state (the state in ManageSieve after a client has 513 connected to the server). The server MUST discard any knowledge 514 obtained from the client which was not obtained from the SASL (or 515 TLS) negotiation itself. Likewise, the client MUST discard any 516 knowledge obtained from the server, such as the list of ManageSieve 517 extensions, which was not obtained from the SASL (or TLS) negotiation 518 itself. (Note that a client MAY compare the advertised SASL 519 mechanisms before and after authentication in order to detect an 520 active down-negotiation attack. See below.) 521 Once a SASL security layer is established, the server MUST re-issue 522 the capability results, followed by an OK response. This is 523 necessary to protect against man-in-the-middle attacks which alter 524 the capabilities list prior to SASL negotiation. The capability 525 results MUST include all SASL mechanisms the server was capable of 526 negotiating with that client. This is done in order to allow the 527 client to detect active down-negotiation attack. 529 When both [TLS] and SASL security layers are in effect, the TLS 530 encoding MUST be applied (when sending data) after the SASL encoding. 532 Server implementations SHOULD support SASL proxy authentication so 533 that an administrator can administer a user's scripts. Proxy 534 authentication is when a user authenticates as herself/himself but 535 requests the server to act (authorize) as another user. 537 The authorization identity generated by this [SASL] exchange is a 538 "simple username" (in the sense defined in [SASLprep]), and both 539 client and server MUST use the [SASLprep] profile of the [StringPrep] 540 algorithm to prepare these names for transmission or comparison. If 541 preparation of the authorization identity fails or results in an 542 empty string (unless it was transmitted as the empty string), the 543 server MUST fail the authentication. 545 If an AUTHENTICATE command fails with a NO response, the client MAY 546 try another authentication mechanism by issuing another AUTHENTICATE 547 command. In other words, the client may request authentication types 548 in decreasing order of preference. 550 Note that a failed (NO) response to the AUTHENTICATE command may 551 contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- 552 NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed 553 description of the relevant conditions. 555 To ensure interoperability, both client and server implementations of 556 the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM] 557 SASL mechanism, as well as [PLAIN] over [TLS]. 559 Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in 560 other email related protocols, however a longer term goal is to 561 migrate email related protocols from using PLAIN over TLS to SCRAM- 562 HMAC-SHA-1 mechanism. 564 Implementations MAY advertise the ANONYMOUS SASL mechanism 565 [SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE 566 script syntax verification. Only the CAPABILITY, PUTSCRIPT and 567 LOGOUT commands are available to the anonymous user. All other 568 commands defined in the base ManageSieve protocol MUST give NO 569 responses, however ManageSieve extensions MAY allow other commands in 570 the ANONYMOUS Sieve script verification mode. Furthermore the 571 PUTSCRIPT command MUST NOT persistently store any data. In this mode 572 a positive response to the PUTSCRIPT command indicates that the given 573 script does not have any syntax errors. 575 Examples (Note that long lines are folded for readability and are not 576 part of protocol exchange): 578 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 579 S: "SASL" "DIGEST-MD5 GSSAPI" 580 S: "SIEVE" "fileinto vacation" 581 S: "STARTTLS" 582 S: "VERSION" "1.0" 583 S: OK 584 C: Authenticate "DIGEST-MD5" 585 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 586 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 587 cyxjaGFyc2V0PXV0Zi04" 588 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 589 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 590 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 591 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 592 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 593 A9YXV0aA==" 594 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ 595 mZmZA==") 597 A slightly different variant of the same authentication exchange: 599 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 600 S: "SASL" "DIGEST-MD5 GSSAPI" 601 S: "SIEVE" "fileinto vacation" 602 S: "VERSION" "1.0" 603 S: "STARTTLS" 604 S: OK 605 C: Authenticate "DIGEST-MD5" 606 S: {136} 607 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 608 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 609 cyxjaGFyc2V0PXV0Zi04 610 C: {300+} 611 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 612 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 613 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 614 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 615 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 616 A9YXV0aA== 617 S: {56} 618 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 619 C: "" 620 S: OK 622 Another example demonstrating use of SASL PLAIN mechanism under TLS. 623 This example also demonstrate use of SASL "initial response" (the 624 second parameter to the Authenticate command): 626 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 627 S: "VERSION" "1.0" 628 S: "SASL" "" 629 S: "SIEVE" "fileinto vacation" 630 S: "STARTTLS" 631 S: OK 632 C: STARTTLS 633 S: OK 634 635 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 636 S: "VERSION" "1.0" 637 S: "SASL" "PLAIN" 638 S: "SIEVE" "fileinto vacation" 639 S: OK 640 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" 641 S: NO 642 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" 643 S: NO 644 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" 645 S: BYE "Too many failed authentication attempts" 646 648 The following example demonstrates use of SASL "initial response". 649 It also demonstrates that an empty response can be sent as a literal, 650 and that negotiation a SASL security layer results in the server 651 reissuing server capabilities: 653 C: AUTHENTICATE "GSSAPI" {1488+} 654 C: YIIE[...1480 octets here ...]dA== 655 S: {208} 656 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic 657 [...114 octets here ...] 658 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 659 C: {0+} 660 C: 661 S: {44} 662 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= 663 C: {44+} 664 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= 665 S: OK 666 667 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 668 S: "VERSION" "1.0" 669 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 670 S: "SIEVE" "fileinto vacation" 671 S: "LANGUAGE" "ru" 672 S: "MAXREDIRECTS" "3" 673 S: ok 675 2.1.1. Use of SASL PLAIN mechanism over TLS 677 This section is normative for ManageSieve client implementations that 678 support SASL [PLAIN] over [TLS]. 680 If a ManageSieve client is willing to use SASL PLAIN over TLS to 681 authenticate to the ManageSieve server, the client MUST verify the 682 server identity (see Section 2.2.1). If the server identity can't be 683 verified (e.g. the server has not provided any certificate, or if the 684 certificate verification fails) the client MUST NOT attempt to 685 authenticate using the SASL PLAIN mechanism. 687 2.2. STARTTLS Command 689 Support for STARTTLS command in servers is optional. Its 690 availability is advertised with "STARTTLS" capability as described in 691 Section 1.7. 693 The STARTTLS command requests commencement of a TLS [TLS] 694 negotiation. The negotiation begins immediately after the CRLF in 695 the OK response. After a client issues a STARTTLS command, it MUST 696 NOT issue further commands until a server response is seen and the 697 TLS negotiation is complete. 699 The STARTTLS command is only valid in non-authenticated state. The 700 server remains in non-authenticated state, even if client credentials 701 are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL 702 mechanism MAY be used to authenticate once TLS client credentials are 703 successfully exchanged, but servers supporting the STARTTLS command 704 are not required to support the EXTERNAL mechanism. 706 After the TLS layer is established, the server MUST re-issue the 707 capability results, followed by an OK response. This is necessary to 708 protect against man-in-the-middle attacks which alter the 709 capabilities list prior to STARTTLS. This capability result MUST NOT 710 include the STARTTLS capability. 712 The client MUST discard cached capability information and replace it 713 with the new information. The server MAY advertise different 714 capabilities after STARTTLS. 716 Example: 718 C: StartTls 719 S: oK 720 721 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 722 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 723 S: "SIEVE" "fileinto vacation" 724 S: "VERSION" "1.0" 725 S: "LANGUAGE" "fr" 726 S: ok 728 2.2.1. Server Identity Check 730 During the TLS negotiation, the ManageSieve client MUST check its 731 understanding of the server hostname/IP address against the server's 732 identity as presented in the server Certificate message, in order to 733 prevent man-in-the-middle attacks. In this section, the client's 734 understanding of the server's identity is called the "reference 735 identity". 737 Checking is performed according to the following rules: 739 o If the reference identity is a hostname: 741 1. If a subjectAltName extension of the SRVName [X509-SRV], 742 dNSName [X509] (in that order of preference) type is present 743 in the server's certificate, then it SHOULD be used as the 744 source of the server's identity. Matching is performed as 745 described in Section 2.2.1.1, with the exception that no 746 wildcard matching is allowed for SRVName type. If the 747 certificate contains multiple names (e.g., more than one 748 dNSName field), then a match with any one of the fields is 749 considered acceptable. 751 2. The client MAY use other types of subjectAltName for 752 performing comparison. 754 3. The server's identity MAY also be verified by comparing the 755 reference identity to the Common Name (CN) [RFC4519] value in 756 the leaf Relative Distinguished Name (RDN) of the subjectName 757 field of the server's certificate. This comparison is 758 performed using the rules for comparison of DNS names in 759 Section 2.2.1.1, below, with the exception that no wildcard 760 matching is allowed. [[anchor8: Chris Newman says that such 761 prohibition of wildcards doesn't match existing practice.]] 762 Although the use of the Common Name value is existing 763 practice, it is deprecated, and Certification Authorities are 764 encouraged to provide subjectAltName values instead. Note 765 that the TLS implementation may represent DNs in certificates 766 according to X.500 or other conventions. For example, some 767 X.500 implementations order the RDNs in a DN using a left-to- 768 right (most significant to least significant) convention 769 instead of LDAP's right- to-left convention. 771 o When the reference identity is an IP address, the iPAddress 772 subjectAltName SHOULD be used by the client for comparison. The 773 comparison is performed as described in Section 2.2.1.2. 775 o In either case the client MAY map the reference identity to a 776 different type prior to performing a comparison. Mappings may be 777 performed for all available subjectAltName types to which the 778 reference identity can be mapped; however, the reference identity 779 should only be mapped to types for which the mapping is either 780 inherently secure (e.g., extracting the DNS hostname from a URI) 781 or for which the mapping is performed in a secure manner (e.g., 782 using DNSSEC, or using user- or admin-configured host-to-address/ 783 address-to-host lookup tables). 785 If the server identity check fails, user-oriented clients SHOULD 786 either notify the user (clients MAY give the user the opportunity to 787 continue with the ManageSieve session in this case) or close the 788 transport connection and indicate that the server's identity is 789 suspect. Automated clients SHOULD return or log an error indicating 790 that the server's identity is suspect and/or SHOULD close the 791 transport connection. Automated clients MAY provide a configuration 792 setting that disables this check, but MUST provide a setting which 793 enables it. 795 Beyond the server identity check described in this section, clients 796 should be prepared to do further checking to ensure that the server 797 is authorized to provide the service it is requested to provide. The 798 client may need to make use of local policy information in making 799 this determination. 801 2.2.1.1. Comparison of DNS Names 803 If the reference identity is an internationalized domain name, 804 conforming implementations MUST convert it to the ASCII Compatible 805 Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] 806 before comparison with subjectAltName values of type dNSName. 807 Specifically, conforming implementations MUST perform the conversion 808 operation specified in Section 4 of [RFC3490] as follows: 810 o in step 1, the domain name SHALL be considered a "stored string"; 812 o in step 3, set the flag called "UseSTD3ASCIIRules"; 814 o in step 4, process each label with the "ToASCII" operation; and 816 o in step 5, change all label separators to U+002E (full stop). 818 After performing the "to-ASCII" conversion, the DNS labels and names 819 MUST be compared for equality according to the rules specified in 820 Section 3 of [RFC3490], i.e. once all label separators are replaced 821 with U+002E (dot) they are compared in the case-insensitive manner. 823 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 824 values of type dNSName, and then only as the left-most (least 825 significant) DNS label in that value. This wildcard matches any 826 left-most DNS label in the server name. That is, the subject 827 *.example.com matches the server names a.example.com and 828 b.example.com, but does not match example.com or a.b.example.com. 830 2.2.1.2. Comparison of IP Addresses 832 When the reference identity is an IP address, the identity MUST be 833 converted to the "network byte order" octet string representation 834 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 835 octet string will contain exactly four octets. For IP Version 6, as 836 specified in RFC 2460, the octet string will contain exactly sixteen 837 octets. This octet string is then compared against subjectAltName 838 values of type iPAddress. A match occurs if the reference identity 839 octet string and value octet strings are identical. 841 2.2.1.3. Comparison of Other subjectName Types 843 Client implementations MAY support matching against subjectAltName 844 values of other types as described in other documents. 846 2.3. LOGOUT Command 848 The client sends the LOGOUT command when it is finished with a 849 connection and wishes to terminate it. The server MUST reply with an 850 OK response and terminate the connection. The server MUST ignore 851 commands issued by the client after the LOGOUT command. 853 Example: 855 C: Logout 856 S: Ok 857 859 2.4. CAPABILITY Command 861 The CAPABILITY command requests the server capabilities as described 862 earlier in this document. It has no parameters. 864 Example: 866 C: CAPABILITY 867 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 868 S: "VERSION" "1.0" 869 S: "SASL" "PLAIN OTP GSSAPI" 870 S: "SIEVE" "fileinto vacation" 871 S: "STARTTLS" 872 S: OK 874 2.5. HAVESPACE Command 876 Arguments: String - name 877 Number - script size 879 The HAVESPACE command is used to query the server for available 880 space. Clients specify the name they wish to save the script as and 881 its size in octets. Servers respond with an NO if storing a script 882 with that name and size would fail or OK otherwise. Clients SHOULD 883 issue this command before attempting to place a script on the server. 885 Note that the OK response from the HAVESPACE command does not 886 constitute a guarantee of success as server disk space conditions 887 could change between the client issuing the HAVESPACE and the client 888 issuing the PUTSCRIPT commands. A QUOTA response code (see 889 Section 1.3) remains a possible (albeit unlikely) response to a 890 subsequent PUTSCRIPT with the same name and size. 892 Example: 894 C: HAVESPACE "myscript" 999999 895 S: NO (QUOTA/MAXSIZE) "Quota exceeded" 897 C: HAVESPACE "foobar" 435 898 S: OK 900 2.6. PUTSCRIPT Command 902 Arguments: String - Script name 903 String - Script content 905 The PUTSCRIPT command is used by the client to submit a Sieve script 906 to the server. 908 If the script already exists, upon success the old script will be 909 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 910 fails in any way. A script of zero length SHOULD be disallowed. 912 This command places the script on the server. It does not affect 913 whether the script is processed on incoming mail, unless it replaces 914 the script which is already active. The SETACTIVE command is used to 915 mark a script as active. 917 When submitting large scripts clients SHOULD use the HAVESPACE 918 command beforehand to query if the server is willing to accept a 919 script of that size. 921 The server MUST check the submitted script for validity, which 922 includes checking that the script complies with the Sieve grammar 923 [SIEVE], that all Sieve extensions mentioned in script's "require" 924 statement(s) are supported by the Sieve interpreter. (Note that if 925 the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], 926 any unrecognized/unsupported extension mentioned in the "ihave" test 927 MUST NOT cause the validation failure.) Other checks such as 928 validating the supplied command arguments for each command MAY be 929 performed. Essentially, the performed validation SHOULD be the same 930 as performed when compiling the script for execution. 931 Implementations that use a binary representation to store compiled 932 scripts can extend the validation to a full compilation, in order to 933 avoid validating uploaded scripts multiple times. 935 If the script fails the validation the server MUST reply with a NO 936 response. Any script that fails the validity test MUST NOT be stored 937 on the server. The message given with a NO response MUST be human 938 readable and SHOULD contain a specific error message giving the line 939 number of the first error. Implementors should strive to produce 940 helpful error messages similar to those given by programming language 941 compilers. Client implementations should note that this may be a 942 multiline literal string with more than one error message separated 943 by CRLFs. The human readable message is in the language returned in 944 the latest LANGUAGE capability (or in "i-default", see Section 1.7), 945 encoded in UTF-8 [UTF-8]. 947 An OK response MAY contain the WARNINGS response code. In such case 948 the message that follows the OK response SHOULD contain a specific 949 warning message (or messages) giving the line number(s) in the script 950 that might contain errors not intended by the script writer. A 951 client seeing such response code SHOULD present the message to the 952 user. 954 Examples: 956 C: Putscript "foo" {31+} 957 C: #comment 958 C: InvalidSieveCommand 959 C: 960 S: NO "line 2: Syntax error" 962 C: Putscript "mysievescript" {110+} 963 C: require ["fileinto"]; 964 C: 965 C: if envelope :contains "to" "tmartin+sent" { 966 C: fileinto "INBOX.sent"; 967 C: } 968 S: OK 970 C: Putscript "myforwards" {190+} 971 C: redirect "111@example.net"; 972 C: 973 C: if size :under 10k { 974 C: redirect "mobile@cell.example.com"; 975 C: } 976 C: 977 C: if envelope :contains "to" "tmartin+lists" { 978 C: redirect "lists@groups.example.com"; 979 C: } 980 S: OK (WARNINGS) "line 8: server redirect action 981 limit is 2, this redirect might be ignored" 983 2.7. LISTSCRIPTS Command 985 This command lists the scripts the user has on the server. Upon 986 success a list of CRLF separated script names (each represented as a 987 quoted or literal string) is returned followed by an OK response. If 988 there exists an active script the atom ACTIVE is appended to the 989 corresponding script name. The atom ACTIVE MUST NOT appear on more 990 than one response line. 992 Example: 994 C: Listscripts 995 S: "summer_script" 996 S: "vacation_script" 997 S: {13} 998 S: clever"script 999 S: "main_script" ACTIVE 1000 S: OK 1002 C: listscripts 1003 S: "summer_script" 1004 S: "main_script" active 1005 S: OK 1007 2.8. SETACTIVE Command 1009 Arguments: String - script name 1011 This command sets a script active. If the script name is the empty 1012 string (i.e. "") then any active script is disabled. Disabling an 1013 active script when there is no script active is not an error and MUST 1014 result in OK reply. 1016 If the script does not exist on the server then the server MUST reply 1017 with a NO response. Such reply SHOULD contain the NONEXISTENT 1018 response code. 1020 Examples: 1022 C: Setactive "vacationscript" 1023 S: Ok 1025 C: Setactive "" 1026 S: Ok 1028 C: Setactive "baz" 1029 S: No (NONEXISTENT) "There is no script by that name" 1031 C: Setactive "baz" 1032 S: No (NONEXISTENT) {31} 1033 S: There is no script by that name 1035 2.9. GETSCRIPT Command 1037 Arguments: String - script name 1039 This command gets the contents of the specified script. If the 1040 script does not exist the server MUST reply with a NO response. Such 1041 reply SHOULD contain the NONEXISTENT response code. 1043 Upon success a string with the contents of the script is returned 1044 followed by a OK response. 1046 Example: 1048 C: Getscript "myscript" 1049 S: {54} 1050 S: #this is my wonderful script 1051 S: reject "I reject all"; 1052 S: 1053 S: OK 1055 2.10. DELETESCRIPT Command 1057 Arguments: String - script name 1059 This command is used to delete a user's Sieve script. Servers MUST 1060 reply with a NO response if the script does not exist. Such 1061 responses SHOULD include the NONEXISTENT response code. 1063 The server MUST NOT allow the client to delete an active script, so 1064 the server MUST reply with a NO response if attempted. Such response 1065 SHOULD contain the ACTIVE response code. If a client wishes to 1066 delete an active script it should use the SETACTIVE command to 1067 disable the script first. 1069 Example: 1071 C: Deletescript "foo" 1072 S: Ok 1074 C: Deletescript "baz" 1075 S: No (ACTIVE) "You may not delete an active script" 1077 2.11. RENAMESCRIPT Command 1079 Arguments: String - Old Script name 1080 String - New Script name 1082 This command is used to rename a user's Sieve script. Servers MUST 1083 reply with a NO response if the old script does not exist (in which 1084 case the NONEXISTENT response code SHOULD be included), or a script 1085 with the new name already exists (in which case the ALREADYEXISTS 1086 response code SHOULD be included). Renaming the active script is 1087 allowed, the renamed script remains active. 1089 Example: 1091 C: Renamescript "foo" "bar" 1092 S: Ok 1094 C: Renamescript "baz" "bar" 1095 S: No "bar already exists" 1097 If the server doesn't support the RENAMESCRIPT command, the client 1098 can emulate it by performing the following steps: 1100 1. List available scripts with LISTSCRIPTS. If the script with the 1101 new script name exists, then the client should ask the user 1102 whether to abort the operation, to replace the script (by issuing 1103 the DELETESCRIPT after that) or to chose a different 1104 name. 1106 2. Download the old script with GETSCRIPT . 1108 3. Upload the old script with the new name: PUTSCRIPT . 1110 4. If the old script was active (as reported by LISTSCRIPTS in step 1111 1), then make the new script active: SETACTIVE 1113 5. Delete the old script: DELETESCRIPT 1115 Note that these steps don't describe how to handle various other 1116 error conditions (for example NO response containing QUOTA response 1117 code in step 3). Error handling is left as an excercise for the 1118 reader. 1120 2.12. CHECKSCRIPT Command 1122 Arguments: String - Script content 1124 The CHECKSCRIPT command is used by the client to verify Sieve script 1125 validity without storing the script on the server. 1127 The server MUST check the submitted script for syntactic validity, 1128 which includes checking that all Sieve extensions mentioned in Sieve 1129 script "require" statement(s) are supported by the Sieve interpreter. 1130 (Note that if the Sieve interpreter supports the Sieve "ihave" 1131 extension [I-HAVE], any unrecognized/unsupported extension mentioned 1132 in the "ihave" test MUST NOT cause the syntactic validation failure.) 1133 If the script fails this test the server MUST reply with a NO 1134 response. The message given with a NO response MUST be human 1135 readable and SHOULD contain a specific error message giving the line 1136 number of the first error. Implementors should strive to produce 1137 helpful error messages similar to those given by programming language 1138 compilers. Client implementations should note that this may be a 1139 multiline literal string with more than one error message separated 1140 by CRLFs. The human readable message is in the language returned in 1141 the latest LANGUAGE capability (or in "i-default", see Section 1.7), 1142 encoded in UTF-8 [UTF-8]. 1144 Examples: 1146 C: CheckScript {31+} 1147 C: #comment 1148 C: InvalidSieveCommand 1149 C: 1150 S: NO "line 2: Syntax error" 1152 A ManageSieve server supporting this command MUST NOT check if the 1153 script will put the current user over its quota limit. 1155 An OK response MAY contain the WARNINGS response code. In such case 1156 the message that follows the OK response SHOULD contain a specific 1157 warning message (or messages) giving the line number(s) in the script 1158 that might contain errors not intended by the script writer. A 1159 client seeing such response code SHOULD present the message to the 1160 user. 1162 The CHECKSCRIPT command is available in the ANONYMOUS Sieve script 1163 verification mode. 1165 2.13. NOOP Command 1167 Arguments: String - tag to echo back (optional) 1169 The NOOP command does nothing, beyond returning a response to the 1170 client. It may be used by clients for protocol re-synchronisation or 1171 to reset any inactivity auto-logout timer on the server. 1173 The NOOP command is available in the ANONYMOUS Sieve script 1174 verification mode. 1176 The response to the NOOP command is always OK, followed by the TAG 1177 response code together with the supplied string; if no string was 1178 supplied in the NOOP command, the TAG response code MUST NOT be 1179 included. 1181 Examples: 1183 C: NOOP 1184 S: OK "NOOP completed" 1186 C: NOOP "STARTTLS-SYNC-42" 1187 S: OK (TAG {16} 1188 S: STARTTLS-SYNC-42) "Done" 1190 2.14. Recommended extensions 1192 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" 1193 capability with no parameters) defines a new UNAUTHENTICATE command, 1194 which allows a client to return the server to non-authenticated 1195 state. Support for this extension is RECOMMENDED. 1197 2.14.1. UNAUTHENTICATE Command 1199 The UNAUTHENTICATE command returns the server to the non- 1200 authenticated state. It doesn't affect any previously established 1201 TLS [TLS] or SASL (Section 2.1) security layer. 1203 The UNAUTHENTICATE command is only valid in authenticated state. If 1204 issued in a wrong state, the server MUST reject it with a NO 1205 response. 1207 The UNAUTHENTICATE command has no parameters. 1209 When issued in the authenticated state, the UNAUTHENTICATE command 1210 MUST NOT fail (i.e. it must never return anything other than OK or 1211 BYE) 1213 3. Sieve URL Scheme 1215 URI scheme name: sieve 1217 Status: permanent 1219 URI scheme syntax: 1221 Described using ABNF [ABNF]. Some ABNF productions not defined 1222 below are from [URI-GEN]. 1224 sieveurl = sieveurl-server / sieveurl-list-scripts / 1225 sieveurl-script 1227 sieveurl-server = "sieve://" authority 1229 sieveurl-list-scripts = "sieve://" authority ["/"] 1231 sieveurl-script = "sieve://" authority "/" 1232 [owner "/"] scriptname 1234 authority = 1236 owner = *ochar 1237 ;; %-encoded version of [SASL] authorization 1238 ;; identity (script owner) or "userid". 1239 ;; 1240 ;; Empty owner is used to reference 1241 ;; global scripts. 1242 ;; 1243 ;; Note that ASCII characters such as " ", ";", 1244 ;; "&", "=", "/" and "?" must be %-encoded 1245 ;; as per rule specified in [URI-GEN]. 1247 scriptname = 1*ochar 1248 ;; %-encoded version of UTF-8 representation 1249 ;; of the script name. 1250 ;; Note that ASCII characters such as " ", ";", 1251 ;; "&", "=", "/" and "?" must be %-encoded 1252 ;; as per rule specified in [URI-GEN]. 1254 ochar = unreserved / pct-encoded / sub-delims-sh / 1255 ":" / "@" 1256 ;; Same as [URI-GEN] 'pchar' 1257 ;; but without ";", "&" and "=". 1259 unreserved = 1261 pct-encoded = 1263 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 1264 "*" / "+" / "," 1265 ;; Same as [URI-GEN] sub-delims, 1266 ;; but without ";", "&" and "=". 1268 URI scheme semantics: 1270 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve 1271 server. The latter form is associated with the application/sieve 1272 MIME type defined in [SIEVE]. There is no MIME type associated 1273 with the former form of Sieve URI. 1275 The server form is used in the REFERRAL response code (see 1276 Section 1.3 in order to designate another server where the client 1277 should perform its operations. 1279 The script form allows to retrieve (GETSCRIPT), update 1280 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the 1281 named script, however the most typical action would be to retrieve 1282 the script. If the script name is empty (omitted), the URI 1283 requests that the client lists available scripts using the 1284 LISTSCRIPTS command. 1286 Encoding considerations: 1288 The script name and/or the owner, if present, is in UTF-8. Non- 1289 US-ASCII UTF-8 octets MUST be percent-encoded as described in 1290 [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", 1291 "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. 1292 Note that "&" and "?" are in this list in order to allow for 1293 future extensions. 1295 Note that the empty owner (e.g. sieve://example.com//script) is 1296 different from the missing owner (e.g. sieve://example.com/script) 1297 and is reserved for referencing global scripts. 1299 The user name (in the "authority" part), if present, is in UTF-8. 1300 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1301 [URI-GEN]. 1303 Applications/protocols that use this URI scheme name: 1304 ManageSieve [RFC XXXX] clients and servers. Clients that can store 1305 user preferences in protocols such as [LDAP] or [ACAP]. 1307 Interoperability considerations: None. 1309 Security considerations: 1310 The part of a ManageSieve URL might potentially disclose 1311 some confidential information about the author of the script or, 1312 depending on a ManageSieve implementation, about configuration of the 1313 mail system. The latter might be used to prepare for a more complex 1314 attack on the mail system. 1316 Clients resolving ManageSieve URLs that wish to achieve data 1317 confidentiality and/or integrity SHOULD use the STARTTLS command (if 1318 supported by the server) before starting authentication, or use a 1319 SASL mechanism, such as GSSAPI, that provides a confidentiality 1320 security layer. 1322 Contact: Alexey Melnikov 1324 Author/Change controller: IESG. 1326 References: This document and RFC 5228 [SIEVE]. 1328 4. Formal Syntax 1330 The following syntax specification uses the augmented Backus-Naur 1331 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 1332 rules as specified in Appendix A of the ABNF specification [ABNF]. 1333 "UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8]. 1335 Except as noted otherwise, all alphabetic characters are case- 1336 insensitive. The use of upper or lower case characters to define 1337 token strings is for editorial clarity only. Implementations MUST 1338 accept these strings in a case-insensitive fashion. 1340 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 1341 %x5D-7F 1342 ;; any TEXT-CHAR except QUOTED-SPECIALS 1344 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 1346 QUOTED-SPECIALS = DQUOTE / "\" 1348 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 1349 ;; , and 1350 ;; are defined in [UTF-8] 1352 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E 1353 ;; Any CHAR except ATOM-SPECIALS 1355 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / 1356 QUOTED-SPECIALS 1358 QUOTED-SPECIALS = <"> / "\" 1360 atom = 1*1024ATOM-CHAR 1362 iana-token = atom 1363 ;; MUST be registered with IANA 1365 auth-type = DQUOTE auth-type-name DQUOTE 1367 auth-type-name = iana-token 1368 ;; as defined in SASL [SASL] 1370 command = (command-any / command-auth / 1371 command-nonauth) CRLF 1372 ;; Modal based on state 1374 command-any = command-capability / command-logout / 1375 command-noop 1376 ;; Valid in all states 1378 command-auth = command-getscript / command-setactive / 1379 command-listscripts / command-deletescript / 1380 command-putscript / command-checkscript / 1381 command-havespace / / 1382 command-renamescript / 1383 command-unauthenticate 1384 ;; Valid only in Authenticated state 1386 command-nonauth = command-authenticate / command-starttls 1387 ;; Valid only when in Non-Authenticated 1388 ;; state 1390 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 1391 *(CRLF string) 1393 command-capability = "CAPABILITY" 1395 command-deletescript = "DELETESCRIPT" SP sieve-name 1397 command-getscript = "GETSCRIPT" SP sieve-name 1399 command-havespace = "HAVESPACE" SP sieve-name SP number 1401 command-listscripts = "LISTSCRIPTS" 1403 command-noop = "NOOP" [SP string] 1405 command-logout = "LOGOUT" 1407 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script 1409 command-checkscript = "CHECKSCRIPT" SP sieve-script 1410 sieve-script = string 1412 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP 1413 new-sieve-name 1415 old-sieve-name = sieve-name 1417 new-sieve-name = sieve-name 1419 command-setactive = "SETACTIVE" SP active-sieve-name 1421 command-starttls = "STARTTLS" 1423 command-unauthenticate= "UNAUTHENTICATE" 1425 extend-token = atom 1426 ;; MUST be defined by a standards track or 1427 ;; IESG approved experimental protocol 1428 ;; extension 1430 extension-data = extension-item *(SP extension-item) 1432 extension-item = extend-token / string / number / 1433 "(" [extension-data] ")" 1435 literal-c2s = "{" number "+}" CRLF *OCTET 1436 ;; The number represents the number of 1437 ;; octets. 1438 ;; This type of literal can only be sent 1439 ;; from the client to the server. 1441 literal-s2c = "{" number "}" CRLF *OCTET 1442 ;; Almost identical to literal-c2s, 1443 ;; but with no '+' character. 1444 ;; The number represents the number of 1445 ;; octets. 1446 ;; This type of literal can only be sent 1447 ;; from the server to the client. 1449 number = 1*DIGIT 1450 ;; A 32-bit unsigned number. 1451 ;; (0 <= n < 4,294,967,296) 1453 number-str = string 1454 ;; encoded as a . 1456 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1457 ;; limited to 1024 octets between the <">s 1459 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1460 "QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] / 1461 resp-code-sasl / 1462 resp-code-referral / 1463 "TRANSITION-NEEDED" / "TRYLATER" / 1464 "ACTIVE" / "NONEXISTENT" / 1465 "ALREADYEXISTS" / "WARNINGS" / 1466 "TAG" SP string / 1467 resp-code-ext 1469 resp-code-referral = "REFERRAL" SP sieveurl 1471 resp-code-sasl = "SASL" SP string 1473 resp-code-name = iana-token 1474 ;; The response code name is hierarchical, 1475 ;; separated by '/'. 1476 ;; The response code name MUST NOT start 1477 ;; with '/'. 1479 resp-code-ext = resp-code-name [SP extension-data] 1480 ;; unknown response codes MUST be tolerated 1481 ;; by the client. 1483 response = response-authenticate / 1484 response-logout / 1485 response-getscript / 1486 response-setactive / 1487 response-listscripts / 1488 response-deletescript / 1489 response-putscript / 1490 response-checkscript / 1491 response-capability / 1492 response-havespace / 1493 response-starttls / 1494 response-renamescript / 1495 response-noop / 1496 response-unauthenticate 1498 response-authenticate = *(string CRLF) 1499 ((response-ok [response-capability]) / 1500 response-nobye) 1501 ;; is REQUIRED if a 1502 ;; SASL security layer was negotiated and 1503 ;; MUST be omitted otherwise. 1505 response-capability = *(single-capability) response-oknobye 1506 single-capability = capability-name [SP string] CRLF 1508 capability-name = string 1509 ;; Note that literal-s2c is allowed. 1511 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1512 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1513 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1514 DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / 1515 DQUOTE "NOTIFY" DQUOTE SP notify-mechs / 1516 DQUOTE "STARTTLS" DQUOTE / 1517 DQUOTE "LANGUAGE" DQUOTE SP language / 1518 DQUOTE "VERSION" DQUOTE SP version / 1519 DQUOTE "OWNER" DQUOTE SP string 1520 ;; Each capability conforms to 1521 ;; the syntax for single-capability. 1522 ;; Also note that the capability name 1523 ;; can be returned as either literal-s2c 1524 ;; or quoted, even though only "quoted" 1525 ;; string is shown above. 1526 version = DQUOTE "1.0" DQUOTE 1528 sasl-mechs = string 1529 ; space separated list of SASL mechanisms, 1530 ; each SASL mechanism name complies with rules 1531 ; specified in [SASL]. 1532 ; Can be empty. 1534 sieve-extensions = string 1535 ; space separated list of supported SIEVE extensions, 1536 ; can be empty. 1538 language = string 1539 ; Contains from [RFC4646]. 1541 notify-mechs = string 1542 ; space separated list of URI schema parts 1543 ; for supported notification [NOTIFY] methods. 1544 ; MUST NOT be empty. 1546 response-deletescript = response-oknobye 1548 response-getscript = (sieve-script CRLF response-ok) / 1549 response-nobye 1551 response-havespace = response-oknobye 1553 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1554 response-oknobye 1555 ;; ACTIVE may only occur with one sieve-name 1557 response-logout = response-oknobye 1559 response-unauthenticate= response-oknobye 1560 ;; "NO" response can only be returned when 1561 ;; the command is issued in a wrong state 1562 ;; or has a wrong number of parameters 1564 response-ok = "OK" [SP "(" resp-code ")"] 1565 [SP string] CRLF 1566 ;; The string contains human readable text 1567 ;; encoded as UTF-8. 1569 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1570 [SP string] CRLF 1571 ;; The string contains human readable text 1572 ;; encoded as UTF-8. 1574 response-oknobye = response-ok / response-nobye 1576 response-noop = response-ok 1578 response-putscript = response-oknobye 1580 response-checkscript = response-oknobye 1582 response-renamescript = response-oknobye 1584 response-setactive = response-oknobye 1586 response-starttls = (response-ok response-capability) / 1587 response-nobye 1589 sieve-name = string 1590 ;; See Section 1.6 for the full list of 1591 ;; prohibited characters. 1592 ;; Empty string is not allowed. 1594 active-sieve-name = string 1595 ;; See Section 1.6 for the full list of 1596 ;; prohibited characters. 1597 ;; This is similar to , but 1598 ;; empty string is allowed and has a special 1599 ;; meaning. 1601 string = quoted / literal-c2s / literal-s2c 1602 ;; literal-c2s is only allowed when sent 1603 ;; from the client to the server. 1604 ;; literal-s2c is only allowed when sent 1605 ;; from the server to the client. 1606 ;; quoted is allowed in either direction. 1608 5. Security Considerations 1610 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1611 and authorization services. Integrity and privacy services can be 1612 provided by [SASL] and/or [TLS]. When a SASL mechanism is used the 1613 security considerations for that mechanism apply. 1615 This protocol's transactions are susceptible to passive observers or 1616 man in the middle attacks which alter the data, unless the optional 1617 encryption and integrity services of the SASL (via the AUTHENTICATE 1618 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1619 external security mechanism is used for protection. It may be useful 1620 to allow configuration of both clients and servers to refuse to 1621 transfer sensitive information in the absence of strong encryption. 1623 If an implementation supports SASL mechanisms that are vulnerable to 1624 passive eavesdropping attacks (such as [PLAIN]), then the 1625 implementation MUST support at least one configuration where these 1626 SASL mechanisms are not advertised or used without the presence of an 1627 external security layer such as [TLS]. 1629 Some response codes returned on failed AUTHENTICATE command may 1630 disclose whether or not the username is valid, so server 1631 implementations SHOULD provide the ability to disable these features 1632 (or make them not conditional on a per-user basis) for sites 1633 concerned about such disclosure. In the case of ENCRYPT-NEEDED, if 1634 it is applied to all identities then no extra information is 1635 disclosed, but if it is applied on a per-user basis it can disclose 1636 information. 1638 6. IANA Considerations 1640 IANA is requested to reserve TCP port number 2000 for use with the 1641 ManageSieve protocol described in this document. 1643 IANA is requested to register the "sieve" URI scheme defined in 1644 Section 3 of this document. 1646 IANA is requested to create a new registry for ManageSieve 1647 capabilities. The registration template for ManageSieve capabilities 1648 is specified in Section 6.1. ManageSieve protocol capabilities MUST 1649 be specified in a standards track or IESG approved experimental RFC. 1651 IANA is requested to create a new registry for ManageSieve response 1652 codes. The registration template for ManageSieve response codes is 1653 specified in Section 6.3. ManageSieve protocol response codes MUST 1654 be specified in a standards track or IESG approved experimental RFC. 1656 6.1. ManageSieve Capability Registration Template 1658 To: iana@iana.org 1659 Subject: ManageSieve Capability Registration 1661 Please register the following ManageSieve Capability: 1662 Capability name: 1663 Description: 1664 Relevant publications: 1665 Person & email address to contact for further information: 1666 Author/Change controller: 1668 6.2. Registration of Initial ManageSieve capabilities 1670 To: iana@iana.org 1671 Subject: ManageSieve Capability Registration 1673 Please register the following ManageSieve Capabilities: 1675 Capability name: IMPLEMENTATION 1677 Description: Its value contains name of server implementation and 1678 its version. 1680 Relevant publications: this RFC, Section 1.7. 1682 Person & email address to contact for further information: Alexey 1683 Melnikov 1685 Author/Change controller: IESG. 1687 Capability name: SASL 1689 Description: Its value contains a space separated list of SASL 1690 mechanisms supported by server. 1692 Relevant publications: this RFC, Section 1.7 and Section 2.1. 1694 Person & email address to contact for further information: Alexey 1695 Melnikov 1696 Author/Change controller: IESG. 1698 Capability name: SIEVE 1700 Description: Its value contains a space separated list of 1701 supported SIEVE extensions 1703 Relevant publications: this RFC, Section 1.7. Also [SIEVE]. 1705 Person & email address to contact for further information: Alexey 1706 Melnikov 1708 Author/Change controller: IESG. 1710 Capability name: STARTTLS 1712 Description: This capability is returned if server supports TLS 1713 (STARTTLS command). 1715 Relevant publications: this RFC, Section 1.7 and Section 2.2. 1717 Person & email address to contact for further information: Alexey 1718 Melnikov 1720 Author/Change controller: IESG. 1722 Capability name: NOTIFY 1724 Description: This capability is returned if server supports 1725 'enotify' [NOTIFY] Sieve extension. 1727 Relevant publications: this RFC, Section 1.7. 1729 Person & email address to contact for further information: Alexey 1730 Melnikov 1732 Author/Change controller: IESG. 1734 Capability name: OWNER 1736 Description: Its value contains UTF-8 encoded name of the 1737 currently logged in user ("authorization identity" according to 1738 RFC 4422). 1740 Relevant publications: this RFC, Section 1.7. 1742 Person & email address to contact for further information: Alexey 1743 Melnikov 1744 Author/Change controller: IESG. 1746 Capability name: VERSION 1748 Description: This capability is returned if the server is 1749 compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT, 1750 CHECKSCRIPT and NOOP commands. 1752 Relevant publications: this RFC, Section 2.11. 1754 Person & email address to contact for further information: Alexey 1755 Melnikov 1757 Author/Change controller: IESG. 1759 6.3. ManageSieve Response Code Registration Template 1761 To: iana@iana.org 1762 Subject: ManageSieve Response Code Registration 1764 Please register the following ManageSieve Response Code: 1766 Response Code: 1768 Arguments (use ABNF to specify syntax, or the word NONE if none 1769 can be specified): 1771 Purpose: 1773 Published Specification(s): 1775 Person & email address to contact for further information: 1777 Author/Change controller: 1779 6.4. Registration of Initial ManageSieve Response Codes 1781 To: iana@iana.org 1782 Subject: ManageSieve Response Code Registration 1784 Please register the following ManageSieve Response Codes: 1786 Response Code: AUTH-TOO-WEAK 1788 Arguments (use ABNF to specify syntax, or the word NONE if none 1789 can be specified): NONE 1790 Purpose: This response code is returned in the NO response from an 1791 AUTHENTICATE command. It indicates that site security policy 1792 forbids the use of the requested mechanism for the specified 1793 authentication identity. 1795 Published Specification(s): [RFCXXXX] 1797 Person & email address to contact for further information: Alexey 1798 Melnikov 1800 Author/Change controller: IESG. 1802 Response Code: ENCRYPT-NEEDED 1804 Arguments (use ABNF to specify syntax, or the word NONE if none 1805 can be specified): NONE 1807 Purpose: This response code is returned in the NO response from an 1808 AUTHENTICATE command. It indicates that site security policy 1809 requires the use of a strong encryption mechanism for the 1810 specified authentication identity and mechanism. 1812 Published Specification(s): [RFCXXXX] 1814 Person & email address to contact for further information: Alexey 1815 Melnikov 1817 Author/Change controller: IESG. 1819 Response Code: QUOTA 1821 Arguments (use ABNF to specify syntax, or the word NONE if none 1822 can be specified): NONE 1824 Purpose: If this response code is returned in the NO/BYE response, 1825 it means that the command would have placed the user above the 1826 site-defined quota constraints. If this response code is returned 1827 in the OK response, it can mean that the user is near its quota or 1828 that the user exceeded its quota, but the server supports soft 1829 quotas. 1831 Published Specification(s): [RFCXXXX] 1833 Person & email address to contact for further information: Alexey 1834 Melnikov 1836 Author/Change controller: IESG. 1838 Response Code: QUOTA/MAXSCRIPTS 1840 Arguments (use ABNF to specify syntax, or the word NONE if none 1841 can be specified): NONE 1843 Purpose: If this response code is returned in the NO/BYE response, 1844 it means that the command would have placed the user above the 1845 site-defined limit on the number of Sieve scripts. If this 1846 response code is returned in the OK response, it can mean that the 1847 user is near its quota or that the user exceeded its quota, but 1848 the server supports soft quotas. This response code is a more 1849 specific version of the QUOTA response code. 1851 Published Specification(s): [RFCXXXX] 1853 Person & email address to contact for further information: Alexey 1854 Melnikov 1856 Author/Change controller: IESG. 1858 Response Code: QUOTA/MAXSIZE 1860 Arguments (use ABNF to specify syntax, or the word NONE if none 1861 can be specified): NONE 1863 Purpose: If this response code is returned in the NO/BYE response, 1864 it means that the command would have placed the user above the 1865 site-defined maximum script size. If this response code is 1866 returned in the OK response, it can mean that the user is near its 1867 quota or that the user exceeded its quota, but the server supports 1868 soft quotas. This response code is a more specific version of the 1869 QUOTA response code. 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: REFERRAL 1880 Arguments (use ABNF to specify syntax, or the word NONE if none 1881 can be specified): 1883 Purpose: This response code may be returned with a BYE result from 1884 any command, and includes a mandatory parameter that indicates 1885 what server to access to manage this user's sieve scripts. The 1886 server will be specified by a Sieve URL (see Section 3). The 1887 scriptname portion of the URL MUST NOT be specified. The client 1888 should authenticate to the specified server and use it for all 1889 further commands in the current session. 1891 Published Specification(s): [RFCXXXX] 1893 Person & email address to contact for further information: Alexey 1894 Melnikov 1896 Author/Change controller: IESG. 1898 Response Code: SASL 1900 Arguments (use ABNF to specify syntax, or the word NONE if none 1901 can be specified): 1903 Purpose: This response code can occur in the OK response to a 1904 successful AUTHENTICATE command and includes the optional final 1905 server response data from the server as specified by [SASL]. 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: TRANSITION-NEEDED 1916 Arguments (use ABNF to specify syntax, or the word NONE if none 1917 can be specified): NONE 1919 Purpose: This response code occurs in a NO response of an 1920 AUTHENTICATE command. It indicates that the user name is valid, 1921 but the entry in the authentication database needs to be updated 1922 in order to permit authentication with the specified mechanism. 1923 This is typically done by establishing a secure channel using TLS, 1924 followed by authenticating once using the [PLAIN] authentication 1925 mechanism. The selected mechanism SHOULD then work for 1926 authentications in subsequent sessions. 1928 Published Specification(s): [RFCXXXX] 1930 Person & email address to contact for further information: Alexey 1931 Melnikov 1932 Author/Change controller: IESG. 1934 Response Code: TRYLATER 1936 Arguments (use ABNF to specify syntax, or the word NONE if none 1937 can be specified): NONE 1939 Purpose: A command failed due to a temporary server failure. The 1940 client MAY continue using local information and try the command 1941 later. This response code only make sense when returned in a NO/ 1942 BYE response. 1944 Published Specification(s): [RFCXXXX] 1946 Person & email address to contact for further information: Alexey 1947 Melnikov 1949 Author/Change controller: IESG. 1951 Response Code: ACTIVE 1953 Arguments (use ABNF to specify syntax, or the word NONE if none 1954 can be specified): NONE 1956 Purpose: A command failed because it is not allowed on the active 1957 script. For example DELETESCRIPT on the active script. This 1958 response code only makes sense when returned in a NO/BYE response. 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: NONEXISTENT 1969 Arguments (use ABNF to specify syntax, or the word NONE if none 1970 can be specified): NONE 1972 Purpose: A command failed because the referenced script name 1973 doesn't exist. This response code only makes sense when returned 1974 in a NO/BYE response. 1976 Published Specification(s): [RFCXXXX] 1978 Person & email address to contact for further information: Alexey 1979 Melnikov 1980 Author/Change controller: IESG. 1982 Response Code: ALREADYEXISTS 1984 Arguments (use ABNF to specify syntax, or the word NONE if none 1985 can be specified): NONE 1987 Purpose: A command failed because the referenced script name 1988 already exists. This response code only makes sense when returned 1989 in a NO/BYE response. 1991 Published Specification(s): [RFCXXXX] 1993 Person & email address to contact for further information: Alexey 1994 Melnikov 1996 Author/Change controller: IESG. 1998 Response Code: WARNINGS 2000 Arguments (use ABNF to specify syntax, or the word NONE if none 2001 can be specified): NONE 2003 Purpose: This response code MAY be returned by the server in the 2004 OK response (but it might be returned with the NO/BYE response as 2005 well) and signals the client that even though the script is 2006 syntactically valid, it might contain errors not intended by the 2007 script writer. 2009 Published Specification(s): [RFCXXXX] 2011 Person & email address to contact for further information: Alexey 2012 Melnikov 2014 Author/Change controller: IESG. 2016 Response Code: TAG 2018 Arguments (use ABNF to specify syntax, or the word NONE if none 2019 can be specified): string 2021 Purpose: This response code name is followed by a string specified 2022 in the command that caused this response. It is typically used 2023 for client state synchronization. 2025 Published Specification(s): [RFCXXXX] 2026 Person & email address to contact for further information: Alexey 2027 Melnikov 2029 Author/Change controller: IESG. 2031 7. Acknowledgements 2033 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 2034 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, 2035 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil 2036 Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan 2037 Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick 2038 Ben Koetter, Bjoern Hoehrmann and Martin Duerst for help with this 2039 document. Special thank you to Phil Pennock for providing text for 2040 the NOOP command, as well as finding various bugs in the document. 2042 8. References 2044 8.1. Normative References 2046 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2047 Specifications: ABNF", RFC 5234, January 2008. 2049 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 2050 Configuration Access Protocol", RFC 2244, November 1997. 2052 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 2053 Encodings", RFC 4648, October 2006. 2055 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2056 specifying the location of services (DNS SRV)", RFC 2782, 2057 February 2000. 2059 [KEYWORDS] 2060 Bradner, S., "Key words for use in RFCs to Indicate 2061 Requirement Levels", RFC 2119, March 1997. 2063 [NET-UNICODE] 2064 Klensin, J. and M. Padlipsky, "Unicode Format for Network 2065 Interchange", RFC 5198, March 2008. 2067 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 2068 Martin, "Sieve Extension: Notifications", 2069 draft-ietf-sieve-notify-12 (work in progress), 2070 December 2007. 2072 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2073 Languages", RFC 2277, January 1998. 2075 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2076 (IPv6) Specification", RFC 2460, December 1998. 2078 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2079 "Internationalizing Domain Names in Applications (IDNA)", 2080 RFC 3490, March 2003. 2082 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2083 (LDAP): Schema for User Applications", RFC 4519, 2084 June 2006. 2086 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 2087 Languages", RFC 4646, September 2006. 2089 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 2091 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2092 Security Layer (SASL)", RFC 4422, June 2006. 2094 [SASL-ANON] 2095 Zeilenga, K., "Anonymous Simple Authentication and 2096 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 2098 [SASLprep] 2099 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 2100 and Passwords", RFC 4013, February 2005. 2102 [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge 2103 Response Authentication Mechanism (SCRAM)", 2104 draft-newman-auth-scram-07.txt (work in progress), 2105 November 2008. 2107 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 2108 Filtering Language", RFC 5228, January 2008. 2110 [StringPrep] 2111 Hoffman, P. and M. Blanchet, "Preparation of 2112 Internationalized Strings ("stringprep")", RFC 3454, 2113 December 2002. 2115 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2116 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2118 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2119 Resource Identifier (URI): Generic Syntax", STD 66, 2120 RFC 3986, January 2005. 2122 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2123 10646", STD 63, RFC 3629, November 2003. 2125 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2126 X.509 Public Key Infrastructure Certificate and 2127 Certificate Revocation List (CRL) Profile", RFC 3280, 2128 April 2002. 2130 [X509-SRV] 2131 Santesson, S., "Internet X.509 Public Key Infrastructure 2132 Subject Alternative Name for Expression of Service Name", 2133 RFC 4985, August 2007. 2135 8.2. Informative References 2137 [DIGEST-MD5] 2138 Leach, P. and C. Newman, "Using Digest Authentication as a 2139 SASL Mechanism", RFC 2831, May 2000. 2141 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", 2142 draft-freed-sieve-ihave-03.txt (work in progress), 2143 October 2008. 2145 [IANA-GUIDELINES] 2146 Narten, T. and H. Alvestrand, "Guidelines for Writing an 2147 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2148 May 2008. 2150 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2151 4rev1", RFC 3501, March 2003. 2153 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 2154 (LDAP): Technical Specification Road Map", RFC 4510, 2155 June 2006. 2157 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 2158 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 2160 Authors' Addresses 2162 Alexey Melnikov (editor) 2163 Isode Limited 2164 5 Castle Business Village 2165 36 Station Road 2166 Hampton, Middlesex TW12 2BX 2167 UK 2169 Email: Alexey.Melnikov@isode.com 2171 Tim Martin 2172 BeThereBeSquare Inc. 2173 672 Haight st. 2174 San Francisco, CA 94117 2175 US 2177 Phone: +1 510 260-4175 2178 Email: timmartin@alumni.cmu.edu 2180 Full Copyright Statement 2182 Copyright (C) The IETF Trust (2008). 2184 This document is subject to the rights, licenses and restrictions 2185 contained in BCP 78, and except as set forth therein, the authors 2186 retain all their rights. 2188 This document and the information contained herein are provided on an 2189 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2190 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2191 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2192 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2193 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2194 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2196 Intellectual Property 2198 The IETF takes no position regarding the validity or scope of any 2199 Intellectual Property Rights or other rights that might be claimed to 2200 pertain to the implementation or use of the technology described in 2201 this document or the extent to which any license under such rights 2202 might or might not be available; nor does it represent that it has 2203 made any independent effort to identify any such rights. Information 2204 on the procedures with respect to rights in RFC documents can be 2205 found in BCP 78 and BCP 79. 2207 Copies of IPR disclosures made to the IETF Secretariat and any 2208 assurances of licenses to be made available, or the result of an 2209 attempt made to obtain a general license or permission for the use of 2210 such proprietary rights by implementers or users of this 2211 specification can be obtained from the IETF on-line IPR repository at 2212 http://www.ietf.org/ipr. 2214 The IETF invites any interested party to bring to its attention any 2215 copyrights, patents or patent applications, or other proprietary 2216 rights that may cover technology that may be required to implement 2217 this standard. Please address the information to the IETF at 2218 ietf-ipr@ietf.org.