rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | README | LICENSE

rfc5804.txt (103194B)


      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 
     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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
    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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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 
   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