I cannot connect to dovecot-managesieve service with client settings= STARTTLS; auth=CRAM-MD5 Kmail says: "Failed to fetch the list of scripts" in "Manage Sieve scripts" menu. The IMAP account in KMail is confugured to use the same login settings for Sieve. Log of dovecot: Dec 20 15:32:12 server dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 2 secs): user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, TLS: Disconnected, session=<TxiomEnRvgAKAABZ> STARTTLS and auth=login is also problematic: Dec 20 15:35:45 server dovecot: managesieve-login: Disconnected (client didn't finish SASL auth, waited 0 secs): user=<>, method=LOGIN, rip=10.0.0.89, lip=10.0.0.249, TLS: Disconnected, session=<eSd0pUnRxwAKAABZ> Connecting to dovecot IMAP with the same settings works without any problem: Dec 20 15:48:03 server dovecot: imap-login: Login: user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, mpid=3295, TLS, session=<SBJt0UnRhwAKAABZ> Reproducible: Always
Have tried to connect to managesieve on the same server with Thunderbird client using SARTTLS and login=CRAM-MD5 without problem: Dec 21 10:11:58 server dovecot: managesieve-login: Login: user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, mpid=3030, TLS, session=<NyhcPVnRhwAKAABZ>
Same problem with DIGEST-MD5 / CRAM-MD5 / LOGIN methods. Only PLAIN is working properly. System: KDE 4.9.4 / openSUSE 12.2 x86_84 Dovecot 2.1.12 reports on CRAM-MD5: dovecot: auth: cram-md5(info,12.34.56.78,<xxxxxxxxxxxxxxxxx>): password mismatch dovecot: auth: Debug: client passdb out: FAIL#0111#011user=info dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 2 secs): user=<info>, method=CRAM-MD5, rip=12.34.56.78, lip=12.34.56.78, TLS: Disconnected, session=<xxxxxxxxxxxxxxxx> With DIGEST-MD5 (same as with LOGIN): dovecot: managesieve-login: Disconnected (client didn't finish SASL auth, waited 0 secs): user=<>, method=DIGEST-MD5, rip=12.34.56.78, lip=12.34.56.78, TLS: Disconnected, session=<xxxxxxxxxxxxxxxx> dovecot: auth: Debug: client in: CANCEL#0111
This problem exists since at least KDE 4.3.
I can confirm this issue with current Fedora Packages $ kmail --version Qt: 4.8.4 KDE Development Platform: 4.9.5 KMail: 4.9.5
I can also confirm this! Plaintext login works.
Ok but I can't test... need a server for it.
(In reply to comment #6) > Ok but I can't test... > need a server for it. I can give you an account on my server if you like.
It's possible :) Not sure that I fix it this week but yes please (in private of course)
Seems I've ended up with exactly the same problem. 1. I have a password file dovecot auth, the password entry is CRAM-MD5 2. dovecot settings disable_plaintext_auth = yes auth_mechanisms = cram-md5 3. kmail is set to "use host and login configuration" on port 4190 IMAP authentication works without a hitch, however sieve gets an authentication error... Oct 19 19:43:35 gbr dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 3 secs): user=<xxx@yyy>, method=CRAM-MD5, rip=105.x.x.x, lip=217.x.x.x, TLS: Disconnected, session=<zzz>
Looks like it's still around in KMail 4.14.1. A long week!
Confirmed the bug still exists: Qt: 4.8.6 KDE: 4.14.3 KMail: 4.14.3 So switching from LOGIN to PLAIN worked for me.
Created attachment 97927 [details] Screenshot of kmail sieve manager dialog This bug exists on KMail 5.0.2 on Kubuntu 15.10 AMD 64. The login to sieve succeeds, data is returned, but is inaccessible to kmail, as can be seen in the attached screenshot
Version here is 15.08.2-0ubuntu1
*** This bug has been confirmed by popular vote. ***
KMail 5.3.3 Kolab 16 server with TLS/STARRTLS log on the server side: Dez 19 23:29:51 test.com sieve[7287]: inittls: Loading hard-coded DH parameters Dez 19 23:29:51 test.com sieve[7287]: STARTTLS failed Dez 19 23:29:51 test.com sieve[7287]: Lost connection to client -- exiting problem still persists!
Some logging from the kmail side: log_kmanagersieve: "session1" connect to host url: QUrl("sieve://alice%40test.com@mail-01.test.com:4190?x-mech=PLAIN") log_kmanagersieve: "session1" void KManageSieve::Session::scheduleJob(KManageSieve::SieveJob*) KManageSieve::SieveJob(0x5607dd4137e0) log_kmanagersieve: "session1" void KManageSieve::Session::killJob(KManageSieve::SieveJob*, KJob::KillVerbosity) KManageSieve::SieveJob(0x5607dd4137e0) log_kmanagersieve: "session1" void KManageSieve::Session::scheduleJob(KManageSieve::SieveJob*) KManageSieve::SieveJob(0x5607dd115640) log_kmanagersieve: S: "\"IMPLEMENTATION\" \"Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16\"" log_kmanagersieve: 1 "IMPLEMENTATION" "Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16" "" 0 log_kmanagersieve: S: "\"SASL\" \"\"" log_kmanagersieve: 1 "SASL" "" "" 0 log_kmanagersieve: "session1" Connected to Sieve server: "Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16" log_kmanagersieve: S: "\"SIEVE\" \"comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy date\"" log_kmanagersieve: "session1" Server SASL authentication methods: () log_kmanagersieve: 1 "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy date" "" 0 log_kmanagersieve: S: "\"STARTTLS\"" log_kmanagersieve: "session1" Server script capabilities: ("comparator-i;ascii-numeric", "fileinto", "reject", "vacation", "imapflags", "notify", "include", "envelope", "body", "relational", "regex", "subaddress", "copy", "date") log_kmanagersieve: 1 "STARTTLS" "" "" 0 log_kmanagersieve: S: "\"UNAUTHENTICATE\"" log_kmanagersieve: "session1" Server supports TLS log_kmanagersieve: 1 "UNAUTHENTICATE" "" "" 0 log_kmanagersieve: S: "OK" log_kmanagersieve: "session1" Unrecognised key "UNAUTHENTICATE" log_kmanagersieve: 2 "OK" "" "" 0 log_kmanagersieve: "session1" Sieve server ready & awaiting authentication. log_kmanagersieve: C: "STARTTLS" log_kmanagersieve: S: "OK \"Begin TLS negotiation now\"" log_kmanagersieve: 2 "OK \"Begin TLS negotiation now\"" "" "" 0 log_kmanagersieve: SessionThread::doStartSsl() log_kmanagersieve: void KManageSieve::SessionThread::slotSocketError() "Unknown error" log_kmanagersieve: "session1" No job for reporting this error message! "Could not connect to host Unknown error." log_kmanagersieve: Initial SSL handshake failed. cipher.isNull() is true , cipher.usedBits() is 0 , the socket says: "Unknown error" and the list of SSL errors contains 0 items. log_kmanagersieve: "session1" TLS negotiation done. log_kmanagersieve: "session1" TLS negotiation done, m_state= 2 log_kmanagersieve: Initial SSL handshake failed. cipher.isNull() is true , cipher.usedBits() is 0 , the socket says: "Unknown error" and the list of SSL errors contains 0 items. log_kmanagersieve: "session1" TLS negotiation done. log_kmanagersieve: "session1" TLS negotiation done, m_state= 2 It looks like we have several problems here. - First of all is probably wrong interprets a username from the imap, so instead of "alice@test.com" we getting "alice%40test.com@mail-01.test.com" - Second one, that "SessionThread::doStartSsl()" fails I can make a email account to a KDE developer if it helps to debug.
For sure I can't investigate this week (Christmas holidays for me) but indeed an account which can provide error will help me to investigate for sure.
(In reply to Laurent Montel from comment #17) > For sure I can't investigate this week (Christmas holidays for me) but > indeed an account which can provide error will help me to investigate for > sure. That would be great! Than I will create an account for you and send you login data. Can I use your *@kde.org address for this? Merry Christmas P.S. Probably the majority is busy with holidays && famirly && friends this week :D So I have expected that only after 1-2 weeks it will be possible to try to find out what is going wrong here.
(In reply to Nikolay Brookstein from comment #18) > (In reply to Laurent Montel from comment #17) > > For sure I can't investigate this week (Christmas holidays for me) but > > indeed an account which can provide error will help me to investigate for > > sure. > > That would be great! > > Than I will create an account for you and send you login data. > Can I use your *@kde.org address for this? Yep montel@kde.org > > Merry Christmas Thanks :) > > P.S. Probably the majority is busy with holidays && famirly && friends this > week :D > So I have expected that only after 1-2 weeks it will be possible to try to > find out what is going wrong here.
I still can confirm this bug and I hit this even with version 5.7.3 (included with kubuntu 18.04). When will there be a fix for this? My investigation shows, that the client response of the md5 challenge is wrong by kmail. Doing the steps manually works perfect. here some log entries of the (dovecot-)sieve server that shows the error: auth: Debug: client in: AUTH#0111#011CRAM-MD5#011service=sieve#011secured#011session=TJDeHydsngDAqLKz#011lip=192.168.xxx.xxx#011rip=192.168.xxx.xxx#011lport=4190#011rport=53662 auth: Debug: client passdb out: CONT#0111#011PDA0NDIzNjg4NDE3NTgzMDcuMTUyNjI5MDE3N0BtYXN0ZXJibGFzdGVyLmhvbWxxxxxxxx== auth: Debug: client in: CONT#0111#011Y2hhbHZhdHogMDE5YzU0MjcyOTM4MGFjNmVhMDkxMTg4YTU1Nzxxxxxxx= <-- this is wrong answer! recreating the challenge response manually produces a different output!! auth: Debug: passwd-file(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): lookup: user=username file=/etc/dovecot/users auth: Debug: password(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): Credentials: dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx auth: cram-md5(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): password mismatch auth: Debug: client passdb out: FAIL#0111#011user=username
Same here. When debugging, I notice the returned CRAM-MD5 is always the same, whatever the challenge the server send. Aug 15 10:10:49 kamino dovecot[25805]: auth: Debug: client passdb out: CONT 1 PDE2MzYzMDkzMDA4MTM5MTYuMTU2NTg2Mzg0OUBrYW1pbm8+ Aug 15 10:10:49 kamino dovecot[25805]: auth: Debug: client in: CONT 1 YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx= (previous base64 data may contain sensitive data) Aug 15 10:11:00 kamino dovecot[25805]: auth: Debug: client passdb out: CONT 1 PDU3NjA0MjQyNTkyMzAwMzEuMTU2NTg2Mzg2MEBrYW1pbm8+ Aug 15 10:11:00 kamino dovecot[25805]: auth: Debug: client in: CONT 1 YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx= (previous base64 data may contain sensitive data) Notice the 2 challenges PDE2MzYzMDkzMDA4MTM5MTYuMTU2NTg2Mzg0OUBrYW1pbm8+ and PDU3NjA0MjQyNTkyMzAwMzEuMTU2NTg2Mzg2MEBrYW1pbm8+, but the same response YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx
Seems the used challenge is empty string ./gen-auth.pl CRAM-MD5 "aeris" "$PASS" "" YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx= Which is the same as the always sent token in my case
Trouble is here: https://github.com/KDE/libksieve/blob/master/src/kmanagesieve/sessionthread.cpp#L265-L266 Seems strange, the challenge is expected to be read *before* the AUTHENTICATE command…
Ok, here is the root cause: https://github.com/KDE/libksieve/blob/master/src/kmanagesieve/session.cpp#L171 With CRAM-MD5, the challenge is on the `response.key()`, not on the `data` field, which is here empty. Don't know how to fix this without breaking other auth type…