idnits 2.17.1 draft-ietf-sieve-managesieve-02.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 2185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2209. 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 (November 30, 2008) is 5619 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 288, but not defined == Missing Reference: 'IMAP4' is mentioned on line 1250, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1294, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 2015, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 2128, but no explicit reference was found in the text == Unused Reference: 'IANA-GUIDELINES' is defined on line 2136, 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. 'IMAP4rev1') (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 9 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 3, 2009 BeThereBeSquare Inc. 6 November 30, 2008 8 A Protocol for Remotely Managing Sieve Scripts 9 draft-ietf-sieve-managesieve-02 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 3, 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 . . . . . . . . . . . . . . . . . . . . . . 30 84 5. Security Considerations . . . . . . . . . . . . . . . . . 36 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 36 87 6.1. ManageSieve Capability Registration Template . . . . . . . 37 88 6.2. Registration of Initial ManageSieve capabilities . . . . . 37 89 6.3. ManageSieve Response Code Registration Template . . . . . 39 90 6.4. Registration of Initial ManageSieve Response Codes . . . . 39 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 44 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . 45 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 45 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 47 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 47 98 Intellectual Property and Copyright Statements . . . . . . 49 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 [IMAP4rev1] or [ACAP]. There 115 are three data types: atoms, numbers and strings. Strings may be 116 quoted or literal. See [ACAP] for detailed descriptions of these 117 types. 119 Each command consists of an atom (the command name) followed by zero 120 or more strings and numbers terminated by CRLF. 122 All client queries are replied to with either an OK, NO, or BYE 123 response. Each response may be followed by a response code (see 124 Section 1.3) and by a string consisting of human readable text in the 125 local language, encoded in [UTF-8]. The contents of the string 126 SHOULD be shown to the user and implementations MUST NOT attempt to 127 parse the message for meaning. 129 The BYE response SHOULD be used if the server wishes to close the 130 connection. A server may wish to do this because the client was idle 131 for too long or there were too many failed authentication attempts. 132 This response can be issued at any time and should be immediately 133 followed by a server hang-up of the connection. If a server has an 134 inactivity timeout resulting in client autologout it MUST be no less 135 than 30 minutes after successful authentication. The inactivity 136 timeout MAY be less before authentication. 138 1.3. Response Codes 140 An OK, NO, or BYE response from the server MAY contain a response 141 code to describe the event in a more detailed machine parsable 142 fashion. A response code consists of data inside parentheses in the 143 form of an atom, possibly followed by a space and arguments. 144 Response codes are defined when there is a specific action that a 145 client can take based upon the additional information. In order to 146 support future extension, the response code is represented as a 147 slash-separated (Solidus, %x2F) hierarchy with each level of 148 hierarchy representing increasing detail about the error. Response 149 codes MUST NOT start with the Solidus character. Clients MUST 150 tolerate additional hierarchical response code detail which they 151 don't understand. For example, if the client supports the "QUOTA" 152 response code, but doesn't understand the "QUOTA/MAXSCRIPTS" response 153 code, it should treat "QUOTA/MAXSCRIPTS" as "QUOTA". 155 Client implementations MUST tolerate (ignore) response codes that 156 they do not recognize. 158 The currently defined response codes are: 160 AUTH-TOO-WEAK 162 This response code is returned in the NO or BYE response from an 163 AUTHENTICATE command. It indicates that site security policy forbids 164 the use of the requested mechanism for the specified authentication 165 identity. 167 ENCRYPT-NEEDED 169 This response code is returned in the NO or BYE response from an 170 AUTHENTICATE command. It indicates that site security policy 171 requires the use of a strong encryption mechanism for the specified 172 authentication identity and mechanism. 174 QUOTA 176 If this response code is returned in the NO/BYE response, it means 177 that the command would have placed the user above the site-defined 178 quota constraints. If this response code is returned in the OK 179 response, it can mean that the user's storage is near its quota, or 180 it can mean that the account exceeded its quota but that that 181 condition is being allowed by the server (the server supports so 182 called "soft quotas"). The QUOTA response code has 2 more detailed 183 variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user scripts) 184 and "QUOTA/MAXSIZE" (the maximum script size). 186 REFERRAL 188 This response code may be returned with a BYE result from any 189 command, and includes a mandatory parameter that indicates what 190 server to access to manage this user's sieve scripts. The server 191 will be specified by a Sieve URL (see Section 3). The scriptname 192 portion of the URL MUST NOT be specified. The client should 193 authenticate to the specified server and use it for all further 194 commands in the current session. 196 SASL 198 This response code can occur in the OK response to a successful 199 AUTHENTICATE command and includes the optional final server response 200 data from the server as specified by [SASL]. 202 TRANSITION-NEEDED 204 This response code occurs in a NO response of an AUTHENTICATE 205 command. It indicates that the user name is valid, but the entry in 206 the authentication database needs to be updated in order to permit 207 authentication with the specified mechanism. This is typically done 208 by establishing a secure channel using TLS, verifying server identity 209 as specified in Section 2.2.1, and finally authenticating once using 210 the [PLAIN] authentication mechanism. The selected mechanism SHOULD 211 then work for authentications in subsequent sessions. 213 This condition can happen if a user has an entry in a system 214 authentication database such as Unix /etc/passwd, but does not have 215 credentials suitable for use by the specified mechanism. 217 TRYLATER 219 A command failed due to a temporary server failure. The client MAY 220 continue using local information and try the command later. This 221 response code only makes sense when returned in a NO/BYE response. 223 ACTIVE 225 A command failed because it is not allowed on the active script. For 226 example DELETESCRIPT on the active script. This response code only 227 makes sense when returned in a NO/BYE response. 229 NONEXISTENT 231 A command failed because the referenced script name doesn't exist. 232 This response code only makes sense when returned in a NO/BYE 233 response. 235 ALREADYEXISTS 237 A command failed because the referenced script name already exists. 238 This response code only makes sense when returned in a NO/BYE 239 response. 241 TAG 243 This response code name is followed by a string specified in the 244 command. See Section 2.13 for a possible use case. 246 WARNINGS 248 This response code MAY be returned by the server in the OK response 249 (but it might be returned with the NO/BYE response as well) and 250 signals the client that even though the script is syntactically 251 valid, it might contain errors not intended by the script writer. 252 This response code is typically returned in response to PUTSCRIPT 253 and/or CHECKSCRIPT commands. A client seeing such response code 254 SHOULD present the returned warning text to the user. 256 1.4. Active Script 258 A user may have multiple Sieve scripts on the server, yet only one 259 script may be used for filtering of incoming messages. This is the 260 active script. Users may have zero or one active scripts and MUST 261 use the SETACTIVE command described below for changing the active 262 script or disabling Sieve processing. For example, a user may have 263 an everyday script they normally use and a special script they use 264 when they go on vacation. Users can change which script is being 265 used without having to download and upload a script stored somewhere 266 else. 268 1.5. Quotas 270 Servers SHOULD impose quotas to prevent malicious users from 271 overflowing available storage. If a command would place a user over 272 a quota setting, servers that impose such quotas MUST reply with a NO 273 response containing the QUOTA response code. Client implementations 274 MUST be able to handle commands failing because of quota 275 restrictions. 277 1.6. Script Names 279 A Sieve script name is a sequence of Unicode characters encoded in 280 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition 281 (Section 2 of [NET-UNICODE]), with the additional restriction of 282 prohibiting the following Unicode characters: 284 o 0000-001F; [CONTROL CHARACTERS] 286 o 007F; DELETE 288 o 0080-009F; [CONTROL CHARACTERS] 290 o 2028; LINE SEPARATOR 291 o 2029; PARAGRAPH SEPARATOR 293 Sieve script names MUST be at least one octet (and hense Unicode 294 character) long. Zero octets script name has a special meaning (see 295 Section 2.8). Servers MUST allow names of up to 128 Unicode 296 characters in length (which can take up to 512 bytes when encoded in 297 UTF-8, not counting the terminating NUL), and MAY allow longer names. 298 A server that receives a script name longer than its internal limit 299 MUST rejects the corresponding operation, in particular it MUST NOT 300 truncate the script name. 302 1.7. Capabilities 304 Server capabilities are sent automatically by the server upon a 305 client connection, or after successful STARTTLS and AUTHENTICATE 306 (which establishes a SASL security layer) commands. Capabilities may 307 change immediately after a successfully completed STARTTLS command, 308 and/or immediately after a successfully completed AUTHENTICATE 309 command, and/or after a successfully completed UNAUTHENTICATE command 310 (see Section 2.14.1). Capabilities MUST remain static at all other 311 times. 313 Clients MAY request the capabilities at a later time by issuing the 314 CAPABILITY command described later. The capabilities consist of a 315 series of lines each with one or two strings. The first string is 316 the name of the capability, which is case-insensitive. The second 317 optional string is the value associated with that capability. Order 318 of capabilities is arbitrary, but each capability name can appear at 319 most once. 321 The following capabilities are defined in this document: 323 IMPLEMENTATION - Name of implementation and version. This capability 324 MUST always be returned by the server. 326 SASL - List of SASL mechanisms supported by the server, each 327 separated by a space. This list can be empty if and only if STARTTLS 328 is also advertised. This means that the client must negotiate TLS 329 encryption with STARTTLS first, at which point the SASL capability 330 will list a non empty list of SASL mechanisms. 332 SIEVE - List of space separated Sieve extensions (as listed in Sieve 333 "require" action [SIEVE]) supported by the Sieve engine. This 334 capability MUST always be returned by the server. 336 STARTTLS - If TLS [TLS] is supported by this implementation. Before 337 advertising this capability a server MUST verify to the best of its 338 ability that TLS can be successfully negotiated by a client with 339 common cipher suites. Specifically, a server should verify that a 340 server certificate has been installed and that the TLS subsystem has 341 successfully initialized. This capability SHOULD NOT be advertised 342 once STARTTLS or AUTHENTICATE command completes successfully. 344 MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" 345 actions a script can perform during a single evaluation. Note, that 346 this is different from the total number of "redirect" actions a 347 script can contain. The value is a non-negative number represented 348 as a ManageSieve string. 350 NOTIFY - A space separated list of URI schema parts for supported 351 notification methods. This capability MUST be specified if the Sieve 352 implementation supports the "enotify" extension [NOTIFY]. 354 LANGUAGE - The language ( from [RFC4646]) currently 355 used for human readable error messages. If this capability is not 356 returned, the "i-default" [RFC2277] language is assumed. Note that 357 the current language MAY be per-user configurable (i.e. it MAY change 358 after authentication). 360 OWNER - The canonical name of the logged in user (SASL "authorization 361 identity") encoded in UTF-8. This capability MUST NOT be returned in 362 unauthenticated state and SHOULD be returned once the AUTHENTICATE 363 command succeeds. 365 VERSION - This capability MUST be returned by servers compliant with 366 this document or its successor. For servers compliant with this 367 document the capability value is the string "1.0". Lack of this 368 capability means that the server predates this specification and thus 369 doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT and 370 NOOP. 372 Section 2.14 defines some additional ManageSieve extensions and their 373 respective capabilities. 375 A server implementation MUST return SIEVE, IMPLEMENTATION and VERSION 376 capabilities. 378 A client implementation MUST ignore any listed capabilities that it 379 does not understand. 381 Example: 383 S: "IMPlemENTATION" "Example1 ManageSieved v001" 384 S: "SASl" "DIGEST-MD5 GSSAPI" 385 S: "SIeVE" "fileinto vacation" 386 S: "StaRTTLS" 387 S: "NOTIFY" "xmpp mailto" 388 S: "MAXREdIRECTS" "5" 389 S: "VERSION" "1.0" 390 S: OK 392 After successful authentication this might look like this: 394 Example: 396 S: "IMPlemENTATION" "Example1 ManageSieved v001" 397 S: "SASl" "DIGEST-MD5 GSSAPI" 398 S: "SIeVE" "fileinto vacation" 399 S: "NOTIFY" "xmpp mailto" 400 S: "OWNER" "alexey@example.com" 401 S: "MAXREdIRECTS" "5" 402 S: "VERSION" "1.0" 403 S: OK 405 1.8. Link Level 407 The ManageSieve protocol assumes a reliable data stream such as that 408 provided by TCP. When TCP is used, a ManageSieve server typically 409 listens on port 2000. [[anchor6: IANA registration of port 2000 is 410 pending.]] 412 Before opening the TCP connection, the ManageSieve client first MUST 413 resolve the Domain Name System (DNS) hostname associated with the 414 receiving entity and determine the appropriate TCP port for 415 communication with the receiving entity. The process is as follows: 417 1. Attempt to resolve the hostname using a [DNS-SRV] Service of 418 "sieve" and a Proto of "tcp" for the target domain (e.g. 419 "example.net"), resulting in resource records such as 420 "_sieve._tcp.example.net.". The result of the SRV lookup, if 421 successful, will be one or more combinations of a port and 422 hostname; the ManageSieve client MUST resolve the returned 423 hostnames to IPv4/IPv6 addresses according to returned SRV record 424 weight. IP addresses from the first successfully resolved 425 hostname (with the corresponding port number returned by SRV 426 lookup) are used to connect to the server. If connection using 427 one of the IP addresses fails, the next resolved IP address is 428 used to connect. If connection to all resolved IP addresses 429 fails, then the resolution/connect is repeated for the next 430 hostname returned by SRV lookup. 432 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or 433 IPv6 address record resolution to determine the IP address, where 434 the port used is the default ManageSieve port of 2000. 436 2. Commands 438 This section and its subsections describes valid ManageSieve 439 commands. Upon initial connection to the server the client's session 440 is in non-authenticated state. Prior to successful authentication 441 only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see 442 Section 2.13) commands are valid. ManageSieve extensions MAY define 443 other commands which are valid in non-authenticated state. Servers 444 MUST reject all other commands with a NO response. Clients may 445 pipeline commands (send more than one command at a time without 446 waiting for completion of the first command ). However, a group of 447 commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS 448 or a HAVESPACE command anywhere but the last command in the list. 450 (*) - The only exception to this rule is when the AUTHENTICATE 451 command contains an initial response for a SASL mechanism that allows 452 clients to send data first, the mechanism is known to complete in one 453 round-trip and the mechanism doesn't negotiate a SASL security layer. 454 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL 455 [SASL]. 457 2.1. AUTHENTICATE Command 459 Arguments: String - mechanism 460 String - initial data (optional) 462 The AUTHENTICATE command indicates a SASL [SASL] authentication 463 mechanism to the server. If the server supports the requested 464 authentication mechanism, it performs an authentication protocol 465 exchange to identify and authenticate the user. Optionally, it also 466 negotiates a security layer for subsequent protocol interactions. If 467 the requested authentication mechanism is not supported, the server 468 rejects the AUTHENTICATE command by sending the NO response. 470 The authentication protocol exchange consists of a series of server 471 challenges and client responses that are specific to the selected 472 authentication mechanism. A server challenge consists of a string 473 (quoted or literal) followed by a CRLF. The contents of the string 474 is a base-64 encoding [BASE64] of the SASL data. A client response 475 consists of a string (quoted or literal) with the base-64 encoding of 476 the SASL data followed by a CRLF. If the client wishes to cancel the 477 authentication exchange, it issues a string containing a single "*". 478 If the server receives such a response, it MUST reject the 479 AUTHENTICATE command by sending an NO reply. 481 Note that an empty challenge/response is sent as an empty string. If 482 the mechanism dictates that the final response is sent by the server 483 this data MAY be placed within the data portion of the SASL response 484 code to save a round trip. 486 The optional initial-response argument to the AUTHENTICATE command is 487 used to save a round trip when using authentication mechanisms that 488 are defined to send no data in the initial challenge. When the 489 initial-response argument is used with such a mechanism, the initial 490 empty challenge is not sent to the client and the server uses the 491 data in the initial-response argument as if it were sent in response 492 to the empty challenge. If the initial-response argument to the 493 AUTHENTICATE command is used with a mechanism that sends data in the 494 initial challenge, the server MUST reject the AUTHENTICATE command by 495 sending the NO response. 497 The service name specified by this protocol's profile of SASL is 498 "sieve". 500 Reauthentication is not supported by ManageSieve protocol's profile 501 of SASL. I.e. after a successfully completed AUTHENTICATE command, 502 no more AUTHENTICATE commands may be issued in the same session. 503 After a successful AUTHENTICATE command completes, a server MUST 504 reject any further AUTHENTICATE commands with a NO reply. However 505 note that a server may implement UNAUTHENTICATE extension described 506 in Section 2.14.1. 508 If a security layer is negotiated through the SASL authentication 509 exchange, it takes effect immediately following the CRLF that 510 concludes the successful authentication exchange for the client, and 511 the CRLF of the OK response for the server. 513 When a security layer takes effect, the ManageSieve protocol is reset 514 to the initial state (the state in ManageSieve after a client has 515 connected to the server). The server MUST discard any knowledge 516 obtained from the client which was not obtained from the SASL (or 517 TLS) negotiation itself. Likewise, the client MUST discard any 518 knowledge obtained from the server, such as the list of ManageSieve 519 extensions, which was not obtained from the SASL (or TLS) negotiation 520 itself. (Note that a client MAY compare the advertised SASL 521 mechanisms before and after authentication in order to detect an 522 active down-negotiation attack. See below.) 523 Once a SASL security layer is established, the server MUST re-issue 524 the capability results, followed by an OK response. This is 525 necessary to protect against man-in-the-middle attacks which alter 526 the capabilities list prior to SASL negotiation. The capability 527 results MUST include all SASL mechanisms the server was capable of 528 negotiating with that client. This is done in order to allow the 529 client to detect active down-negotiation attack. 531 When both [TLS] and SASL security layers are in effect, the TLS 532 encoding MUST be applied (when sending data) after the SASL encoding. 534 Server implementations SHOULD support SASL proxy authentication so 535 that an administrator can administer a user's scripts. Proxy 536 authentication is when a user authenticates as herself/himself but 537 requests the server to act (authorize) as another user. 539 The authorization identity generated by this [SASL] exchange is a 540 "simple username" (in the sense defined in [SASLprep]), and both 541 client and server MUST use the [SASLprep] profile of the [StringPrep] 542 algorithm to prepare these names for transmission or comparison. If 543 preparation of the authorization identity fails or results in an 544 empty string (unless it was transmitted as the empty string), the 545 server MUST fail the authentication. 547 If an AUTHENTICATE command fails with a NO response, the client MAY 548 try another authentication mechanism by issuing another AUTHENTICATE 549 command. In other words, the client may request authentication types 550 in decreasing order of preference. 552 Note that a failed (NO) response to the AUTHENTICATE command may 553 contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- 554 NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed 555 description of the relevant conditions. 557 To ensure interoperability, both client and server implementations of 558 the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM] 559 SASL mechanism, as well as [PLAIN] over [TLS]. 561 Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in 562 other email related protocols, however a longer term goal is to 563 migrate email related protocols from using PLAIN over TLS to SCRAM- 564 HMAC-SHA-1 mechanism. 566 Implementations MAY advertise the ANONYMOUS SASL mechanism 567 [SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE 568 script syntax verification. Only the CAPABILITY, PUTSCRIPT and 569 LOGOUT commands are available to the anonymous user. All other 570 commands defined in the base ManageSieve protocol MUST give NO 571 responses, however ManageSieve extensions MAY allow other commands in 572 the ANONYMOUS Sieve script verification mode. Furthermore the 573 PUTSCRIPT command MUST NOT persistently store any data. In this mode 574 a positive response to the PUTSCRIPT command indicates that the given 575 script does not have any syntax errors. 577 Examples (Note that long lines are folded for readability and are not 578 part of protocol exchange): 580 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 581 S: "SASL" "DIGEST-MD5 GSSAPI" 582 S: "SIEVE" "fileinto vacation" 583 S: "STARTTLS" 584 S: "VERSION" "1.0" 585 S: OK 586 C: Authenticate "DIGEST-MD5" 587 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 588 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 589 cyxjaGFyc2V0PXV0Zi04" 590 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 591 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 592 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 593 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 594 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 595 A9YXV0aA==" 596 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ 597 mZmZA==") 599 A slightly different variant of the same authentication exchange: 601 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 602 S: "SASL" "DIGEST-MD5 GSSAPI" 603 S: "SIEVE" "fileinto vacation" 604 S: "VERSION" "1.0" 605 S: "STARTTLS" 606 S: OK 607 C: Authenticate "DIGEST-MD5" 608 S: {136} 609 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik 610 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz 611 cyxjaGFyc2V0PXV0Zi04 612 C: {300+} 613 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 614 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo 615 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX 616 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy 617 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 618 A9YXV0aA== 619 S: {56} 620 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 621 C: "" 622 S: OK 624 Another example demonstrating use of SASL PLAIN mechanism under TLS. 625 This example also demonstrate use of SASL "initial response" (the 626 second parameter to the Authenticate command): 628 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 629 S: "VERSION" "1.0" 630 S: "SASL" "" 631 S: "SIEVE" "fileinto vacation" 632 S: "STARTTLS" 633 S: OK 634 C: STARTTLS 635 S: OK 636 637 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 638 S: "VERSION" "1.0" 639 S: "SASL" "PLAIN" 640 S: "SIEVE" "fileinto vacation" 641 S: OK 642 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" 643 S: NO 644 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" 645 S: NO 646 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" 647 S: BYE "Too many failed authentication attempts" 648 650 The following example demonstrates use of SASL "initial response". 651 It also demonstrates that an empty response can be sent as a literal, 652 and that negotiation a SASL security layer results in the server 653 reissuing server capabilities: 655 C: AUTHENTICATE "GSSAPI" {1488+} 656 C: YIIE[...1480 octets here ...]dA== 657 S: {208} 658 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic 659 [...114 octets here ...] 660 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 661 C: {0+} 662 C: 663 S: {44} 664 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= 665 C: {44+} 666 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= 667 S: OK 668 669 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 670 S: "VERSION" "1.0" 671 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 672 S: "SIEVE" "fileinto vacation" 673 S: "LANGUAGE" "ru" 674 S: "MAXREDIRECTS" "3" 675 S: ok 677 2.1.1. Use of SASL PLAIN mechanism over TLS 679 This section is normative for ManageSieve client implementations that 680 support SASL [PLAIN] over [TLS]. 682 If a ManageSieve client is willing to use SASL PLAIN over TLS to 683 authenticate to the ManageSieve server, the client MUST verify the 684 server identity (see Section 2.2.1). If the server identity can't be 685 verified (e.g. the server has not provided any certificate, or if the 686 certificate verification fails) the client MUST NOT attempt to 687 authenticate using the SASL PLAIN mechanism. 689 2.2. STARTTLS Command 691 Support for STARTTLS command in servers is optional. Its 692 availability is advertised with "STARTTLS" capability as described in 693 Section 1.7. 695 The STARTTLS command requests commencement of a TLS [TLS] 696 negotiation. The negotiation begins immediately after the CRLF in 697 the OK response. After a client issues a STARTTLS command, it MUST 698 NOT issue further commands until a server response is seen and the 699 TLS negotiation is complete. 701 The STARTTLS command is only valid in non-authenticated state. The 702 server remains in non-authenticated state, even if client credentials 703 are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL 704 mechanism MAY be used to authenticate once TLS client credentials are 705 successfully exchanged, but servers supporting the STARTTLS command 706 are not required to support the EXTERNAL mechanism. 708 After the TLS layer is established, the server MUST re-issue the 709 capability results, followed by an OK response. This is necessary to 710 protect against man-in-the-middle attacks which alter the 711 capabilities list prior to STARTTLS. This capability result MUST NOT 712 include the STARTTLS capability. 714 The client MUST discard cached capability information and replace it 715 with the new information. The server MAY advertise different 716 capabilities after STARTTLS. 718 Example: 720 C: StartTls 721 S: oK 722 723 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 724 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 725 S: "SIEVE" "fileinto vacation" 726 S: "VERSION" "1.0" 727 S: "LANGUAGE" "fr" 728 S: ok 730 2.2.1. Server Identity Check 732 During the TLS negotiation, the ManageSieve client MUST check its 733 understanding of the server hostname/IP address against the server's 734 identity as presented in the server Certificate message, in order to 735 prevent man-in-the-middle attacks. In this section, the client's 736 understanding of the server's identity is called the "reference 737 identity". 739 Checking is performed according to the following rules: 741 o If the reference identity is a hostname: 743 1. If a subjectAltName extension of the SRVName [X509-SRV], 744 dNSName [X509] (in that order of preference) type is present 745 in the server's certificate, then it SHOULD be used as the 746 source of the server's identity. Matching is performed as 747 described in Section 2.2.1.1, with the exception that no 748 wildcard matching is allowed for SRVName type. If the 749 certificate contains multiple names (e.g., more than one 750 dNSName field), then a match with any one of the fields is 751 considered acceptable. 753 2. The client MAY use other types of subjectAltName for 754 performing comparison. 756 3. The server's identity MAY also be verified by comparing the 757 reference identity to the Common Name (CN) [RFC4519] value in 758 the leaf Relative Distinguished Name (RDN) of the subjectName 759 field of the server's certificate. This comparison is 760 performed using the rules for comparison of DNS names in 761 Section 2.2.1.1, below, with the exception that no wildcard 762 matching is allowed. [[anchor8: Chris Newman says that such 763 prohibition of wildcards doesn't match existing practice.]] 764 Although the use of the Common Name value is existing 765 practice, it is deprecated, and Certification Authorities are 766 encouraged to provide subjectAltName values instead. Note 767 that the TLS implementation may represent DNs in certificates 768 according to X.500 or other conventions. For example, some 769 X.500 implementations order the RDNs in a DN using a left-to- 770 right (most significant to least significant) convention 771 instead of LDAP's right- to-left convention. 773 o When the reference identity is an IP address, the iPAddress 774 subjectAltName SHOULD be used by the client for comparison. The 775 comparison is performed as described in Section 2.2.1.2. 777 o In either case the client MAY map the reference identity to a 778 different type prior to performing a comparison. Mappings may be 779 performed for all available subjectAltName types to which the 780 reference identity can be mapped; however, the reference identity 781 should only be mapped to types for which the mapping is either 782 inherently secure (e.g., extracting the DNS hostname from a URI) 783 or for which the mapping is performed in a secure manner (e.g., 784 using DNSSEC, or using user- or admin-configured host-to-address/ 785 address-to-host lookup tables). 787 If the server identity check fails, user-oriented clients SHOULD 788 either notify the user (clients MAY give the user the opportunity to 789 continue with the ManageSieve session in this case) or close the 790 transport connection and indicate that the server's identity is 791 suspect. Automated clients SHOULD return or log an error indicating 792 that the server's identity is suspect and/or SHOULD close the 793 transport connection. Automated clients MAY provide a configuration 794 setting that disables this check, but MUST provide a setting which 795 enables it. 797 Beyond the server identity check described in this section, clients 798 should be prepared to do further checking to ensure that the server 799 is authorized to provide the service it is requested to provide. The 800 client may need to make use of local policy information in making 801 this determination. 803 2.2.1.1. Comparison of DNS Names 805 If the reference identity is an internationalized domain name, 806 conforming implementations MUST convert it to the ASCII Compatible 807 Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] 808 before comparison with subjectAltName values of type dNSName. 809 Specifically, conforming implementations MUST perform the conversion 810 operation specified in Section 4 of [RFC3490] as follows: 812 o in step 1, the domain name SHALL be considered a "stored string"; 814 o in step 3, set the flag called "UseSTD3ASCIIRules"; 816 o in step 4, process each label with the "ToASCII" operation; and 818 o in step 5, change all label separators to U+002E (full stop). 820 After performing the "to-ASCII" conversion, the DNS labels and names 821 MUST be compared for equality according to the rules specified in 822 Section 3 of [RFC3490], i.e. once all label separators are replaced 823 with U+002E (dot) they are compared in the case-insensitive manner. 825 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 826 values of type dNSName, and then only as the left-most (least 827 significant) DNS label in that value. This wildcard matches any 828 left-most DNS label in the server name. That is, the subject 829 *.example.com matches the server names a.example.com and 830 b.example.com, but does not match example.com or a.b.example.com. 832 2.2.1.2. Comparison of IP Addresses 834 When the reference identity is an IP address, the identity MUST be 835 converted to the "network byte order" octet string representation 836 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 837 octet string will contain exactly four octets. For IP Version 6, as 838 specified in RFC 2460, the octet string will contain exactly sixteen 839 octets. This octet string is then compared against subjectAltName 840 values of type iPAddress. A match occurs if the reference identity 841 octet string and value octet strings are identical. 843 2.2.1.3. Comparison of Other subjectName Types 845 Client implementations MAY support matching against subjectAltName 846 values of other types as described in other documents. 848 2.3. LOGOUT Command 850 The client sends the LOGOUT command when it is finished with a 851 connection and wishes to terminate it. The server MUST reply with an 852 OK response and terminate the connection. The server MUST ignore 853 commands issued by the client after the LOGOUT command. 855 Example: 857 C: Logout 858 S: Ok 859 861 2.4. CAPABILITY Command 863 The CAPABILITY command requests the server capabilities as described 864 earlier in this document. It has no parameters. 866 Example: 868 C: CAPABILITY 869 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 870 S: "VERSION" "1.0" 871 S: "SASL" "PLAIN OTP GSSAPI" 872 S: "SIEVE" "fileinto vacation" 873 S: "STARTTLS" 874 S: OK 876 2.5. HAVESPACE Command 878 Arguments: String - name 879 Number - script size 881 The HAVESPACE command is used to query the server for available 882 space. Clients specify the name they wish to save the script as and 883 its size in octets. Servers respond with an NO if storing a script 884 with that name and size would fail or OK otherwise. Clients SHOULD 885 issue this command before attempting to place a script on the server. 887 Note that the OK response from the HAVESPACE command does not 888 constitute a guarantee of success as server disk space conditions 889 could change between the client issuing the HAVESPACE and the client 890 issuing the PUTSCRIPT commands. A QUOTA response code (see 891 Section 1.3) remains a possible (albeit unlikely) response to a 892 subsequent PUTSCRIPT with the same name and size. 894 Example: 896 C: HAVESPACE "myscript" 999999 897 S: NO (QUOTA/MAXSIZE) "Quota exceeded" 899 C: HAVESPACE "foobar" 435 900 S: OK 902 2.6. PUTSCRIPT Command 904 Arguments: String - Script name 905 String - Script content 907 The PUTSCRIPT command is used by the client to submit a Sieve script 908 to the server. 910 If the script already exists, upon success the old script will be 911 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 912 fails in any way. A script of zero length SHOULD be disallowed. 914 This command places the script on the server. It does not affect 915 whether the script is processed on incoming mail, unless it replaces 916 the script which is already active. The SETACTIVE command is used to 917 mark a script as active. 919 When submitting large scripts clients SHOULD use the HAVESPACE 920 command beforehand to query if the server is willing to accept a 921 script of that size. 923 The server MUST check the submitted script for validity, which 924 includes checking that the script complies with the Sieve grammar 925 [SIEVE], that all Sieve extensions mentioned in script's "require" 926 statement(s) are supported by the Sieve interpreter. (Note that if 927 the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], 928 any unrecognized/unsupported extension mentioned in the "ihave" test 929 MUST NOT cause the validation failure.) Other checks such as 930 validating the supplied command arguments for each command MAY be 931 performed. Essentially, the performed validation SHOULD be the same 932 as performed when compiling the script for execution. 933 Implementations that use a binary representation to store compiled 934 scripts can extend the validation to a full compilation, in order to 935 avoid validating uploaded scripts multiple times. 937 If the script fails the validation the server MUST reply with a NO 938 response. Any script that fails the validity test MUST NOT be stored 939 on the server. The message given with a NO response MUST be human 940 readable and SHOULD contain a specific error message giving the line 941 number of the first error. Implementors should strive to produce 942 helpful error messages similar to those given by programming language 943 compilers. Client implementations should note that this may be a 944 multiline literal string with more than one error message separated 945 by CRLFs. The human readable message is in the language returned in 946 the latest LANGUAGE capability (or in "i-default", see Section 1.7), 947 encoded in UTF-8 [UTF-8]. 949 An OK response MAY contain the WARNINGS response code. In such case 950 the message that follows the OK response SHOULD contain a specific 951 warning message (or messages) giving the line number(s) in the script 952 that might contain errors not intended by the script writer. A 953 client seeing such response code SHOULD present the message to the 954 user. 956 Examples: 958 C: Putscript "foo" {31+} 959 C: #comment 960 C: InvalidSieveCommand 961 C: 962 S: NO "line 2: Syntax error" 964 C: Putscript "mysievescript" {110+} 965 C: require ["fileinto"]; 966 C: 967 C: if envelope :contains "to" "tmartin+sent" { 968 C: fileinto "INBOX.sent"; 969 C: } 970 S: OK 972 C: Putscript "myforwards" {190+} 973 C: redirect "111@example.net"; 974 C: 975 C: if size :under 10k { 976 C: redirect "mobile@cell.example.com"; 977 C: } 978 C: 979 C: if envelope :contains "to" "tmartin+lists" { 980 C: redirect "lists@groups.example.com"; 981 C: } 982 S: OK (WARNINGS) "line 8: server redirect action 983 limit is 2, this redirect might be ignored" 985 2.7. LISTSCRIPTS Command 987 This command lists the scripts the user has on the server. Upon 988 success a list of CRLF separated script names (each represented as a 989 quoted or literal string) is returned followed by an OK response. If 990 there exists an active script the atom ACTIVE is appended to the 991 corresponding script name. The atom ACTIVE MUST NOT appear on more 992 than one response line. 994 Example: 996 C: Listscripts 997 S: "summer_script" 998 S: "vacation_script" 999 S: {13} 1000 S: clever"script 1001 S: "main_script" ACTIVE 1002 S: OK 1004 C: listscripts 1005 S: "summer_script" 1006 S: "main_script" active 1007 S: OK 1009 2.8. SETACTIVE Command 1011 Arguments: String - script name 1013 This command sets a script active. If the script name is the empty 1014 string (i.e. "") then any active script is disabled. Disabling an 1015 active script when there is no script active is not an error and MUST 1016 result in OK reply. 1018 If the script does not exist on the server then the server MUST reply 1019 with a NO response. Such reply SHOULD contain the NONEXISTENT 1020 response code. 1022 Examples: 1024 C: Setactive "vacationscript" 1025 S: Ok 1027 C: Setactive "" 1028 S: Ok 1030 C: Setactive "baz" 1031 S: No (NONEXISTENT) "There is no script by that name" 1033 C: Setactive "baz" 1034 S: No (NONEXISTENT) {31} 1035 S: There is no script by that name 1037 2.9. GETSCRIPT Command 1039 Arguments: String - script name 1041 This command gets the contents of the specified script. If the 1042 script does not exist the server MUST reply with a NO response. Such 1043 reply SHOULD contain the NONEXISTENT response code. 1045 Upon success a string with the contents of the script is returned 1046 followed by a OK response. 1048 Example: 1050 C: Getscript "myscript" 1051 S: {54} 1052 S: #this is my wonderful script 1053 S: reject "I reject all"; 1054 S: 1055 S: OK 1057 2.10. DELETESCRIPT Command 1059 Arguments: String - script name 1061 This command is used to delete a user's Sieve script. Servers MUST 1062 reply with a NO response if the script does not exist. Such 1063 responses SHOULD include the NONEXISTENT response code. 1065 The server MUST NOT allow the client to delete an active script, so 1066 the server MUST reply with a NO response if attempted. Such response 1067 SHOULD contain the ACTIVE response code. If a client wishes to 1068 delete an active script it should use the SETACTIVE command to 1069 disable the script first. 1071 Example: 1073 C: Deletescript "foo" 1074 S: Ok 1076 C: Deletescript "baz" 1077 S: No (ACTIVE) "You may not delete an active script" 1079 2.11. RENAMESCRIPT Command 1081 Arguments: String - Old Script name 1082 String - New Script name 1084 This command is used to rename a user's Sieve script. Servers MUST 1085 reply with a NO response if the old script does not exist (in which 1086 case the NONEXISTENT response code SHOULD be included), or a script 1087 with the new name already exists (in which case the ALREADYEXISTS 1088 response code SHOULD be included). Renaming the active script is 1089 allowed, the renamed script remains active. 1091 Example: 1093 C: Renamescript "foo" "bar" 1094 S: Ok 1096 C: Renamescript "baz" "bar" 1097 S: No "bar already exists" 1099 If the server doesn't support the RENAMESCRIPT command, the client 1100 can emulate it by performing the following steps: 1102 1. List available scripts with LISTSCRIPTS. If the script with the 1103 new script name exists, then the client should ask the user 1104 whether to abort the operation, to replace the script (by issuing 1105 the DELETESCRIPT after that) or to chose a different 1106 name. 1108 2. Download the old script with GETSCRIPT . 1110 3. Upload the old script with the new name: PUTSCRIPT . 1112 4. If the old script was active (as reported by LISTSCRIPTS in step 1113 1), then make the new script active: SETACTIVE 1115 5. Delete the old script: DELETESCRIPT 1117 Note that these steps don't describe how to handle various other 1118 error conditions (for example NO response containing QUOTA response 1119 code in step 3). Error handling is left as an excercise for the 1120 reader. 1122 2.12. CHECKSCRIPT Command 1124 Arguments: String - Script content 1126 The CHECKSCRIPT command is used by the client to verify Sieve script 1127 validity without storing the script on the server. 1129 The server MUST check the submitted script for syntactic validity, 1130 which includes checking that all Sieve extensions mentioned in Sieve 1131 script "require" statement(s) are supported by the Sieve interpreter. 1132 (Note that if the Sieve interpreter supports the Sieve "ihave" 1133 extension [I-HAVE], any unrecognized/unsupported extension mentioned 1134 in the "ihave" test MUST NOT cause the syntactic validation failure.) 1135 If the script fails this test the server MUST reply with a NO 1136 response. The message given with a NO response MUST be human 1137 readable and SHOULD contain a specific error message giving the line 1138 number of the first error. Implementors should strive to produce 1139 helpful error messages similar to those given by programming language 1140 compilers. Client implementations should note that this may be a 1141 multiline literal string with more than one error message separated 1142 by CRLFs. The human readable message is in the language returned in 1143 the latest LANGUAGE capability (or in "i-default", see Section 1.7), 1144 encoded in UTF-8 [UTF-8]. 1146 Examples: 1148 C: CheckScript {31+} 1149 C: #comment 1150 C: InvalidSieveCommand 1151 C: 1152 S: NO "line 2: Syntax error" 1154 A ManageSieve server supporting this command MUST NOT check if the 1155 script will put the current user over its quota limit. 1157 An OK response MAY contain the WARNINGS response code. In such case 1158 the message that follows the OK response SHOULD contain a specific 1159 warning message (or messages) giving the line number(s) in the script 1160 that might contain errors not intended by the script writer. A 1161 client seeing such response code SHOULD present the message to the 1162 user. 1164 The CHECKSCRIPT command is available in the ANONYMOUS Sieve script 1165 verification mode. 1167 2.13. NOOP Command 1169 Arguments: String - tag to echo back (optional) 1171 The NOOP command does nothing, beyond returning a response to the 1172 client. It may be used by clients for protocol re-synchronisation or 1173 to reset any inactivity auto-logout timer on the server. 1175 The NOOP command is available in the ANONYMOUS Sieve script 1176 verification mode. 1178 The response to the NOOP command is always OK, followed by the TAG 1179 response code together with the supplied string; if no string was 1180 supplied in the NOOP command, the TAG response code MUST NOT be 1181 included. 1183 Examples: 1185 C: NOOP 1186 S: OK "NOOP completed" 1188 C: NOOP "STARTTLS-SYNC-42" 1189 S: OK (TAG {16} 1190 S: STARTTLS-SYNC-42) "Done" 1192 2.14. Recommended extensions 1194 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" 1195 capability with no parameters) defines a new UNAUTHENTICATE command, 1196 which allows a client to return the server to non-authenticated 1197 state. Support for this extension is RECOMMENDED. 1199 2.14.1. UNAUTHENTICATE Command 1201 The UNAUTHENTICATE command returns the server to the non- 1202 authenticated state. It doesn't affect any previously established 1203 TLS [TLS] or SASL (Section 2.1) security layer. 1205 The UNAUTHENTICATE command is only valid in authenticated state. If 1206 issued in a wrong state, the server MUST reject it with a NO 1207 response. 1209 The UNAUTHENTICATE command has no parameters. 1211 When issued in the authenticated state, the UNAUTHENTICATE command 1212 MUST NOT fail (i.e. it must never return anything other than OK or 1213 BYE) 1215 3. Sieve URL Scheme 1217 URI scheme name: sieve 1219 Status: permanent 1221 URI scheme syntax: 1223 Described using ABNF [ABNF] and ABNF entities from [URI-GEN]. 1225 sieveurl = sieveurl-server / sieveurl-list-scripts / 1226 sieveurl-script 1228 sieveurl-server = "sieve://" authority 1230 sieveurl-list-scripts = "sieve://" authority ["/"] 1232 sieveurl-script = "sieve://" authority "/" 1233 [owner "/"] scriptname 1235 sub-delims-sh = "!" / "$" / "'" / "(" / ")" / 1236 "*" / "+" / "," 1237 ;; Same as [URI-GEN] sub-delims, 1238 ;; but without ";", "&" and "=". 1240 uchar = unreserved / pct-encoded / sub-delims-sh 1241 ;; Same as [URI-GEN] 1242 ;; 'unreserved / pct-encoded / sub-delims', 1243 ;; but without ";", "&" and "=". 1245 ochar = uchar / ":" / "@" 1246 ;; Same as [URI-GEN] 'pchar' 1247 ;; but without ";", "&" and "=". 1249 owner = *ochar 1250 ;; %-encoded version of [IMAP4] authorization 1251 ;; identity (owner) or "userid". 1252 ;; 1253 ;; Empty owner is used to reference 1254 ;; global scripts. 1255 ;; 1256 ;; Note that ASCII characters such as " ", ";", 1257 ;; "&", "=", "/" and "?" MUST be %-encoded. 1259 scriptname = 1*ochar 1260 ;; %-encoded version of UTF-8 representation 1261 ;; of the script name. 1262 ;; Note that ASCII characters such as " ", ";", 1263 ;; "&", "=", "/" and "?" MUST be %-encoded. 1265 URI scheme semantics: 1267 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve 1268 server. The latter form is associated with the application/sieve 1269 MIME type defined in [SIEVE]. There is no MIME type associated 1270 with the former form of Sieve URI. 1272 The server form is used in the REFERRAL response code in order to 1273 designate another server where the client should perform its 1274 operations. 1276 The script form allows to retrieve (GETSCRIPT), update 1277 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the 1278 named script, however the most typical action would be to retrieve 1279 the script. If the script name is empty (omitted), the URI 1280 requests that the client lists available scripts using the 1281 LISTSCRIPTS command. 1283 Encoding considerations: The script name or the owner, if present, is 1284 in UTF-8. Non-US-ASCII UTF-8 octets MUST be percent-encoded as 1285 described in [URI-GEN]. US-ASCII characters such as " " (space), 1286 ";", "&", "=", "/" and "?" MUST be %-encoded as described in 1287 [URI-GEN]. 1289 The user name (in the "authority" part), if present, is in UTF-8. 1290 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1291 [URI-GEN]. 1293 Applications/protocols that use this URI scheme name: 1294 ManageSieve [RFC XXXX] clients and servers. Clients that can store 1295 user preferences in protocols such as [LDAP] or [ACAP]. 1297 Interoperability considerations: None. 1299 Security considerations: 1300 The part of a ManageSieve URL might potentially disclose 1301 some confidential information about the author of the script or, 1302 depending on a ManageSieve implementation, about configuration of the 1303 mail system. The latter might be used to prepare for a more complex 1304 attack on the mail system. 1306 Clients resolving ManageSieve URLs that wish to achieve data 1307 confidentiality and/or integrity SHOULD use the STARTTLS command (if 1308 supported by the server) before starting authentication, or use a 1309 SASL mechanism, such as GSSAPI, that provides a confidentiality 1310 security layer. 1312 Contact: Alexey Melnikov 1314 Author/Change controller: IESG. 1316 References: This document and RFC 5228 [SIEVE]. 1318 4. Formal Syntax 1320 The following syntax specification uses the augmented Backus-Naur 1321 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 1322 rules as specified in Appendix A of the ABNF specification [ABNF]. 1323 "UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8]. 1325 Except as noted otherwise, all alphabetic characters are case- 1326 insensitive. The use of upper or lower case characters to define 1327 token strings is for editorial clarity only. Implementations MUST 1328 accept these strings in a case-insensitive fashion. 1330 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 1331 %x5D-7F 1332 ;; any TEXT-CHAR except QUOTED-SPECIALS 1334 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 1336 QUOTED-SPECIALS = DQUOTE / "\" 1338 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 1339 ;; , and 1340 ;; are defined in [UTF-8] 1342 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E 1343 ;; Any CHAR except ATOM-SPECIALS 1345 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / 1346 QUOTED-SPECIALS 1348 QUOTED-SPECIALS = <"> / "\" 1350 atom = 1*1024ATOM-CHAR 1352 iana-token = atom 1353 ;; MUST be registered with IANA 1355 auth-type = DQUOTE auth-type-name DQUOTE 1357 auth-type-name = iana-token 1358 ;; as defined in SASL [SASL] 1360 command = (command-any / command-auth / 1361 command-nonauth) CRLF 1362 ;; Modal based on state 1364 command-any = command-capability / command-logout / 1365 command-noop 1366 ;; Valid in all states 1368 command-auth = command-getscript / command-setactive / 1369 command-listscripts / command-deletescript / 1370 command-putscript / command-checkscript / 1371 command-havespace / / 1372 command-renamescript / 1373 command-unauthenticate 1374 ;; Valid only in Authenticated state 1376 command-nonauth = command-authenticate / command-starttls 1377 ;; Valid only when in Non-Authenticated 1378 ;; state 1380 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 1381 *(CRLF string) 1383 command-capability = "CAPABILITY" 1385 command-deletescript = "DELETESCRIPT" SP sieve-name 1387 command-getscript = "GETSCRIPT" SP sieve-name 1389 command-havespace = "HAVESPACE" SP sieve-name SP number 1391 command-listscripts = "LISTSCRIPTS" 1393 command-noop = "NOOP" [SP string] 1395 command-logout = "LOGOUT" 1397 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script 1399 command-checkscript = "CHECKSCRIPT" SP sieve-script 1401 sieve-script = string 1403 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP 1404 new-sieve-name 1406 old-sieve-name = sieve-name 1407 new-sieve-name = sieve-name 1409 command-setactive = "SETACTIVE" SP active-sieve-name 1411 command-starttls = "STARTTLS" 1413 command-unauthenticate= "UNAUTHENTICATE" 1415 extend-token = atom 1416 ;; MUST be defined by a standards track or 1417 ;; IESG approved experimental protocol 1418 ;; extension 1420 extension-data = extension-item *(SP extension-item) 1422 extension-item = extend-token / string / number / 1423 "(" [extension-data] ")" 1425 literal-c2s = "{" number "+}" CRLF *OCTET 1426 ;; The number represents the number of 1427 ;; octets. 1428 ;; This type of literal can only be sent 1429 ;; from the client to the server. 1431 literal-s2c = "{" number "}" CRLF *OCTET 1432 ;; Almost identical to literal-c2s, 1433 ;; but with no '+' character. 1434 ;; The number represents the number of 1435 ;; octets. 1436 ;; This type of literal can only be sent 1437 ;; from the server to the client. 1439 number = 1*DIGIT 1440 ;; A 32-bit unsigned number. 1441 ;; (0 <= n < 4,294,967,296) 1443 number-str = string 1444 ;; encoded as a . 1446 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1447 ;; limited to 1024 octets between the <">s 1449 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1450 "QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] / 1451 resp-code-sasl / 1452 resp-code-referral / 1453 "TRANSITION-NEEDED" / "TRYLATER" / 1454 "ACTIVE" / "NONEXISTENT" / 1455 "ALREADYEXISTS" / "WARNINGS" / 1456 "TAG" SP string / 1457 resp-code-ext 1459 resp-code-referral = "REFERRAL" SP sieveurl 1461 resp-code-sasl = "SASL" SP string 1463 resp-code-name = iana-token 1464 ;; The response code name is hierarchical, 1465 ;; separated by '/'. 1466 ;; The response code name MUST NOT start 1467 ;; with '/'. 1469 resp-code-ext = resp-code-name [SP extension-data] 1470 ;; unknown response codes MUST be tolerated 1471 ;; by the client. 1473 response = response-authenticate / 1474 response-logout / 1475 response-getscript / 1476 response-setactive / 1477 response-listscripts / 1478 response-deletescript / 1479 response-putscript / 1480 response-checkscript / 1481 response-capability / 1482 response-havespace / 1483 response-starttls / 1484 response-renamescript / 1485 response-noop / 1486 response-unauthenticate 1488 response-authenticate = *(string CRLF) 1489 ((response-ok [response-capability]) / 1490 response-nobye) 1491 ;; is REQUIRED if a 1492 ;; SASL security layer was negotiated and 1493 ;; MUST be omitted otherwise. 1495 response-capability = *(single-capability) response-oknobye 1497 single-capability = capability-name [SP string] CRLF 1499 capability-name = string 1500 ;; Note that literal-s2c is allowed. 1502 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1503 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1504 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1505 DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / 1506 DQUOTE "NOTIFY" DQUOTE SP notify-mechs / 1507 DQUOTE "STARTTLS" DQUOTE / 1508 DQUOTE "LANGUAGE" DQUOTE SP language / 1509 DQUOTE "VERSION" DQUOTE SP version / 1510 DQUOTE "OWNER" DQUOTE SP string 1511 ;; Each capability conforms to 1512 ;; the syntax for single-capability. 1513 ;; Also note that the capability name 1514 ;; can be returned as either literal-s2c 1515 ;; or quoted, even though only "quoted" 1516 ;; string is shown above. 1517 version = DQUOTE "1.0" DQUOTE 1519 sasl-mechs = string 1520 ; space separated list of SASL mechanisms, 1521 ; each SASL mechanism name complies with rules 1522 ; specified in [SASL]. 1523 ; Can be empty. 1525 sieve-extensions = string 1526 ; space separated list of supported SIEVE extensions, 1527 ; can be empty. 1529 language = string 1530 ; Contains from [RFC4646]. 1532 notify-mechs = string 1533 ; space separated list of URI schema parts 1534 ; for supported notification [NOTIFY] methods. 1535 ; MUST NOT be empty. 1537 response-deletescript = response-oknobye 1539 response-getscript = (sieve-script CRLF response-ok) / 1540 response-nobye 1542 response-havespace = response-oknobye 1544 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1545 response-oknobye 1546 ;; ACTIVE may only occur with one sieve-name 1548 response-logout = response-oknobye 1550 response-unauthenticate= response-oknobye 1551 ;; "NO" response can only be returned when 1552 ;; the command is issued in a wrong state 1553 ;; or has a wrong number of parameters 1555 response-ok = "OK" [SP "(" resp-code ")"] 1556 [SP string] CRLF 1557 ;; The string contains human readable text 1558 ;; encoded as UTF-8. 1560 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1561 [SP string] CRLF 1562 ;; The string contains human readable text 1563 ;; encoded as UTF-8. 1565 response-oknobye = response-ok / response-nobye 1567 response-noop = response-ok 1569 response-putscript = response-oknobye 1571 response-checkscript = response-oknobye 1573 response-renamescript = response-oknobye 1575 response-setactive = response-oknobye 1577 response-starttls = (response-ok response-capability) / 1578 response-nobye 1580 sieve-name = string 1581 ;; See Section 1.6 for the full list of 1582 ;; prohibited characters. 1583 ;; Empty string is not allowed. 1585 active-sieve-name = string 1586 ;; See Section 1.6 for the full list of 1587 ;; prohibited characters. 1588 ;; This is similar to , but 1589 ;; empty string is allowed and has a special 1590 ;; meaning. 1592 string = quoted / literal-c2s / literal-s2c 1593 ;; literal-c2s is only allowed when sent 1594 ;; from the client to the server. 1595 ;; literal-s2c is only allowed when sent 1596 ;; from the server to the client. 1597 ;; quoted is allowed in either direction. 1599 5. Security Considerations 1601 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1602 and authorization services. Integrity and privacy services can be 1603 provided by [SASL] and/or [TLS]. When a SASL mechanism is used the 1604 security considerations for that mechanism apply. 1606 This protocol's transactions are susceptible to passive observers or 1607 man in the middle attacks which alter the data, unless the optional 1608 encryption and integrity services of the SASL (via the AUTHENTICATE 1609 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1610 external security mechanism is used for protection. It may be useful 1611 to allow configuration of both clients and servers to refuse to 1612 transfer sensitive information in the absence of strong encryption. 1614 If an implementation supports SASL mechanisms that are vulnerable to 1615 passive eavesdropping attacks (such as [PLAIN]), then the 1616 implementation MUST support at least one configuration where these 1617 SASL mechanisms are not advertised or used without the presence of an 1618 external security layer such as [TLS]. 1620 Some response codes returned on failed AUTHENTICATE command may 1621 disclose whether or not the username is valid, so server 1622 implementations SHOULD provide the ability to disable these features 1623 (or make them not conditional on a per-user basis) for sites 1624 concerned about such disclosure. In the case of ENCRYPT-NEEDED, if 1625 it is applied to all identities then no extra information is 1626 disclosed, but if it is applied on a per-user basis it can disclose 1627 information. 1629 6. IANA Considerations 1631 IANA is requested to reserve TCP port number 2000 for use with the 1632 ManageSieve protocol described in this document. 1634 IANA is requested to register the "sieve" URI scheme defined in 1635 Section 3 of this document. 1637 IANA is requested to create a new registry for ManageSieve 1638 capabilities. The registration template for ManageSieve capabilities 1639 is specified in Section 6.1. ManageSieve protocol capabilities MUST 1640 be specified in a standards track or IESG approved experimental RFC. 1642 IANA is requested to create a new registry for ManageSieve response 1643 codes. The registration template for ManageSieve response codes is 1644 specified in Section 6.3. ManageSieve protocol response codes MUST 1645 be specified in a standards track or IESG approved experimental RFC. 1647 6.1. ManageSieve Capability Registration Template 1649 To: iana@iana.org 1650 Subject: ManageSieve Capability Registration 1651 Please register the following ManageSieve Capability: 1652 Capability name: 1653 Description: 1654 Relevant publications: 1655 Person & email address to contact for further information: 1656 Author/Change controller: 1658 6.2. Registration of Initial ManageSieve capabilities 1660 To: iana@iana.org 1661 Subject: ManageSieve Capability Registration 1662 Please register the following ManageSieve Capabilities: 1664 Capability name: IMPLEMENTATION 1666 Description: Its value contains name of server implementation and 1667 its version. 1669 Relevant publications: this RFC, Section 1.7. 1671 Person & email address to contact for further information: Alexey 1672 Melnikov 1674 Author/Change controller: IESG. 1676 Capability name: SASL 1678 Description: Its value contains a space separated list of SASL 1679 mechanisms supported by server. 1681 Relevant publications: this RFC, Section 1.7 and Section 2.1. 1683 Person & email address to contact for further information: Alexey 1684 Melnikov 1686 Author/Change controller: IESG. 1688 Capability name: SIEVE 1690 Description: Its value contains a space separated list of 1691 supported SIEVE extensions 1693 Relevant publications: this RFC, Section 1.7. Also [SIEVE]. 1695 Person & email address to contact for further information: Alexey 1696 Melnikov 1698 Author/Change controller: IESG. 1700 Capability name: STARTTLS 1702 Description: This capability is returned if server supports TLS 1703 (STARTTLS command). 1705 Relevant publications: this RFC, Section 1.7 and Section 2.2. 1707 Person & email address to contact for further information: Alexey 1708 Melnikov 1710 Author/Change controller: IESG. 1712 Capability name: NOTIFY 1714 Description: This capability is returned if server supports 1715 'enotify' [NOTIFY] Sieve extension. 1717 Relevant publications: this RFC, Section 1.7. 1719 Person & email address to contact for further information: Alexey 1720 Melnikov 1722 Author/Change controller: IESG. 1724 Capability name: OWNER 1726 Description: Its value contains UTF-8 encoded name of the 1727 currently logged in user ("authorization identity" according to 1728 RFC 4422). 1730 Relevant publications: this RFC, Section 1.7. 1732 Person & email address to contact for further information: Alexey 1733 Melnikov 1735 Author/Change controller: IESG. 1737 Capability name: VERSION 1739 Description: This capability is returned if the server is 1740 compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT, 1741 CHECKSCRIPT and NOOP commands. 1743 Relevant publications: this RFC, Section 2.11. 1745 Person & email address to contact for further information: Alexey 1746 Melnikov 1748 Author/Change controller: IESG. 1750 6.3. ManageSieve Response Code Registration Template 1752 To: iana@iana.org 1753 Subject: ManageSieve Response Code Registration 1754 Please register the following ManageSieve Response Code: 1756 Response Code: 1758 Arguments (use ABNF to specify syntax, or the word NONE if none 1759 can be specified): 1761 Purpose: 1763 Published Specification(s): 1765 Person & email address to contact for further information: 1767 Author/Change controller: 1769 6.4. Registration of Initial ManageSieve Response Codes 1771 To: iana@iana.org 1772 Subject: ManageSieve Response Code Registration 1773 Please register the following ManageSieve Response Codes: 1775 Response Code: AUTH-TOO-WEAK 1777 Arguments (use ABNF to specify syntax, or the word NONE if none 1778 can be specified): NONE 1780 Purpose: This response code is returned in the NO response from an 1781 AUTHENTICATE command. It indicates that site security policy 1782 forbids the use of the requested mechanism for the specified 1783 authentication identity. 1785 Published Specification(s): [RFCXXXX] 1787 Person & email address to contact for further information: Alexey 1788 Melnikov 1789 Author/Change controller: IESG. 1791 Response Code: ENCRYPT-NEEDED 1793 Arguments (use ABNF to specify syntax, or the word NONE if none 1794 can be specified): NONE 1796 Purpose: This response code is returned in the NO response from an 1797 AUTHENTICATE command. It indicates that site security policy 1798 requires the use of a strong encryption mechanism for the 1799 specified authentication identity and mechanism. 1801 Published Specification(s): [RFCXXXX] 1803 Person & email address to contact for further information: Alexey 1804 Melnikov 1806 Author/Change controller: IESG. 1808 Response Code: QUOTA 1810 Arguments (use ABNF to specify syntax, or the word NONE if none 1811 can be specified): NONE 1813 Purpose: If this response code is returned in the NO/BYE response, 1814 it means that the command would have placed the user above the 1815 site-defined quota constraints. If this response code is returned 1816 in the OK response, it can mean that the user is near its quota or 1817 that the user exceeded its quota, but the server supports soft 1818 quotas. 1820 Published Specification(s): [RFCXXXX] 1822 Person & email address to contact for further information: Alexey 1823 Melnikov 1825 Author/Change controller: IESG. 1827 Response Code: QUOTA/MAXSCRIPTS 1829 Arguments (use ABNF to specify syntax, or the word NONE if none 1830 can be specified): NONE 1832 Purpose: If this response code is returned in the NO/BYE response, 1833 it means that the command would have placed the user above the 1834 site-defined limit on the number of Sieve scripts. If this 1835 response code is returned in the OK response, it can mean that the 1836 user is near its quota or that the user exceeded its quota, but 1837 the server supports soft quotas. This response code is a more 1838 specific version of the QUOTA response code. 1840 Published Specification(s): [RFCXXXX] 1842 Person & email address to contact for further information: Alexey 1843 Melnikov 1845 Author/Change controller: IESG. 1847 Response Code: QUOTA/MAXSIZE 1849 Arguments (use ABNF to specify syntax, or the word NONE if none 1850 can be specified): NONE 1852 Purpose: If this response code is returned in the NO/BYE response, 1853 it means that the command would have placed the user above the 1854 site-defined maximum script size. If this response code is 1855 returned in the OK response, it can mean that the user is near its 1856 quota or that the user exceeded its quota, but the server supports 1857 soft quotas. This response code is a more specific version of the 1858 QUOTA response code. 1860 Published Specification(s): [RFCXXXX] 1862 Person & email address to contact for further information: Alexey 1863 Melnikov 1865 Author/Change controller: IESG. 1867 Response Code: REFERRAL 1869 Arguments (use ABNF to specify syntax, or the word NONE if none 1870 can be specified): 1872 Purpose: This response code may be returned with a BYE result from 1873 any command, and includes a mandatory parameter that indicates 1874 what server to access to manage this user's sieve scripts. The 1875 server will be specified by a Sieve URL (see Section 3). The 1876 scriptname portion of the URL MUST NOT be specified. The client 1877 should authenticate to the specified server and use it for all 1878 further commands in the current session. 1880 Published Specification(s): [RFCXXXX] 1882 Person & email address to contact for further information: Alexey 1883 Melnikov 1884 Author/Change controller: IESG. 1886 Response Code: SASL 1888 Arguments (use ABNF to specify syntax, or the word NONE if none 1889 can be specified): 1891 Purpose: This response code can occur in the OK response to a 1892 successful AUTHENTICATE command and includes the optional final 1893 server response data from the server as specified by [SASL]. 1895 Published Specification(s): [RFCXXXX] 1897 Person & email address to contact for further information: Alexey 1898 Melnikov 1900 Author/Change controller: IESG. 1902 Response Code: TRANSITION-NEEDED 1904 Arguments (use ABNF to specify syntax, or the word NONE if none 1905 can be specified): NONE 1907 Purpose: This response code occurs in a NO response of an 1908 AUTHENTICATE command. It indicates that the user name is valid, 1909 but the entry in the authentication database needs to be updated 1910 in order to permit authentication with the specified mechanism. 1911 This is typically done by establishing a secure channel using TLS, 1912 followed by authenticating once using the [PLAIN] authentication 1913 mechanism. The selected mechanism SHOULD then work for 1914 authentications in subsequent sessions. 1916 Published Specification(s): [RFCXXXX] 1918 Person & email address to contact for further information: Alexey 1919 Melnikov 1921 Author/Change controller: IESG. 1923 Response Code: TRYLATER 1925 Arguments (use ABNF to specify syntax, or the word NONE if none 1926 can be specified): NONE 1928 Purpose: A command failed due to a temporary server failure. The 1929 client MAY continue using local information and try the command 1930 later. This response code only make sense when returned in a NO/ 1931 BYE response. 1933 Published Specification(s): [RFCXXXX] 1935 Person & email address to contact for further information: Alexey 1936 Melnikov 1938 Author/Change controller: IESG. 1940 Response Code: ACTIVE 1942 Arguments (use ABNF to specify syntax, or the word NONE if none 1943 can be specified): NONE 1945 Purpose: A command failed because it is not allowed on the active 1946 script. For example DELETESCRIPT on the active script. This 1947 response code only makes sense when returned in a NO/BYE response. 1949 Published Specification(s): [RFCXXXX] 1951 Person & email address to contact for further information: Alexey 1952 Melnikov 1954 Author/Change controller: IESG. 1956 Response Code: NONEXISTENT 1958 Arguments (use ABNF to specify syntax, or the word NONE if none 1959 can be specified): NONE 1961 Purpose: A command failed because the referenced script name 1962 doesn't exist. This response code only makes sense when returned 1963 in a NO/BYE response. 1965 Published Specification(s): [RFCXXXX] 1967 Person & email address to contact for further information: Alexey 1968 Melnikov 1970 Author/Change controller: IESG. 1972 Response Code: ALREADYEXISTS 1974 Arguments (use ABNF to specify syntax, or the word NONE if none 1975 can be specified): NONE 1977 Purpose: A command failed because the referenced script name 1978 already exists. This response code only makes sense when returned 1979 in a NO/BYE response. 1981 Published Specification(s): [RFCXXXX] 1983 Person & email address to contact for further information: Alexey 1984 Melnikov 1986 Author/Change controller: IESG. 1988 Response Code: WARNINGS 1990 Arguments (use ABNF to specify syntax, or the word NONE if none 1991 can be specified): NONE 1993 Purpose: This response code MAY be returned by the server in the 1994 OK response (but it might be returned with the NO/BYE response as 1995 well) and signals the client that even though the script is 1996 syntactically valid, it might contain errors not intended by the 1997 script writer. 1999 Published Specification(s): [RFCXXXX] 2001 Person & email address to contact for further information: Alexey 2002 Melnikov 2004 Author/Change controller: IESG. 2006 Response Code: TAG 2008 Arguments (use ABNF to specify syntax, or the word NONE if none 2009 can be specified): string 2011 Purpose: This response code name is followed by a string specified 2012 in the command that caused this response. It is typically used 2013 for client state synchronization. 2015 Published Specification(s): [RFCXXXX] 2017 Person & email address to contact for further information: Alexey 2018 Melnikov 2020 Author/Change controller: IESG. 2022 7. Acknowledgements 2024 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 2025 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, 2026 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil 2027 Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan 2028 Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin and 2029 Patrick Ben Koetter for help with this document. Special thank you 2030 to Phil Pennock for providing text for the NOOP command, as well as 2031 finding various bugs in the document. 2033 8. References 2035 8.1. Normative References 2037 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2038 Specifications: ABNF", RFC 5234, January 2008. 2040 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 2041 Configuration Access Protocol", RFC 2244, November 1997. 2043 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 2044 Encodings", RFC 4648, October 2006. 2046 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2047 specifying the location of services (DNS SRV)", RFC 2782, 2048 February 2000. 2050 [KEYWORDS] 2051 Bradner, S., "Key words for use in RFCs to Indicate 2052 Requirement Levels", RFC 2119, March 1997. 2054 [NET-UNICODE] 2055 Klensin, J. and M. Padlipsky, "Unicode Format for Network 2056 Interchange", RFC 5198, March 2008. 2058 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 2059 Martin, "Sieve Extension: Notifications", 2060 draft-ietf-sieve-notify-12 (work in progress), 2061 December 2007. 2063 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 2064 Languages", RFC 2277, January 1998. 2066 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2067 (IPv6) Specification", RFC 2460, December 1998. 2069 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 2070 "Internationalizing Domain Names in Applications (IDNA)", 2071 RFC 3490, March 2003. 2073 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 2074 (LDAP): Schema for User Applications", RFC 4519, 2075 June 2006. 2077 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 2078 Languages", RFC 4646, September 2006. 2080 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 2082 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2083 Security Layer (SASL)", RFC 4422, June 2006. 2085 [SASL-ANON] 2086 Zeilenga, K., "Anonymous Simple Authentication and 2087 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 2089 [SASLprep] 2090 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 2091 and Passwords", RFC 4013, February 2005. 2093 [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge 2094 Response Authentication Mechanism (SCRAM)", 2095 draft-newman-auth-scram-07.txt (work in progress), 2096 November 2008. 2098 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 2099 Filtering Language", RFC 5228, January 2008. 2101 [StringPrep] 2102 Hoffman, P. and M. Blanchet, "Preparation of 2103 Internationalized Strings ("stringprep")", RFC 3454, 2104 December 2002. 2106 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2107 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 2109 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2110 Resource Identifier (URI): Generic Syntax", STD 66, 2111 RFC 3986, January 2005. 2113 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 2114 10646", STD 63, RFC 3629, November 2003. 2116 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2117 X.509 Public Key Infrastructure Certificate and 2118 Certificate Revocation List (CRL) Profile", RFC 3280, 2119 April 2002. 2121 [X509-SRV] 2122 Santesson, S., "Internet X.509 Public Key Infrastructure 2123 Subject Alternative Name for Expression of Service Name", 2124 RFC 4985, August 2007. 2126 8.2. Informative References 2128 [DIGEST-MD5] 2129 Leach, P. and C. Newman, "Using Digest Authentication as a 2130 SASL Mechanism", RFC 2831, May 2000. 2132 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", 2133 draft-freed-sieve-ihave-03.txt (work in progress), 2134 October 2008. 2136 [IANA-GUIDELINES] 2137 Narten, T. and H. Alvestrand, "Guidelines for Writing an 2138 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2139 May 2008. 2141 [IMAP4rev1] 2142 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 2143 4rev1", RFC 3501, March 2003. 2145 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 2146 (LDAP): Technical Specification Road Map", RFC 4510, 2147 June 2006. 2149 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 2150 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 2152 Authors' Addresses 2154 Alexey Melnikov (editor) 2155 Isode Limited 2156 5 Castle Business Village 2157 36 Station Road 2158 Hampton, Middlesex TW12 2BX 2159 UK 2161 Email: Alexey.Melnikov@isode.com 2162 Tim Martin 2163 BeThereBeSquare Inc. 2164 672 Haight st. 2165 San Francisco, CA 94117 2166 US 2168 Phone: +1 510 260-4175 2169 Email: timmartin@alumni.cmu.edu 2171 Full Copyright Statement 2173 Copyright (C) The IETF Trust (2008). 2175 This document is subject to the rights, licenses and restrictions 2176 contained in BCP 78, and except as set forth therein, the authors 2177 retain all their rights. 2179 This document and the information contained herein are provided on an 2180 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2181 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2182 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2183 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2184 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2185 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2187 Intellectual Property 2189 The IETF takes no position regarding the validity or scope of any 2190 Intellectual Property Rights or other rights that might be claimed to 2191 pertain to the implementation or use of the technology described in 2192 this document or the extent to which any license under such rights 2193 might or might not be available; nor does it represent that it has 2194 made any independent effort to identify any such rights. Information 2195 on the procedures with respect to rights in RFC documents can be 2196 found in BCP 78 and BCP 79. 2198 Copies of IPR disclosures made to the IETF Secretariat and any 2199 assurances of licenses to be made available, or the result of an 2200 attempt made to obtain a general license or permission for the use of 2201 such proprietary rights by implementers or users of this 2202 specification can be obtained from the IETF on-line IPR repository at 2203 http://www.ietf.org/ipr. 2205 The IETF invites any interested party to bring to its attention any 2206 copyrights, patents or patent applications, or other proprietary 2207 rights that may cover technology that may be required to implement 2208 this standard. Please address the information to the IETF at 2209 ietf-ipr@ietf.org.