| Summary: | error in CRAM-MD5-Auth WITHOUT STARTTLS | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Christian Kuehn <christian> |
| Component: | smtp | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | andreas.korinek, carstenlohrke, mg, mss, roger.miliker |
| Priority: | NOR | ||
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Christian Kuehn
2003-03-24 15:20:09 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 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. |