Hello list,

I'm trying to get pidgeonhole/managesieve running, and I'm stuck connecting clients to the server (Dovecot 2.2.33.2-1ubuntu4.1 on an Ubnutu 18.04 machine). So far, my config looks like this:


    protocols = imap lmtp sieve
    disable_plaintext_auth = yes
    auth_mechanisms = plain login scram-sha-1

    service managesieve-login {
        inet_listener sieve {
            port = 4190
            ssl = yes
        }
        service_count = 1
    }

    service managesieve {
        process_limit = 256
    }

    protocol sieve {
        managesieve_max_line_length = 65536
    }


(please let me know if you need more details).

When I connect via


    openssl s_client -connect $myserver:4190


I get the following prompt (after the usual certificate prompt):


    "IMPLEMENTATION" "Dovecot (Ubuntu) Pigeonhole"
"SIEVE" "fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext vacation-seconds imapsieve vnd.dovecot.imapsieve"
    "NOTIFY" "mailto"
    "SASL" "PLAIN LOGIN SCRAM-SHA-1"
    "VERSION" "1.0"
    OK "Dovecot (Ubuntu) ready."


and I can login successfully:


    AUTHENTICATE "PLAIN" "base64(0x00 $user 0x00 $password)"
    OK "Logged In."


Note how this is different from the troubleshooting guide [1], which suggests gnutls-bin and waiting for the STARTTLS capability before hitting Ctrl-D. This is what I get with gnutls-bin:


    $ gnutls-cli --starttls --insecure -p 4190 $myserver
    Processed 0 CA certificate(s).
    Resolving '$myserver:4190'...
    Connecting to '$myserverip:4190'...

    - Simple Client Mode:

    _


where "_" denotes the waiting prompt. When I hit Ctrl-D here, I get an output similar that of s_client.

Now, my problem are the clients: neither Thunderbird's sieve extenstion [2], nor the Ruby ManageSieve class [3], nor Roundcube's managesieve plugin [4] (via Net_Sieve module [5]) are able to communicate with my server. They all wait for a "STARTTLS" line, before they attempt to perform a TLS handshake.

This leads me to my question: How do I force Dovecot to print at least a STARTTLS line after a client connects to port 4190? Looking


Kind regards,
Dominik


[1]: https://wiki.dovecot.org/Pigeonhole/ManageSieve/Troubleshooting#Manual_TLS_Login
[2]: https://github.com/thsmi/sieve
[3]: https://www.rubydoc.info/gems/ruby-managesieve/0.4.3/ManageSieve
[4]: https://github.com/roundcube/roundcubemail/tree/1.3.8/plugins/managesieve [5]: http://pear.php.net/package/Net_Sieve/docs/1.3.4/Net_Sieve/Net_Sieve.html

Reply via email to