doc/src/rfc5804.txt

   1
   2
   3
   4
   5
   6
   7 Internet Engineering Task Force (IETF)                  A. Melnikov, Ed.
   8 Request for Comments: 5804                                 Isode Limited
   9 Category: Standards Track                                      T. Martin
  10 ISSN: 2070-1721                                    BeThereBeSquare, Inc.
  11                                                                July 2010
  12
  13
  14               A Protocol for Remotely Managing Sieve Scripts
  15
  16 Abstract
  17
  18    Sieve scripts allow users to filter incoming email.  Message stores
  19    are commonly sealed servers so users cannot log into them, yet users
  20    must be able to update their scripts on them.  This document
  21    describes a protocol "ManageSieve" for securely managing Sieve
  22    scripts on a remote server.  This protocol allows a user to have
  23    multiple scripts, and also alerts a user to syntactically flawed
  24    scripts.
  25
  26 Status of This Memo
  27
  28    This is an Internet Standards Track document.
  29
  30    This document is a product of the Internet Engineering Task Force
  31    (IETF).  It represents the consensus of the IETF community.  It has
  32    received public review and has been approved for publication by the
  33    Internet Engineering Steering Group (IESG).  Further information on
  34    Internet Standards is available in Section 2 of RFC 5741.
  35
  36    Information about the current status of this document, any errata,
  37    and how to provide feedback on it may be obtained at
  38    http://www.rfc-editor.org/info/rfc5804.
  39
  40 Copyright Notice
  41
  42    Copyright (c) 2010 IETF Trust and the persons identified as the
  43    document authors.  All rights reserved.
  44
  45    This document is subject to BCP 78 and the IETF Trust's Legal
  46    Provisions Relating to IETF Documents
  47    (http://trustee.ietf.org/license-info) in effect on the date of
  48    publication of this document.  Please review these documents
  49    carefully, as they describe your rights and restrictions with respect
  50    to this document.  Code Components extracted from this document must
  51    include Simplified BSD License text as described in Section 4.e of
  52    the Trust Legal Provisions and are provided without warranty as
  53    described in the Simplified BSD License.
  54
  55
  56
  57
  58 Melnikov & Martin            Standards Track                    [Page 1]
  59 \f
  60 RFC 5804                       ManageSieve                     July 2010
  61
  62
  63 Table of Contents
  64
  65    1. Introduction ....................................................3
  66       1.1. Commands and Responses .....................................3
  67       1.2. Syntax .....................................................3
  68       1.3. Response Codes .............................................3
  69       1.4. Active Script ..............................................6
  70       1.5. Quotas .....................................................6
  71       1.6. Script Names ...............................................6
  72       1.7. Capabilities ...............................................7
  73       1.8. Transport ..................................................9
  74       1.9. Conventions Used in This Document .........................10
  75    2. Commands .......................................................10
  76       2.1. AUTHENTICATE Command ......................................11
  77            2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
  78       2.2. STARTTLS Command ..........................................16
  79            2.2.1. Server Identity Check ..............................17
  80       2.3. LOGOUT Command ............................................20
  81       2.4. CAPABILITY Command ........................................20
  82       2.5. HAVESPACE Command .........................................20
  83       2.6. PUTSCRIPT Command .........................................21
  84       2.7. LISTSCRIPTS Command .......................................23
  85       2.8. SETACTIVE Command .........................................24
  86       2.9. GETSCRIPT Command .........................................25
  87       2.10. DELETESCRIPT Command .....................................25
  88       2.11. RENAMESCRIPT Command .....................................26
  89       2.12. CHECKSCRIPT Command ......................................27
  90       2.13. NOOP Command .............................................28
  91       2.14. Recommended Extensions ...................................28
  92            2.14.1. UNAUTHENTICATE Command ............................28
  93    3. Sieve URL Scheme ...............................................29
  94    4. Formal Syntax ..................................................31
  95    5. Security Considerations ........................................37
  96    6. IANA Considerations ............................................38
  97       6.1. ManageSieve Capability Registration Template ..............39
  98       6.2. Registration of Initial ManageSieve Capabilities ..........39
  99       6.3. ManageSieve Response Code Registration Template ...........41
 100       6.4. Registration of Initial ManageSieve Response Codes ........41
 101    7. Internationalization Considerations ............................46
 102    8. Acknowledgements ...............................................46
 103    9. References .....................................................47
 104       9.1. Normative References ......................................47
 105       9.2. Informative References ....................................48
 106
 107
 108
 109
 110
 111
 112
 113
 114 Melnikov & Martin            Standards Track                    [Page 2]
 115 \f
 116 RFC 5804                       ManageSieve                     July 2010
 117
 118
 119 1.  Introduction
 120
 121 1.1.  Commands and Responses
 122
 123    A ManageSieve connection consists of the establishment of a client/
 124    server network connection, an initial greeting from the server, and
 125    client/server interactions.  These client/server interactions consist
 126    of a client command, server data, and a server completion result
 127    response.
 128
 129    All interactions transmitted by client and server are in the form of
 130    lines, that is, strings that end with a CRLF.  The protocol receiver
 131    of a ManageSieve client or server is either reading a line or reading
 132    a sequence of octets with a known count followed by a line.
 133
 134 1.2.  Syntax
 135
 136    ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP],
 137    which runs over TCP.  There are three data types: atoms, numbers and
 138    strings.  Strings may be quoted or literal.  See [ACAP] for detailed
 139    descriptions of these types.
 140
 141    Each command consists of an atom (the command name) followed by zero
 142    or more strings and numbers terminated by CRLF.
 143
 144    All client queries are replied to with either an OK, NO, or BYE
 145    response.  Each response may be followed by a response code (see
 146    Section 1.3) and by a string consisting of human-readable text in the
 147    local language (as returned by the LANGUAGE capability; see
 148    Section 1.7), encoded in UTF-8 [UTF-8].  The contents of the string
 149    SHOULD be shown to the user ,and implementations MUST NOT attempt to
 150    parse the message for meaning.
 151
 152    The BYE response SHOULD be used if the server wishes to close the
 153    connection.  A server may wish to do this because the client was idle
 154    for too long or there were too many failed authentication attempts.
 155    This response can be issued at any time and should be immediately
 156    followed by a server hang-up of the connection.  If a server has an
 157    inactivity timeout resulting in client autologout, it MUST be no less
 158    than 30 minutes after successful authentication.  The inactivity
 159    timeout MAY be less before authentication.
 160
 161 1.3.  Response Codes
 162
 163    An OK, NO, or BYE response from the server MAY contain a response
 164    code to describe the event in a more detailed machine-parsable
 165    fashion.  A response code consists of data inside parentheses in the
 166    form of an atom, possibly followed by a space and arguments.
 167
 168
 169
 170 Melnikov & Martin            Standards Track                    [Page 3]
 171 \f
 172 RFC 5804                       ManageSieve                     July 2010
 173
 174
 175    Response codes are defined when there is a specific action that a
 176    client can take based upon the additional information.  In order to
 177    support future extension, the response code is represented as a
 178    slash-separated (Solidus, %x2F) hierarchy with each level of
 179    hierarchy representing increasing detail about the error.  Response
 180    codes MUST NOT start with the Solidus character.  Clients MUST
 181    tolerate additional hierarchical response code detail that they don't
 182    understand.  For example, if the client supports the "QUOTA" response
 183    code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it
 184    should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
 185
 186    Client implementations MUST tolerate (ignore) response codes that
 187    they do not recognize.
 188
 189    The currently defined response codes are the following:
 190
 191    AUTH-TOO-WEAK
 192
 193    This response code is returned in the NO or BYE response from an
 194    AUTHENTICATE command.  It indicates that site security policy forbids
 195    the use of the requested mechanism for the specified authentication
 196    identity.
 197
 198    ENCRYPT-NEEDED
 199
 200    This response code is returned in the NO or BYE response from an
 201    AUTHENTICATE command.  It indicates that site security policy
 202    requires the use of a strong encryption mechanism for the specified
 203    authentication identity and mechanism.
 204
 205    QUOTA
 206
 207    If this response code is returned in the NO/BYE response, it means
 208    that the command would have placed the user above the site-defined
 209    quota constraints.  If this response code is returned in the OK
 210    response, it can mean that the user's storage is near its quota, or
 211    it can mean that the account exceeded its quota but that the
 212    condition is being allowed by the server (the server supports
 213    so-called soft quotas).  The QUOTA response code has two more
 214    detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user
 215    scripts) and "QUOTA/MAXSIZE" (the maximum script size).
 216
 217    REFERRAL
 218
 219    This response code may be returned with a BYE result from any
 220    command, and includes a mandatory parameter that indicates what
 221    server to access to manage this user's Sieve scripts.  The server
 222    will be specified by a Sieve URL (see Section 3).  The scriptname
 223
 224
 225
 226 Melnikov & Martin            Standards Track                    [Page 4]
 227 \f
 228 RFC 5804                       ManageSieve                     July 2010
 229
 230
 231    portion of the URL MUST NOT be specified.  The client should
 232    authenticate to the specified server and use it for all further
 233    commands in the current session.
 234
 235    SASL
 236
 237    This response code can occur in the OK response to a successful
 238    AUTHENTICATE command and includes the optional final server response
 239    data from the server as specified by [SASL].
 240
 241    TRANSITION-NEEDED
 242
 243    This response code occurs in a NO response of an AUTHENTICATE
 244    command.  It indicates that the user name is valid, but the entry in
 245    the authentication database needs to be updated in order to permit
 246    authentication with the specified mechanism.  This is typically done
 247    by establishing a secure channel using TLS, verifying server identity
 248    as specified in Section 2.2.1, and finally authenticating once using
 249    the [PLAIN] authentication mechanism.  The selected mechanism SHOULD
 250    then work for authentications in subsequent sessions.
 251
 252    This condition can happen if a user has an entry in a system
 253    authentication database such as Unix /etc/passwd, but does not have
 254    credentials suitable for use by the specified mechanism.
 255
 256    TRYLATER
 257
 258    A command failed due to a temporary server failure.  The client MAY
 259    continue using local information and try the command later.  This
 260    response code only makes sense when returned in a NO/BYE response.
 261
 262    ACTIVE
 263
 264    A command failed because it is not allowed on the active script, for
 265    example, DELETESCRIPT on the active script.  This response code only
 266    makes sense when returned in a NO/BYE response.
 267
 268    NONEXISTENT
 269
 270    A command failed because the referenced script name doesn't exist.
 271    This response code only makes sense when returned in a NO/BYE
 272    response.
 273
 274    ALREADYEXISTS
 275
 276    A command failed because the referenced script name already exists.
 277    This response code only makes sense when returned in a NO/BYE
 278    response.
 279
 280
 281
 282 Melnikov & Martin            Standards Track                    [Page 5]
 283 \f
 284 RFC 5804                       ManageSieve                     July 2010
 285
 286
 287    TAG
 288
 289    This response code name is followed by a string specified in the
 290    command.  See Section 2.13 for a possible use case.
 291
 292    WARNINGS
 293
 294    This response code MAY be returned by the server in the OK response
 295    (but it might be returned with the NO/BYE response as well) and
 296    signals the client that even though the script is syntactically
 297    valid, it might contain errors not intended by the script writer.
 298    This response code is typically returned in response to PUTSCRIPT
 299    and/or CHECKSCRIPT commands.  A client seeing such response code
 300    SHOULD present the returned warning text to the user.
 301
 302 1.4.  Active Script
 303
 304    A user may have multiple Sieve scripts on the server, yet only one
 305    script may be used for filtering of incoming messages.  This is the
 306    active script.  Users may have zero or one active script and MUST use
 307    the SETACTIVE command described below for changing the active script
 308    or disabling Sieve processing.  For example, users may have an
 309    everyday script they normally use and a special script they use when
 310    they go on vacation.  Users can change which script is being used
 311    without having to download and upload a script stored somewhere else.
 312
 313 1.5.  Quotas
 314
 315    Servers SHOULD impose quotas to prevent malicious users from
 316    overflowing available storage.  If a command would place a user over
 317    a quota setting, servers that impose such quotas MUST reply with a NO
 318    response containing the QUOTA response code.  Client implementations
 319    MUST be able to handle commands failing because of quota
 320    restrictions.
 321
 322 1.6.  Script Names
 323
 324    A Sieve script name is a sequence of Unicode characters encoded in
 325    UTF-8 [UTF-8].  A script name MUST comply with Net-Unicode Definition
 326    (Section 2 of [NET-UNICODE]), with the additional restriction of
 327    prohibiting the following Unicode characters:
 328
 329    o  0000-001F; [CONTROL CHARACTERS]
 330
 331    o  007F; DELETE
 332
 333    o  0080-009F; [CONTROL CHARACTERS]
 334
 335
 336
 337
 338 Melnikov & Martin            Standards Track                    [Page 6]
 339 \f
 340 RFC 5804                       ManageSieve                     July 2010
 341
 342
 343    o  2028; LINE SEPARATOR
 344
 345    o  2029; PARAGRAPH SEPARATOR
 346
 347    Sieve script names MUST be at least one octet (and hence Unicode
 348    character) long.  Zero octets script name has a special meaning (see
 349    Section 2.8).  Servers MUST allow names of up to 128 Unicode
 350    characters in length (which can take up to 512 bytes when encoded in
 351    UTF-8, not counting the terminating NUL), and MAY allow longer names.
 352    A server that receives a script name longer than its internal limit
 353    MUST reject the corresponding operation, in particular it MUST NOT
 354    truncate the script name.
 355
 356 1.7.  Capabilities
 357
 358    Server capabilities are sent automatically by the server upon a
 359    client connection, or after successful STARTTLS and AUTHENTICATE
 360    (which establishes a Simple Authentication and Security Layer (SASL))
 361    commands.  Capabilities may change immediately after a successfully
 362    completed STARTTLS command, and/or immediately after a successfully
 363    completed AUTHENTICATE command, and/or after a successfully completed
 364    UNAUTHENTICATE command (see Section 2.14.1).  Capabilities MUST
 365    remain static at all other times.
 366
 367    Clients MAY request the capabilities at a later time by issuing the
 368    CAPABILITY command described later.  The capabilities consist of a
 369    series of lines each with one or two strings.  The first string is
 370    the name of the capability, which is case-insensitive.  The second
 371    optional string is the value associated with that capability.  Order
 372    of capabilities is arbitrary, but each capability name can appear at
 373    most once.
 374
 375    The following capabilities are defined in this document:
 376
 377    IMPLEMENTATION - Name of implementation and version.  This capability
 378    MUST always be returned by the server.
 379
 380    SASL - List of SASL mechanisms supported by the server, each
 381    separated by a space.  This list can be empty if and only if STARTTLS
 382    is also advertised.  This means that the client must negotiate TLS
 383    encryption with STARTTLS first, at which point the SASL capability
 384    will list a non-empty list of SASL mechanisms.
 385
 386    SIEVE - List of space-separated Sieve extensions (as listed in Sieve
 387    "require" action [SIEVE]) supported by the Sieve engine.  This
 388    capability MUST always be returned by the server.
 389
 390
 391
 392
 393
 394 Melnikov & Martin            Standards Track                    [Page 7]
 395 \f
 396 RFC 5804                       ManageSieve                     July 2010
 397
 398
 399    STARTTLS - If TLS [TLS] is supported by this implementation.  Before
 400    advertising this capability a server MUST verify to the best of its
 401    ability that TLS can be successfully negotiated by a client with
 402    common cipher suites.  Specifically, a server should verify that a
 403    server certificate has been installed and that the TLS subsystem has
 404    successfully initialized.  This capability SHOULD NOT be advertised
 405    once STARTTLS or AUTHENTICATE command completes successfully.  Client
 406    and server implementations MUST implement the STARTTLS extension.
 407
 408    MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
 409    actions a script can perform during a single evaluation.  Note that
 410    this is different from the total number of "redirect" actions a
 411    script can contain.  The value is a non-negative number represented
 412    as a ManageSieve string.
 413
 414    NOTIFY - A space-separated list of URI schema parts for supported
 415    notification methods.  This capability MUST be specified if the Sieve
 416    implementation supports the "enotify" extension [NOTIFY].
 417
 418    LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently
 419    used for human-readable error messages.  If this capability is not
 420    returned, the "i-default" [RFC2277] language is assumed.  Note that
 421    the current language MAY be per-user configurable (i.e., it MAY
 422    change after authentication).
 423
 424    OWNER - The canonical name of the logged-in user (SASL "authorization
 425    identity") encoded in UTF-8.  This capability MUST NOT be returned in
 426    unauthenticated state and SHOULD be returned once the AUTHENTICATE
 427    command succeeds.
 428
 429    VERSION - This capability MUST be returned by servers compliant with
 430    this document or its successor.  For servers compliant with this
 431    document, the capability value is the string "1.0".  Lack of this
 432    capability means that the server predates this specification and thus
 433    doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT,
 434    and NOOP.
 435
 436    Section 2.14 defines some additional ManageSieve extensions and their
 437    respective capabilities.
 438
 439    A server implementation MUST return SIEVE, IMPLEMENTATION, and
 440    VERSION capabilities.
 441
 442    A client implementation MUST ignore any listed capabilities that it
 443    does not understand.
 444
 445
 446
 447
 448
 449
 450 Melnikov & Martin            Standards Track                    [Page 8]
 451 \f
 452 RFC 5804                       ManageSieve                     July 2010
 453
 454
 455        Example:
 456
 457        S: "IMPlemENTATION" "Example1 ManageSieved v001"
 458        S: "SASl" "DIGEST-MD5 GSSAPI"
 459        S: "SIeVE" "fileinto vacation"
 460        S: "StaRTTLS"
 461        S: "NOTIFY" "xmpp mailto"
 462        S: "MAXREdIRECTS" "5"
 463        S: "VERSION" "1.0"
 464        S: OK
 465
 466    After successful authentication, this might look like this:
 467
 468        Example:
 469
 470        S: "IMPlemENTATION" "Example1 ManageSieved v001"
 471        S: "SASl" "DIGEST-MD5 GSSAPI"
 472        S: "SIeVE" "fileinto vacation"
 473        S: "NOTIFY" "xmpp mailto"
 474        S: "OWNER" "alexey@example.com"
 475        S: "MAXREdIRECTS" "5"
 476        S: "VERSION" "1.0"
 477        S: OK
 478
 479 1.8.  Transport
 480
 481    The ManageSieve protocol assumes a reliable data stream such as that
 482    provided by TCP.  When TCP is used, a ManageSieve server typically
 483    listens on port 4190.
 484
 485    Before opening the TCP connection, the ManageSieve client first MUST
 486    resolve the Domain Name System (DNS) hostname associated with the
 487    receiving entity and determine the appropriate TCP port for
 488    communication with the receiving entity.  The process is as follows:
 489
 490    1.  Attempt to resolve the hostname using a [DNS-SRV] Service of
 491        "sieve" and a Proto of "tcp" for the target domain (e.g.,
 492        "example.net"), resulting in resource records such as
 493        "_sieve._tcp.example.net.".  The result of the SRV lookup, if
 494        successful, will be one or more combinations of a port and
 495        hostname; the ManageSieve client MUST resolve the returned
 496        hostnames to IPv4/IPv6 addresses according to returned SRV record
 497        weight.  IP addresses from the first successfully resolved
 498        hostname (with the corresponding port number returned by SRV
 499        lookup) are used to connect to the server.  If connection using
 500        one of the IP addresses fails, the next resolved IP address is
 501
 502
 503
 504
 505
 506 Melnikov & Martin            Standards Track                    [Page 9]
 507 \f
 508 RFC 5804                       ManageSieve                     July 2010
 509
 510
 511        used to connect.  If connection to all resolved IP addresses
 512        fails, then the resolution/connect is repeated for the next
 513        hostname returned by SRV lookup.
 514
 515    2.  If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
 516        IPv6 address record resolution to determine the IP address, where
 517        the port used is the default ManageSieve port of 4190.
 518
 519 1.9.  Conventions Used in This Document
 520
 521    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 522    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 523    document are to be interpreted as described in [KEYWORDS].
 524
 525    In examples, "C:" and "S:" indicate lines sent by the client and
 526    server respectively.  Line breaks that do not start a new "C:" or
 527    "S:" exist for editorial reasons.
 528
 529    Examples of authentication in this document are using DIGEST-MD5
 530    [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
 531
 532 2.  Commands
 533
 534    This section and its subsections describe valid ManageSieve commands.
 535    Upon initial connection to the server, the client's session is in
 536    non-authenticated state.  Prior to successful authentication, only
 537    the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section
 538    2.13) commands are valid.  ManageSieve extensions MAY define other
 539    commands that are valid in non-authenticated state.  Servers MUST
 540    reject all other commands with a NO response.  Clients may pipeline
 541    commands (send more than one command at a time without waiting for
 542    completion of the first command).  However, a group of commands sent
 543    together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a
 544    HAVESPACE command anywhere but the last command in the list.
 545
 546    (*) - The only exception to this rule is when the AUTHENTICATE
 547    command contains an initial response for a SASL mechanism that allows
 548    clients to send data first, the mechanism is known to complete in one
 549    round trip, and the mechanism doesn't negotiate a SASL security
 550    layer.  Two examples of such SASL mechanisms are PLAIN [PLAIN] and
 551    EXTERNAL [SASL].
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Melnikov & Martin            Standards Track                   [Page 10]
 563 \f
 564 RFC 5804                       ManageSieve                     July 2010
 565
 566
 567 2.1.  AUTHENTICATE Command
 568
 569    Arguments:  String - mechanism
 570                String - initial data (optional)
 571
 572    The AUTHENTICATE command indicates a SASL [SASL] authentication
 573    mechanism to the server.  If the server supports the requested
 574    authentication mechanism, it performs an authentication protocol
 575    exchange to identify and authenticate the user.  Optionally, it also
 576    negotiates a security layer for subsequent protocol interactions.  If
 577    the requested authentication mechanism is not supported, the server
 578    rejects the AUTHENTICATE command by sending the NO response.
 579
 580    The authentication protocol exchange consists of a series of server
 581    challenges and client responses that are specific to the selected
 582    authentication mechanism.  A server challenge consists of a string
 583    (quoted or literal) followed by a CRLF.  The contents of the string
 584    is a base-64 encoding [BASE64] of the SASL data.  A client response
 585    consists of a string (quoted or literal) with the base-64 encoding of
 586    the SASL data followed by a CRLF.  If the client wishes to cancel the
 587    authentication exchange, it issues a string containing a single "*".
 588    If the server receives such a response, it MUST reject the
 589    AUTHENTICATE command by sending a NO reply.
 590
 591    Note that an empty challenge/response is sent as an empty string.  If
 592    the mechanism dictates that the final response is sent by the server,
 593    this data MAY be placed within the data portion of the SASL response
 594    code to save a round trip.
 595
 596    The optional initial-response argument to the AUTHENTICATE command is
 597    used to save a round trip when using authentication mechanisms that
 598    are defined to send no data in the initial challenge.  When the
 599    initial-response argument is used with such a mechanism, the initial
 600    empty challenge is not sent to the client and the server uses the
 601    data in the initial-response argument as if it were sent in response
 602    to the empty challenge.  If the initial-response argument to the
 603    AUTHENTICATE command is used with a mechanism that sends data in the
 604    initial challenge, the server MUST reject the AUTHENTICATE command by
 605    sending the NO response.
 606
 607    The service name specified by this protocol's profile of SASL is
 608    "sieve".
 609
 610    Reauthentication is not supported by ManageSieve protocol's profile
 611    of SASL.  That is, after a successfully completed AUTHENTICATE
 612    command, no more AUTHENTICATE commands may be issued in the same
 613    session.  After a successful AUTHENTICATE command completes, a server
 614    MUST reject any further AUTHENTICATE commands with a NO reply.
 615
 616
 617
 618 Melnikov & Martin            Standards Track                   [Page 11]
 619 \f
 620 RFC 5804                       ManageSieve                     July 2010
 621
 622
 623    However, note that a server may implement the UNAUTHENTICATE
 624    extension described in Section 2.14.1.
 625
 626    If a security layer is negotiated through the SASL authentication
 627    exchange, it takes effect immediately following the CRLF that
 628    concludes the successful authentication exchange for the client, and
 629    the CRLF of the OK response for the server.
 630
 631    When a security layer takes effect, the ManageSieve protocol is reset
 632    to the initial state (the state in ManageSieve after a client has
 633    connected to the server).  The server MUST discard any knowledge
 634    obtained from the client that was not obtained from the SASL (or TLS)
 635    negotiation itself.  Likewise, the client MUST discard any knowledge
 636    obtained from the server, such as the list of ManageSieve extensions,
 637    that was not obtained from the SASL (and/or TLS) negotiation itself.
 638    (Note that a client MAY compare the advertised SASL mechanisms before
 639    and after authentication in order to detect an active down-
 640    negotiation attack.  See below.)
 641
 642    Once a SASL security layer is established, the server MUST re-issue
 643    the capability results, followed by an OK response.  This is
 644    necessary to protect against man-in-the-middle attacks that alter the
 645    capabilities list prior to SASL negotiation.  The capability results
 646    MUST include all SASL mechanisms the server was capable of
 647    negotiating with that client.  This is done in order to allow the
 648    client to detect an active down-negotiation attack.  If a user-
 649    oriented client detects such a down-negotiation attack, it SHOULD
 650    either notify the user (it MAY give the user the opportunity to
 651    continue with the ManageSieve session in this case) or close the
 652    transport connection and indicate that a down-negotiation attack
 653    might be in progress.  If an automated client detects a down-
 654    negotiation attack, it SHOULD return or log an error indicating that
 655    a possible attack might be in progress and/or SHOULD close the
 656    transport connection.
 657
 658    When both [TLS] and SASL security layers are in effect, the TLS
 659    encoding MUST be applied (when sending data) after the SASL encoding.
 660
 661    Server implementations SHOULD support SASL proxy authentication so
 662    that an administrator can administer a user's scripts.  Proxy
 663    authentication is when a user authenticates as herself/himself but
 664    requests the server to act (authorize) as another user.
 665
 666    The authorization identity generated by this [SASL] exchange is a
 667    "simple username" (in the sense defined in [SASLprep]), and both
 668    client and server MUST use the [SASLprep] profile of the [StringPrep]
 669    algorithm to prepare these names for transmission or comparison.  If
 670    preparation of the authorization identity fails or results in an
 671
 672
 673
 674 Melnikov & Martin            Standards Track                   [Page 12]
 675 \f
 676 RFC 5804                       ManageSieve                     July 2010
 677
 678
 679    empty string (unless it was transmitted as the empty string), the
 680    server MUST fail the authentication.
 681
 682    If an AUTHENTICATE command fails with a NO response, the client MAY
 683    try another authentication mechanism by issuing another AUTHENTICATE
 684    command.  In other words, the client may request authentication types
 685    in decreasing order of preference.
 686
 687    Note that a failed (NO) response to the AUTHENTICATE command may
 688    contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
 689    NEEDED, or TRANSITION-NEEDED.  See Section 1.3 for detailed
 690    description of the relevant conditions.
 691
 692    To ensure interoperability, both client and server implementations of
 693    the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL
 694    mechanism, as well as [PLAIN] over [TLS].
 695
 696    Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
 697    other email-related protocols; however, a longer-term goal is to
 698    migrate email-related protocols from using PLAIN over TLS to SCRAM-
 699    SHA-1 mechanism.
 700
 701    Examples (Note that long lines are folded for readability and are not
 702    part of protocol exchange):
 703
 704        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 705        S: "SASL" "DIGEST-MD5 GSSAPI"
 706        S: "SIEVE" "fileinto vacation"
 707        S: "STARTTLS"
 708        S: "VERSION" "1.0"
 709        S: OK
 710        C: Authenticate "DIGEST-MD5"
 711        S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
 712           9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
 713           cyxjaGFyc2V0PXV0Zi04"
 714        C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
 715           QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
 716           aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
 717           N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
 718           ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
 719           A9YXV0aA=="
 720        S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
 721           mZmZA==")
 722
 723
 724
 725
 726
 727
 728
 729
 730 Melnikov & Martin            Standards Track                   [Page 13]
 731 \f
 732 RFC 5804                       ManageSieve                     July 2010
 733
 734
 735    A slightly different variant of the same authentication exchange is:
 736
 737        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 738        S: "SASL" "DIGEST-MD5 GSSAPI"
 739        S: "SIEVE" "fileinto vacation"
 740        S: "VERSION" "1.0"
 741        S: "STARTTLS"
 742        S: OK
 743        C: Authenticate "DIGEST-MD5"
 744        S: {136}
 745        S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
 746           9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
 747           cyxjaGFyc2V0PXV0Zi04
 748        C: {300+}
 749        C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
 750           QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
 751           aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
 752           N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
 753           ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
 754           A9YXV0aA==
 755        S: {56}
 756        S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
 757        C: ""
 758        S: OK
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Melnikov & Martin            Standards Track                   [Page 14]
 787 \f
 788 RFC 5804                       ManageSieve                     July 2010
 789
 790
 791    Another example demonstrating use of SASL PLAIN mechanism under TLS
 792    follows.  This example also demonstrate use of SASL "initial
 793    response" (the second parameter to the Authenticate command):
 794
 795        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 796        S: "VERSION" "1.0"
 797        S: "SASL" ""
 798        S: "SIEVE" "fileinto vacation"
 799        S: "STARTTLS"
 800        S: OK
 801        C: STARTTLS
 802        S: OK
 803        <TLS negotiation, further commands are under TLS layer>
 804        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 805        S: "VERSION" "1.0"
 806        S: "SASL" "PLAIN"
 807        S: "SIEVE" "fileinto vacation"
 808        S: OK
 809        C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
 810        S: NO
 811        C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
 812        S: NO
 813        C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
 814        S: BYE "Too many failed authentication attempts"
 815        <Server closes connection>
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Melnikov & Martin            Standards Track                   [Page 15]
 843 \f
 844 RFC 5804                       ManageSieve                     July 2010
 845
 846
 847    The following example demonstrates use of SASL "initial response".
 848    It also demonstrates that an empty response can be sent as a literal
 849    and that negotiating a SASL security layer results in the server
 850    re-issuing server capabilities:
 851
 852        C: AUTHENTICATE "GSSAPI" {1488+}
 853        C: YIIE[...1480 octets here ...]dA==
 854        S: {208}
 855        S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
 856           [...114 octets here ...]
 857           /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
 858        C: {0+}
 859        C:
 860        S: {44}
 861        S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
 862        C: {44+}
 863        C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
 864        S: OK
 865        <Further commands/responses are under SASL security layer>
 866        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 867        S: "VERSION" "1.0"
 868        S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
 869        S: "SIEVE" "fileinto vacation"
 870        S: "LANGUAGE" "ru"
 871        S: "MAXREDIRECTS" "3"
 872        S: ok
 873
 874 2.1.1.  Use of SASL PLAIN Mechanism over TLS
 875
 876    This section is normative for ManageSieve client implementations that
 877    support SASL [PLAIN] over [TLS].
 878
 879    If a ManageSieve client is willing to use SASL PLAIN over TLS to
 880    authenticate to the ManageSieve server, the client MUST verify the
 881    server identity (see Section 2.2.1).  If the server identity can't be
 882    verified (e.g., the server has not provided any certificate, or if
 883    the certificate verification fails), the client MUST NOT attempt to
 884    authenticate using the SASL PLAIN mechanism.
 885
 886 2.2.  STARTTLS Command
 887
 888    Support for STARTTLS command in servers is optional.  Its
 889    availability is advertised with "STARTTLS" capability as described in
 890    Section 1.7.
 891
 892    The STARTTLS command requests commencement of a TLS [TLS]
 893    negotiation.  The negotiation begins immediately after the CRLF in
 894    the OK response.  After a client issues a STARTTLS command, it MUST
 895
 896
 897
 898 Melnikov & Martin            Standards Track                   [Page 16]
 899 \f
 900 RFC 5804                       ManageSieve                     July 2010
 901
 902
 903    NOT issue further commands until a server response is seen and the
 904    TLS negotiation is complete.
 905
 906    The STARTTLS command is only valid in non-authenticated state.  The
 907    server remains in non-authenticated state, even if client credentials
 908    are supplied during the TLS negotiation.  The SASL [SASL] EXTERNAL
 909    mechanism MAY be used to authenticate once TLS client credentials are
 910    successfully exchanged, but servers supporting the STARTTLS command
 911    are not required to support the EXTERNAL mechanism.
 912
 913    After the TLS layer is established, the server MUST re-issue the
 914    capability results, followed by an OK response.  This is necessary to
 915    protect against man-in-the-middle attacks that alter the capabilities
 916    list prior to STARTTLS.  This capability result MUST NOT include the
 917    STARTTLS capability.
 918
 919    The client MUST discard cached capability information and replace it
 920    with the new information.  The server MAY advertise different
 921    capabilities after STARTTLS.
 922
 923        Example:
 924
 925        C: StartTls
 926        S: oK
 927        <TLS negotiation, further commands are under TLS layer>
 928        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
 929        S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
 930        S: "SIEVE" "fileinto vacation"
 931        S: "VERSION" "1.0"
 932        S: "LANGUAGE" "fr"
 933        S: ok
 934
 935 2.2.1.  Server Identity Check
 936
 937    During the TLS negotiation, the ManageSieve client MUST check its
 938    understanding of the server hostname/IP address against the server's
 939    identity as presented in the server Certificate message, in order to
 940    prevent man-in-the-middle attacks.  In this section, the client's
 941    understanding of the server's identity is called the "reference
 942    identity".
 943
 944    Checking is performed according to the following rules:
 945
 946    o  If the reference identity is a hostname:
 947
 948       1.  If a subjectAltName extension of the SRVName [X509-SRV],
 949           dNSName [X509] (in that order of preference) type is present
 950           in the server's certificate, then it SHOULD be used as the
 951
 952
 953
 954 Melnikov & Martin            Standards Track                   [Page 17]
 955 \f
 956 RFC 5804                       ManageSieve                     July 2010
 957
 958
 959           source of the server's identity.  Matching is performed as
 960           described in Section 2.2.1.1, with the exception that no
 961           wildcard matching is allowed for SRVName type.  If the
 962           certificate contains multiple names (e.g., more than one
 963           dNSName field), then a match with any one of the fields is
 964           considered acceptable.
 965
 966       2.  The client MAY use other types of subjectAltName for
 967           performing comparison.
 968
 969       3.  The server's identity MAY also be verified by comparing the
 970           reference identity to the Common Name (CN) [RFC4519] value in
 971           the leaf Relative Distinguished Name (RDN) of the subjectName
 972           field of the server's certificate.  This comparison is
 973           performed using the rules for comparison of DNS names in
 974           Section 2.2.1.1, below.  Although the use of the Common Name
 975           value is existing practice, it is deprecated, and
 976           Certification Authorities are encouraged to provide
 977           subjectAltName values instead.  Note that the TLS
 978           implementation may represent DNs in certificates according to
 979           X.500 or other conventions.  For example, some X.500
 980           implementations order the RDNs in a DN using a left-to-right
 981           (most significant to least significant) convention instead of
 982           LDAP's right-to-left convention.
 983
 984    o  When the reference identity is an IP address, the iPAddress
 985       subjectAltName SHOULD be used by the client for comparison.  The
 986       comparison is performed as described in Section 2.2.1.2.
 987
 988    If the server identity check fails, user-oriented clients SHOULD
 989    either notify the user (clients MAY give the user the opportunity to
 990    continue with the ManageSieve session in this case) or close the
 991    transport connection and indicate that the server's identity is
 992    suspect.  Automated clients SHOULD return or log an error indicating
 993    that the server's identity is suspect and/or SHOULD close the
 994    transport connection.  Automated clients MAY provide a configuration
 995    setting that disables this check, but MUST provide a setting that
 996    enables it.
 997
 998    Beyond the server identity check described in this section, clients
 999    should be prepared to do further checking to ensure that the server
1000    is authorized to provide the service it is requested to provide.  The
1001    client may need to make use of local policy information in making
1002    this determination.
1003
1004
1005
1006
1007
1008
1009
1010 Melnikov & Martin            Standards Track                   [Page 18]
1011 \f
1012 RFC 5804                       ManageSieve                     July 2010
1013
1014
1015 2.2.1.1.  Comparison of DNS Names
1016
1017    If the reference identity is an internationalized domain name,
1018    conforming implementations MUST convert it to the ASCII Compatible
1019    Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
1020    before comparison with subjectAltName values of type dNSName.
1021    Specifically, conforming implementations MUST perform the conversion
1022    operation specified in Section 4 of [RFC3490] as follows:
1023
1024    o  in step 1, the domain name SHALL be considered a "stored string";
1025
1026    o  in step 3, set the flag called "UseSTD3ASCIIRules";
1027
1028    o  in step 4, process each label with the "ToASCII" operation; and
1029
1030    o  in step 5, change all label separators to U+002E (full stop).
1031
1032    After performing the "to-ASCII" conversion, the DNS labels and names
1033    MUST be compared for equality according to the rules specified in
1034    Section 3 of [RFC3490]; i.e., once all label separators are replaced
1035    with U+002E (dot) they are compared in the case-insensitive manner.
1036
1037    The '*' (ASCII 42) wildcard character is allowed in subjectAltName
1038    values of type dNSName, and then only as the left-most (least
1039    significant) DNS label in that value.  This wildcard matches any
1040    left-most DNS label in the server name.  That is, the subject
1041    *.example.com matches the server names a.example.com and
1042    b.example.com, but does not match example.com or a.b.example.com.
1043
1044 2.2.1.2.  Comparison of IP Addresses
1045
1046    When the reference identity is an IP address, the identity MUST be
1047    converted to the "network byte order" octet string representation
1048    [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
1049    octet string will contain exactly four octets.  For IP Version 6, as
1050    specified in RFC 2460, the octet string will contain exactly sixteen
1051    octets.  This octet string is then compared against subjectAltName
1052    values of type iPAddress.  A match occurs if the reference identity
1053    octet string and value octet strings are identical.
1054
1055 2.2.1.3.  Comparison of Other subjectName Types
1056
1057    Client implementations MAY support matching against subjectAltName
1058    values of other types as described in other documents.
1059
1060
1061
1062
1063
1064
1065
1066 Melnikov & Martin            Standards Track                   [Page 19]
1067 \f
1068 RFC 5804                       ManageSieve                     July 2010
1069
1070
1071 2.3.  LOGOUT Command
1072
1073    The client sends the LOGOUT command when it is finished with a
1074    connection and wishes to terminate it.  The server MUST reply with an
1075    OK response.  The server MUST ignore commands issued by the client
1076    after the LOGOUT command.
1077
1078    The client SHOULD wait for the OK response before closing the
1079    connection.  This avoids the TCP connection going into the TIME_WAIT
1080    state on the server.  In order to avoid going into the TIME_WAIT TCP
1081    state, the server MAY wait for a short while for the client to close
1082    the TCP connection first.  Whether or not the server waits for the
1083    client to close the connection, it MUST then close the connection
1084    itself.
1085
1086        Example:
1087
1088        C: Logout
1089        S: Ok
1090        <connection is terminated>
1091
1092 2.4.  CAPABILITY Command
1093
1094    The CAPABILITY command requests the server capabilities as described
1095    earlier in this document.  It has no parameters.
1096
1097        Example:
1098
1099        C: CAPABILITY
1100        S: "IMPLEMENTATION" "Example1 ManageSieved v001"
1101        S: "VERSION" "1.0"
1102        S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
1103        S: "SIEVE" "fileinto vacation"
1104        S: "STARTTLS"
1105        S: OK
1106
1107 2.5.  HAVESPACE Command
1108
1109    Arguments:  String - name
1110                Number - script size
1111
1112    The HAVESPACE command is used to query the server for available
1113    space.  Clients specify the name they wish to save the script as and
1114    its size in octets.  Both parameters can be used by the server to see
1115    if the script with the specified name and size is within a user's
1116    quota(s).  For example, the server MAY use the script name to check
1117    if a script would be replaced or a new one would be created.  Servers
1118    respond with a NO if storing a script with that name and size would
1119
1120
1121
1122 Melnikov & Martin            Standards Track                   [Page 20]
1123 \f
1124 RFC 5804                       ManageSieve                     July 2010
1125
1126
1127    fail or OK otherwise.  Clients SHOULD issue this command before
1128    attempting to place a script on the server.
1129
1130    Note that the OK response from the HAVESPACE command does not
1131    constitute a guarantee of success as server disk space conditions
1132    could change between the client issuing the HAVESPACE and the client
1133    issuing the PUTSCRIPT commands.  A QUOTA response code (see
1134    Section 1.3) remains a possible (albeit unlikely) response to a
1135    subsequent PUTSCRIPT with the same name and size.
1136
1137        Example:
1138
1139        C: HAVESPACE "myscript" 999999
1140        S: NO (QUOTA/MAXSIZE) "Quota exceeded"
1141
1142        C: HAVESPACE "foobar" 435
1143        S: OK
1144
1145 2.6.  PUTSCRIPT Command
1146
1147    Arguments:  String - Script name
1148                String - Script content
1149
1150    The PUTSCRIPT command is used by the client to submit a Sieve script
1151    to the server.
1152
1153    If the script already exists, upon success the old script will be
1154    overwritten.  The old script MUST NOT be overwritten if PUTSCRIPT
1155    fails in any way.  A script of zero length SHOULD be disallowed.
1156
1157    This command places the script on the server.  It does not affect
1158    whether the script is processed on incoming mail, unless it replaces
1159    the script that is already active.  The SETACTIVE command is used to
1160    mark a script as active.
1161
1162    When submitting large scripts, clients SHOULD use the HAVESPACE
1163    command beforehand to query if the server is willing to accept a
1164    script of that size.
1165
1166    The server MUST check the submitted script for validity, which
1167    includes checking that the script complies with the Sieve grammar
1168    [SIEVE] and that all Sieve extensions mentioned in the script's
1169    "require" statement(s) are supported by the Sieve interpreter.  (Note
1170    that if the Sieve interpreter supports the Sieve "ihave" extension
1171    [I-HAVE], any unrecognized/unsupported extension mentioned in the
1172    "ihave" test MUST NOT cause the validation failure.)  Other checks
1173    such as validating the supplied command arguments for each command
1174    MAY be performed.  Essentially, the performed validation SHOULD be
1175
1176
1177
1178 Melnikov & Martin            Standards Track                   [Page 21]
1179 \f
1180 RFC 5804                       ManageSieve                     July 2010
1181
1182
1183    the same as performed when compiling the script for execution.
1184    Implementations that use a binary representation to store compiled
1185    scripts can extend the validation to a full compilation, in order to
1186    avoid validating uploaded scripts multiple times.
1187
1188    If the script fails the validation, the server MUST reply with a NO
1189    response.  Any script that fails the validity test MUST NOT be stored
1190    on the server.  The message given with a NO response MUST be human
1191    readable and SHOULD contain a specific error message giving the line
1192    number of the first error.  Implementors should strive to produce
1193    helpful error messages similar to those given by programming language
1194    compilers.  Client implementations should note that this may be a
1195    multiline literal string with more than one error message separated
1196    by CRLFs.  The human-readable message is in the language returned in
1197    the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1198    encoded in UTF-8 [UTF-8].
1199
1200    An OK response MAY contain the WARNINGS response code.  In such a
1201    case the human-readable message that follows the OK response SHOULD
1202    contain a specific warning message (or messages) giving the line
1203    number(s) in the script that might contain errors not intended by the
1204    script writer.  The human-readable message is in the language
1205    returned in the latest LANGUAGE capability (or in "i-default"; see
1206    Section 1.7), encoded in UTF-8 [UTF-8].  A client seeing such a
1207    response code SHOULD present the message to the user.
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234 Melnikov & Martin            Standards Track                   [Page 22]
1235 \f
1236 RFC 5804                       ManageSieve                     July 2010
1237
1238
1239        Examples:
1240
1241        C: Putscript "foo" {31+}
1242        C: #comment
1243        C: InvalidSieveCommand
1244        C:
1245        S: NO "line 2: Syntax error"
1246
1247        C: Putscript "mysievescript" {110+}
1248        C: require ["fileinto"];
1249        C:
1250        C: if envelope :contains "to" "tmartin+sent" {
1251        C:   fileinto "INBOX.sent";
1252        C: }
1253        S: OK
1254
1255        C: Putscript "myforwards" {190+}
1256        C: redirect "111@example.net";
1257        C:
1258        C: if size :under 10k {
1259        C:     redirect "mobile@cell.example.com";
1260        C: }
1261        C:
1262        C: if envelope :contains "to" "tmartin+lists" {
1263        C:     redirect "lists@groups.example.com";
1264        C: }
1265        S: OK (WARNINGS) "line 8: server redirect action
1266                limit is 2, this redirect might be ignored"
1267
1268 2.7.  LISTSCRIPTS Command
1269
1270    This command lists the scripts the user has on the server.  Upon
1271    success, a list of CRLF-separated script names (each represented as a
1272    quoted or literal string) is returned followed by an OK response.  If
1273    there exists an active script, the atom ACTIVE is appended to the
1274    corresponding script name.  The atom ACTIVE MUST NOT appear on more
1275    than one response line.
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Melnikov & Martin            Standards Track                   [Page 23]
1291 \f
1292 RFC 5804                       ManageSieve                     July 2010
1293
1294
1295        Example:
1296
1297        C: Listscripts
1298        S: "summer_script"
1299        S: "vacation_script"
1300        S: {13}
1301        S: clever"script
1302        S: "main_script" ACTIVE
1303        S: OK
1304
1305        C: listscripts
1306        S: "summer_script"
1307        S: "main_script" active
1308        S: OK
1309
1310 2.8.  SETACTIVE Command
1311
1312    Arguments:  String - script name
1313
1314    This command sets a script active.  If the script name is the empty
1315    string (i.e., ""), then any active script is disabled.  Disabling an
1316    active script when there is no script active is not an error and MUST
1317    result in an OK reply.
1318
1319    If the script does not exist on the server, then the server MUST
1320    reply with a NO response.  Such a reply SHOULD contain the
1321    NONEXISTENT response code.
1322
1323        Examples:
1324
1325        C: Setactive "vacationscript"
1326        S: Ok
1327
1328        C: Setactive ""
1329        S: Ok
1330
1331        C: Setactive "baz"
1332        S: No (NONEXISTENT) "There is no script by that name"
1333
1334        C: Setactive "baz"
1335        S: No (NONEXISTENT) {31}
1336        S: There is no script by that name
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Melnikov & Martin            Standards Track                   [Page 24]
1347 \f
1348 RFC 5804                       ManageSieve                     July 2010
1349
1350
1351 2.9.  GETSCRIPT Command
1352
1353    Arguments:  String - script name
1354
1355    This command gets the contents of the specified script.  If the
1356    script does not exist, the server MUST reply with a NO response.
1357    Such a reply SHOULD contain the NONEXISTENT response code.
1358
1359    Upon success, a string with the contents of the script is returned
1360    followed by an OK response.
1361
1362        Example:
1363
1364        C: Getscript "myscript"
1365        S: {54}
1366        S: #this is my wonderful script
1367        S: reject "I reject all";
1368        S:
1369        S: OK
1370
1371 2.10.  DELETESCRIPT Command
1372
1373    Arguments:  String - script name
1374
1375    This command is used to delete a user's Sieve script.  Servers MUST
1376    reply with a NO response if the script does not exist.  Such
1377    responses SHOULD include the NONEXISTENT response code.
1378
1379    The server MUST NOT allow the client to delete an active script, so
1380    the server MUST reply with a NO response if attempted.  Such a
1381    response SHOULD contain the ACTIVE response code.  If a client wishes
1382    to delete an active script, it should use the SETACTIVE command to
1383    disable the script first.
1384
1385        Example:
1386
1387        C: Deletescript "foo"
1388        S: Ok
1389
1390        C: Deletescript "baz"
1391        S: No (ACTIVE) "You may not delete an active script"
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Melnikov & Martin            Standards Track                   [Page 25]
1403 \f
1404 RFC 5804                       ManageSieve                     July 2010
1405
1406
1407 2.11.  RENAMESCRIPT Command
1408
1409    Arguments:  String - Old Script name
1410                String - New Script name
1411
1412    This command is used to rename a user's Sieve script.  Servers MUST
1413    reply with a NO response if the old script does not exist (in which
1414    case the NONEXISTENT response code SHOULD be included), or a script
1415    with the new name already exists (in which case the ALREADYEXISTS
1416    response code SHOULD be included).  Renaming the active script is
1417    allowed; the renamed script remains active.
1418
1419        Example:
1420
1421        C: Renamescript "foo" "bar"
1422        S: Ok
1423
1424        C: Renamescript "baz" "bar"
1425        S: No "bar already exists"
1426
1427    If the server doesn't support the RENAMESCRIPT command, the client
1428    can emulate it by performing the following steps:
1429
1430    1.  List available scripts with LISTSCRIPTS.  If the script with the
1431        new script name exists, then the client should ask the user
1432        whether to abort the operation, to replace the script (by issuing
1433        the DELETESCRIPT <newname> after that), or to choose a different
1434        name.
1435
1436    2.  Download the old script with GETSCRIPT <oldname>.
1437
1438    3.  Upload the old script with the new name: PUTSCRIPT <newname>.
1439
1440    4.  If the old script was active (as reported by LISTSCRIPTS in step
1441        1), then make the new script active: SETACTIVE <newname>.
1442
1443    5.  Delete the old script: DELETESCRIPT <oldname>.
1444
1445    Note that these steps don't describe how to handle various other
1446    error conditions (for example, NO response containing QUOTA response
1447    code in step 3).  Error handling is left as an exercise for the
1448    reader.
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Melnikov & Martin            Standards Track                   [Page 26]
1459 \f
1460 RFC 5804                       ManageSieve                     July 2010
1461
1462
1463 2.12.  CHECKSCRIPT Command
1464
1465    Arguments:  String - Script content
1466
1467    The CHECKSCRIPT command is used by the client to verify Sieve script
1468    validity without storing the script on the server.
1469
1470    The server MUST check the submitted script for syntactic validity,
1471    which includes checking that all Sieve extensions mentioned in Sieve
1472    script "require" statement(s) are supported by the Sieve interpreter.
1473    (Note that if the Sieve interpreter supports the Sieve "ihave"
1474    extension [I-HAVE], any unrecognized/unsupported extension mentioned
1475    in the "ihave" test MUST NOT cause the syntactic validation failure.)
1476    If the script fails this test, the server MUST reply with a NO
1477    response.  The message given with a NO response MUST be human
1478    readable and SHOULD contain a specific error message giving the line
1479    number of the first error.  Implementors should strive to produce
1480    helpful error messages similar to those given by programming language
1481    compilers.  Client implementations should note that this may be a
1482    multiline literal string with more than one error message separated
1483    by CRLFs.  The human-readable message is in the language returned in
1484    the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1485    encoded in UTF-8 [UTF-8].
1486
1487        Examples:
1488
1489        C: CheckScript {31+}
1490        C: #comment
1491        C: InvalidSieveCommand
1492        C:
1493        S: NO "line 2: Syntax error"
1494
1495    A ManageSieve server supporting this command MUST NOT check if the
1496    script will put the current user over its quota limit.
1497
1498    An OK response MAY contain the WARNINGS response code.  In such a
1499    case, the human-readable message that follows the OK response SHOULD
1500    contain a specific warning message (or messages) giving the line
1501    number(s) in the script that might contain errors not intended by the
1502    script writer.  The human-readable message is in the language
1503    returned in the latest LANGUAGE capability (or in "i-default"; see
1504    Section 1.7), encoded in UTF-8 [UTF-8].  A client seeing such a
1505    response code SHOULD present the message to the user.
1506
1507
1508
1509
1510
1511
1512
1513
1514 Melnikov & Martin            Standards Track                   [Page 27]
1515 \f
1516 RFC 5804                       ManageSieve                     July 2010
1517
1518
1519 2.13.  NOOP Command
1520
1521    Arguments:  String - tag to echo back (optional)
1522
1523    The NOOP command does nothing, beyond returning a response to the
1524    client.  It may be used by clients for protocol re-synchronization or
1525    to reset any inactivity auto-logout timer on the server.
1526
1527    The response to the NOOP command is always OK, followed by the TAG
1528    response code together with the supplied string.  If no string was
1529    supplied in the NOOP command, the TAG response code MUST NOT be
1530    included.
1531
1532        Examples:
1533
1534        C: NOOP
1535        S: OK "NOOP completed"
1536
1537        C: NOOP "STARTTLS-SYNC-42"
1538        S: OK (TAG {16}
1539        S: STARTTLS-SYNC-42) "Done"
1540
1541 2.14.  Recommended Extensions
1542
1543    The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
1544    capability with no parameters) defines a new UNAUTHENTICATE command,
1545    which allows a client to return the server to non-authenticated
1546    state.  Support for this extension is RECOMMENDED.
1547
1548 2.14.1.  UNAUTHENTICATE Command
1549
1550    The UNAUTHENTICATE command returns the server to the
1551    non-authenticated state.  It doesn't affect any previously
1552    established TLS [TLS] or SASL (Section 2.1) security layer.
1553
1554    The UNAUTHENTICATE command is only valid in authenticated state.  If
1555    issued in a wrong state, the server MUST reject it with a NO
1556    response.
1557
1558    The UNAUTHENTICATE command has no parameters.
1559
1560    When issued in the authenticated state, the UNAUTHENTICATE command
1561    MUST NOT fail (i.e., it must never return anything other than OK or
1562    BYE).
1563
1564
1565
1566
1567
1568
1569
1570 Melnikov & Martin            Standards Track                   [Page 28]
1571 \f
1572 RFC 5804                       ManageSieve                     July 2010
1573
1574
1575 3.  Sieve URL Scheme
1576
1577    URI scheme name: sieve
1578
1579    Status: permanent
1580
1581    URI scheme syntax: Described using ABNF [ABNF].  Some ABNF
1582    productions not defined below are from [URI-GEN].
1583
1584          sieveurl = sieveurl-server / sieveurl-list-scripts /
1585                     sieveurl-script
1586
1587          sieveurl-server = "sieve://" authority
1588
1589          sieveurl-list-scripts = "sieve://" authority ["/"]
1590
1591          sieveurl-script = "sieve://" authority "/"
1592                            [owner "/"] scriptname
1593
1594          authority = <defined in [URI-GEN]>
1595
1596          owner         = *ochar
1597                          ;; %-encoded version of [SASL] authorization
1598                          ;; identity (script owner) or "userid".
1599                          ;;
1600                          ;; Empty owner is used to reference
1601                          ;; global scripts.
1602                          ;;
1603                          ;; Note that ASCII characters such as " ", ";",
1604                          ;; "&", "=", "/" and "?" must be %-encoded
1605                          ;; as per rule specified in [URI-GEN].
1606
1607          scriptname    = 1*ochar
1608                          ;; %-encoded version of UTF-8 representation
1609                          ;; of the script name.
1610                          ;; Note that ASCII characters such as " ", ";",
1611                          ;; "&", "=", "/" and "?" must be %-encoded
1612                          ;; as per rule specified in [URI-GEN].
1613
1614          ochar         = unreserved / pct-encoded / sub-delims-sh /
1615                          ":" / "@"
1616                          ;; Same as [URI-GEN] 'pchar',
1617                          ;; but without ";", "&" and "=".
1618
1619          unreserved = <defined in [URI-GEN]>
1620
1621          pct-encoded = <defined in [URI-GEN]>
1622
1623
1624
1625
1626 Melnikov & Martin            Standards Track                   [Page 29]
1627 \f
1628 RFC 5804                       ManageSieve                     July 2010
1629
1630
1631          sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
1632                          "*" / "+" / ","
1633                          ;; Same as [URI-GEN] sub-delims,
1634                          ;; but without ";", "&" and "=".
1635
1636    URI scheme semantics:
1637
1638       A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
1639       server.  The latter form is associated with the application/sieve
1640       MIME type defined in [SIEVE].  There is no MIME type associated
1641       with the former form of Sieve URI.
1642
1643       The server form is used in the REFERRAL response code (see Section
1644       1.3) in order to designate another server where the client should
1645       perform its operations.
1646
1647       The script form allows to retrieve (GETSCRIPT), update
1648       (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the
1649       named script; however, the most typical action would be to
1650       retrieve the script.  If the script name is empty (omitted), the
1651       URI requests that the client lists available scripts using the
1652       LISTSCRIPTS command.
1653
1654    Encoding considerations:
1655
1656       The script name and/or the owner, if present, is in UTF-8.  Non--
1657       US-ASCII UTF-8 octets MUST be percent-encoded as described in
1658       [URI-GEN].  US-ASCII characters such as " " (space), ";", "&",
1659       "=", "/" and "?"  MUST be %-encoded as described in [URI-GEN].
1660       Note that "&" and "?" are in this list in order to allow for
1661       future extensions.
1662
1663       Note that the empty owner (e.g., sieve://example.com//script) is
1664       different from the missing owner (e.g.,
1665       sieve://example.com/script) and is reserved for referencing global
1666       scripts.
1667
1668       The user name (in the "authority" part), if present, is in UTF-8.
1669       Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
1670       [URI-GEN].
1671
1672    Applications/protocols that use this URI scheme name:
1673    ManageSieve [RFC5804] clients and servers.  Clients that can store
1674    user preferences in protocols such as [LDAP] or [ACAP].
1675
1676    Interoperability considerations: None.
1677
1678
1679
1680
1681
1682 Melnikov & Martin            Standards Track                   [Page 30]
1683 \f
1684 RFC 5804                       ManageSieve                     July 2010
1685
1686
1687    Security considerations:
1688    The <scriptname> part of a ManageSieve URL might potentially disclose
1689    some confidential information about the author of the script or,
1690    depending on a ManageSieve implementation, about configuration of the
1691    mail system.  The latter might be used to prepare for a more complex
1692    attack on the mail system.
1693
1694    Clients resolving ManageSieve URLs that wish to achieve data
1695    confidentiality and/or integrity SHOULD use the STARTTLS command (if
1696    supported by the server) before starting authentication, or use a
1697    SASL mechanism, such as GSSAPI, that provides a confidentiality
1698    security layer.
1699
1700    Contact: Alexey Melnikov <alexey.melnikov@isode.com>
1701
1702    Author/Change controller: IESG.
1703
1704    References: This document and RFC 5228 [SIEVE].
1705
1706 4.  Formal Syntax
1707
1708    The following syntax specification uses the Augmented Backus-Naur
1709    Form (BNF) notation as specified in [ABNF].  This uses the ABNF core
1710    rules as specified in Appendix A of the ABNF specification [ABNF].
1711    "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
1712
1713    Except as noted otherwise, all alphabetic characters are case-
1714    insensitive.  The use of upper- or lowercase characters to define
1715    token strings is for editorial clarity only.  Implementations MUST
1716    accept these strings in a case-insensitive fashion.
1717
1718     SAFE-CHAR             = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
1719                             %x5D-7F
1720                             ;; any TEXT-CHAR except QUOTED-SPECIALS
1721
1722     QUOTED-CHAR           = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
1723
1724     QUOTED-SPECIALS       = DQUOTE / "\"
1725
1726     SAFE-UTF8-CHAR        = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
1727                             ;; <UTF8-2>, <UTF8-3>, and <UTF8-4>
1728                             ;; are defined in [UTF-8].
1729
1730     ATOM-CHAR             = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
1731                             ;; Any CHAR except ATOM-SPECIALS
1732
1733     ATOM-SPECIALS         = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
1734
1735
1736
1737
1738 Melnikov & Martin            Standards Track                   [Page 31]
1739 \f
1740 RFC 5804                       ManageSieve                     July 2010
1741
1742
1743     NZDIGIT               = %x31-39
1744                             ;; 1-9
1745
1746     atom                  = 1*1024ATOM-CHAR
1747
1748     iana-token            = atom
1749                             ;; MUST be registered with IANA
1750
1751     auth-type             = DQUOTE auth-type-name DQUOTE
1752
1753     auth-type-name        = iana-token
1754                             ;; as defined in SASL [SASL]
1755
1756     command               = (command-any / command-auth /
1757                              command-nonauth) CRLF
1758                             ;; Modal based on state
1759
1760     command-any           = command-capability / command-logout /
1761                             command-noop
1762                             ;; Valid in all states
1763
1764     command-auth          = command-getscript / command-setactive /
1765                             command-listscripts / command-deletescript /
1766                             command-putscript / command-checkscript /
1767                             command-havespace /
1768                             command-renamescript /
1769                             command-unauthenticate
1770                             ;; Valid only in Authenticated state
1771
1772     command-nonauth       = command-authenticate / command-starttls
1773                             ;; Valid only when in Non-Authenticated
1774                             ;; state
1775
1776     command-authenticate  = "AUTHENTICATE" SP auth-type [SP string]
1777                             *(CRLF string)
1778
1779     command-capability    = "CAPABILITY"
1780
1781     command-deletescript  = "DELETESCRIPT" SP sieve-name
1782
1783     command-getscript     = "GETSCRIPT" SP sieve-name
1784
1785     command-havespace     = "HAVESPACE" SP sieve-name SP number
1786
1787     command-listscripts   = "LISTSCRIPTS"
1788
1789     command-noop          = "NOOP" [SP string]
1790
1791
1792
1793
1794 Melnikov & Martin            Standards Track                   [Page 32]
1795 \f
1796 RFC 5804                       ManageSieve                     July 2010
1797
1798
1799     command-logout        = "LOGOUT"
1800
1801     command-putscript     = "PUTSCRIPT" SP sieve-name SP sieve-script
1802
1803     command-checkscript   = "CHECKSCRIPT" SP sieve-script
1804
1805     sieve-script          = string
1806
1807     command-renamescript  = "RENAMESCRIPT" SP old-sieve-name SP
1808                             new-sieve-name
1809
1810     old-sieve-name        = sieve-name
1811
1812     new-sieve-name        = sieve-name
1813
1814     command-setactive     = "SETACTIVE" SP active-sieve-name
1815
1816     command-starttls      = "STARTTLS"
1817
1818     command-unauthenticate= "UNAUTHENTICATE"
1819
1820     extend-token          = atom
1821                             ;; MUST be defined by a Standards Track or
1822                             ;; IESG-approved experimental protocol
1823                             ;; extension
1824
1825     extension-data        = extension-item *(SP extension-item)
1826
1827     extension-item        = extend-token / string / number /
1828                             "(" [extension-data] ")"
1829
1830     literal-c2s           = "{" number "+}" CRLF *OCTET
1831                             ;; The number represents the number of
1832                             ;; octets.
1833                             ;; This type of literal can only be sent
1834                             ;; from the client to the server.
1835
1836     literal-s2c           = "{" number "}" CRLF *OCTET
1837                             ;; Almost identical to literal-c2s,
1838                             ;; but with no '+' character.
1839                             ;; The number represents the number of
1840                             ;; octets.
1841                             ;; This type of literal can only be sent
1842                             ;; from the server to the client.
1843
1844
1845
1846
1847
1848
1849
1850 Melnikov & Martin            Standards Track                   [Page 33]
1851 \f
1852 RFC 5804                       ManageSieve                     July 2010
1853
1854
1855     number                = (NZDIGIT *DIGIT) / "0"
1856                             ;; A 32-bit unsigned number
1857                             ;; with no extra leading zeros.
1858                             ;; (0 <= n < 4,294,967,296)
1859
1860     number-str            = string
1861                             ;; <number> encoded as a <string>.
1862
1863     quoted                = DQUOTE *1024QUOTED-CHAR DQUOTE
1864                             ;; limited to 1024 octets between the <">s
1865
1866     resp-code             = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
1867                             ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
1868                             resp-code-sasl /
1869                             resp-code-referral /
1870                             "TRANSITION-NEEDED" / "TRYLATER" /
1871                             "ACTIVE" / "NONEXISTENT" /
1872                             "ALREADYEXISTS" / "WARNINGS" /
1873                             "TAG" SP string /
1874                             resp-code-ext
1875
1876     resp-code-referral    = "REFERRAL" SP sieveurl
1877
1878     resp-code-sasl        = "SASL" SP string
1879
1880     resp-code-name        = iana-token
1881                             ;; The response code name is hierarchical,
1882                             ;; separated by '/'.
1883                             ;; The response code name MUST NOT start
1884                             ;; with '/'.
1885
1886     resp-code-ext         = resp-code-name [SP extension-data]
1887                             ;; unknown response codes MUST be tolerated
1888                             ;; by the client.
1889
1890     response              = response-authenticate /
1891                             response-logout /
1892                             response-getscript /
1893                             response-setactive /
1894                             response-listscripts /
1895                             response-deletescript /
1896                             response-putscript /
1897                             response-checkscript /
1898                             response-capability /
1899                             response-havespace /
1900                             response-starttls /
1901                             response-renamescript /
1902                             response-noop /
1903
1904
1905
1906 Melnikov & Martin            Standards Track                   [Page 34]
1907 \f
1908 RFC 5804                       ManageSieve                     July 2010
1909
1910
1911                             response-unauthenticate
1912
1913     response-authenticate = *(string CRLF)
1914                             ((response-ok [response-capability]) /
1915                              response-nobye)
1916                             ;; <response-capability> is REQUIRED if a
1917                             ;; SASL security layer was negotiated and
1918                             ;; MUST be omitted otherwise.
1919
1920     response-capability   = *(single-capability) response-oknobye
1921
1922     single-capability     = capability-name [SP string] CRLF
1923
1924     capability-name       = string
1925
1926                             ;; Note that literal-s2c is allowed.
1927
1928     initial-capabilities  = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
1929                             DQUOTE "SASL" DQUOTE SP sasl-mechs /
1930                             DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
1931                             DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
1932                             DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
1933                             DQUOTE "STARTTLS" DQUOTE /
1934                             DQUOTE "LANGUAGE" DQUOTE SP language /
1935                             DQUOTE "VERSION" DQUOTE SP version /
1936                             DQUOTE "OWNER" DQUOTE SP string
1937                             ;; Each capability conforms to
1938                             ;; the syntax for single-capability.
1939                             ;; Also, note that the capability name
1940                             ;; can be returned as either literal-s2c
1941                             ;; or quoted, even though only "quoted"
1942                             ;; string is shown above.
1943
1944     version = ( DQUOTE "1.0" DQUOTE ) / version-ext
1945
1946     version-ext = DQUOTE ver-major "." ver-minor DQUOTE
1947                  ; Future versions specified in updates
1948                  ; to this document.  An increment to
1949                  ; the ver-major means a backward-incompatible
1950                  ; change to the protocol, e.g., "3.5" (ver-major "3")
1951                  ; is not backward-compatible with any "2.X" version.
1952                  ; Any version "Z.W" MUST be backward compatible
1953                  ; with any version "Z.Q", where Q < W.
1954                  ; For example, version "2.4" is backward compatible
1955                  ; with version "2.0", "2.1", "2.2", and "2.3".
1956
1957     ver-major = number
1958
1959
1960
1961
1962 Melnikov & Martin            Standards Track                   [Page 35]
1963 \f
1964 RFC 5804                       ManageSieve                     July 2010
1965
1966
1967     ver-minor = number
1968
1969     sasl-mechs = string
1970                  ; Space-separated list of SASL mechanisms,
1971                  ; each SASL mechanism name complies with rules
1972                  ; specified in [SASL].
1973                  ; Can be empty.
1974
1975     sieve-extensions = string
1976                  ; Space-separated list of supported SIEVE extensions.
1977                  ; Can be empty.
1978
1979     language     = string
1980                  ; Contains <Language-Tag> from [RFC5646].
1981
1982
1983     notify-mechs = string
1984                  ; Space-separated list of URI schema parts
1985                  ; for supported notification [NOTIFY] methods.
1986                  ; MUST NOT be empty.
1987
1988     response-deletescript = response-oknobye
1989
1990     response-getscript    = (sieve-script CRLF response-ok) /
1991                             response-nobye
1992
1993     response-havespace    = response-oknobye
1994
1995     response-listscripts  = *(sieve-name [SP "ACTIVE"] CRLF)
1996                             response-oknobye
1997                             ;; ACTIVE may only occur with one sieve-name
1998
1999     response-logout       = response-oknobye
2000
2001     response-unauthenticate= response-oknobye
2002                              ;; "NO" response can only be returned when
2003                              ;; the command is issued in a wrong state
2004                              ;; or has a wrong number of parameters
2005
2006     response-ok           = "OK" [SP "(" resp-code ")"]
2007                             [SP string] CRLF
2008                             ;; The string contains human-readable text
2009                             ;; encoded as UTF-8.
2010
2011     response-nobye        = ("NO" / "BYE") [SP "(" resp-code ")"]
2012                             [SP string] CRLF
2013                             ;; The string contains human-readable text
2014                             ;; encoded as UTF-8.
2015
2016
2017
2018 Melnikov & Martin            Standards Track                   [Page 36]
2019 \f
2020 RFC 5804                       ManageSieve                     July 2010
2021
2022
2023     response-oknobye      = response-ok / response-nobye
2024
2025     response-noop         = response-ok
2026
2027     response-putscript    = response-oknobye
2028
2029     response-checkscript  = response-oknobye
2030
2031     response-renamescript = response-oknobye
2032
2033     response-setactive    = response-oknobye
2034
2035     response-starttls     = (response-ok response-capability) /
2036                             response-nobye
2037
2038     sieve-name            = string
2039                             ;; See Section 1.6 for the full list of
2040                             ;; prohibited characters.
2041                             ;; Empty string is not allowed.
2042
2043     active-sieve-name     = string
2044                             ;; See Section 1.6 for the full list of
2045                             ;; prohibited characters.
2046                             ;; This is similar to <sieve-name>, but
2047                             ;; empty string is allowed and has a special
2048                             ;; meaning.
2049
2050     string                = quoted / literal-c2s / literal-s2c
2051                             ;; literal-c2s is only allowed when sent
2052                             ;; from the client to the server.
2053                             ;; literal-s2c is only allowed when sent
2054                             ;; from the server to the client.
2055                             ;; quoted is allowed in either direction.
2056
2057 5.  Security Considerations
2058
2059    The AUTHENTICATE command uses SASL [SASL] to provide authentication
2060    and authorization services.  Integrity and privacy services can be
2061    provided by [SASL] and/or [TLS].  When a SASL mechanism is used, the
2062    security considerations for that mechanism apply.
2063
2064    This protocol's transactions are susceptible to passive observers or
2065    man-in-the-middle attacks that alter the data, unless the optional
2066    encryption and integrity services of the SASL (via the AUTHENTICATE
2067    command) and/or [TLS] (via the STARTTLS command) are enabled, or an
2068    external security mechanism is used for protection.  It may be useful
2069    to allow configuration of both clients and servers to refuse to
2070    transfer sensitive information in the absence of strong encryption.
2071
2072
2073
2074 Melnikov & Martin            Standards Track                   [Page 37]
2075 \f
2076 RFC 5804                       ManageSieve                     July 2010
2077
2078
2079    If an implementation supports SASL mechanisms that are vulnerable to
2080    passive eavesdropping attacks (such as [PLAIN]), then the
2081    implementation MUST support at least one configuration where these
2082    SASL mechanisms are not advertised or used without the presence of an
2083    external security layer such as [TLS].
2084
2085    Some response codes returned on failed AUTHENTICATE command may
2086    disclose whether or not the username is valid (e.g., TRANSITION-
2087    NEEDED), so server implementations SHOULD provide the ability to
2088    disable these features (or make them not conditional on a per-user
2089    basis) for sites concerned about such disclosure.  In the case of
2090    ENCRYPT-NEEDED, if it is applied to all identities then no extra
2091    information is disclosed, but if it is applied on a per-user basis it
2092    can disclose information.
2093
2094    A compromised or malicious server can use the TRANSITION-NEEDED
2095    response code to force the client that is configured to use a
2096    mechanism that does not disclose the user's password to the server
2097    (e.g., Kerberos), to send the bare password to the server.  Clients
2098    SHOULD have the ability to disable the password transition feature,
2099    or disclose that risk to the user and offer the user an option of how
2100    to proceed.
2101
2102 6.  IANA Considerations
2103
2104    IANA has reserved TCP port number 4190 for use with the ManageSieve
2105    protocol described in this document.
2106
2107    IANA has registered the "sieve" URI scheme defined in Section 3 of
2108    this document.
2109
2110    IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service
2111    Names" registry.
2112
2113    IANA has created a new registry for ManageSieve capabilities.  The
2114    registration template for ManageSieve capabilities is specified in
2115    Section 6.1.  ManageSieve protocol capabilities MUST be specified in
2116    a Standards-Track or IESG-approved Experimental RFC.
2117
2118    IANA has created a new registry for ManageSieve response codes.  The
2119    registration template for ManageSieve response codes is specified in
2120    Section 6.3.  ManageSieve protocol response codes MUST be specified
2121    in a Standards-Track or IESG-approved Experimental RFC.
2122
2123
2124
2125
2126
2127
2128
2129
2130 Melnikov & Martin            Standards Track                   [Page 38]
2131 \f
2132 RFC 5804                       ManageSieve                     July 2010
2133
2134
2135 6.1.  ManageSieve Capability Registration Template
2136
2137    To: iana@iana.org
2138    Subject: ManageSieve Capability Registration
2139
2140    Please register the following ManageSieve capability:
2141
2142    Capability name:
2143    Description:
2144    Relevant publications:
2145    Person & email address to contact for further information:
2146    Author/Change controller:
2147
2148 6.2.  Registration of Initial ManageSieve Capabilities
2149
2150    To: iana@iana.org
2151    Subject: ManageSieve Capability Registration
2152
2153    Please register the following ManageSieve capabilities:
2154
2155    Capability name:  IMPLEMENTATION
2156    Description:   Its value contains the name of the server
2157                   implementation and its version.
2158    Relevant publications:  this RFC, Section 1.7.
2159    Person & email address to contact for further information:
2160                   Alexey Melnikov <alexey.melnikov@isode.com>
2161    Author/Change controller:  IESG.
2162
2163    Capability name:  SASL
2164    Description:   Its value contains a space-separated list of SASL
2165                   mechanisms supported by the server.
2166    Relevant publications:  this RFC, Sections 1.7 and 2.1.
2167    Person & email address to contact for further information:
2168                   Alexey Melnikov <alexey.melnikov@isode.com>
2169    Author/Change controller:  IESG.
2170
2171    Capability name:  SIEVE
2172    Description:   Its value contains a space-separated list of supported
2173                   SIEVE extensions.
2174    Relevant publications:  this RFC, Section 1.7.  Also [SIEVE].
2175    Person & email address to contact for further information:
2176                   Alexey Melnikov <alexey.melnikov@isode.com>
2177    Author/Change controller:  IESG.
2178
2179
2180
2181
2182
2183
2184
2185
2186 Melnikov & Martin            Standards Track                   [Page 39]
2187 \f
2188 RFC 5804                       ManageSieve                     July 2010
2189
2190
2191    Capability name:  STARTTLS
2192    Description:   This capability is returned if the server supports TLS
2193                   (STARTTLS command).
2194    Relevant publications:  this RFC, Sections 1.7 and 2.2.
2195    Person & email address to contact for further information:
2196                   Alexey Melnikov <alexey.melnikov@isode.com>
2197    Author/Change controller:  IESG.
2198
2199    Capability name:  NOTIFY
2200    Description:   This capability is returned if the server supports the
2201                   'enotify' [NOTIFY] Sieve extension.
2202    Relevant publications:  this RFC, Section 1.7.
2203    Person & email address to contact for further information:
2204                   Alexey Melnikov <alexey.melnikov@isode.com>
2205    Author/Change controller:  IESG.
2206
2207    Capability name:  MAXREDIRECTS
2208    Description:   This capability returns the limit on the number of
2209                   Sieve "redirect" actions a script can perform during a
2210                   single evaluation.  The value is a non-negative number
2211                   represented as a ManageSieve string.
2212    Relevant publications:  this RFC, Section 1.7.
2213    Person & email address to contact for further information:
2214                   Alexey Melnikov <alexey.melnikov@isode.com>
2215    Author/Change controller:  IESG.
2216
2217    Capability name:  LANGUAGE
2218    Description:   The language (<Language-Tag> from [RFC5646]) currently
2219                   used for human-readable error messages.
2220    Relevant publications:  this RFC, Section 1.7.
2221    Person & email address to contact for further information:
2222                   Alexey Melnikov <alexey.melnikov@isode.com>
2223    Author/Change controller:  IESG.
2224
2225    Capability name:  OWNER
2226    Description:   Its value contains the UTF-8-encoded name of the
2227                   currently logged-in user ("authorization identity"
2228                   according to RFC 4422).
2229    Relevant publications:  this RFC, Section 1.7.
2230    Person & email address to contact for further information:
2231                   Alexey Melnikov <alexey.melnikov@isode.com>
2232    Author/Change controller:  IESG.
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242 Melnikov & Martin            Standards Track                   [Page 40]
2243 \f
2244 RFC 5804                       ManageSieve                     July 2010
2245
2246
2247    Capability name:  VERSION
2248    Description:   This capability is returned if the server is compliant
2249                   with RFC 5804; i.e., that it supports RENAMESCRIPT,
2250                   CHECKSCRIPT, and NOOP commands.
2251    Relevant publications:  this RFC, Sections 2.11, 2.12, and 2.13.
2252    Person & email address to contact for further information:
2253                   Alexey Melnikov <alexey.melnikov@isode.com>
2254    Author/Change controller:  IESG.
2255
2256 6.3.  ManageSieve Response Code Registration Template
2257
2258    To: iana@iana.org
2259    Subject: ManageSieve Response Code Registration
2260
2261    Please register the following ManageSieve response code:
2262
2263       Response Code:
2264       Arguments (use ABNF to specify syntax, or the word NONE if none
2265       can be specified):
2266       Purpose:
2267       Published Specification(s):
2268       Person & email address to contact for further information:
2269       Author/Change controller:
2270
2271 6.4.  Registration of Initial ManageSieve Response Codes
2272
2273    To: iana@iana.org
2274    Subject: ManageSieve Response Code Registration
2275
2276    Please register the following ManageSieve response codes:
2277
2278    Response Code: AUTH-TOO-WEAK
2279    Arguments (use ABNF to specify syntax, or the word NONE if none can
2280    be specified):  NONE
2281    Purpose:       This response code is returned in the NO response from
2282                   an AUTHENTICATE command.  It indicates that site
2283                   security policy forbids the use of the requested
2284                   mechanism for the specified authentication identity.
2285    Published Specification(s):  [RFC5804]
2286    Person & email address to contact for further information:
2287                   Alexey Melnikov <alexey.melnikov@isode.com>
2288    Author/Change controller:  IESG.
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Melnikov & Martin            Standards Track                   [Page 41]
2299 \f
2300 RFC 5804                       ManageSieve                     July 2010
2301
2302
2303    Response Code: ENCRYPT-NEEDED
2304    Arguments (use ABNF to specify syntax, or the word NONE if none can
2305    be specified):  NONE
2306    Purpose:       This response code is returned in the NO response from
2307                   an AUTHENTICATE command.  It indicates that site
2308                   security policy requires the use of a strong
2309                   encryption mechanism for the specified authentication
2310                   identity and mechanism.
2311    Published Specification(s):  [RFC5804]
2312    Person & email address to contact for further information:
2313                   Alexey Melnikov <alexey.melnikov@isode.com>
2314    Author/Change controller:  IESG.
2315
2316    Response Code: QUOTA
2317    Arguments (use ABNF to specify syntax, or the word NONE if none can
2318    be specified):  NONE
2319    Purpose:       If this response code is returned in the NO/BYE
2320                   response, it means that the command would have placed
2321                   the user above the site-defined quota constraints.  If
2322                   this response code is returned in the OK response, it
2323                   can mean that the user is near its quota or that the
2324                   user exceeded its quota, but the server supports soft
2325                   quotas.
2326    Published Specification(s):  [RFC5804]
2327    Person & email address to contact for further information:
2328                   Alexey Melnikov <alexey.melnikov@isode.com>
2329    Author/Change controller:  IESG.
2330
2331    Response Code: QUOTA/MAXSCRIPTS
2332    Arguments (use ABNF to specify syntax, or the word NONE if none can
2333    be specified):  NONE
2334    Purpose:       If this response code is returned in the NO/BYE
2335                   response, it means that the command would have placed
2336                   the user above the site-defined limit on the number of
2337                   Sieve scripts.  If this response code is returned in
2338                   the OK response, it can mean that the user is near its
2339                   quota or that the user exceeded its quota, but the
2340                   server supports soft quotas.  This response code is a
2341                   more specific version of the QUOTA response code.
2342    Published Specification(s):  [RFC5804]
2343    Person & email address to contact for further information:
2344                   Alexey Melnikov <alexey.melnikov@isode.com>
2345    Author/Change controller:  IESG.
2346
2347
2348
2349
2350
2351
2352
2353
2354 Melnikov & Martin            Standards Track                   [Page 42]
2355 \f
2356 RFC 5804                       ManageSieve                     July 2010
2357
2358
2359    Response Code: QUOTA/MAXSIZE
2360    Arguments (use ABNF to specify syntax, or the word NONE if none can
2361    be specified):  NONE
2362    Purpose:       If this response code is returned in the NO/BYE
2363                   response, it means that the command would have placed
2364                   the user above the site-defined maximum script size.
2365                   If this response code is returned in the OK response,
2366                   it can mean that the user is near its quota or that
2367                   the user exceeded its quota, but the server supports
2368                   soft quotas.  This response code is a more specific
2369                   version of the QUOTA response code.
2370    Published Specification(s):  [RFC5804]
2371    Person & email address to contact for further information:
2372                   Alexey Melnikov <alexey.melnikov@isode.com>
2373    Author/Change controller:  IESG.
2374
2375    Response Code: REFERRAL
2376    Arguments (use ABNF to specify syntax, or the word NONE if none can
2377    be specified):  <sieveurl>
2378    Purpose:       This response code may be returned with a BYE result
2379                   from any command, and includes a mandatory parameter
2380                   that indicates what server to access to manage this
2381                   user's Sieve scripts.  The server will be specified by
2382                   a Sieve URL (see Section 3).  The scriptname portion
2383                   of the URL MUST NOT be specified.  The client should
2384                   authenticate to the specified server and use it for
2385                   all further commands in the current session.
2386    Published Specification(s):  [RFC5804]
2387    Person & email address to contact for further information:
2388                   Alexey Melnikov <alexey.melnikov@isode.com>
2389    Author/Change controller:  IESG.
2390
2391    Response Code: SASL
2392    Arguments (use ABNF to specify syntax, or the word NONE if none can
2393    be specified):  <string>
2394    Purpose:       This response code can occur in the OK response to a
2395                   successful AUTHENTICATE command and includes the
2396                   optional final server response data from the server as
2397                   specified by [SASL].
2398    Published Specification(s):  [RFC5804]
2399    Person & email address to contact for further information:
2400                   Alexey Melnikov <alexey.melnikov@isode.com>
2401    Author/Change controller:  IESG.
2402
2403
2404
2405
2406
2407
2408
2409
2410 Melnikov & Martin            Standards Track                   [Page 43]
2411 \f
2412 RFC 5804                       ManageSieve                     July 2010
2413
2414
2415    Response Code: TRANSITION-NEEDED
2416    Arguments (use ABNF to specify syntax, or the word NONE if none can
2417    be specified):  NONE
2418    Purpose:       This response code occurs in a NO response of an
2419                   AUTHENTICATE command.  It indicates that the user name
2420                   is valid, but the entry in the authentication database
2421                   needs to be updated in order to permit authentication
2422                   with the specified mechanism.  This is typically done
2423                   by establishing a secure channel using TLS, followed
2424                   by authenticating once using the [PLAIN]
2425                   authentication mechanism.  The selected mechanism
2426                   SHOULD then work for authentications in subsequent
2427                   sessions.
2428    Published Specification(s):  [RFC5804]
2429    Person & email address to contact for further information:
2430                   Alexey Melnikov <alexey.melnikov@isode.com>
2431    Author/Change controller:  IESG.
2432
2433    Response Code: TRYLATER
2434    Arguments (use ABNF to specify syntax, or the word NONE if none can
2435    be specified):  NONE
2436    Purpose:       A command failed due to a temporary server failure.
2437                   The client MAY continue using local information and
2438                   try the command later.  This response code only make
2439                   sense when returned in a NO/BYE response.
2440    Published Specification(s):  [RFC5804]
2441    Person & email address to contact for further information:
2442                   Alexey Melnikov <alexey.melnikov@isode.com>
2443    Author/Change controller:  IESG.
2444
2445    Response Code: ACTIVE
2446    Arguments (use ABNF to specify syntax, or the word NONE if none can
2447    be specified):  NONE
2448    Purpose:       A command failed because it is not allowed on the
2449                   active script, for example, DELETESCRIPT on the active
2450                   script.  This response code only makes sense when
2451                   returned in a NO/BYE response.
2452    Published Specification(s):  [RFC5804]
2453    Person & email address to contact for further information:
2454                   Alexey Melnikov <alexey.melnikov@isode.com>
2455    Author/Change controller:  IESG.
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466 Melnikov & Martin            Standards Track                   [Page 44]
2467 \f
2468 RFC 5804                       ManageSieve                     July 2010
2469
2470
2471    Response Code: NONEXISTENT
2472    Arguments (use ABNF to specify syntax, or the word NONE if none can
2473    be specified):  NONE
2474    Purpose:       A command failed because the referenced script name
2475                   doesn't exist.  This response code only makes sense
2476                   when returned in a NO/BYE response.
2477    Published Specification(s):  [RFC5804]
2478    Person & email address to contact for further information:
2479                   Alexey Melnikov <alexey.melnikov@isode.com>
2480    Author/Change controller:  IESG.
2481
2482    Response Code: ALREADYEXISTS
2483    Arguments (use ABNF to specify syntax, or the word NONE if none can
2484    be specified):  NONE
2485    Purpose:       A command failed because the referenced script name
2486                   already exists.  This response code only makes sense
2487                   when returned in a NO/BYE response.
2488    Published Specification(s):  [RFC5804]
2489    Person & email address to contact for further information:
2490                   Alexey Melnikov <alexey.melnikov@isode.com>
2491    Author/Change controller:  IESG.
2492
2493    Response Code: WARNINGS
2494    Arguments (use ABNF to specify syntax, or the word NONE if none can
2495    be specified):  NONE
2496    Purpose:       This response code MAY be returned by the server in
2497                   the OK response (but it might be returned with the NO/
2498                   BYE response as well) and signals the client that even
2499                   though the script is syntactically valid, it might
2500                   contain errors not intended by the script writer.
2501    Published Specification(s):  [RFC5804]
2502    Person & email address to contact for further information:
2503                   Alexey Melnikov <alexey.melnikov@isode.com>
2504    Author/Change controller:  IESG.
2505
2506    Response Code: TAG
2507    Arguments (use ABNF to specify syntax, or the word NONE if none can
2508    be specified):  string
2509    Purpose:       This response code name is followed by a string
2510                   specified in the command that caused this response.
2511                   It is typically used for client state synchronization.
2512    Published Specification(s):  [RFC5804]
2513    Person & email address to contact for further information:
2514                   Alexey Melnikov <alexey.melnikov@isode.com>
2515    Author/Change controller:  IESG.
2516
2517
2518
2519
2520
2521
2522 Melnikov & Martin            Standards Track                   [Page 45]
2523 \f
2524 RFC 5804                       ManageSieve                     July 2010
2525
2526
2527 7.  Internationalization Considerations
2528
2529    The LANGUAGE capability (see Section 1.7) allows a client to discover
2530    the current language used in all human-readable responses that might
2531    be returned at the end of any OK/NO/BYE response.  Human-readable
2532    text in OK responses typically doesn't need to be shown to the user,
2533    unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT
2534    command that also contains the WARNINGS response code (Section 1.3).
2535    Human-readable text from NO/BYE responses is intended be shown to the
2536    user, unless the client can automatically handle failure of the
2537    command that caused such a response.  Clients SHOULD use response
2538    codes (Section 1.3) for automatic error handling.  Response codes MAY
2539    also be used by the client to present error messages in a language
2540    understood by the user, for example, if the LANGUAGE capability
2541    doesn't return a language understood by the user.
2542
2543    Note that the human-readable text from OK (WARNINGS) or NO/BYE
2544    responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
2545    users that understand Sieve language.  Such advanced users are often
2546    sophisticated enough to be able to handle whatever language the
2547    server is using, even if it is not their preferred language, and will
2548    want to see error/warning text no matter what language the server
2549    puts it in.
2550
2551    A client that generates Sieve script automatically, for example, if
2552    the script is generated without user intervention or from a UI that
2553    presents an abstract list of conditions and corresponding actions,
2554    SHOULD NOT present warning/error messages to the user, because the
2555    user might not even be aware that the client is using Sieve
2556    underneath.  However, if the client has a debugging mode, such
2557    warnings/errors SHOULD be available in the debugging mode.
2558
2559    Note that this document doesn't provide a way to modify the currently
2560    used language.  It is expected that a future extension will address
2561    that.
2562
2563 8.  Acknowledgements
2564
2565    Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
2566    Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
2567    Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
2568    Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
2569    Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
2570    Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus
2571    Westerlund, Tim Polk, and Julien Coloos for help with this document.
2572    Special thank you to Phil Pennock for providing text for the NOOP
2573    command, as well as finding various bugs in the document.
2574
2575
2576
2577
2578 Melnikov & Martin            Standards Track                   [Page 46]
2579 \f
2580 RFC 5804                       ManageSieve                     July 2010
2581
2582
2583 9.  References
2584
2585 9.1.  Normative References
2586
2587    [ABNF]         Crocker, D. and P. Overell, "Augmented BNF for Syntax
2588                   Specifications: ABNF", STD 68, RFC 5234, January 2008.
2589
2590    [ACAP]         Newman, C. and J. Myers, "ACAP -- Application
2591                   Configuration Access Protocol", RFC 2244, November
2592                   1997.
2593
2594    [BASE64]       Josefsson, S., "The Base16, Base32, and Base64 Data
2595                   Encodings", RFC 4648, October 2006.
2596
2597    [DNS-SRV]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
2598                   for specifying the location of services (DNS SRV)",
2599                   RFC 2782, February 2000.
2600
2601    [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
2602                   Requirement Levels", BCP 14, RFC 2119, March 1997.
2603
2604    [NET-UNICODE]  Klensin, J. and M. Padlipsky, "Unicode Format for
2605                   Network Interchange", RFC 5198, March 2008.
2606
2607    [NOTIFY]       Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
2608                   "Sieve Email Filtering: Extension for Notifications",
2609                   RFC 5435, January 2009.
2610
2611    [RFC2277]      Alvestrand, H., "IETF Policy on Character Sets and
2612                   Languages", BCP 18, RFC 2277, January 1998.
2613
2614    [RFC2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
2615                   6 (IPv6) Specification", RFC 2460, December 1998.
2616
2617    [RFC3490]      Faltstrom, P., Hoffman, P., and A. Costello,
2618                   "Internationalizing Domain Names in Applications
2619                   (IDNA)", RFC 3490, March 2003.
2620
2621    [RFC4519]      Sciberras, A., "Lightweight Directory Access Protocol
2622                   (LDAP): Schema for User Applications", RFC 4519, June
2623                   2006.
2624
2625    [RFC5646]      Phillips, A. and M. Davis, "Tags for Identifying
2626                   Languages", BCP 47, RFC 5646, September 2009.
2627
2628    [RFC791]       Postel, J., "Internet Protocol", STD 5, RFC 791,
2629                   September 1981.
2630
2631
2632
2633
2634 Melnikov & Martin            Standards Track                   [Page 47]
2635 \f
2636 RFC 5804                       ManageSieve                     July 2010
2637
2638
2639    [SASL]         Melnikov, A. and K. Zeilenga, "Simple Authentication
2640                   and Security Layer (SASL)", RFC 4422, June 2006.
2641
2642    [SASLprep]     Zeilenga, K., "SASLprep: Stringprep Profile for User
2643                   Names and Passwords", RFC 4013, February 2005.
2644
2645    [SCRAM]        Menon-Sen, A., Melnikov, A., Newman, C., and N.
2646                   Williams, "Salted Challenge Response Authentication
2647                   Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC
2648                   5802, July 2010.
2649
2650    [SIEVE]        Guenther, P. and T. Showalter, "Sieve: An Email
2651                   Filtering Language", RFC 5228, January 2008.
2652
2653    [StringPrep]   Hoffman, P. and M. Blanchet, "Preparation of
2654                   Internationalized Strings ("stringprep")", RFC 3454,
2655                   December 2002.
2656
2657    [TLS]          Dierks, T. and E. Rescorla, "The Transport Layer
2658                   Security (TLS) Protocol Version 1.2", RFC 5246, August
2659                   2008.
2660
2661    [URI-GEN]      Berners-Lee, T., Fielding, R., and L. Masinter,
2662                   "Uniform Resource Identifier (URI): Generic Syntax",
2663                   STD 66, RFC 3986, January 2005.
2664
2665    [UTF-8]        Yergeau, F., "UTF-8, a transformation format of ISO
2666                   10646", STD 63, RFC 3629, November 2003.
2667
2668    [X509]         Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2669                   Housley, R., and W. Polk, "Internet X.509 Public Key
2670                   Infrastructure Certificate and Certificate Revocation
2671                   List (CRL) Profile", RFC 5280, May 2008.
2672
2673    [X509-SRV]     Santesson, S., "Internet X.509 Public Key
2674                   Infrastructure Subject Alternative Name for Expression
2675                   of Service Name", RFC 4985, August 2007.
2676
2677 9.2.  Informative References
2678
2679    [DIGEST-MD5]   Leach, P. and C. Newman, "Using Digest Authentication
2680                   as a SASL Mechanism", RFC 2831, May 2000.
2681
2682    [GSSAPI]       Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
2683                   Authentication and Security Layer (SASL) Mechanism",
2684                   RFC 4752, November 2006.
2685
2686
2687
2688
2689
2690 Melnikov & Martin            Standards Track                   [Page 48]
2691 \f
2692 RFC 5804                       ManageSieve                     July 2010
2693
2694
2695    [I-HAVE]       Freed, N., "Sieve Email Filtering: Ihave Extension",
2696                   RFC 5463, March 2009.
2697
2698    [IMAP]         Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
2699                   VERSION 4rev1", RFC 3501, March 2003.
2700
2701    [LDAP]         Zeilenga, K., "Lightweight Directory Access Protocol
2702                   (LDAP): Technical Specification Road Map", RFC 4510,
2703                   June 2006.
2704
2705    [PLAIN]        Zeilenga, K., "The PLAIN Simple Authentication and
2706                   Security Layer (SASL) Mechanism", RFC 4616, August
2707                   2006.
2708
2709 Authors' Addresses
2710
2711    Alexey Melnikov (editor)
2712    Isode Limited
2713    5 Castle Business Village
2714    36 Station Road
2715    Hampton, Middlesex  TW12 2BX
2716    UK
2717
2718    EMail: Alexey.Melnikov@isode.com
2719
2720
2721    Tim Martin
2722    BeThereBeSquare, Inc.
2723    672 Haight st.
2724    San Francisco, CA  94117
2725    USA
2726
2727    Phone: +1 510 260-4175
2728    EMail: timmartin@alumni.cmu.edu
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746 Melnikov & Martin            Standards Track                   [Page 49]
2747 \f