Bug 56319 - error in CRAM-MD5-Auth WITHOUT STARTTLS
Summary: error in CRAM-MD5-Auth WITHOUT STARTTLS
Status: CONFIRMED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: smtp (show other bugs)
Version: 3.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 68520 72167 74722 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-24 15:20 UTC by Christian Kuehn
Modified: 2007-12-12 23:38 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Kuehn 2003-03-24 15:20:09 UTC
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
Comment 1 vyp08 2003-04-16 14:35:01 UTC
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 
 
Comment 2 Marc Mutz 2003-10-12 17:16:59 UTC
Does POP3/IMAP work with CRAM-MD5/DIGEST-MD5? Or is it only SMTP? 
Comment 3 Christian Kuehn 2003-10-12 17:19:47 UTC
Didn't test it for POP3/IMAP, just SMTP-AUTH.
Comment 4 Ingo Klöcker 2003-11-19 13:48:20 UTC
*** Bug 68520 has been marked as a duplicate of this bug. ***
Comment 5 M Graff 2003-11-27 03:10:04 UTC
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
Comment 6 Julian Scheel 2003-12-29 21:09:42 UTC
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
Comment 7 Julian Scheel 2003-12-29 22:11:40 UTC
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
Comment 8 Ingo Klöcker 2004-01-13 18:48:59 UTC
*** Bug 72167 has been marked as a duplicate of this bug. ***
Comment 9 Ingo Klöcker 2004-02-09 18:45:41 UTC
*** Bug 74722 has been marked as a duplicate of this bug. ***
Comment 10 Andreas Korinek 2004-02-09 18:48:07 UTC
Worked in KMail 1.5, but doesn't work in 1.6 in my case
Comment 11 Joel Atyas 2004-03-28 18:04:25 UTC
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. 
Comment 12 Julian Scheel 2004-03-28 18:28:26 UTC
Finally stopped working completely here, too.
Works with many other Mail clients fine on the same server.
Comment 13 Andreas Korinek 2004-03-28 18:32:08 UTC
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.
Comment 14 dom 2004-04-03 11:23:19 UTC
yep, unfortunately i am experiencing the same prob.
Comment 15 Andreas Korinek 2004-04-03 11:29:43 UTC
Converted another workstation to Gentoo with KDE3.2.1, same problem shows up again.
Comment 16 Carsten Lohrke 2004-05-20 03:38:32 UTC
Any chance to get this into KDE 3.2.3?
Comment 17 Eggert Ehmke 2004-09-23 14:29:42 UTC
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.
Comment 18 Marc Mutz 2004-10-24 18:36:50 UTC
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
Comment 19 Marc Mutz 2004-10-29 19:08:46 UTC
And another SASL failure.
Comment 20 Szombathelyi György 2004-10-30 19:48:16 UTC
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.
Comment 21 Carsten Lohrke 2004-10-30 22:22:51 UTC
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. 
Comment 22 Dexter Filmore 2005-02-05 14:30:30 UTC
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.
Comment 23 Larry Rosenman 2005-02-26 21:14:05 UTC
I'm also having this issue with kmail 1.7.1, and an Exim 
server. 

(US if that matters).
Comment 24 David Kessler 2005-03-07 02:28:41 UTC
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.
Comment 25 Thomas McGuire 2007-12-12 23:38:10 UTC
Reassigning the bugs of the SMTP, IMAP and POP ioslaves to kdepim-bugs.