idnits 2.17.1 draft-martin-managesieve-12.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 1865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1889. 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 (September 13, 2008) is 5703 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 275, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1120, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1699, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 1811, but no explicit reference was found in the text == Unused Reference: 'IANA-GUIDELINES' is defined on line 1815, 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-05 ** 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) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-GUIDELINES') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP4rev1') (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 7 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: March 17, 2009 BeThereBeSquare Inc. 6 September 13, 2008 8 A Protocol for Remotely Managing Sieve Scripts 9 draft-martin-managesieve-12 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 March 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 61 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 10 63 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 14 64 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 15 65 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 15 66 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 18 67 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 18 68 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 18 69 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 19 70 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 20 71 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 21 72 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 21 73 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 22 74 2.11. Recommended extensions . . . . . . . . . . . . . . . . . . 22 75 2.11.1. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 23 76 2.11.2. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 24 77 2.11.3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 24 79 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 24 81 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 26 83 5. Security Considerations . . . . . . . . . . . . . . . . . 31 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 86 6.1. Manage Sieve Capability Registration Template . . . . . . 32 87 6.2. Registration of Initial Manage Sieve capabilities . . . . 33 88 6.3. Manage Sieve Response Code Registration Template . . . . . 35 89 6.4. Registration of Initial Manage Sieve Response Codes . . . 35 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . 38 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 38 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 40 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 98 Intellectual Property and Copyright Statements . . . . . . 42 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 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 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"). 184 REFERRAL 186 This response code may be returned with a BYE result from any 187 command, and includes a mandatory parameter that indicates what 188 server to access to manage this user's sieve scripts. The server 189 will be specified by a Sieve URL (see Section 3). The scriptname 190 portion of the URL MUST NOT be specified. The client should 191 authenticate to the specified server and use it for all further 192 commands in the current session. 194 SASL 195 This response code can occur in the OK response to a successful 196 AUTHENTICATE command and includes the optional final server response 197 data from the server as specified by [SASL]. 199 TRANSITION-NEEDED 201 This response code occurs in a NO response of an AUTHENTICATE 202 command. It indicates that the user name is valid, but the entry in 203 the authentication database needs to be updated in order to permit 204 authentication with the specified mechanism. This is typically done 205 by establishing a secure channel using TLS, verifying server identity 206 as specified in Section 2.2.1, and finally authenticating once using 207 the [PLAIN] authentication mechanism. The selected mechanism SHOULD 208 then work for authentications in subsequent sessions. 210 This condition can happen if a user has an entry in a system 211 authentication database such as Unix /etc/passwd, but does not have 212 credentials suitable for use by the specified mechanism. 214 TRYLATER 216 A command failed due to a temporary server failure. The client MAY 217 continue using local information and try the command later. This 218 response code only makes sense when returned in a NO/BYE response. 220 ACTIVE 222 A command failed because it is not allowed on the active script. For 223 example DELETESCRIPT on the active script. This response code only 224 makes sense when returned in a NO/BYE response. 226 NONEXISTENT 228 A command failed because the references script name doesn't exist. 229 This response code only makes sense when returned in a NO/BYE 230 response. 232 ALREADYEXISTS 234 A command failed because the references script name already exists. 235 This response code only makes sense when returned in a NO/BYE 236 response. 238 TAG 240 This response code name is followed by a string specified in the 241 command. See Section 2.11.2 for a possible use case. 243 1.4. Active Script 245 A user may have multiple Sieve scripts on the server, yet only one 246 script may be used for filtering of incoming messages. This is the 247 active script. Users may have zero or one active scripts and MUST 248 use the SETACTIVE command described below for changing the active 249 script or disabling Sieve processing. For example, a user may have 250 an everyday script they normally use and a special script they use 251 when they go on vacation. Users can change which script is being 252 used without having to download and upload a script stored somewhere 253 else. 255 1.5. Quotas 257 Servers SHOULD impose quotas to prevent malicious users from 258 overflowing available storage. If a command would place a user over 259 a quota setting, servers that impose such quotas MUST reply with a NO 260 response containing the QUOTA response code. Client implementations 261 MUST be able to handle commands failing because of quota 262 restrictions. 264 1.6. Script Names 266 A Sieve script name is a sequence of Unicode characters encoded in 267 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition 268 (Sectio 2 of [NET-UNICODE]), with the following additional 269 restrictions: 271 o 0000-001F; [CONTROL CHARACTERS] 273 o 007F; DELETE 275 o 0080-009F; [CONTROL CHARACTERS] 277 o 2028; LINE SEPARATOR 279 o 2029; PARAGRAPH SEPARATOR 281 Sieve script names MUST be at least one octet (and hense Unicode 282 character) long. Zero octets script name has a special meaning (see 283 Section 2.8). Servers MUST allow names of up to 128 Unicode 284 characters in length (which can take up to 512 bytes when encoded in 285 UTF-8, not counting the terminating NUL), and MAY allow longer names. 286 A server that receives a script name longer than its internal limit 287 MUST rejects the corresponding operation, in particular it MUST NOT 288 truncate the script name. 290 1.7. Capabilities 292 Server capabilities are sent automatically by the server upon a 293 client connection, or after successful STARTTLS and AUTHENTICATE 294 (which establishes a SASL security layer) commands. Capabilities may 295 change immediately after a successfully completed STARTTLS command 296 and/or immediately after a successfully completed AUTHENTICATE 297 command. Capabilities MUST remain static at all other times. 299 Clients MAY request the capabilities at a later time by issuing the 300 CAPABILITY command described later. The capabilities consist of a 301 series of lines each with one or two strings. The first string is 302 the name of the capability, which is case-insensitive. The second 303 optional string is the value associated with that capability. Order 304 of capabilities is arbitrary, but each capability name can appear at 305 most once. 307 The following capabilities are defined in this document: 309 IMPLEMENTATION - Name of implementation and version. 311 SASL - List of SASL mechanisms supported by the server, each 312 separated by a space. This list can be empty if and only if STARTTLS 313 is also advertised. This means that the client must negotiate TLS 314 encryption with STARTTLS first, at which point the SASL capability 315 will list a non empty list of SASL mechanisms. 317 SIEVE - List of space separated Sieve extensions (as listed in Sieve 318 "require" action [SIEVE]) supported by the Sieve engine. 320 STARTTLS - If TLS [TLS] is supported by this implementation. Before 321 advertising this capability a server MUST verify to the best of its 322 ability that TLS can be successfully negotiated by a client with 323 common cipher suites. Specifically, a server should verify that a 324 server certificate has be installed and that the TLS subsystem has 325 successfully initialized. 327 NOTIFY - A space separated list of URI schema parts for supported 328 notification methods. This capability MUST be specified if the Sieve 329 implementation supports the "enotify" extension [NOTIFY]. 331 LANGUAGE - The language ( from [RFC4646]) currently 332 used for human readable error messages. If this capability is not 333 returned, the "i-default" [RFC2277] language is assumed. Note that 334 the current language MAY be per-user configurable (i.e. it MAY change 335 after authentication). 337 Section 2.11 defines some additional ManageSieve extensions and their 338 respective capabilities. 340 A server implementation MUST return SIEVE and IMPLEMENTATION 341 capabilities. 343 A client implementation MUST ignore any listed capabilities that it 344 does not understand. 346 Example: 348 S: "IMPlemENTATION" "Example1 ManageSieved v001" 349 S: "SASl" "DIGEST-MD5 GSSAPI" 350 S: "SIeVE" "fileinto vacation" 351 S: "StaRTTLS" 352 S: "NOTIFY" "xmpp mailto" 353 S: OK 355 1.8. Link Level 357 The ManageSieve protocol assumes a reliable data stream such as that 358 provided by TCP. When TCP is used, a ManageSieve server typically 359 listens on port 2000. [[anchor6: IANA registration of port 2000 is 360 pending.]] 362 Before opening the TCP connection, the ManageSieve client first MUST 363 resolve the Domain Name System (DNS) hostname associated with the 364 receiving entity and determine the appropriate TCP port for 365 communication with the receiving entity. The process is as follows: 367 1. Attempt to resolve the hostname using a [DNS-SRV] Service of 368 "sieve" and a Proto of "tcp" for the target domain (e.g. 369 "example.net"), resulting in resource records such as 370 "_sieve._tcp.example.net.". The result of the SRV lookup, if 371 successful, will be one or more combinations of a port and 372 hostname; the ManageSieve client MUST resolve the returned 373 hostnames to IPv4/IPv6 addresses according to returned SRV record 374 weight. IP addresses from the first successfully resolved 375 hostname (with the corresponding port number returned by SRV 376 lookup) are used to connect to the server. If connection using 377 one of the IP addresses fails, the next resolved IP address is 378 used to connect. If connection to all resolved IP addresses 379 fails, then the resolution/connect is repeated for the next 380 hostname returned by SRV lookup. 382 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or 383 IPv6 address record resolution to determine the IP address, where 384 the port used is the default ManageSieve port of 2000. 386 2. Commands 388 This section and its subsections describes valid ManageSieve 389 commands. Upon initial connection to the server the client's session 390 is in non-authenticated state. Prior to successful authentication 391 only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see 392 Section 2.11.2) commands are valid. ManageSieve extensions MAY 393 define other commands which are valid in non-authenticated state. 394 Servers MUST reject all other commands with a NO response. Clients 395 may pipeline commands (send more than one command at a time without 396 waiting for completion of the first command ). However, a group of 397 commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS 398 or a HAVESPACE command anywhere but the last command in the list. 400 (*) - The only exception to this rule is when the AUTHENTICATE 401 command contains an initial response for a SASL mechanism that allows 402 clients to send data first, the mechanism is known to complete in one 403 round-trip and the mechanism doesn't negotiate a SASL security layer. 404 Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL 405 [SASL]. 407 2.1. AUTHENTICATE Command 409 Arguments: String - mechanism 410 String - initial data (optional) 412 The AUTHENTICATE command indicates a SASL [SASL] authentication 413 mechanism to the server. If the server supports the requested 414 authentication mechanism, it performs an authentication protocol 415 exchange to identify and authenticate the user. Optionally, it also 416 negotiates a security layer for subsequent protocol interactions. If 417 the requested authentication mechanism is not supported, the server 418 rejects the AUTHENTICATE command by sending the NO response. 420 The authentication protocol exchange consists of a series of server 421 challenges and client responses that are specific to the selected 422 authentication mechanism. A server challenge consists of a string 423 (quoted or literal) followed by a CRLF. The contents of the string 424 is a base-64 encoding [BASE64] of the SASL data. A client response 425 consists of a string (quoted or literal) with the base-64 encoding of 426 the SASL data followed by a CRLF. If the client wishes to cancel the 427 authentication exchange, it issues a string containing a single "*". 428 If the server receives such a response, it MUST reject the 429 AUTHENTICATE command by sending an NO reply. 431 Note that an empty challenge/response is sent as an empty string. If 432 the mechanism dictates that the final response is sent by the server 433 this data MAY be placed within the data portion of the SASL response 434 code to save a round trip. 436 The optional initial-response argument to the AUTHENTICATE command is 437 used to save a round trip when using authentication mechanisms that 438 are defined to send no data in the initial challenge. When the 439 initial-response argument is used with such a mechanism, the initial 440 empty challenge is not sent to the client and the server uses the 441 data in the initial-response argument as if it were sent in response 442 to the empty challenge. If the initial-response argument to the 443 AUTHENTICATE command is used with a mechanism that sends data in the 444 initial challenge, the server MUST reject the AUTHENTICATE command by 445 sending the NO response. 447 The service name specified by this protocol's profile of SASL is 448 "sieve". 450 Reauthentication is not supported by ManageSieve protocol's profile 451 of SASL. I.e. after a successfully completed AUTHENTICATE command, 452 no more AUTHENTICATE commands may be issued in the same session. 453 After a successful AUTHENTICATE command completes, a server MUST 454 reject any further AUTHENTICATE commands with a NO reply. However 455 note that a server may implement UNAUTHENTICATE extension described 456 in Section 2.11.3. 458 If a security layer is negotiated through the SASL authentication 459 exchange, it takes effect immediately following the CRLF that 460 concludes the successful authentication exchange for the client, and 461 the CRLF of the OK response for the server. 463 When a security layer takes effect, the ManageSieve protocol is reset 464 to the initial state (the state in ManageSieve after a client has 465 connected to the server). The server MUST discard any knowledge 466 obtained from the client which was not obtained from the SASL (or 467 TLS) negotiation itself. Likewise, the client MUST discard any 468 knowledge obtained from the server, such as the list of ManageSieve 469 extensions, which was not obtained from the SASL (or TLS) negotiation 470 itself. (Note that a client MAY compare the advertised SASL 471 mechanisms before and after authentication in order to detect an 472 active down-negotiation attack. See below.) 474 Once a SASL security layer is established, the server MUST re-issue 475 the capability results, followed by an OK response. This is 476 necessary to protect against man-in-the-middle attacks which alter 477 the capabilities list prior to SASL negotiation. The capability 478 results MUST include all SASL mechanisms the server was capable of 479 negotiating with that client. This is done in order to allow client 480 to detect active down-negotiation attack. 482 When both [TLS] and SASL security layers are in effect, the TLS 483 encoding MUST be applied (when sending data) after the SASL encoding, 484 regardless of the order in which the layers were negotiated. 486 Server implementations SHOULD support SASL proxy authentication so 487 that an administrator can administer a user's scripts. Proxy 488 authentication is when a user authenticates as herself/himself but 489 requests the server to act (authorize) as another user. 491 The authorization identity generated by this [SASL] exchange is a 492 "simple username" (in the sense defined in [SASLprep]), and both 493 client and server MUST use the [SASLprep] profile of the [StringPrep] 494 algorithm to prepare these names for transmission or comparison. If 495 preparation of the authorization identity fails or results in an 496 empty string (unless it was transmitted as the empty string), the 497 server MUST fail the authentication. 499 If an AUTHENTICATE command fails with a NO response, the client MAY 500 try another authentication mechanism by issuing another AUTHENTICATE 501 command. In other words, the client may request authentication types 502 in decreasing order of preference. 504 Note that a failed (NO) response to the AUTHENTICATE command may 505 contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- 506 NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed 507 description of the relevant conditions. 509 To ensure interoperability, client and server implementations of this 510 extension MUST implement the [SCRAM] SASL mechanism. 512 Implementations MAY advertise the ANONYMOUS SASL mechanism 513 [SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE 514 script syntax verification. Only the CAPABILITY, PUTSCRIPT and 515 LOGOUT commands are available to the anonymous user. All other 516 commands MUST give NO responses. Furthermore the PUTSCRIPT command 517 MUST NOT persistently store any data. In this mode a positive 518 response to the PUTSCRIPT command indicates that the given script 519 does not have any syntax errors. 521 Examples (Note that long lines are folded for readability and are not 522 part of protocol exchange): 524 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 525 S: "SASL" "DIGEST-MD5 GSSAPI" 526 S: "SIEVE" "fileinto vacation" 527 S: "STARTTLS" 528 S: OK 529 C: Authenticate "DIGEST-MD5" 530 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 531 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 532 cnNldD11dGYtOA==" 533 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 534 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 535 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 536 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 537 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=" 538 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ 539 mZmZA==") 541 A slightly different variant of the same authentication exchange: 543 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 544 S: "SASL" "DIGEST-MD5 GSSAPI" 545 S: "SIEVE" "fileinto vacation" 546 S: "STARTTLS" 547 S: OK 548 C: Authenticate "DIGEST-MD5" 549 S: {128} 550 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 551 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 552 cnNldD11dGYtOA== 553 C: {276+} 554 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 555 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 556 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 557 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 558 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=" 559 S: {56} 560 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 561 C: "" 562 S: OK 564 Another example demonstrating use of SASL PLAIN mechanism under TLS. 565 This example also demonstrate use of SASL "initial response" (the 566 second parameter to the Authenticate command): 568 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 569 S: "SASL" "" 570 S: "SIEVE" "fileinto vacation" 571 S: "STARTTLS" 572 S: OK 573 C: STARTTLS 574 S: OK 575 576 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 577 S: "SASL" "PLAIN" 578 S: "SIEVE" "fileinto vacation" 579 S: OK 580 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" 581 S: NO 582 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" 583 S: NO 584 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" 585 S: BYE "Too many failed authentication attempts" 586 588 The following example demonstrates use of SASL "initial response". 589 It also demonstrates that an empty response can be sent as a literal: 591 C: AUTHENTICATE "GSSAPI" {1488+} 592 C: YIIE[...1480 octets here ...]dA== 593 S: {208} 594 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic 595 [...114 octets here ...] 596 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 597 C: {0+} 598 C: 599 S: {44} 600 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= 601 C: {44+} 602 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= 603 S: OK 605 2.1.1. Use of SASL PLAIN mechanism over TLS 607 This section is normative for ManageSieve client implementations that 608 support SASL [PLAIN] over [TLS]. 610 If a ManageSieve client is willing to use SASL PLAIN over TLS to 611 authenticate to the ManageSieve server, the client MUST verify the 612 server identity (see Section 2.2.1). If the server identity can't be 613 verified (e.g. the server has not provided any certificate, or if the 614 certificate verification fails) the client MUST NOT attempt to 615 authenticate using the SASL PLAIN mechanism. 617 2.2. STARTTLS Command 619 Support for STARTTLS command in servers is optional. Its 620 availability is advertised with "STARTTLS" capability as described in 621 Section 1.7. 623 The STARTTLS command requests commencement of a TLS [TLS] 624 negotiation. The negotiation begins immediately after the CRLF in 625 the OK response. After a client issues a STARTTLS command, it MUST 626 NOT issue further commands until a server response is seen and the 627 TLS negotiation is complete. 629 The STARTTLS command is only valid in non-authenticated state. The 630 server remains in non-authenticated state, even if client credentials 631 are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL 632 mechanism MAY be used to authenticate once TLS client credentials are 633 successfully exchanged, but servers supporting the STARTTLS command 634 are not required to support the EXTERNAL mechanism. 636 After the TLS layer is established, the server MUST re-issue the 637 capability results, followed by an OK response. This is necessary to 638 protect against man-in-the-middle attacks which alter the 639 capabilities list prior to STARTTLS. This capability result MUST NOT 640 include the STARTTLS capability. 642 The client MUST discard cached capability information and replace it 643 with the new information. The server MAY advertise different 644 capabilities after STARTTLS. 646 Example: 648 C: StartTls 649 S: oK 650 651 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 652 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 653 S: "SIEVE" "fileinto vacation" 654 S: "LANGUAGE" "fr" 655 S: ok 657 2.2.1. Server Identity Check 659 During the TLS negotiation, the ManageSieve client MUST check its 660 understanding of the server hostname/IP address against the server's 661 identity as presented in the server Certificate message, in order to 662 prevent man-in-the-middle attacks. In this section, the client's 663 understanding of the server's identity is called the "reference 664 identity". 666 Checking is performed according to the following rules: 668 o If the reference identity is a hostname: 670 1. If a subjectAltName extension of the SRVName [X509-SRV], 671 dNSName [X509] (in that order of preference) type is present 672 in the server's certificate, than it SHOULD be used as the 673 source of the server's identity. Matching is performed as 674 described in Section 2.2.1.1, with the exception that no 675 wildcard matching is allowed for SRVName type. If the 676 certificate contains multiple names (e.g., more than one 677 dNSName field), then a match with any one of the fields is 678 considered acceptable. 680 2. The client MAY use other types of subjectAltName for 681 performing comparison. 683 3. The server's identity MAY also be verified by comparing the 684 reference identity to the Common Name (CN) [RFC4519] value in 685 the leaf Relative Distinguished Name (RDN) of the subjectName 686 field of the server's certificate. This comparison is 687 performed using the rules for comparison of DNS names in 688 Section 2.2.1.1, below, with the exception that no wildcard 689 matching is allowed. [[anchor8: Chris Newman says that such 690 prohibition of wildcards doesn't match existing practice.]] 691 Although the use of the Common Name value is existing 692 practice, it is deprecated, and Certification Authorities are 693 encouraged to provide subjectAltName values instead. Note 694 that the TLS implementation may represent DNs in certificates 695 according to X.500 or other conventions. For example, some 696 X.500 implementations order the RDNs in a DN using a left-to- 697 right (most significant to least significant) convention 698 instead of LDAP's right- to-left convention. 700 o When the reference identity is an IP address, the iPAddress 701 subjectAltName SHOULD be used by the client for comparison. The 702 comparison is performed as described in Section 2.2.1.2. 704 o In either case the client MAY map the reference identity to a 705 different type prior to performing a comparison. Mappings may be 706 performed for all available subjectAltName types to which the 707 reference identity can be mapped; however, the reference identity 708 should only be mapped to types for which the mapping is either 709 inherently secure (e.g., extracting the DNS hostname from a URI) 710 or for which the mapping is performed in a secure manner (e.g., 711 using DNSSEC, or using user- or admin-configured host-to-address/ 712 address-to-host lookup tables). 714 If the server identity check fails, user-oriented clients SHOULD 715 either notify the user (clients MAY give the user the opportunity to 716 continue with the ManageSieve session in this case) or close the 717 transport connection and indicate that the server's identity is 718 suspect. Automated clients SHOULD return or log an error indicating 719 that the server's identity is suspect and/or SHOULD close the 720 transport connection. Automated clients MAY provide a configuration 721 setting that disables this check, but MUST provide a setting which 722 enables it. 724 Beyond the server identity check described in this section, clients 725 should be prepared to do further checking to ensure that the server 726 is authorized to provide the service it is requested to provide. The 727 client may need to make use of local policy information in making 728 this determination. 730 2.2.1.1. Comparison of DNS Names 732 If the reference identity is an internationalized domain name, 733 conforming implementations MUST convert it to the ASCII Compatible 734 Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] 735 before comparison with subjectAltName values of type dNSName. 736 Specifically, conforming implementations MUST perform the conversion 737 operation specified in Section 4 of [RFC3490] as follows: 739 o in step 1, the domain name SHALL be considered a "stored string"; 741 o in step 3, set the flag called "UseSTD3ASCIIRules"; 743 o in step 4, process each label with the "ToASCII" operation; and 745 o in step 5, change all label separators to U+002E (full stop). 747 After performing the "to-ASCII" conversion, the DNS labels and names 748 MUST be compared for equality according to the rules specified in 749 Section 3 of [RFC3490], i.e. once all label separators are replaced 750 with U+002E (dot) they are compared in the case-insensitive manner. 752 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 753 values of type dNSName, and then only as the left-most (least 754 significant) DNS label in that value. This wildcard matches any 755 left-most DNS label in the server name. That is, the subject 756 *.example.com matches the server names a.example.com and 757 b.example.com, but does not match example.com or a.b.example.com. 759 2.2.1.2. Comparison of IP Addresses 761 When the reference identity is an IP address, the identity MUST be 762 converted to the "network byte order" octet string representation 763 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the 764 octet string will contain exactly four octets. For IP Version 6, as 765 specified in RFC 2460, the octet string will contain exactly sixteen 766 octets. This octet string is then compared against subjectAltName 767 values of type iPAddress. A match occurs if the reference identity 768 octet string and value octet strings are identical. 770 2.2.1.3. Comparison of Other subjectName Types 772 Client implementations MAY support matching against subjectAltName 773 values of other types as described in other documents. 775 2.3. LOGOUT Command 777 The client sends the LOGOUT command when it is finished with a 778 connection and wishes to terminate it. The server MUST reply with an 779 OK response and terminate the connection. The server MUST ignore 780 commands issued by the client after the LOGOUT command. 782 Example: 784 C: Logout 785 S: Ok 786 788 2.4. CAPABILITY Command 790 The CAPABILITY command requests the server capabilities as described 791 earlier in this document. It has no parameters. 793 Example: 795 C: CAPABILITY 796 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 797 S: "SASL" "PLAIN KERBEROS_V4 GSSAPI" 798 S: "SIEVE" "fileinto vacation" 799 S: "STARTTLS" 800 S: OK 802 2.5. HAVESPACE Command 803 Arguments: String - name 804 Number - script size 806 The HAVESPACE command is used to query the server for available 807 space. Clients specify the name they wish to save the script as and 808 its size in octets. Servers respond with an NO if storing a script 809 with that name and size would fail or OK otherwise. Clients SHOULD 810 issue this command before attempting to place a script on the server. 812 Note that the OK response from the HAVESPACE command does not 813 constitute a guarantee of success as server disk space conditions 814 could change between the client issuing the HAVESPACE and the client 815 issuing the PUTSCRIPT commands. A QUOTA response code (see 816 Section 1.3) remains a possible (albeit unlikely) response to a 817 subsequent PUTSCRIPT with the same name and size. 819 Example: 821 C: HAVESPACE "myscript" 999999 822 S: NO (QUOTA) "Quota exceeded" 824 C: HAVESPACE "foobar" 435 825 S: OK 827 2.6. PUTSCRIPT Command 829 Arguments: String - Script name 830 String - Script content 832 The PUTSCRIPT command is used by the client to submit a Sieve script 833 to the server. 835 If the script already exists, upon success the old script will be 836 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 837 fails in any way. A script of zero length SHOULD be disallowed. 839 This command places the script on the server. It does not affect 840 whether the script is processed on incoming mail, unless it replaces 841 the script which is already active. The SETACTIVE command is used to 842 mark a script as active. 844 When submitting large scripts clients SHOULD use the HAVESPACE 845 command beforehand to query if the server is willing to accept a 846 script of that size. 848 The server MUST check the submitted script for syntactic validity, 849 which includes checking that all Sieve extensions mentioned in Sieve 850 script "require" statement(s) are supported by the Sieve interpreter. 852 If the script fails this test the server MUST reply with a NO 853 response. Any script that fails the validity test MUST NOT be stored 854 on the server. The message given with a NO response MUST be human 855 readable and SHOULD contain a specific error message giving the line 856 number of the first error. Implementors should strive to produce 857 helpful error messages similar to those given by programming language 858 compilers. Client implementations should note that this may be a 859 multiline literal string with more than one error message separated 860 by CRLFs. The human readable message is in the language returned in 861 the latest LANGUAGE capability (or in "i-default", see Section 1.7), 862 encoded in UTF-8 [UTF-8]. 864 Example: 866 C: Putscript "foo" {31+} 867 C: #comment 868 C: InvalidSieveCommand 869 C: 870 S: NO "line 2: Syntax error" 872 C: Putscript "mysievescript" {110+} 873 C: require ["fileinto"]; 874 C: 875 C: if envelope :contains "to" "tmartin+sent" { 876 C: fileinto "INBOX.sent"; 877 C: } 878 S: OK 880 2.7. LISTSCRIPTS Command 882 This command lists the scripts the user has on the server. Upon 883 success a list of CRLF separated script names (each represented as a 884 quoted or literal string) is returned followed by an OK response. If 885 there exists an active script the atom ACTIVE is appended to the 886 corresponding script name. The atom ACTIVE MUST NOT appear on more 887 than one response line. 889 Example: 891 C: Listscripts 892 S: "summer_script" 893 S: "vacation_script" 894 S: {13} 895 S: clever"script 896 S: "main_script" ACTIVE 897 S: OK 899 C: listscripts 900 S: "summer_script" 901 S: "main_script" active 902 S: OK 904 2.8. SETACTIVE Command 906 Arguments: String - script name 908 This command sets a script active. If the script name is the empty 909 string (i.e. "") then any active script is disabled. Disabling an 910 active script when there is no script active is not an error and MUST 911 result in OK reply. 913 If the script does not exist on the server then the server MUST reply 914 with a NO response. Such reply SHOULD contain the NONEXISTENT 915 response code. 917 Examples: 919 C: Setactive "vacationscript" 920 S: Ok 922 C: Setactive "" 923 S: Ok 925 C: Setactive "baz" 926 S: No (NONEXISTENT) "There is no script by that name" 928 C: Setactive "baz" 929 S: No (NONEXISTENT) {31} 930 S: There is no script by that name 932 2.9. GETSCRIPT Command 933 Arguments: String - script name 935 This command gets the contents of the specified script. If the 936 script does not exist the server MUST reply with a NO response. Such 937 reply SHOULD contain the NONEXISTENT response code. 939 Upon success a string with the contents of the script is returned 940 followed by a OK response. 942 Example: 944 C: Getscript "myscript" 945 S: {54} 946 S: #this is my wonderful script 947 S: reject "I reject all"; 948 S: 949 S: OK 951 2.10. DELETESCRIPT Command 953 Arguments: String - script name 955 This command is used to delete a user's Sieve script. Servers MUST 956 reply with a NO response if the script does not exist. Such 957 responses SHOULD include the NONEXISTENT response code. 959 The server MUST NOT allow the client to delete an active script, so 960 the server MUST reply with a NO response if attempted. Such response 961 SHOULD contain the ACTIVE response code. If a client wishes to 962 delete an active script it should use the SETACTIVE command to 963 disable the script first. 965 Example: 967 C: Deletescript "foo" 968 S: Ok 970 C: Deletescript "baz" 971 S: No (ACTIVE) "You may not delete an active script" 973 2.11. Recommended extensions 975 This Section defines several extensions support for which is 976 RECOMMENDED. 978 The RENAME extension (advertised as the "RENAME" capability with no 979 parameters) defines a new RENAMESCRIPT command. 981 The NOOP extension (advertised as the "NOOP" capability with no 982 parameters) defines a new NOOP command. 984 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" 985 capability with no parameters) defines a new UNAUTHENTICATE command, 986 which allows a client to return the server to non-authenticated 987 state. 989 2.11.1. RENAMESCRIPT Command 991 Arguments: String - Old Script name 992 String - New Script name 994 This command is used to rename a user's Sieve script. Servers MUST 995 reply with a NO response if the old script does not exist (in which 996 case the NONEXISTENT response code SHOULD be included), or a script 997 with the new name already exists (in which case the ALREADYEXISTS 998 response code SHOULD be included). Renaming the active script is 999 allowed, the renamed script remains active. 1001 Example: 1003 C: Renamescript "foo" "bar" 1004 S: Ok 1006 C: Renamescript "baz" "bar" 1007 S: No "bar already exists" 1009 If the server doesn't support the RENAMESCRIPT command, the client 1010 can emulate it by performing the following steps: 1012 1. List available scripts with LISTSCRIPTS. If the script with the 1013 new script name exists, then the client should ask the user 1014 whether to abort the operation, to replace the script (by issuing 1015 the DELETESCRIPT after that) or to chose a different 1016 name. 1018 2. Download the old script with GETSCRIPT . 1020 3. Upload the old script with the new name: PUTSCRIPT . 1022 4. If the old script was active (as reported by LISTSCRIPTS in step 1023 1), then make the new script active: SETACTIVE 1025 5. Delete the old script: DELETESCRIPT 1027 Note that these steps don't describe how to handle various other 1028 error conditions (for example NO response containing QUOTA response 1029 code in step 3). Error handling is left as an excercise for the 1030 reader. 1032 2.11.2. NOOP Command 1034 Arguments: String - tag to echo back (optional) 1036 The NOOP command does nothing, beyond returning a response to the 1037 client. It may be used by clients for protocol re-synchronisation or 1038 to reset any inactivity auto-logout timer on the server. 1040 The response to the NOOP command is always OK, followed by the TAG 1041 response code together with the supplied string; if no string was 1042 supplied in the NOOP command, the TAG response code MUST NOT be 1043 included. 1045 Older servers may not understand the NOOP client and robust clients 1046 SHOULD be prepared to receive a NO response. 1048 Examples: 1050 C: NOOP 1051 S: OK "NOOP completed" 1053 C: NOOP "STARTTLS-SYNC-42" 1054 S: OK (TAG {16} 1055 S: STARTTLS-SYNC-42) "Done" 1057 2.11.3. UNAUTHENTICATE Command 1059 The UNAUTHENTICATE command returns the server to the non- 1060 authenticated state. It doesn't affect any previously established 1061 TLS [TLS] or SASL (Section 2.1) security layer. 1063 The UNAUTHENTICATE command is only valid in authenticated state. If 1064 issued in a wrong state, the server MUST reject it with a NO 1065 response. 1067 The UNAUTHENTICATE command has no parameters. 1069 When issued in the authenticated state, the UNAUTHENTICATE command 1070 MUST NOT fail (i.e. it must never return anything other than OK or 1071 BYE) 1073 3. Sieve URL Scheme 1075 URI scheme name: sieve 1076 Status: permanent 1078 URI scheme syntax: 1080 Described using ABNF [ABNF] and ABNF entities from [URI-GEN]. 1082 sieveurl = sieveurl-server / sieveurl-list-scripts / 1083 sieveurl-script 1085 sieveurl-server = "sieve://" authority 1087 sieveurl-list-scripts = "sieve://" [ authority ] ["/"] 1089 sieveurl-script = "sieve://" [ authority ] "/" scriptname 1091 scriptname = 1*pchar 1093 URI scheme semantics: 1095 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve 1096 server. The latter form is associated with the application/sieve 1097 MIME type defined in [SIEVE]. There is no MIME type associated 1098 with the former form of Sieve URI. 1100 The server form is used in the REFERRAL response code in order to 1101 designate another server where the client should perform its 1102 operations. 1104 The script form allows to retrieve (GETSCRIPT), update 1105 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the 1106 named script, however the most typical action would be to retrieve 1107 the script. If the script name is empty (omitted), the URI 1108 requests that the client lists available scripts using the 1109 LISTSCRIPTS command. 1111 Encoding considerations: The script name, if present, is in UTF-8. 1112 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1113 [URI-GEN]. 1115 The user name (in the "authority" part), if present, is in UTF-8. 1116 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 1117 [URI-GEN]. 1119 Applications/protocols that use this URI scheme name: 1120 ManageSieve [RFC XXXX] clients and servers. Clients that can store 1121 user preferences in protocols such as [LDAP] or [ACAP]. 1123 Interoperability considerations: None. 1125 Security considerations: 1126 The part of a ManageSieve URL might potentially disclose 1127 some confidential information about the author of the script or, 1128 depending on a ManageSieve implementation, about configuration of the 1129 mail server. The latter might be used to prepare for a more complex 1130 attack on the mail system. 1132 Clients resolving ManageSieve URLs that wish to achieve data 1133 confidentiality and/or integrity SHOULD use the STARTTLS command (if 1134 supported by the server) before starting authentication, or use a 1135 SASL mechanism, such as GSSAPI, that provides a confidentiality 1136 security layer. 1138 Contact: Alexey Melnikov 1140 Author/Change controller: IESG. 1142 References: This document and RFC 5228 [SIEVE]. 1144 4. Formal Syntax 1146 The following syntax specification uses the augmented Backus-Naur 1147 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 1148 rules as specified in Appendix A of the ABNF specification [ABNF]. 1149 "UTF8-2", "UTF8-3" and "UTF8-4" non-terminal are defined in [UTF-8]. 1151 Except as noted otherwise, all alphabetic characters are case- 1152 insensitive. The use of upper or lower case characters to define 1153 token strings is for editorial clarity only. Implementations MUST 1154 accept these strings in a case-insensitive fashion. 1156 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 1157 %x5D-7F 1158 ;; any TEXT-CHAR except QUOTED-SPECIALS 1160 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 1162 QUOTED-SPECIALS = DQUOTE / "\" 1164 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 1165 ;; , and 1166 ;; are defined in [UTF-8] 1168 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E 1169 ;; Any CHAR except ATOM-SPECIALS 1171 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / 1172 QUOTED-SPECIALS 1174 QUOTED-SPECIALS = <"> / "\" 1176 atom = 1*1024ATOM-CHAR 1178 iana-token = atom 1179 ;; MUST be registered with IANA 1181 auth-type = DQUOTE auth-type-name DQUOTE 1183 auth-type-name = iana-token 1184 ;; as defined in SASL [SASL] 1186 command = (command-any / command-auth / 1187 command-nonauth) CRLF 1188 ;; Modal based on state 1190 command-any = command-capability / command-logout / 1191 command-noop 1192 ;; Valid in all states 1194 command-auth = command-getscript / command-setactive / 1195 command-listscripts / command-deletescript / 1196 command-putscript / 1197 command-havespace / / 1198 command-renamescript / 1199 command-unauthenticate 1200 ;; Valid only in Authenticated state 1202 command-nonauth = command-authenticate / command-starttls 1203 ;; Valid only when in Non-Authenticated 1204 ;; state 1206 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 1207 *(CRLF string) 1209 command-capability = "CAPABILITY" 1211 command-deletescript = "DELETESCRIPT" SP sieve-name 1213 command-getscript = "GETSCRIPT" SP sieve-name 1215 command-havespace = "HAVESPACE" SP sieve-name SP number 1217 command-listscripts = "LISTSCRIPTS" 1219 command-noop = "NOOP" [SP string] 1220 command-logout = "LOGOUT" 1222 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script 1224 sieve-script = string 1226 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP 1227 new-sieve-name 1229 old-sieve-name = sieve-name 1231 new-sieve-name = sieve-name 1233 command-setactive = "SETACTIVE" SP sieve-name 1235 command-starttls = "STARTTLS" 1237 command-unauthenticate= "UNAUTHENTICATE" 1239 extend-token = atom 1240 ;; MUST be defined by a standards track or 1241 ;; IESG approved experimental protocol 1242 ;; extension 1244 extension-data = extension-item *(SP extension-item) 1246 extension-item = extend-token / string / number / 1247 "(" [extension-data] ")" 1249 literal-c2s = "{" number "+}" CRLF *OCTET 1250 ;; The number represents the number of 1251 ;; octets. 1252 ;; This type of literal can only be sent 1253 ;; from the client to the server. 1255 literal-s2c = "{" number "}" CRLF *OCTET 1256 ;; Almost identical to literal-c2s, 1257 ;; but with no '+' character. 1258 ;; The number represents the number of 1259 ;; octets. 1260 ;; This type of literal can only be sent 1261 ;; from the server to the client. 1263 number = 1*DIGIT 1264 ;; A 32-bit unsigned number. 1265 ;; (0 <= n < 4,294,967,296) 1267 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1268 ;; limited to 1024 octets between the <">s 1270 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1271 "QUOTA" / resp-code-sasl / 1272 resp-code-referral / 1273 "TRANSITION-NEEDED" / "TRYLATER" / 1274 "ACTIVE" / "NONEXISTENT" / 1275 "ALREADYEXISTS" / 1276 "TAG" SP string / 1277 resp-code-ext 1279 resp-code-referral = "REFERRAL" SP sieveurl 1281 resp-code-sasl = "SASL" SP string 1283 resp-code-name = iana-token 1284 ;; The response code name is hierarchical, 1285 ;; separated by '/'. 1286 ;; The response code name MUST NOT start 1287 ;; with '/'. 1289 resp-code-ext = resp-code-name [SP extension-data] 1290 ;; unknown response codes MUST be tolerated 1291 ;; by the client. 1293 response = response-authenticate / 1294 response-logout / 1295 response-getscript / 1296 response-setactive / 1297 response-listscripts / 1298 response-deletescript / 1299 response-putscript / 1300 response-capability / 1301 response-havespace / 1302 response-starttls / 1303 response-renamescript / 1304 response-noop / 1305 response-unauthenticate 1307 response-authenticate = *(string CRLF) 1308 ((response-ok [response-capability]) / 1309 response-nobye) 1310 ;; is REQUIRED if a 1311 ;; SASL security layer was negotiated and 1312 ;; MUST be omitted otherwise. 1314 response-capability = *(single-capability) response-oknobye 1315 single-capability = capability-name [SP string] CRLF 1317 capability-name = string 1318 ;; Note that literal-s2c is allowed. 1320 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1321 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1322 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1323 DQUOTE "NOTIFY" DQUOTE SP notify-mechs / 1324 DQUOTE "STARTTLS" DQUOTE / 1325 DQUOTE "LANGUAGE" DQUOTE SP language / 1326 DQUOTE "RENAME" DQUOTE / 1327 DQUOTE "NOOP" DQUOTE 1328 ;; Each capability conforms to 1329 ;; the syntax for single-capability. 1330 ;; Also note that the capability name 1331 ;; can be returned as either literal-s2c 1332 ;; or quoted, even though only "quoted" 1333 ;; string is shown above. 1335 sasl-mechs = string 1336 ; space separated list of SASL mechanisms, 1337 ; each SASL mechanism name complies with rules 1338 ; specified in [SASL]. 1339 ; Can be empty. 1341 sieve-extensions = string 1342 ; space separated list of supported SIEVE extensions, 1343 ; can be empty. 1345 language = string 1346 ; Contains from [RFC4646]. 1348 notify-mechs = string 1349 ; space separated list of URI schema parts 1350 ; for supported notification [NOTIFY] methods. 1351 ; MUST NOT be empty. 1353 response-deletescript = response-oknobye 1355 response-getscript = (sieve-script CRLF response-ok) / 1356 response-nobye 1358 response-havespace = response-oknobye 1360 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1361 response-oknobye 1362 ;; ACTIVE may only occur with one sieve-name 1364 response-logout = response-oknobye 1366 response-unauthenticate= response-oknobye 1367 ;; "NO" response can only be returned when 1368 ;; the command is issued in a wrong state 1369 ;; or has a wrong number of parameters 1371 response-ok = "OK" [SP "(" resp-code ")"] 1372 [SP string] CRLF 1373 ;; The string contains human readable text 1374 ;; encoded as UTF-8. 1376 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1377 [SP string] CRLF 1378 ;; The string contains human readable text 1379 ;; encoded as UTF-8. 1381 response-oknobye = response-ok / response-nobye 1383 response-noop = response-ok 1385 response-putscript = response-oknobye 1387 response-renamescript = response-oknobye 1389 response-setactive = response-oknobye 1391 response-starttls = (response-ok response-capability) / 1392 response-nobye 1394 sieve-name = string 1395 ;; See Section 1.6 for the full list of 1396 ;; prohibited characters. 1398 string = quoted / literal-c2s / literal-s2c 1399 ;; literal-c2s is only allowed when sent 1400 ;; from the client to the server. 1401 ;; literal-s2c is only allowed when sent 1402 ;; from the server to the client. 1403 ;; quoted is allowed in either direction. 1405 5. Security Considerations 1407 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1408 and authorization services. Integrity and privacy services can be 1409 provided by [SASL] and/or [TLS]. When a SASL mechanism is used the 1410 security considerations for that mechanism apply. 1412 This protocol's transactions are susceptible to passive observers or 1413 man in the middle attacks which alter the data, unless the optional 1414 encryption and integrity services of the SASL (via the AUTHENTICATE 1415 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1416 external security mechanism is used for protection. It may be useful 1417 to allow configuration of both clients and servers to refuse to 1418 transfer sensitive information in the absence of strong encryption. 1420 If an implementation supports SASL mechanisms that are vulnerable to 1421 passive eavesdropping attacks (such as [PLAIN]), then the 1422 implementation MUST support at least one configuration where these 1423 SASL mechanisms are not advertised or used without the presence of an 1424 external security layer such as [TLS]. 1426 Some response codes returned on failed AUTHENTICATE command may 1427 disclose whether or not the username is valid, so server 1428 implementations SHOULD provide the ability to disable these features 1429 (or make them not conditional on a per-user basis) for sites 1430 concerned about such disclosure. In the case of ENCRYPT-NEEDED, if 1431 it is applied to all identities then no extra information is 1432 disclosed, but if it is applied on a per-user basis it can disclose 1433 information. 1435 6. IANA Considerations 1437 IANA is requested to reserve TCP port number 2000 for use with the 1438 Manage Sieve protocol described in this document. 1440 IANA is requested to register the "sieve" URI scheme defined in 1441 Section 3 of this document. 1443 IANA is requested to create a new registry for Manage Sieve 1444 capabilities. The registration template for Manage Sieve 1445 capabilities is specified in Section 6.1. Manage Sieve protocol 1446 capabilities MUST be specified in a standards track or IESG approved 1447 experimental RFC. 1449 IANA is requested to create a new registry for Manage Sieve response 1450 codes. The registration template for Manage Sieve response codes is 1451 specified in Section 6.3. Manage Sieve protocol response codes MUST 1452 be specified in a standards track or IESG approved experimental RFC. 1454 6.1. Manage Sieve Capability Registration Template 1456 To: iana@iana.org 1457 Subject: Manage Sieve Capability Registration 1458 Please register the following Manage Sieve Capability: 1460 Capability name: 1461 Description: 1462 Relevant publications: 1463 Person & email address to contact for further information: 1464 Author/Change controller: 1466 6.2. Registration of Initial Manage Sieve capabilities 1468 To: iana@iana.org 1469 Subject: Manage Sieve Capability Registration 1470 Please register the following Manage Sieve Capabilities: 1472 Capability name: IMPLEMENTATION 1474 Description: Its value contains name of server implementation and 1475 its version. 1477 Relevant publications: this RFC, Section 1.7. 1479 Person & email address to contact for further information: Alexey 1480 Melnikov 1482 Author/Change controller: IESG. 1484 Capability name: SASL 1486 Description: Its value contains a space separated list of SASL 1487 mechanisms supported by server. 1489 Relevant publications: this RFC, Section 1.7 and Section 2.1. 1491 Person & email address to contact for further information: Alexey 1492 Melnikov 1494 Author/Change controller: IESG. 1496 Capability name: SIEVE 1498 Description: Its value contains a space separated list of 1499 supported SIEVE extensions 1501 Relevant publications: this RFC, Section 1.7. Also [SIEVE]. 1503 Person & email address to contact for further information: Alexey 1504 Melnikov 1506 Author/Change controller: IESG. 1508 Capability name: STARTTLS 1510 Description: This capability is returned if server supports TLS 1511 (STARTTLS command). 1513 Relevant publications: this RFC, Section 1.7 and Section 2.2. 1515 Person & email address to contact for further information: Alexey 1516 Melnikov 1518 Author/Change controller: IESG. 1520 Capability name: NOTIFY 1522 Description: This capability is returned if server supports 1523 'enotify' [NOTIFY] Sieve extension. 1525 Relevant publications: this RFC, Section 1.7. 1527 Person & email address to contact for further information: Alexey 1528 Melnikov 1530 Author/Change controller: IESG. 1532 Capability name: RENAME 1534 Description: This capability is returned if the server supports 1535 the RENAMESCRIPT command. 1537 Relevant publications: this RFC, Section 2.11.1. 1539 Person & email address to contact for further information: Alexey 1540 Melnikov 1542 Author/Change controller: IESG. 1544 Capability name: NOOP 1546 Description: This capability is returned if the server supports 1547 the NOOP command. 1549 Relevant publications: this RFC, Section 2.11.2. 1551 Person & email address to contact for further information: Alexey 1552 Melnikov 1554 Author/Change controller: IESG. 1556 6.3. Manage Sieve Response Code Registration Template 1558 To: iana@iana.org 1559 Subject: Manage Sieve Response Code Registration 1560 Please register the following Manage Sieve Response Code: 1562 Response Code: 1564 Arguments (use ABNF to specify syntax, or the word NONE if none 1565 can be specified): 1567 Purpose: 1569 Published Specification(s): 1571 Person & email address to contact for further information: 1573 Author/Change controller: 1575 6.4. Registration of Initial Manage Sieve Response Codes 1577 To: iana@iana.org 1578 Subject: Manage Sieve Response Code Registration 1579 Please register the following Manage Sieve Response Codes: 1581 Response Code: AUTH-TOO-WEAK 1583 Arguments (use ABNF to specify syntax, or the word NONE if none 1584 can be specified): NONE 1586 Purpose: This response code is returned in the NO response from an 1587 AUTHENTICATE command. It indicates that site security policy 1588 forbids the use of the requested mechanism for the specified 1589 authentication identity. 1591 Published Specification(s): [RFCXXXX] 1593 Person & email address to contact for further information: Alexey 1594 Melnikov 1596 Author/Change controller: IESG. 1598 Response Code: ENCRYPT-NEEDED 1600 Arguments (use ABNF to specify syntax, or the word NONE if none 1601 can be specified): NONE 1602 Purpose: This response code is returned in the NO response from an 1603 AUTHENTICATE command. It indicates that site security policy 1604 requires the use of a strong encryption mechanism for the 1605 specified authentication identity and mechanism. 1607 Published Specification(s): [RFCXXXX] 1609 Person & email address to contact for further information: Alexey 1610 Melnikov 1612 Author/Change controller: IESG. 1614 Response Code: QUOTA 1616 Arguments (use ABNF to specify syntax, or the word NONE if none 1617 can be specified): NONE 1619 Purpose: If this response code is returned in the NO/BYE response, 1620 it means that the command would have placed the user above the 1621 site-defined quota constraints. If this response code is returned 1622 in the OK response, it can mean that the user is near its quota or 1623 that the user exceeded its quota, but the server supports soft 1624 quotas. 1626 Published Specification(s): [RFCXXXX] 1628 Person & email address to contact for further information: Alexey 1629 Melnikov 1631 Author/Change controller: IESG. 1633 Response Code: REFERRAL 1635 Arguments (use ABNF to specify syntax, or the word NONE if none 1636 can be specified): 1638 Purpose: This response code may be returned with a BYE result from 1639 any command, and includes a mandatory parameter that indicates 1640 what server to access to manage this user's sieve scripts. The 1641 server will be specified by a Sieve URL (see Section 3). The 1642 scriptname portion of the URL MUST NOT be specified. The client 1643 should authenticate to the specified server and use it for all 1644 further commands in the current session. 1646 Published Specification(s): [RFCXXXX] 1648 Person & email address to contact for further information: Alexey 1649 Melnikov 1650 Author/Change controller: IESG. 1652 Response Code: SASL 1654 Arguments (use ABNF to specify syntax, or the word NONE if none 1655 can be specified): 1657 Purpose: This response code can occur in the OK response to a 1658 successful AUTHENTICATE command and includes the optional final 1659 server response data from the server as specified by [SASL]. 1661 Published Specification(s): [RFCXXXX] 1663 Person & email address to contact for further information: Alexey 1664 Melnikov 1666 Author/Change controller: IESG. 1668 Response Code: TRANSITION-NEEDED 1670 Arguments (use ABNF to specify syntax, or the word NONE if none 1671 can be specified): NONE 1673 Purpose: This response code occurs in a NO response of an 1674 AUTHENTICATE command. It indicates that the user name is valid, 1675 but the entry in the authentication database needs to be updated 1676 in order to permit authentication with the specified mechanism. 1677 This is typically done by establishing a secure channel using TLS, 1678 followed by authenticating once using the [PLAIN] authentication 1679 mechanism. The selected mechanism SHOULD then work for 1680 authentications in subsequent sessions. 1682 Published Specification(s): [RFCXXXX] 1684 Person & email address to contact for further information: Alexey 1685 Melnikov 1687 Author/Change controller: IESG. 1689 Response Code: TRYLATER 1691 Arguments (use ABNF to specify syntax, or the word NONE if none 1692 can be specified): NONE 1694 Purpose: A command failed due to a temporary server failure. The 1695 client MAY continue using local information and try the command 1696 later. This response code only make sense when returned in a NO/ 1697 BYE response. 1699 Published Specification(s): [RFCXXXX] 1701 Person & email address to contact for further information: Alexey 1702 Melnikov 1704 Author/Change controller: IESG. 1706 7. Acknowledgements 1708 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 1709 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, 1710 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil 1711 Pennock, Jeffrey Hutzelman, Mark E. Mallett, Dave Cridland and Robert 1712 Burrell Donkin for help with this document. Special thank you to 1713 Phil Pennock for providing text for the NOOP command, as well as 1714 finding various bugs in the document. 1716 8. References 1718 8.1. Normative References 1720 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1721 Specifications: ABNF", RFC 5234, January 2008. 1723 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 1724 Configuration Access Protocol", RFC 2244, November 1997. 1726 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1727 Encodings", RFC 4648, October 2006. 1729 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1730 specifying the location of services (DNS SRV)", RFC 2782, 1731 February 2000. 1733 [KEYWORDS] 1734 Bradner, S., "Key words for use in RFCs to Indicate 1735 Requirement Levels", RFC 2119, March 1997. 1737 [NET-UNICODE] 1738 Klensin, J. and M. Padlipsky, "Unicode Format for Network 1739 Interchange", RFC 5198, March 2008. 1741 [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 1742 Martin, "Sieve Extension: Notifications", 1743 draft-ietf-sieve-notify-12 (work in progress), 1744 December 2007. 1746 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1747 Languages", RFC 2277, January 1998. 1749 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1750 (IPv6) Specification", RFC 2460, December 1998. 1752 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1753 "Internationalizing Domain Names in Applications (IDNA)", 1754 RFC 3490, March 2003. 1756 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 1757 (LDAP): Schema for User Applications", RFC 4519, 1758 June 2006. 1760 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 1761 Languages", RFC 4646, September 2006. 1763 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 1765 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1766 Security Layer (SASL)", RFC 4422, June 2006. 1768 [SASL-ANON] 1769 Zeilenga, K., "Anonymous Simple Authentication and 1770 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 1772 [SASLprep] 1773 Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1774 and Passwords", RFC 4013, February 2005. 1776 [SCRAM] Menon-Sen, A., Ed. and C. Newman, "Salted Challenge 1777 Response Authentication Mechanism (SCRAM)", 1778 draft-newman-auth-scram-05.txt (work in progress), 1779 December 2007. 1781 [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 1782 Filtering Language", RFC 5228, January 2008. 1784 [StringPrep] 1785 Hoffman, P. and M. Blanchet, "Preparation of 1786 Internationalized Strings ("stringprep")", RFC 3454, 1787 December 2002. 1789 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1790 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1792 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1793 Resource Identifier (URI): Generic Syntax", STD 66, 1794 RFC 3986, January 2005. 1796 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1797 10646", STD 63, RFC 3629, November 2003. 1799 [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1800 X.509 Public Key Infrastructure Certificate and 1801 Certificate Revocation List (CRL) Profile", RFC 3280, 1802 April 2002. 1804 [X509-SRV] 1805 Santesson, S., "Internet X.509 Public Key Infrastructure 1806 Subject Alternative Name for Expression of Service Name", 1807 RFC 4985, August 2007. 1809 8.2. Informative References 1811 [DIGEST-MD5] 1812 Leach, P. and C. Newman, "Using Digest Authentication as a 1813 SASL Mechanism", RFC 2831, May 2000. 1815 [IANA-GUIDELINES] 1816 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1817 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1818 October 1998. 1820 [IMAP4rev1] 1821 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1822 4rev1", RFC 3501, March 2003. 1824 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol 1825 (LDAP): Technical Specification Road Map", RFC 4510, 1826 June 2006. 1828 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and 1829 Security Layer (SASL) Mechanism", RFC 4616, August 2006. 1831 Authors' Addresses 1833 Alexey Melnikov (editor) 1834 Isode Limited 1835 5 Castle Business Village 1836 36 Station Road 1837 Hampton, Middlesex TW12 2BX 1838 UK 1840 Email: Alexey.Melnikov@isode.com 1842 Tim Martin 1843 BeThereBeSquare Inc. 1844 672 Haight st. 1845 San Francisco, CA 94117 1846 US 1848 Phone: +1 510 260-4175 1849 Email: timmartin@alumni.cmu.edu 1851 Full Copyright Statement 1853 Copyright (C) The IETF Trust (2008). 1855 This document is subject to the rights, licenses and restrictions 1856 contained in BCP 78, and except as set forth therein, the authors 1857 retain all their rights. 1859 This document and the information contained herein are provided on an 1860 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1861 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1862 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1863 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1864 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1865 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1867 Intellectual Property 1869 The IETF takes no position regarding the validity or scope of any 1870 Intellectual Property Rights or other rights that might be claimed to 1871 pertain to the implementation or use of the technology described in 1872 this document or the extent to which any license under such rights 1873 might or might not be available; nor does it represent that it has 1874 made any independent effort to identify any such rights. Information 1875 on the procedures with respect to rights in RFC documents can be 1876 found in BCP 78 and BCP 79. 1878 Copies of IPR disclosures made to the IETF Secretariat and any 1879 assurances of licenses to be made available, or the result of an 1880 attempt made to obtain a general license or permission for the use of 1881 such proprietary rights by implementers or users of this 1882 specification can be obtained from the IETF on-line IPR repository at 1883 http://www.ietf.org/ipr. 1885 The IETF invites any interested party to bring to its attention any 1886 copyrights, patents or patent applications, or other proprietary 1887 rights that may cover technology that may be required to implement 1888 this standard. Please address the information to the IETF at 1889 ietf-ipr@ietf.org.