idnits 2.17.1 draft-martin-managesieve-09.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1341. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1419 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (May 22, 2008) is 5810 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: 'RFC XXXX' is mentioned on line 902, but not defined == Unused Reference: 'DIGEST-MD5' is defined on line 1295, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4013 (ref. 'SASLprep') (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 3454 (ref. 'StringPrep') (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- No information found for draft-ietf-sieve-notify-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NOTIFY' == Outdated reference: A later version (-13) exists of draft-newman-auth-scram-05 -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP4rev1') (Obsoleted by RFC 9051) -- No information found for draft-ietf-sasl-rfc2831bis-XX - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Martin 2 INTERNET-DRAFT BeThereBeSquare Inc. 3 Intended status: Standards Track Alexey Melnikov 4 Expires: November 2008 Isode Limited 5 May 22, 2008 7 A Protocol for Remotely Managing Sieve Scripts 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its 19 working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Distribution of this memo is unlimited. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Sieve scripts allow users to filter incoming email. Message stores 43 are commonly sealed servers so users cannot log into them, yet users 44 must be able to update their scripts on them. This document 45 describes a protocol "sieve" for securely managing Sieve scripts on 46 a remote server. This protocol allows a user to have multiple 47 scripts, and also alerts a user to syntactically flawed scripts. 49 Table of Contents 51 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . . 1 52 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Conventions Used in the Document . . . . . . . . . . . . . . 4 56 1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . . 8 64 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . . 10 65 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . . 10 66 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . . 11 67 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . . . 11 68 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . . . 11 69 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . . . 13 70 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . . . 13 71 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . . . 13 72 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . . 14 73 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . . 14 74 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 78 7.2. Informative References . . . . . . . . . . . . . . . . . . . 79 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . 81 1. Introduction 83 1.1. Changes 85 [[Note to RFC editor: please delete this section before 86 publication]] 88 Changes since 08 90 - Updated the text describing prohibited Unicode characters in script 91 names 93 - Clarified that non-synchronizing literals (i.e. {+}CRLF...) 94 can only be sent by the client, while synchronizing literals (i.e. 95 {}CRLF...) are only sent by the server 97 - Various other ABNF fixes 99 - Changed DIGEST-MD5 to SCRAM as the mandatory to implement SASL 100 mechanism 102 - Updated references 104 - Other editorial changes 106 Changes since 07 108 -Fixed examples to match 3028bis - capability names are case 109 sensitive, so examples should show "fileinto" instead of 110 "FILEINTO", etc. 112 -Minor editorial changes 114 Changes since 06 116 -Clarified meaning of the QUOTA response code 118 -Clarified which characters are not allowed in script names 119 and the maximum script name length 121 -Clarified that the empty list of SASL mechanisms is allowed 123 -Clarified that PUTSCRIPT must not store data after anonymous 124 authentication 126 -Move text about NOTIFY capability into this document 128 -Additional examples 130 -Updated ABNF, References, Contact information 132 Changes since 05 134 -More ABNF fixes 136 -Added IANA considerations 138 -Added/fixed text about AUTHENTICATE. 140 -Updated the text om Sieve URLs. 142 -Updated and added new examples. 144 Changes since 04 146 -Updated boilerplate and some references. Added Alexey as co-editor. 148 -Minor ABNF fixes 150 -Cleaned up terminology (for example, made more consistent with 151 SASL) 153 -Added more examples, fixed some existing examples 155 -Clarified that STARTTLS command is optional 157 -Clarified that disabling an active script when there is no script 158 active is not an error. 160 Changes since 03 162 -Add referals and Sieve URLs 164 -Lots of spelling/grammer fixes 166 -Don't give capabilities after successful STARTTLS. This is because 167 it isn't consistant with AUTHENTICATE. There is language specifying 168 that a client should re-issue a CAPABILITY command after 169 AUTHENTICATE/STARTTLS. 171 -Putting a script of length 0 doesn't remove the script. If this 172 functionality is desired, the DELETESCRIPT command should be used. 174 Changes since 02 176 -add BYE response 178 -typo on line 588 180 -allow ANONYMOUS access for sieve script verification 182 -updated SIEVE spec reference 184 Changes since 01 186 -changed contact info 188 Changes since 00 190 -added response codes (from ACAP) 192 -removed special-ok response from authenticate command (response 193 codes obsolete it) 195 -changed service name to "sieve" 197 -ABNF fixes 199 -Alexey's wording changes 201 -Eliminated lame PLAIN paragraph 203 Changes since PRE 205 -dropped synchronized literals. added HAVESPACE command 207 -changed capability response syntax. added CAPABILITY command 209 -allowed pipelining 211 - "sieve" -> "Sieve". Other minor fixes 213 -made script names more flexible 215 -added starttls support 217 1.2. Conventions Used in the Document 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in [KEYWORDS]. 223 In examples, "C:" and "S:" indicate lines sent by the client and 224 server respectively. Line breaks that do not start a new "C:" or 225 "S:" exist for editorial reasons. 227 1.3. Syntax 229 This a line oriented protocol much like [IMAP4rev1] or [ACAP]. There 230 are three data types: ATOMS, numbers and strings. Strings may be quoted 231 or literal. See [ACAP] for detailed descriptions of these types. 233 Each command consists of an atom followed by zero or more strings 234 and numbers terminated by a newline. 236 All client queries are replied to with either an OK, NO, or BYE 237 response. Each response may be followed by a response code (see 238 response codes section) and by a string consisting of human readable 239 text in the local language. The contents of the string SHOULD be 240 shown to the user and implementations MUST NOT attempt to parse the 241 message for meaning. 243 The BYE response may be used if the server wishes to close the 244 connection. A server may wish to do this because the client was idle 245 for too long or there were too many failed authentication attempts. 246 This response can be issued at any time and should be immediately 247 followed by a server hang-up of the connection. If a server has a 248 inactivity timeout resulting in client autologout it MUST be no less 249 than 30 minutes. 251 <> 254 1.4. Response Codes 256 An OK, NO, or BYE response from the server MAY contain a response 257 code to describe the event in a more detailed machine parsable 258 fashion. A response code consists of data inside parentheses in the 259 form of an atom, possibly followed by a space and arguments. 260 Response codes are defined when there is a specific action that a 261 client can take based upon the additional information. In order to 262 support future extension, the response code is represented as a 263 slash-separated hierarchy with each level of hierarchy representing 264 increasing detail about the error. Clients MUST tolerate additional 265 hierarchical response code detail which they don't understand. 267 The currently defined response codes are: 269 AUTH-TOO-WEAK 271 This response code is returned in the NO response from an 272 AUTHENTICATE command. It indicates that site security policy forbids 273 the use of the requested mechanism for the specified authentication 274 identity. 276 ENCRYPT-NEEDED 278 This response code is returned in the NO response from an 279 AUTHENTICATE command. It indicates that site security policy 280 requires the use of a strong encryption mechanism for the specified 281 authentication identity and mechanism. 283 QUOTA 285 If this response code is returned in the NO/BYE response, it means 286 that the command would have placed the user above the site-defined 287 quota constraints. If this response code is returned in the OK 288 response, it can mean that the user is near its quota or that the 289 user exceeded its quota, but the server supports soft quotas. 291 REFERRAL 293 This response code may be returned with a BYE result from any 294 command, and includes a mandatory parameter that indicates what 295 server to access to manage this user's sieve scripts. The server 296 will be specified by a Sieve URL (see "Sieve URL Scheme" section). 297 The scriptname portion of the URL MUST NOT be specified. The client 298 should authenticate to the specified server and use it for all 299 further commands in the current session. 301 SASL 303 This response code can occur in the OK response to a successful 304 AUTHENTICATE command and includes the optional final server response 305 data from the server as specified by [SASL]. 307 TRANSITION-NEEDED 309 This response code occurs in a NO response of an AUTHENTICATE 310 command. It indicates that the user name is valid, but the entry in 311 the authentication database needs to be updated in order to permit 312 authentication with the specified mechanism. This is typically done 313 by establishing a secure channel using TLS, followed by 314 authenticating once using the [PLAIN] authentication mechanism. 315 The selected mechanism SHOULD then work for authentications in 316 subsequent sessions. 318 This condition can happen if a user has an entry in a system 319 authentication database such as Unix /etc/passwd, but does not have 320 credentials suitable for use by the specified mechanism. 322 TRYLATER 324 A command failed due to a temporary server failure. The client MAY 325 continue using local information and try the command later. This 326 response code only make sense when returned in a NO/BYE response. 328 Client implementations MUST tolerate response codes that they do not 329 recognize. 331 1.5. Active Script 333 A user may have multiple Sieve scripts on the server, yet only one 334 script may be used for filtering of incoming messages. This is the 335 active script. Users may have zero or one active scripts and MUST 336 use the SETACTIVE command described below for changing the active 337 script or disabling Sieve processing. For example, a user may have 338 an everyday script they normally use and a special script they use 339 when they go on vacation. Users can change which script is being 340 used without having to download and upload a script stored somewhere 341 else. 343 1.6. Quotas 345 Servers SHOULD impose quotas to prevent malicious users from 346 overflowing available storage. If a command would place a user over 347 a quota setting, servers that impose such quotas MUST reply with a 348 NO response. Client implementations MUST be able to handle commands 349 failing because of quota restrictions. 351 1.7. Script Names 353 A Sieve script name is a sequence of Unicode characters encoded 354 in UTF-8 [UTF-8]. Characters listed in Section 2.3 of [SASLprep] 355 are prohibited in Sieve script names. <> 357 Server implementations MAY further restrict the list of allowed 358 characters, but they MUST at least allow for US-ASCII DIGIT and 359 ALPHA [ABNF] and '-' (hyphen) characters. 360 Sieve script names MUST be at least one octet long. Zero 361 octets script name has a special meaning (see SETACTIVE command 362 section). Servers MUST allow names of up to 128 Unicode characters 363 in length, and MAY allow longer names. 365 1.8. Capabilities 367 Server capabilities are sent automatically by the server upon a client 368 connection, or after successful STARTTLS and AUTHENTICATE (which 369 establishes a SASL security layer) commands. 370 Clients may request the capabilities at a later time by issuing the 371 CAPABILITY command described later. The capabilities consist of a 372 series of lines each with one or two strings. The first string is 373 the name of the capability, which is case-insensitive. The second 374 optional string is the value associated with that capability. 375 Order of capabilities is arbitrary, but each capability name can 376 appear at most once. 378 The following capabilities are defined in this document: 380 IMPLEMENTATION - Name of implementation and version 382 SASL - List of SASL mechanisms supported by the server, each 383 separated by a space. This list can be empty if and only if 384 STARTTLS is also advertised. This means that the client must 385 negotiate TLS encryption with STARTTLS first, at which point 386 the SASL capability will list a non empty list of SASL mechanisms. 388 SIEVE - List of space separated Sieve extensions (as listed 389 in Sieve "require" action [SIEVE]) supported by the Sieve engine 391 STARTTLS - If TLS [TLS] is supported by this implementation 393 NOTIFY - A space separated list of URI schema parts for supported 394 notification methods. This capability MUST be specified if the 395 Sieve implementation supports the "enotify" extension 396 [NOTIFY]. 398 A server implementation MUST return SIEVE and IMPLEMENTATION 399 capabilities. 401 A client implementation MUST ignore any listed capabilities 402 that it does not understand. 404 Example: 406 S: "IMPlemENTATION" "Example1 ManageSieved v001" 407 S: "SASl" "DIGEST-MD5 GSSAPI" 408 S: "SIeVE" "fileinto vacation" 409 S: "StaRTTLS" 410 S: "NOTIFY" "xmpp mailto" 411 S: OK 413 <> 415 2. Commands 417 The following commands are valid. Prior to successful authentication 418 only the AUTHENTICATE, CAPABILITY, STARTTLS, and LOGOUT commands are 419 valid. Servers MUST reject all other commands with a NO response. 420 Clients may pipeline commands (send more than one command at a time 421 without waiting for completion of the first command ). However, a 422 group of commands sent together MUST NOT have an AUTHENTICATE, 423 a STARTTLS or a HAVESPACE command anywhere but the last command in 424 the list. 426 2.1. AUTHENTICATE Command 428 Arguments: 429 String - mechanism 430 String - initial data (optional) 432 The AUTHENTICATE command indicates a SASL [SASL] authentication 433 mechanism to the server. If the server supports the requested 434 authentication mechanism, it performs an authentication protocol 435 exchange to identify and authenticate the user. Optionally, it also 436 negotiates a security layer for subsequent protocol interactions. 437 If the requested authentication mechanism is not supported, the 438 server rejects the AUTHENTICATE command by sending the NO response. 440 The authentication protocol exchange consists of a series of server 441 challenges and client responses that are specific to the selected 442 authentication mechanism. A server challenge consists of a string 443 (quoted or literal) followed by a CRLF. The contents of the string 444 is a base-64 encoding [BASE64] of the SASL data. A client response 445 consists of a string (quoted or literal) with the base-64 encoding 446 of the SASL data followed by a CRLF. If the client wishes to cancel 447 the authentication exchange, it issues a string containing a single 448 "*". If the server receives such a response, it MUST reject the 449 AUTHENTICATE command by sending an NO reply. 451 Note that an empty challenge/response is sent as an empty string. 452 If the mechanism dictates that the final response is sent by the 453 server this data MAY be placed within the data portion of the SASL 454 response code to save a round trip. 456 The optional initial-response argument to the AUTHENTICATE command 457 is used to save a round trip when using authentication mechanisms 458 that are defined to send no data in the initial challenge. When the 459 initial-response argument is used with such a mechanism, the initial 460 empty challenge is not sent to the client and the server uses the 461 data in the initial-response argument as if it were sent in response 462 to the empty challenge. If the initial-response argument to the 463 AUTHENTICATE command is used with a mechanism that sends data in the 464 initial challenge, the server rejects the AUTHENTICATE command by 465 sending the NO response. 467 The service name specified by this protocol's profile of SASL is 468 "sieve". 470 Reauthentication is not supported by ManageSieve protocol's profile 471 of SASL. I.e. after a successfully completed AUTHENTICATE command, 472 no more AUTHENTICATE commands may be issued in the same session. 473 After a successful AUTHENTICATE command completes, a server MUST 474 reject any further AUTHENTICATE commands with a NO reply. 476 If a security layer is negotiated through the SASL authentication 477 exchange, it takes effect immediately following the CRLF that 478 concludes the authentication exchange for the client, and the CRLF 479 of the OK response for the server. 481 When a security layer takes effect, the ManageSieve protocol is 482 reset to the initial state (the state in ManageSieve after a client 483 has connected to the server). The server MUST discard any 484 knowledge obtained from the client which was not obtained from 485 the SASL (or TLS) negotiation itself. 486 Likewise, the client MUST discard any knowledge obtained from 487 the server, such as the list of ManageSieve extensions, which 488 was not obtained from the SASL (or TLS) negotiation itself. 489 (Note that a client MAY compare the advertised SASL mechanisms 490 before and after authentication in order to detect an active 491 down-negotiation attack. See below.) 493 Once a SASL security layer is established, the server MUST re-issue 494 the capability results, followed by an OK response. This is 495 necessary to protect against man-in-the-middle attacks which alter 496 the capabilities list prior to SASL negotiation. 497 The capability results MUST include all SASL mechanisms. This is 498 done in order to allow client to detect active down-negotiation 499 attack. 501 When both [TLS] and SASL security layers are in effect, the 502 TLS encoding MUST be applied (when sending data) after the SASL 503 encoding, regardless of the order in which the layers were 504 negotiated. 506 Server implementations SHOULD support SASL proxy authentication so 507 that an administrator can administer a user's scripts. Proxy 508 authentication is when a user authenticates as herself/himself but 509 requests the server to act (authorize) as another user. 511 <> 519 If an AUTHENTICATE command fails with a NO response, the client may 520 try another authentication mechanism by issuing another AUTHENTICATE 521 command. In other words, the client may request authentication 522 types in decreasing order of preference. 524 Note that a failed NO response to the AUTHENTICATE command may 525 contain one of the following response codes: AUTH-TOO-WEAK, 526 ENCRYPT-NEEDED or TRANSITION-NEEDED. See section 1.4 for detailed 527 description of the relevant conditions. 529 To ensure interoperability, client and server implementations 530 of this extension MUST implement the [SCRAM] SASL 531 mechanism. 533 Implementations MAY advertise the ANONYMOUS SASL mechanism 534 [SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE 535 script syntax verification. Only the CAPABILITY, PUTSCRIPT and 536 LOGOUT commands are available to the anonymous user. All other 537 commands MUST give NO responses. Furthermore the PUTSCRIPT command 538 MUST NOT persistently store any data. In this mode a positive 539 response to the PUTSCRIPT command indicates that the given script 540 does not have any syntax errors. 542 Examples (Note that long lines are folded for readability and are 543 not part of protocol exchange): 545 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 546 S: "SASL" "DIGEST-MD5 GSSAPI" 547 S: "SIEVE" "fileinto vacation" 548 S: "STARTTLS" 549 S: OK 550 C: Authenticate "DIGEST-MD5" 551 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 552 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 553 cnNldD11dGYtOA==" 554 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 555 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 556 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 557 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 558 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=" 559 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ 560 mZmZA==") 562 A slightly different variant of the same authentication exchange: 564 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 565 S: "SASL" "DIGEST-MD5 GSSAPI" 566 S: "SIEVE" "fileinto vacation" 567 S: "STARTTLS" 568 S: OK 569 C: Authenticate "DIGEST-MD5" 570 S: {128} 571 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 572 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh 573 cnNldD11dGYtOA== 574 C: {276+} 575 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 576 QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw 577 MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9Im 578 ltYXAvZWx3b29kLmlubm9zb2Z0LmNvbSIscmVzcG9uc2U9ZDM4OGRhZDkw 579 ZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcscW9wPWF1dGg=" 580 S: {56} 581 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 582 C: "" 583 S: OK 585 Another example demostrating use of SASL PLAIN mechanism under TLS. 586 This example also demonstrate use of SASL "initial response" 587 (the second parameter to the Authenticate command): 589 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 590 S: "SASL" "" 591 S: "SIEVE" "fileinto vacation" 592 S: "STARTTLS" 593 S: OK 594 C: STARTTLS 595 S: OK 596 597 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 598 S: "SASL" "PLAIN" 599 S: "SIEVE" "fileinto vacation" 600 S: OK 601 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" 602 S: NO 603 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" 604 S: NO 605 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" 606 S: BYE "Too many failed authentication attempts" 607 609 The following example demonstrate use of SASL "initial response". 610 It also demonstrates that an empty response can be sent as a 611 literal: 613 C: AUTHENTICATE "GSSAPI" {1488+} 614 C: YIIE[...1480 octets here ...]dA== 615 S: {208} 616 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic 617 [...114 octets here ...] 618 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 619 C: {0+} 620 C: 621 S: {44} 622 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= 623 C: {44+} 624 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= 625 S: OK 627 2.2. STARTTLS Command 629 Support for STARTTLS command in servers is optional. Its 630 availability is advertised with "STARTTLS" capability as described 631 in section 1.8. 633 The STARTTLS command requests commencement of a TLS negotiation. 634 The negotiation begins immediately after the CRLF in the OK 635 response. After a client issues a STARTTLS command, it MUST NOT 636 issue further commands until a server response is seen and the TLS 637 negotiation is complete. 639 The STARTTLS command is only valid in non-authenticated state. The 640 server remains in non-authenticated state, even if client 641 credentials are supplied during the TLS negotiation. The SASL [SASL] 642 EXTERNAL mechanism MAY be used to authenticate once TLS client 643 credentials are successfully exchanged, but servers supporting the 644 STARTTLS command are not required to support the EXTERNAL mechanism. 646 After the TLS layer is established, the server MUST re-issue the 647 capability results, followed by an OK response. This is necessary to 648 protect against man-in-the-middle attacks which alter the 649 capabilities list prior to STARTTLS. This capability result MUST NOT 650 include the STARTTLS capability. 652 The client MUST discard cached capability information and replace it 653 with the new information. The server MAY advertise different 654 capabilities after STARTTLS. 656 Example: 658 C: StartTls 659 S: oK 660 661 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 662 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" 663 S: "SIEVE" "fileinto vacation" 664 S: ok 666 2.3. LOGOUT Command 668 The client sends the LOGOUT command when it is finished with a 669 connection and wishes to terminate it. The server MUST reply with an 670 OK response and terminate the connection. The server MUST ignore 671 commands issued by the client after the LOGOUT command. 673 Example: 675 C: Logout 676 S: Ok 677 679 2.4. CAPABILITY Command 681 The CAPABILITY command requests the server capabilities as described 682 earlier in this document. While the capabilities are sent upon 683 connection, they may change during authentication. The client SHOULD 684 issue a CAPABILITY command after successful authentication or after 685 negotiating a security layer using STARTTLS. 687 Example: 689 C: CAPABILITY 690 S: "IMPLEMENTATION" "Example1 ManageSieved v001" 691 S: "SASL" "PLAIN KERBEROS_V4 GSSAPI" 692 S: "SIEVE" "fileinto vacation" 693 S: "STARTTLS" 694 S: OK 696 2.5. HAVESPACE Command 698 Arguments: 699 String - name 700 Number - size 702 The HAVESPACE command is used to query the server for available 703 space. Clients specify the name they wish to save the script as and 704 its size in octets. Servers respond with an NO if storing a script 705 with that name and size would fail or OK otherwise. Clients SHOULD 706 issue this command before attempting to place a script on the 707 server. 709 Example: 711 C: HAVESPACE "myscript" 999999 712 S: NO (QUOTA) "Quota exceeded" 714 C: HAVESPACE "foobar" 435 715 S: OK 717 2.6. PUTSCRIPT Command 719 Arguments: 720 String - Script name 721 String - Script content 723 The PUTSCRIPT command is used by the client to submit a Sieve script 724 to the server. 726 If the script already exists, upon success the old script will be 727 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT 728 fails in any way. A script of zero length SHOULD be disallowed. 730 This command places the script on the server. It does not affect 731 whether the script is processed on incoming mail, unless it replaces 732 the script which is already active. The SETACTIVE 733 command is used to mark a script as active. 735 When submitting large scripts clients SHOULD use the HAVESPACE 736 command beforehand to query if the server is willing to accept a 737 script of that size. 739 The server MUST check the submitted script for syntactic validity. 740 If the script fails this test the server MUST reply with a NO 741 response. Any script that fails the validity test MUST NOT be stored 742 on the server. The message given with a NO response MUST be human 743 readable and SHOULD contain a specific error message giving the line 744 number of the first error. Implementors should strive to produce 745 helpful error messages similar to those given by programming 746 language compilers. Client implementations should note that this may 747 be a multiline literal string with more than one error message 748 separated by newlines. 750 Example: 752 C: Putscript "foo" {31+} 753 C: #comment 754 C: InvalidSieveCommand 755 C: 756 S: NO "line 2: Syntax error" 758 C: Putscript "mysievescript" {110+} 759 C: require ["fileinto"]; 760 C: 761 C: if envelope :contains "to" "tmartin+sent" { 762 C: fileinto "INBOX.sent"; 763 C: } 764 S: OK 766 2.7. LISTSCRIPTS Command 768 This command lists the scripts the user has on the server. Upon 769 success a list of CRLF separated script names (each represented 770 as a quoted or literal string) is returned followed by an OK 771 response. If there exists an active script the atom ACTIVE is 772 appended to the corresponding script name. The atom ACTIVE 773 MUST NOT appear on more than one response line. 775 Example: 777 C: Listscripts 778 S: "summer_script" 779 S: "vacation_script" 780 S: {13} 781 S: clever"script 782 S: "main_script" ACTIVE 783 S: OK 785 C: listscripts 786 S: "summer_script" 787 S: "main_script" active 788 S: OK 790 2.8. SETACTIVE Command 792 Arguments: 793 String - script name 795 This command sets a script active. If the script name is the empty 796 string (i.e. "") then any active script is disabled. Disabling an 797 active script when there is no script active is not an error and 798 MUST result in OK reply. 800 If the script does not exist on the server then the server MUST 801 reply with a NO response. 803 Examples: 805 C: Setactive "vacationscript" 806 S: Ok 808 C: Setactive "" 809 S: Ok 811 C: Setactive "baz" 812 S: No "There is no script by that name" 814 C: Setactive "baz" 815 S: No {31} 816 S: There is no script by that name 818 2.9. GETSCRIPT Command 820 Arguments: 821 String - Script name 823 This command gets the contents of the specified script. If the 824 script does not exist the server MUST reply with a NO response. Upon 825 success a string with the contents of the script is returned 826 followed by a OK response. 828 Example: 830 C: Getscript "myscript" 831 S: {54} 832 S: #this is my wonderful script 833 S: reject "I reject all"; 834 S: 835 S: OK 837 2.10. DELETESCRIPT Command 839 Parameters: 840 sieve-name - Script name 842 This command is used to delete a user's Sieve script. Servers MUST 843 reply with a NO response if the script does not exist. The server 844 MUST NOT allow the client to delete an active script, so the server 845 MUST reply with a NO response if attempted. If a client wishes to 846 delete an active script it should use the SETACTIVE command to 847 disable the script first. 849 Example: 851 C: Deletescript "foo" 852 S: Ok 854 C: Deletescript "baz" 855 S: No "You may not delete an active script" 857 3. Sieve URL Scheme 859 URI scheme name: sieve 861 Status: permanent 863 URI scheme syntax: 865 Described using ABNF [ABNF] and ABNF entities from [URI-GEN]. 867 sieveurl = sieveurl-server / sieveurl-script 869 sieveurl-server = "sieve://" authority 871 sieveurl-script = "sieve://" [ authority ] "/" scriptname 873 scriptname = *pchar 875 URI scheme semantics: 877 A Sieve URL identifies a Sieve server or a Sieve 878 script on a Sieve server. The latter form is associated with 879 the application/sieve MIME type defined in [SIEVE]. 880 There is no MIME type associated with the former form of Sieve URI. 882 The server form is used in the REFERRAL response code in order 883 to designate another server where the client should perform 884 its operations. 886 The script form allows to retrieve (GETSCRIPT), update 887 (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) 888 the named script, however the most typical action would be to 889 retrieve the script. If the script name is empty, the URI 890 requests that the client lists available scripts using 891 the LISTSCRIPTS command. 893 Encoding considerations: The script name, if present, 894 is in UTF-8. Non-US-ASCII UTF-8 octets MUST be percent-encoded as 895 described in [URI-GEN]. 897 The user name (in the "authority" part), if present, 898 is in UTF-8. Non-US-ASCII UTF-8 octets MUST be percent-encoded as 899 described in [URI-GEN]. 901 Applications/protocols that use this URI scheme name: 902 ManageSieve [RFC XXXX] clients and servers. 903 Clients that can store user preferences in protocols such as 904 [LDAP] or [ACAP]. 906 Interoperability considerations: None. 908 Security considerations: <>. 910 Contact: Alexey Melnikov 912 Author/Change controller: IESG. 914 References: This document and RFC 5228 [SIEVE]. 916 4. Formal Syntax 918 The following syntax specification uses the augmented Backus-Naur 919 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core 920 rules as specified in Appendix A of the ABNF specification [ABNF]. 921 "iana-token" and "extension-data" non-terminal are defined in 922 [ACAP]. 924 Except as noted otherwise, all alphabetic characters are case- 925 insensitive. The use of upper or lower case characters to define 926 token strings is for editorial clarity only. Implementations MUST 927 accept these strings in a case-insensitive fashion. 929 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / 930 %x5D-7F 931 ;; any TEXT-CHAR except QUOTED-SPECIALS 933 QUOTED-CHAR = SAFE-UTF8-CHAR / DQUOTE QUOTED-SPECIALS 935 QUOTED-SPECIALS = DQUOTE / "\" 937 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 / 938 UTF8-5 / UTF8-6 940 UTF8-1 = %x80-BF 942 UTF8-2 = %xC0-DF UTF8-1 944 UTF8-3 = %xE0-EF 2UTF8-1 946 UTF8-4 = %xF0-F7 3UTF8-1 948 UTF8-5 = %xF8-FB 4UTF8-1 950 UTF8-6 = %xFC-FD 5UTF8-1 952 <> 954 auth-type = DQUOTE auth-type-name DQUOTE 956 auth-type-name = iana-token 957 ;; as defined in SASL [SASL] 959 command = command-authenticate / command-logout / 960 command-getscript / command-setactive / 961 command-listscripts / command-deletescript / 962 command-putscript / command-capability / 963 command-havespace / command-starttls 965 command-authenticate = "AUTHENTICATE" SP auth-type [SP string] 966 *(CRLF string) CRLF 968 command-capability = "CAPABILITY" CRLF 970 command-deletescript = "DELETESCRIPT" SP sieve-name CRLF 972 command-getscript = "GETSCRIPT" SP sieve-name CRLF 974 command-havespace = "HAVESPACE" SP sieve-name SP number CRLF 976 command-listscripts = "LISTSCRIPTS" CRLF 978 command-logout = "LOGOUT" CRLF 980 command-putscript = "PUTSCRIPT" SP sieve-name SP string CRLF 982 command-setactive = "SETACTIVE" SP sieve-name CRLF 984 command-starttls = "STARTTLS" CRLF 986 literal-c2s = "{" number "+}" CRLF *OCTET 987 ;; The number represents the number of 988 ;; octets. 989 ;; This type of literal can only be sent 990 ;; from the client to the server. 992 literal-s2c = "{" number "}" CRLF *OCTET 993 ;; Almost identical to literal-c2s, 994 ;; but with no '+' character. 995 ;; The number represents the number of 996 ;; octets. 997 ;; This type of literal can only be sent 998 ;; from the server to the client. 1000 number = 1*DIGIT 1001 ;; A 32-bit unsigned number. 1002 ;; (0 <= n < 4,294,967,296) 1004 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE 1005 ;; limited to 1024 octets between the <">s 1007 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / 1008 "QUOTA" / resp-code-sasl / 1009 resp-code-referral / 1010 "TRANSITION-NEEDED" / "TRYLATER" / 1011 resp-code-ext 1013 resp-code-referral = "REFERRAL" SP sieveurl 1015 resp-code-sasl = "SASL" SP string 1017 resp-code-ext = iana-token [SP extension-data] 1018 ;; unknown response codes MUST be tolerated 1019 ;; by the client. "iana-token" and 1020 ;; "extension-data" are defined in [ACAP]. 1022 response = response-authenticate / 1023 response-logout / 1024 response-getscript / 1025 response-setactive / 1026 response-listscripts / 1027 response-deletescript / 1028 response-putscript / 1029 response-capability / 1030 response-havespace / 1031 response-starttls 1033 response-authenticate = *(string CRLF) (response-oknobye) 1035 response-capability = *(single-capability) response-oknobye 1037 single-capability = capability-name [SP string] CRLF 1039 capability-name = string 1040 ;; Note that literal-s2c is allowed. 1042 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / 1043 DQUOTE "SASL" DQUOTE SP sasl-mechs / 1044 DQUOTE "SIEVE" DQUOTE SP sieve-extensions / 1045 DQUOTE "STARTTLS" DQUOTE 1046 ;; Each capability conforms to 1047 ;; the syntax for single-capability. 1048 ;; Also note that the capability name 1049 ;; can be returned as either literal-s2c 1050 ;; or quoted, even though only "quoted" 1051 ;; string is shown above. 1053 sasl-mechs = string 1054 ; space separated list of SASL mechanisms, 1055 ; can be empty 1057 sieve-extensions = string 1058 ; space separated list of supported SIEVE extensions, 1059 ; can be empty 1061 response-deletescript = response-oknobye 1063 response-getscript = (string CRLF response-ok) / 1064 response-nobye 1066 response-havespace = response-oknobye 1068 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) 1069 response-oknobye 1070 ;; ACTIVE may only occur with one sieve-name 1072 response-logout = response-oknobye 1074 response-ok = "OK" [SP "(" resp-code ")"] 1075 [SP string] CRLF 1077 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] 1078 [SP string] CRLF 1080 response-oknobye = response-ok / response-nobye 1082 response-putscript = response-oknobye 1084 response-setactive = response-oknobye 1086 response-starttls = response-oknobye 1088 sieve-name = string 1089 ;; See Section 1.7 for the full list of 1090 ;; prohibited characters. 1092 string = quoted / literal-c2s / literal-s2c 1093 ;; literal-c2s is only allowed when sent 1094 ;; from the client to the server. 1095 ;; literal-s2c is only allowed when sent 1096 ;; from the server to the client. 1097 ;; quoted is allowed in either direction. 1099 <> 1102 5. Security Considerations 1104 The AUTHENTICATE command uses SASL [SASL] to provide authentication 1105 and authorization services. 1106 Integrity and privacy services can be provided by [SASL] and/or 1107 [TLS]. When a SASL mechanism is used the security considerations for 1108 that mechanism apply. 1110 This protocol's transactions are susceptible to passive observers or 1111 man in the middle attacks which alter the data, unless the optional 1112 encryption and integrity services of the SASL (via the AUTHENTICATE 1113 command) and/or [TLS] (via the STARTTLS command) are enabled, or an 1114 external security mechanism is used for protection. It may be useful 1115 to allow configuration of both clients and servers to refuse to 1116 transfer sensitive information in the absence of strong encryption. 1118 6. IANA Considerations 1120 IANA is requested to reserve TCP port number 2000 for use with 1121 the Manage Sieve protocol described in this document. 1123 IANA is requested to create a new registry for Manage Sieve 1124 capabilities. The registration template for Manage Sieve 1125 capabilities is specified in the next section. 1126 Manage Sieve protocol capabilities MUST be specified in a standards 1127 track or IESG approved experimental RFC. 1129 <> 1131 <> 1133 6.1. Manage Sieve Capability Registration Template 1135 To: iana@iana.org 1136 Subject: Manage Sieve Capability Registration 1138 Please register the following Manage Sieve Capability: 1140 Capability name: 1142 Description: 1144 Relevant publications: 1146 Person & email address to contact for further information: 1148 Author/Change controller: 1150 6.2. Registration of Initial Manage Sieve capabilities. 1152 To: iana@iana.org 1153 Subject: Manage Sieve Capability Registration 1155 Please register the following Manage Sieve Capability: 1157 Capability name: IMPLEMENTATION 1159 Description: Its value contains name of server 1160 implementation and its version. 1162 Relevant publications: this RFC, section 1.8. 1164 Person & email address to contact for further information: 1165 Alexey Melnikov 1167 Author/Change controller: IESG. 1169 To: iana@iana.org 1170 Subject: Manage Sieve Capability Registration 1172 Please register the following Manage Sieve Capability: 1174 Capability name: SASL 1176 Description: Its value contains a space separated 1177 list of SASL mechanisms supported by server. 1179 Relevant publications: this RFC, sections 1.8 and 2.1. 1181 Person & email address to contact for further information: 1182 Alexey Melnikov 1184 Author/Change controller: IESG. 1186 To: iana@iana.org 1187 Subject: Manage Sieve Capability Registration 1189 Please register the following Manage Sieve Capability: 1191 Capability name: SIEVE 1193 Description: Its value contains a space separated 1194 list of supported SIEVE extensions 1196 Relevant publications: this RFC, section 1.8. 1197 Also [SIEVE]. 1199 Person & email address to contact for further information: 1200 Alexey Melnikov 1202 Author/Change controller: IESG. 1204 To: iana@iana.org 1205 Subject: Manage Sieve Capability Registration 1207 Please register the following Manage Sieve Capability: 1209 Capability name: STARTTLS 1211 Description: This capability is returned if server 1212 supports TLS (STARTTLS command). 1214 Relevant publications: this RFC, sections 1.8 and 2.2. 1216 Person & email address to contact for further information: 1217 Alexey Melnikov 1219 Author/Change controller: IESG. 1221 To: iana@iana.org 1222 Subject: Manage Sieve Capability Registration 1224 Please register the following Manage Sieve Capability: 1226 Capability name: NOTIFY 1228 Description: This capability is returned if server 1229 supports 'enotify' Sieve extension. 1231 Relevant publications: this RFC, section 1.8. 1233 Person & email address to contact for further information: 1234 Alexey Melnikov 1236 Author/Change controller: IESG. 1238 7. References 1240 7.1. Normative References 1242 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1243 Requirement Levels", BCP 14, RFC 2119, March 1997. 1245 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1246 Specifications: ABNF", RFC 5234, January 2008. 1248 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 1249 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 1251 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1252 10646", RFC 3629, STD 63, November 2003. 1254 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1255 Security Layer (SASL)", RFC 4422, June 2006. 1257 [SASLprep] Zeilega, K., "SASLprep: Stringprep profile for User Names 1258 and Passwords", RFC 4013, February 2005. 1260 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of 1261 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 1263 [SASL-ANON] K. Zeilenga (Ed.), "Anonymous Simple Authentication and 1264 Security Layer (SASL) Mechanism", RFC 4505, June 2006. 1266 [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An Email 1267 Filtering Language", RFC 5228, January 2008. 1269 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1270 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1272 [URI-GEN] Berners-Lee, T., Fielding, R. and L. Masinter, 1273 "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, 1274 January 2005. 1276 [BASE64] - Josefsson, S., "The Base16, Base32, and Base64 Data 1277 Encodings", RFC 4648, October 2006. 1279 [NOTIFY] Melnikov, A. (Ed.), Leiba, B. (Ed.), Segmuller, W. and 1280 T. Martin, "Sieve Extension: Notifications", work in progress, 1281 draft-ietf-sieve-notify-XX.txt. 1283 [SCRAM] Menon-Sen, A. and C. Newman, "Salted Challenge Response 1284 Authentication Mechanism (SCRAM)", work in progress, 1285 draft-newman-auth-scram-05.txt. 1287 7.2. Informative References 1289 [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 1290 4rev1", RFC 3501, March 2003. 1292 [PLAIN] K. Zeilenga, "The PLAIN Simple Authentication and Security 1293 Layer (SASL) Mechanism", RFC 4616, August 2006. 1295 [DIGEST-MD5] Melnikov, A. (Ed.), "Using Digest Authentication as 1296 a SASL Mechanism", work in progress, 1297 draft-ietf-sasl-rfc2831bis-XX.txt. 1299 [LDAP] Zeilenga, K. (Ed.), "Lightweight Directory Access 1300 Protocol (LDAP): Technical Specification Road Map", RFC 4510, 1301 June 2006. 1303 8. Author's Address 1305 Tim Martin 1306 BeThereBeSquare Inc. 1307 672 Haight st. 1308 San Francisco, CA 94117 1309 Phone: (510) 260-4175 1310 EMail: timmartin@alumni.cmu.edu 1312 Alexey Melnikov 1313 Isode Ltd. 1314 5 Castle Business Village 1315 36 Station Road 1316 Hampton, Middlesex, TW12 2BX, GB 1317 Email: alexey.melnikov@isode.com 1319 Intellectual Property 1321 The IETF takes no position regarding the validity or scope of any 1322 Intellectual Property Rights or other rights that might be claimed 1323 to pertain to the implementation or use of the technology described 1324 in this document or the extent to which any license under such 1325 rights might or might not be available; nor does it represent that 1326 it has made any independent effort to identify any such rights. 1327 Information on the procedures with respect to rights in RFC 1328 documents can be found in BCP 78 and BCP 79. 1330 Copies of IPR disclosures made to the IETF Secretariat and any 1331 assurances of licenses to be made available, or the result of an 1332 attempt made to obtain a general license or permission for the use 1333 of such proprietary rights by implementers or users of this 1334 specification can be obtained from the IETF on-line IPR repository 1335 at http://www.ietf.org/ipr. 1337 The IETF invites any interested party to bring to its attention any 1338 copyrights, patents or patent applications, or other proprietary 1339 rights that may cover technology that may be required to implement 1340 this standard. Please address the information to the IETF at 1341 ietf-ipr@ietf.org. 1343 18. Full Copyright Statement 1345 Copyright (C) The IETF Trust (2008). 1347 This document is subject to the rights, licenses and restrictions 1348 contained in BCP 78, and except as set forth therein, the authors 1349 retain all their rights. 1351 This document and the information contained herein are provided on 1352 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1353 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1354 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1355 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1356 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1357 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1358 FOR A PARTICULAR PURPOSE. 1360 Acknowledgement 1362 Funding for the RFC Editor function is currently provided by the 1363 Internet Society. 1365 Appendix A. Acknowledgments 1367 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris 1368 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter 1369 Wong, Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, 1370 Phil Pennock and Jeffrey Hutzelman for help with this document.