Version:            (using KDE 3.5.9KDE 3.5.6KDE 1.2KDE 1.2)
Installed from:    Debian stable PackagesDebian stable PackagesDebian testing/unstable PackagesDebian stable Packages
OS:                Linux

hi!

manage sieve server must send after "TLS negotiation" an capability-response. if he do it, the client (kmail/kio) have problems with following commands (AUTHENTICATE).

              
draft-martin-managesieve-08.txt:
2.2. STARTTLS Command
    Support for STARTTLS command in servers is optional. Its
    availability is advertised with "STARTTLS" capability as described
    in section 1.8.

    The STARTTLS command requests commencement of a TLS negotiation.
    The negotiation begins immediately after the CRLF in the OK
    response. After a client issues a STARTTLS command, it MUST NOT
    issue further commands until a server response is seen and the TLS
    negotiation is complete.

    The STARTTLS command is only valid in non-authenticated state. The
    server remains in non-authenticated state, even if client
    credentials are supplied during the TLS negotiation. The SASL [SASL]
    EXTERNAL mechanism MAY be used to authenticate once TLS client
    credentials are successfully exchanged, but servers supporting the
    STARTTLS command are not required to support the EXTERNAL mechanism.

    After the TLS layer is established, the server MUST re-issue the
    capability results, followed by an OK response. This is necessary to
    protect against man-in-the-middle attacks which alter the
    capabilities list prior to STARTTLS. This capability result MUST NOT
    include the STARTTLS capability.

    The client MUST discard cached capability information and replace it
    with the new information. The server MAY advertise different
    capabilities after STARTTLS.

    Example:

    C: StartTls
    S: oK
    <TLS negotiation, further commands are under TLS layer>
    S: "IMPLEMENTATION" "Example1 ManageSieved v001"
    S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
    S: "SIEVE" "fileinto vacation"
    S: ok