Version: 1.9.7 (using KDE KDE 3.5.7) Installed from: Gentoo Packages Compiler: Target: x86_64-pc-linux-gnu OS: Linux (x86_64) release 2.6.21.7 The mailserver is qmail, and smtp-auth and pop-before-smtp are enabled. When I set up kmail to use TLS and Plain as login methods it fails with the following error: The server responded: "you are already authenticated" Using "Login" instead of plain doesn't work at all. This is a problem with kmail, as the same settings work without any problem in thunderbird (and outlook). The server message is only a notice not an error as kmail interprets it. It should just continue, but it doesn't. This is a major problem for me as I'm unable to currently use that outgoing mailserver with kmail. The server reports the following features: 250-domain.tld 250-AUTH=LOGIN CRAM-MD5 PLAIN 250-AUTH LOGIN CRAM-MD5 PLAIN 250-STARTTLS 250-PIPELINING 250 8BITMIME If you need any more information, please let me know. I could also create an account for a developer willing to have a look at this.
I've never tested this before, but apparently CRAM-MD5 works fine. But I still think there is something wrong with LOGIN.
Does kmail have to handle this "you are already authenticated" error? qmail displays: "503 you are already authenticated". May be kmail just doesn't like this 503? And there should be some other error code? Is there some mechanizm in kmail which detects if kmail must use authentication or not? For example, if it doesn't see AUTH=.. line, it doesn't use authentication..
I didn't add this, but cram-md5 just works like 2 times and then the same error happens. Well I guess it really should as other mail-clients do handle it and authenticate normaly. qmail is really standard conform, so I guess qmail is right about giving that error (it is no error actually, kmail only interprets it as error) and kmail should just ignore it and go ahead with the authentication. As you can see from my telnet session, qmail does accept authentication and print those AUTH=... lines.
>As you can see from my telnet session, qmail does accept authentication and print those AUTH=... lines Was your telnet connection opened from the same host from which you authenticated via pop? Because, as you know, when smtp-after-pop authorization method enabled, qmail remebers the host after pop authetication so user from this host can use qmail as open relay without autentication during poplock time. If so, are you sure that you were in "poplock window" when opening that telnet conection? Yes, seems like kmail is right when it throws the error. According to rfc server must return 503 error only when using AUTH command after it was used once and autentication was successfull. kmail uses AUTH first time, so it doesn't expect this error. As I can see, thunderbird even doesn't try to autenticate (doesn't use AUTH command) if it's not needed: Auth is not needed (pop auth has been used before, and we are in "poplock window"): -------------------------------------------------------------------- <...> [pid 1444] write(1, "220 ##SERVER_HOSTNAME## ESMTP\r\n", 31) = 31 [pid 1444] select(1, [0], NULL, NULL, {1200, 0}) = 1 (in [0], left {1199, 964000}) [pid 1444] read(0, "EHLO ##LOCAL_HOSTNAME##\r\n", 1024) = 25 [pid 1444] select(2, NULL, [1], NULL, {1200, 0}) = 1 (out [1], left {1200, 0}) [pid 1444] write(1, "250-##SERVER_HOSTNAME##\r\n250-STARTTLS\r\n250-PIPELINING\r\n250 8BITMIME\r\n", 69) = 69 [pid 1444] select(1, [0], NULL, NULL, {1200, 0}) = 1 (in [0], left {1199, 960000}) [pid 1444] read(0, "MAIL FROM:<##SENDER##>\r\n", 1024) = 39 [pid 1444] select(2, NULL, [1], NULL, {1200, 0}) = 1 (out [1], left {1200, 0}) [pid 1444] write(1, "250 ok\r\n", 8) = 8 [pid 1444] select(1, [0], NULL, NULL, {1200, 0}) = 1 (in [0], left {1199, 966000}) [pid 1444] read(0, "RCPT TO:<##RECIPIENT##>\r\n", 1024) = 32 <...> -------------------------------------------------------------------- Auth is needed: -------------------------------------------------------------------- <...> [pid 1497] write(1, "220 ##SERVER_HOSTNAME## ESMTP\r\n", 31) = 31 [pid 1497] select(1, [0], NULL, NULL, {1200, 0}) = 1 (in [0], left {1199, 965000}) [pid 1497] read(0, "EHLO ##LOCAL_HOSTNAME##\r\n", 1024) = 25 [pid 1497] select(2, NULL, [1], NULL, {1200, 0}) = 1 (out [1], left {1200, 0}) [pid 1497] write(1, "250-##SERVER_HOSTNAME##\r\n250-AUTH=LOGIN CRAM-MD5 PLAIN\r\n250-AUTH LOGIN CRAM-MD5 PLAIN\r\n250-STARTTLS\r\n250-PIPELINING\r\n250 8BITMIME\r\n", 131) = 131 [pid 1497] select(1, [0], NULL, NULL, {1200, 0}) = 1 (in [0], left {1199, 967000}) [pid 1497] read(0, "AUTH CRAM-MD5\r\n", 1024) = 15 <...> -------------------------------------------------------------------- I think the kmail behaviour should be similar.
Yes it was opened from the same host I am using kmail on (and kmail has been used before for sending/receiving). And yes I was in the "poplock window" when I did the telnet test (just to be sure, I did it again now, same result). >Yes, seems like kmail is right when it throws the error. According to rfc server must return 503 error only when using AUTH command after it was used once and autentication was successfull. kmail uses AUTH first time, so it doesn't expect this error. That might correct, but kmail isn't able to send mails at all. Thunderbird works perfectly fine. Also this seems to be a correct behaviour then, qmail knows that I am already authenticated, so it throws that error, kmail should then just try to send the mail withtout authenticating because the server said we are already authenticated. But it just queues the mail and stops. When I disable authentication in kmail, according to your reasoning it should work ? It doesn't. It works for sending mails to domains hosted on the same server but for all other recipients I get this error: The server responded: "sorry, that domain isn't in my list of allowed rcpthosts; no valid cert for gatewaying (#5.7.1)"
"sorry, that domain isn't in my list of allowed rcpthosts" means that relaying is closed and you can send mail only to local users on qmail host. You should disabe authentication in kmail AND before sending message you must try to recieve messages from your mailbox via POP. After you click recieve mail via POP, the relaying will be open without authentication. Or I didn't understand you correctly.
I know that with pop-before-smtp you have to check your mail before trying to send, as the name implies :-). That is not the problem here. Kmail doesn't correctly handle the above mentioned error. I've tried several clients and they all work correctly, but kmail. Anyway, this is not a special insanely configured mail server... it's just a standard setup. Sending doesn't work either way with this server. I would gladly give you an account to try for yourself :-).
> I know that with pop-before-smtp you have to check your mail before trying to send, as the name implies :-). Ok, understood =) And yes, it's a kmail bug. But I think that it doesn't actually handle the "503" error, it must detect if authentication is needed and not ot use AUTH command if it's already authenticated. I would gladly give you an account to try for yourself :-). It would be nice =)
The same happens in Ubuntu Gutsy with KMail 1.9.6. In Feisty was working fine.
Ummm, just found that removing the "Server requires authentication" in the SMTP setup it works .... :S
>Ummm, just found that removing the "Server requires authentication" in the SMTP setup it works .... :S Well, closing this bug report then.
It fixes the problem for him but it still doesn't work here. Valeriy also confirmed this to be a bug in kmail: "And yes, it's a kmail bug. But I think that it doesn't actually handle the "503" error, it must detect if authentication is needed and not ot use AUTH command if it's already authenticated. " Kmail does not check when to authenticate, other clients like thunderbird do. Since this bug hit me I've been forced to use thunderbird instead of kmail...which sucks :-(
As commented in #12, this issue hasn't been solved yet.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.