Version: 1.5 (using KDE KDE 3.1) Installed from: SuSE RPMs OS: Linux KMail cannot authenticate itself to a smtp-server via CRAM-MD5 if no encryption is selected. Two situation: No.1 SMTP-AUTH required, I select CRAM-MD5 as authebtication-method, enter username and password and start to send the mail. This failed because of wrong authentication data. No.2 Same as no.1, but now I select encryption TLS. All other parameters are unchanged. The mail can send sucessfully to the server. For debugging I look at the server and found this No. 1 14:59:28 24844 result: test 14:59:28 24844 CRAM-MD5: user name = lt@nana.de 14:59:28 24844 challenge = <24844.1048514368@mail.hamburg.cityline.net> 14:59:28 24844 received = cad91310d99198baeeb0db4ef51c381a 14:59:28 24844 digest = 99f1122086d93b0eae1bed326cf44aef No. 214:57:18 24841 result: test 14:57:18 24841 CRAM-MD5: user name = lt@nana.de 14:57:18 24841 challenge = <24841.1048514238@mail.hamburg.cityline.net> 14:57:18 24841 received = 017fc1b1901561613ea6da5ad9c7a31c 14:57:18 24841 digest = 017fc1b1901561613ea6da5ad9c7a31c result means the password. As you can see KMail calculate the digest no correct (the digest coming from KMail named "received" in the debug-output above. The value of "digest" is correct, checked by calculating this here. It looks like a problem reading the challenge from an unencryptet smtp-connection... Best wishes.... Christian
Also not work DIGEST-MD5. Server: Debian 2.2, k2.2.19, sendmail 8.12.8p1. Client: Slackware 9.0, k2.4.20, KDE3.1.0. vyp08@mail.ru
Does POP3/IMAP work with CRAM-MD5/DIGEST-MD5? Or is it only SMTP?
Didn't test it for POP3/IMAP, just SMTP-AUTH.
*** Bug 68520 has been marked as a duplicate of this bug. ***
Actually, I see the opposite problem. In kmail 3.1.4, if I use TLS encryption, cram-md5 fails, but if I disable encryption, it succeeds. Note that login works fine over TLS, and also works without TLS. --M
I have this problem also with TLS enabled. Had it working for ~1 day after I enabled TLS on my server. But now it stopped working and I get the same error as I get without encryption. Mail server is Exim 4.2
Forget my last comment - Works with TLS again now. Looks like it was a problem with the server. After I installed a script for checking what is sent through the SMTP-Port, which listens on a port and redirects it to the SMTP-Port (so I had to change the destination-port in KMail), and restartet my firewall on the server it works again. Even when I exit the script again. Julian
*** Bug 72167 has been marked as a duplicate of this bug. ***
*** Bug 74722 has been marked as a duplicate of this bug. ***
Worked in KMail 1.5, but doesn't work in 1.6 in my case
I cannot not successfully authenticate to the smtp server with any combination of Authentication or Encryption. I can send successfully in other clients like Evolution using ssl, etc. I have the same authentication problem in kmail with other smtp servers. Prior to the total failure the client is experiencing now I was able to successfully authenticate sporadically.
Finally stopped working completely here, too. Works with many other Mail clients fine on the same server.
I recently installed kde3.2.1 from gentoo ebuilds on my laptop, Kmail worked a few days and then suddenly showed this bug again. I use plain now.
yep, unfortunately i am experiencing the same prob.
Converted another workstation to Gentoo with KDE3.2.1, same problem shows up again.
Any chance to get this into KDE 3.2.3?
Same problem here. Using KDE 3.3.0 with Gentoo, I am not able to send mails to my smtp server with CRAM-MD5. 4 out of 5 tries fail. I swiched to the LOGIN method now, that works.
Can you try with kdebase/kioslaves/smtp from HEAD? We use a different SASL library there, and I long suspected that the bug is actually in libkdesasl. Thanks, Marc
And another SASL failure.
Before I converted the ioslaves to cyrus-sasl, I tested the changes with all available mechanisms with a Sendmail server, and they're worked. The bugs I encountered in the old implementation which could cause the problem with encrypted sessions were mainly that the service names wer called smtps, pop3s and imaps with SSL/TLS, but they should remain smtp, pop and imap even if SSL/TLS used.
Thank you for finally having a look at it. Hopefully we'll see v.3.3.2 with a fix/backport, soon. I'll have to face this bug for a couple of months now - if you look at the bug opening date, quite a few users much longer - it's really annoying.
I noticed a lot of people who have this problem live in an area where codepage 437 is not default, and I think here lies the problem: look at the way the passwd is stored in kmailrc, it seems some fairly simple algorithm sine it's always -3 bytes for one passwd char -all 3-byte-sequences start with ï¿ or ïŸ Now look at what ascii code Ÿ is in codepage 437 (ain't there at all, don't bother), look at it's code in cp850 and in iso8859-1. all different. So I guess kmail might store it in what ever encoding it uses by default and then tries to read it from a text config file which is eventually been edited edited in another encoding or gets a different encoding due to mount options or whatever. In other words, should go away when I use KWallet instead of kmailrc storing. Gonna investigate that when I have time to tinker.
I'm also having this issue with kmail 1.7.1, and an Exim server. (US if that matters).
Same here (kmail 1.7.1 and Exim 3.3 server). This is without encryption. Testing with the cmd5 authentication tester (http://www.net-track.ch/opensource/cmd5/) and a telnet session shows that the server is working correctly.
Reassigning the bugs of the SMTP, IMAP and POP ioslaves to kdepim-bugs.