A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-09

[Ballot discuss]
(updated discuss)

It seems the Security Considerations text should say something
about the TRANSITION-NEEDED response?

Section 2.2.1: the last bullet point about mapping the reference
identity to some other type seems weird. AFAIK no other protocol does
anything like this, and even with DNSSEC, it may not actually
do what you'd expect (and I can't see why it would be useful).

[Ballot comment]
2.3.  LOGOUT Command

  The client sends the LOGOUT command when it is finished with a
  connection and wishes to terminate it.  The server MUST reply with an
  OK response and terminate the connection.  The server MUST ignore
  commands issued by the client after the LOGOUT command.

      Example:

      C: Logout
      S: Ok
     

To reduce the TCP Timed-wait loading on the server, wouldn't it be smarter to have the client close the TCP connection upon receiving the response? 

Section 4:

    number                = 1*DIGIT
                            ;; A 32-bit unsigned number.
                            ;; (0 <= n < 4,294,967,296)

Why isn't the number of digits restricted? Because clearly a 32-bit unsigned number will never need more than 10 DIGITs, thus the construct would make more sense as:

number                = 1*10DIGIT
                            ;; A 32-bit unsigned number.
                            ;; (0 <= n < 4,294,967,296)

[Ballot discuss]
Section 4:

A minor interoperability issue for the future, but I think it should be addressed.

The "initial-capabilites" alternative:

DQUOTE "VERSION" DQUOTE SP version

Which references the following ABNF rule

version = DQUOTE "1.0" DQUOTE

Seems to not provide any way of knowing how an old version could parse a future version correctly to determine what version is supported. The issue I am getting at is that the range for the version number in future extensions aren't defined. I would recommend the following solution:

version = ( DQUOTE "1.0" DQUOTE ) / version-ext

version-ext = DQUOTE number "." number DQUOTE

[Ballot comment]
[Sorry for the long winded comment that follows, but I noticed in the gen-art email thread
that this anchor was specifically left in to prompt my feedback. Just trying to be responsive!]

Anchor9 highlights Chris Newman's observation on differences between the specifications and
existing practice for wildcard matching when performing the server identity check.

The PKIX wg spent some time discussing this problem at the Philadelphia IETF.  To paraphrase
the minutes:

    Wildcards in DNS names in certificates are commonly supported, both in terms of
    certificates issued by some major CAs and in platforms processing them, but it has never
    been acknowledged in PKIX standards. 2818 allows wildcards, but inconsistently with some
    common platforms (e.g., Windows).  Note also that 2818 is Informational, not standards
    track.  Also, TLS is used in many other environments, and these environments can write
    standards to address this issue in their context.

Basically, I agree with Chris that wildcard matching is supported on many platforms, including
the scenario where the CN contains the server identity (Section 2.2.1, Rule 3.)  However, there
is no specific standard to reference that accurately describes the behavior of existing clients,
since that processing is not uniform.  This is unfortunate, but there are so many legacy
implementations that developing a standard seems unlikely at this point.

Given that, the text (in sections 2.2.1 and 2.2.1.1) as written seems reasonable and complete.
It establishes clear and unambiguous expectations for this context.  I would also note that
the matching rule used here is less complicated than that in 2818.  (2818 permits matching
substrings in a domain name: "f*.com matches foo.com but not bar.com".  Personally, I do
not think that is a very useful feature.)

One change you *might* consider is relaxing rule 3 and permitting wildcard matches in the
CN, since this is permitted by 2818.

One last thing: I support Pasi's request for text in the Security Considerations highlighting
TRANSITION-NEEDED.

[Ballot comment]
[Sorry for the long winded comment that follows, but I noticed in the gen-art email thread that this
anchor was specifically left in to prompt my feedback.]

Anchor9 highlights Chris Newman's observation on differences between the specifications and
existing practice for wildcard matching when performing the server identity check.

The PKIX wg spent some time discussing this problem at the Philadelphia IETF.  To paraphrase
the minutes:

    Wildcards in DNS names in certificates are commonly supported, both in terms of
    certificates issued by some major CAs and in platforms processing them, but it has never
    been acknowledged in PKIX standards. 2818 allows wildcards, but inconsistently with some
    common platforms (e.g., Windows).  Note also that 2818 is Informational, not standards
    track.  Also, TLS is used in many other environments, and these environments can write
    standards to address this issue in their context.

Basically, I agree with Chris that wildcard matching is supported on many platforms, including
the scenario where the CN contains the server identity (Section 2.2.1, Rule 3.)  However, there
is no specific standard to reference that accurately describes the behavior of existing clients,
since that processing is not uniform.  This is unfortunate, but there are so many legacy
implementations that developing a standard seems unlikely at this point.

Given that, the text (in sections 2.2.1 and 2.2.1.1) as written seems reasonable and complete.
It establishes clear and unambiguous expectations for this context.  I would also note that
the matching rule used here is less complicated than that in 2818.  (2818 permits matching
substrings in a domain name: "f*.com matches foo.com but not bar.com".  Personally, I do
not think that is a very useful feature.)

One change you *might* consider is relaxing rule 3 and permitting wildcard matches in the
CN, since this is permitted by 2818.

[Ballot comment]
Anchor9 highlights Chris Newman's observation on differences between the specifications and
existing practice for wildcard matching when performing the server identity check.

The PKIX wg spent some time discussing this problem at the Philadelphia IETF.  To paraphrase
the minutes:

    Wildcards in DNS names in certificates are commonly supported, both in terms of certificates
    issued by some major CAs and in platforms processing them, but it has never been acknowledged
    in PKIX standards. 2818 allows wildcards, but inconsistently with some common platforms (e.g.,
    Windows).  Note also that 2818 is Informational, not standards track.  Also, TLS is used in many
    other environments, and these environments can write standards to address this issue in their
    context.

[Ballot discuss]
When I try to compile the ABNF with Bill's ABNF parser, I get an
error here:

                            command-havespace /  /

This seems to be a mistake.

[Ballot discuss]
(updated discuss)

It seems the Security Considerations text should say something
about the TRANSITION-NEEDED response?

IANA Considerations: should you ask IANA to add "sieve" to the
"GSSAPI/Kerberos/SASL Service names" registry?

[Ballot comment]
Section 1.9., paragraph 0:

> 1.9.  Link Level
>
>    The ManageSieve protocol assumes a reliable data stream such as that
>    provided by TCP.

  I think you want to make TCP support for ManageSieve REQUIRED. (Also,
  nit, "Link Level" isn't the greatest section name for this - maybe
  "Transport"?)


Section 1.9., paragraph 1:
>    When TCP is used, a ManageSieve server typically
>    listens on port 2000. [[anchor7: IANA registration of port 2000 is
>    pending.]]

  Port 2000 is unavailable, but I see Chris is holding the DISCUSS.

[Ballot discuss]
Holding discuss for IANA issue -- port 2000 is already registered; Sieve needs to pick a different port.

Will change to "yes" once that's resolved.

IANA questions/comments:

- This document requests the allocation of a TCP port that has
already been registered (2000, Cisco SCCP). Should the existing
registration be changed from "Cisco SCCP" to "ManageSieve"?

- Do the commands defined in Section 2 require a registry?

- Section 1.7 defines MAXREDIRECTS and LANGUAGE, but templates
for these capabilities do not appear to be included in the IANA
Considerations. Is this an oversight?

ACTION 1:

Upon approval of this document, IANA will make the following
TCP port number assignment in the registry at
http://www.iana.org/assignments/port-numbers

Keyword Decimal Description References
------- ------- ----------- ----------
managesieve TBD ManageSieve [RFC-sieve-managesieve-05]


ACTION 2:

Upon approval of this document, IANA will make the following
assignments in the "Permanent URI Schemes" registry at
http://www.iana.org/assignments/uri-schemes.html

URI Scheme + Description + Reference
sieve + Sieve Protocol + [RFC-sieve-managesieve-05]


ACTION 3:

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD

ManageSieve Capabilities
Registration Procedures: Standards Action or IESG-approved Experimental RFC

Capability name: IMPLEMENTATION
Description: Its value contains name of server implementation and
its version.
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Capability name: SASL
Description: Its value contains a space separated list of SASL
mechanisms supported by server.
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7 and Section 2.1.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Capability name: SIEVE
Description: Its value contains a space separated list of
supported SIEVE extensions
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7. Also [SIEVE].
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Capability name: STARTTLS
Description: This capability is returned if server supports TLS
(STARTTLS command).
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7 and Section 2.2.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.


Capability name: NOTIFY
Description: This capability is returned if server supports
'enotify' [NOTIFY] Sieve extension.
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Capability name: OWNER
Description: Its value contains UTF-8 encoded name of the
currently logged in user ("authorization identity" according to
RFC 4422).
Relevant publications: [RFC-sieve-managesieve-05] Section 1.7.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Capability name: VERSION
Description: This capability is returned if the server is
compliant with [RFC-sieve-managesieve-05], i.e. that it supports RENAMESCRIPT,
CHECKSCRIPT and NOOP commands.
Relevant publications: [RFC-sieve-managesieve-05] Section 2.11.
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.


ACTION 4:

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD

ManageSieve Response Codes
Registration Procedure: Standards Action or IESG-approved Experimental RFC

Response Code: AUTH-TOO-WEAK
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: This response code is returned in the NO response from an
AUTHENTICATE command. It indicates that site security policy
forbids the use of the requested mechanism for the specified
authentication identity.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: ENCRYPT-NEEDED
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: This response code is returned in the NO response from an
AUTHENTICATE command. It indicates that site security policy
requires the use of a strong encryption mechanism for the
specified authentication identity and mechanism.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: QUOTA
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: If this response code is returned in the NO/BYE response,
it means that the command would have placed the user above the
site-defined quota constraints. If this response code is returned
in the OK response, it can mean that the user is near its quota or
that the user exceeded its quota, but the server supports soft
quotas.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: QUOTA/MAXSCRIPTS
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: If this response code is returned in the NO/BYE response,
it means that the command would have placed the user above the
site-defined limit on the number of Sieve scripts. If this
response code is returned in the OK response, it can mean that the
user is near its quota or that the user exceeded its quota, but
the server supports soft quotas. This response code is a more
specific version of the QUOTA response code.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: QUOTA/MAXSIZE
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: If this response code is returned in the NO/BYE response,
it means that the command would have placed the user above the
site-defined maximum script size. If this response code is
returned in the OK response, it can mean that the user is near its
quota or that the user exceeded its quota, but the server supports
soft quotas. This response code is a more specific version of the
QUOTA response code.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: REFERRAL
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified):
Purpose: This response code may be returned with a BYE result from
any command, and includes a mandatory parameter that indicates
what server to access to manage this user's sieve scripts. The
server will be specified by a Sieve URL (see Section 3). The
scriptname portion of the URL MUST NOT be specified. The client
should authenticate to the specified server and use it for all
further commands in the current session.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: SASL
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified):
Purpose: This response code can occur in the OK response to a
successful AUTHENTICATE command and includes the optional final
server response data from the server as specified by [SASL].
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: TRANSITION-NEEDED
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: This response code occurs in a NO response of an
AUTHENTICATE command. It indicates that the user name is valid,
but the entry in the authentication database needs to be updated
in order to permit authentication with the specified mechanism.
This is typically done by establishing a secure channel using TLS,
followed by authenticating once using the [PLAIN] authentication
mechanism. The selected mechanism SHOULD then work for
authentications in subsequent sessions.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: TRYLATER
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: A command failed due to a temporary server failure. The
client MAY continue using local information and try the command
later. This response code only make sense when returned in a NO/
BYE response.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: ACTIVE
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: A command failed because it is not allowed on the active
script. For example DELETESCRIPT on the active script. This
response code only makes sense when returned in a NO/BYE response.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: NONEXISTENT
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: A command failed because the referenced script name
doesn't exist. This response code only makes sense when returned
in a NO/BYE response.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: ALREADYEXISTS
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: A command failed because the referenced script name
already exists. This response code only makes sense when returned
in a NO/BYE response.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: WARNINGS
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): NONE
Purpose: This response code MAY be returned by the server in the
OK response (but it might be returned with the NO/BYE response as
well) and signals the client that even though the script is
syntactically valid, it might contain errors not intended by the
script writer.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Response Code: TAG
Arguments (use ABNF to specify syntax, or the word NONE if none
can be specified): string
Purpose: This response code name is followed by a string specified
in the command that caused this response. It is typically used
for client state synchronization.
Published Specification(s): [RFC-sieve-managesieve-05]
Person & email address to contact for further information: Alexey
Melnikov
Author/Change controller: IESG.

Attached below is the writeup for draft-ietf-sieve-managesieve-03.txt.
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Ned Freed  is the document shepherd for this document.
He has reviewed the document and believes it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

This document was reviewed and discussed by several active and experienced
Sieve WG members, including but not limited to: Stephan Bosch
, Arnt Gulbrandsen arnt@gulbrandsen.priv.no>, Kjetil
Torgrim Homme , and Jeffrey Hutzelman .

There are no concerns about the depth of the reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

This is a new protocol, and while almost everything in it is modelled on proven
approaches in other protocol, careful review, espectially in regards to
security, is definitely in order.

This document defines a sieve: URL scheme. This has already been reviewed and
is believed to be well defined, but nevertheless additional review by those
with expertise in URL schemes would be helpful.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no specific concerns. No IPR disclosure has been filed for this
document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is a strong WG consensus behind the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

idnits 2.10.03  was used to verify the document. It reported outdated use of
outdated RFC 3978 boilerplate (but since the boilerplate revision is
apparently stalled due to late-breaking issuues this is not a real concern),
two unused referennces, and two outdated references. All of these can easily
be dealt with by the RFC Editor.

The complete output of idnits is as follows (note that the remaining nits
it found are all bogus):

Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
----------------------------------------------------------------------------

== It looks like you're using RFC 3978 boilerplate.  You should update
    this, as the boilerplate described in the IETF Trust License Policy
    document (see http://trustee.ietf.org/license-info) is accepted from 10
    November 2008, and will soon be required.  Version 1.34 of xml2rfc can
    (when released) be used to produce documents with boilerplate according
    to the mentioned Trust License Policy document.


Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------

    No issues found here.

Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------

    No issues found here.

Miscellaneous warnings:
----------------------------------------------------------------------------

    No issues found here.

Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

== Missing Reference: 'CONTROL CHARACTERS' is mentioned on line 286, but
    not defined

== Missing Reference: 'RFC XXXX' is mentioned on line 1304, but not defined

== Missing Reference: 'RFCXXXX' is mentioned on line 2025, but not defined

== Unused Reference: 'DIGEST-MD5' is defined on line 2137, but no explicit
    reference was found in the text

== Unused Reference: 'IANA-GUIDELINES' is defined on line 2145, but no
    explicit reference was found in the text

** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC
    5246)

** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC
    5280)


    Summary: 2 errors (**), 6 warnings (==), 0 comments (--).

As noted previously, the document does define a new URL scheme and should
be reciewed accordingly.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes, references are properly split. There are no downward normative
references. There is a normative reference to a draft being actively
worked on in the SASL WG (draft-newman-auth-scram), whose intended
status is as a proposed standard.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

An IANA considerations section exists and is clearly defined. It  contains
registration of a new TCP port number, registration of a new URI scheme and it
also creates 2 new IANA  registries: for ManageSieve extensions and for Manage
Sieve response codes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Two ABNFs from the document were verified by the apps.ietf.org ABNF validator.
The only problem noted was the duplication of the QUOTED-SPECIALS (the two
definitions are identical but redundant nevertheless). The redundant definition
can be removed in the next revision, or failing that, during AUTH48.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

        Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

There was a discussion on the mailing list about use of synchronizing  literals
in the protocol. An earlier version incorrectly documented  existing practice
and at the same time was inconsistent with IMAP  LITERAL+ extension. So there
was a concern that some existing  implementation might implement this
incorrectly. However the author is  not aware of any such implementation.

More recently, there has been discussion of the overall command structure,
mandtory-to-implement security mechanisms, and of some specific details in the
sieve URL format. Consensus appears to have been reached on all of these
issues.

        Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

The are multiple server and client implementations of the ManageSieve
protocol. The following is an incomplete list of servers implementing
ManageSieve: CMU, Dbmail, Dovecot, Isode, ArchiveOpteryx, pysieved (Python
Managesieve Server), Citadel.

The following clients are known to implement ManageSieve: Mulberry, Phil
Pennock's sieve-connect, Polymer, Ruby/ManageSieve,  Net-ManageSieve (perl),
SIEVE plugin for Thunderbird, KMail, gsieve,  Emacs-based ManageSieve
implementation.

Note that many if not most of these implementtations were written according to
earlier versions of the specification and may require updates to be compliant
with the current version.