(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: KDE 3.0.3 Severity: normal Installed from: Mandrake RPMs Compiler: gcc-2.96 OS: Linux OS/Compiler notes: Using Mandrake 8.1 kernel 2.4.8-34.1 When checking the box: delete mail from sever kmail "hangs" on popping the next time after deleting mail. When the box is not checked and there is at least one mail on the server everything seems to work perfectly. Clicking the cross in the statusbar does solve the problem but it is rather annoying to do when using kmail as a background process to check for mail. Also just clicking apply in the configuration window for sending takes kmail out of the "hang". Done test "delete mail from server" is checked. state: server empty send myself a mail check mail mail is there check mail (transmission does not finish) send myself a mail because previous transmission is not finished mail is not seen. CPU-usage grows to 73% change settings for pop mail (any setting) immediately pop-up announcing: "you have new mail" check mail mail is there Maybe the reply from the pop server is not in standard format but then I would expect the pop-slave to die. Gertjan (Submitted via bugs.kde.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 27 August 2002 10:52 g.kloosterman@ctw.utwente.nl wrote: > > Done test "delete mail from server" is checked. > state: server empty > send myself a mail > check mail > mail is there > check mail > (transmission does not finish) > send myself a mail > because previous transmission is not finished mail is not seen. > CPU-usage grows to 73% Which process takes the CPU? > change settings for pop mail (any setting) > immediately pop-up announcing: "you have new mail" > check mail > mail is there Could it be that your server doesn't like it if you check for new mail more that once a minute or something like that? > Maybe the reply from the pop server is not in standard format but then I > would expect the pop-slave to die. What server software are you using? You probably can check this with "telnet your.server.com 110". Could you watch with a network traffic monitor like ethereal what exactely is going on? You shouldn't send a log file that includes your password. Regards Michael Häckel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9a0Jte9KEPyN2R8URAl9jAKCHimFTHLFqGF0hfBYIEHAHAU/3XgCfRNqy lgOnaNhHDnHEHkAtWeT9L0I= =9twP -----END PGP SIGNATURE-----
--------------Boundary-00=_DUYHKB02N2SPQU7PL32C Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable > > Which process takes the CPU? the process is kmail CPU usage runs up over time set to auto-check every = 2 minutes.=20 > > Could it be that your server doesn't like it if you check for new mail > more that once a minute or something like that? Nope that is not a problem if there is one mail on the server and I leave= it there I can check every 0.001 seconds > What server software are you using? IMS POP3 Server 0.87 > > Could you watch with a network traffic monitor like ethereal what exacte= ly > is going on? You shouldn't send a log file that includes your password. Oki installed ethereal results are as follows: Response: IMS POP3 Server 0.87 Ready <13456984.1030441584.343@mohr.ctw.utwe= nte.nl> Request: USER myname Response: +OK myname is welcome here Request: PASS ********* Response: +OK myname's mailbox has 0 message(s) (0 octets) Request: LIST Response: +OK 0 message (0 octets) And no further POP messages after that i.e. pop hang" Find attached the capture.=20 Kind regards Gertjan Kloosterman (Complete bug history is available at http://bugs.kde.org/db/47/47045.html) --------------Boundary-00=_DUYHKB02N2SPQU7PL32C Content-Type: application/octet-stream; name="poppacks.libpcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="poppacks.libpcap" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA+01rPV1rDACDAAAAgwAAAADQtwkG HwBgsFcL7AgARQAAdZzQQACABtKOgllDWoJZQxcAbghvia+So83fcfRQGCI4 Zd8AACtPSyBJTVMgUE9QMyBTZXJ2ZXIgMC44NyBSZWFkeSA8MTM0NDgzNTIu MTAzMDQ0MjUyMS4zMUBtb2hyLmN0dy51dHdlbnRlLm5sPg0K+01rPb54DABF AAAARQAAAABgsFcL7ADQtwkGHwgARQAAN4dmQABABig3gllDF4JZQ1oIbwBu zd9x9ImvkvBQGBbQIRIAAFVTRVIgbXluYW1laXMNCvtNaz3neQwAVAAAAFQA AAAA0LcJBh8AYLBXC+wIAEUAAEad0EAAgAbRvYJZQ1qCWUMXAG4Ib4mvkvDN 33IDUBgiKT8aAAArT0sgbXluYW1laXMgaXMgd2VsY29tZSBoZXJlDQr7TWs9 hXoMAEcAAABHAAAAAGCwVwvsANC3CQYfCABFAAA5h2dAAEAGKDSCWUMXgllD WghvAG7N33IDia+TDlAYFtAIwQAAUEFTUyAqKioqKioqKioqDQr7TWs9/ZcN AGoAAABqAAAAANC3CQYfAGCwVwvsCABFAABcntBAAIAG0KeCWUNagllDFwBu CG+Jr5MOzd9yFFAYIhgHdQAAK09LIG15bmFtZWlzJ3MgbWFpbGJveCBoYXMg MCBtZXNzYWdlKHMpICgwIG9jdGV0cykNCvtNaz0DnA0APAAAADwAAAAAYLBX C+wA0LcJBh8IAEUAAC6HaEAAQAYoPoJZQxeCWUNaCG8Abs3fchSJr5NCUBgW 0PtnAABMSVNUDQr7TWs9vZ0NAGcAAABnAAAAANC3CQYfAGCwVwvsCABFAABZ n9BAAIAGz6qCWUNagllDFwBuCG+Jr5NCzd9yGlAYIhIJiwAAK09LIDAgbWVz c2FnZSAoMCBvY3RldHMpDQowIG1lc3NhZ2VzICgwIG9jdGV0cykNCg== --------------Boundary-00=_DUYHKB02N2SPQU7PL32C--
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 27 August 2002 12:08 Gertjan Kloosterman wrote: > > Oki installed ethereal results are as follows: > Response: IMS POP3 Server 0.87 Ready > <13456984.1030441584.343@mohr.ctw.utwente.nl> Request: USER myname > Response: +OK myname is welcome here > Request: PASS ********* > Response: +OK myname's mailbox has 0 message(s) (0 octets) > Request: LIST > Response: +OK 0 message (0 octets) > > And no further POP messages after that i.e. pop hang" > Find attached the capture. The server should actually send an additional Response: . in order to tell the client that the LIST command finished. Is this really not there (also if you try manually via telnet on port 110)? This is probably for what KMail is waiting then and I can't see what we could do about it if the server simply doesn't send it. Regards Michael Häckel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9bTZEe9KEPyN2R8URAiAPAJ9QQOXM1806PcRpvFVFHqSvyShbYwCcCo7v LXOrfhvymARcUZY6KAeZbnY= =rHMN -----END PGP SIGNATURE-----
> The server should actually send an additional > > Response: . > > in order to tell the client that the LIST command finished. > > Is this really not there (also if you try manually via telnet on port 110= )? > > This is probably for what KMail is waiting then and I can't see what we > could do about it if the server simply doesn't send it. I see what you mean LIST is a multiline response and should be ended by a termination octet. The server does not send it (checked manually). Howeve= r=20 if the reply is +OK 0 0 then the next client command is obviously going to= =20 be QUIT might as well send that without waiting for the server to send th= e=20 termination octet. I guess that is what all the other mailers do since I= =20 have not encountered problems with them before.=20 Thanks for the support so far though at least I now know what the problem = is. Kind regards Gertjan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 August 2002 09:55 Gertjan Kloosterman wrote: > > I see what you mean LIST is a multiline response and should be ended by > a termination octet. The server does not send it (checked manually). Well according to http://www.ietf.org/rfc/rfc1939.txt it _must_ send it. > However if the reply is +OK 0 0 then the next client command is obviously > going to be QUIT might as well send that without waiting for the server > to send the termination octet. I guess that is what all the other mailers > do since I have not encountered problems with them before. For everything that is right of the "+OK" there is no standard. My server for example just responds "+OK scan listing follows". I therefore still have no idea how this server can work together with any other POP3 client. Do they maybe just time out after some time? The only other way to check for mail I currently see is the stat command but using that only produces overhead on all other correctely working servers. At least in the case not all messages are fetched from the server but only the new ones we definitely need the output of the list command to display the progress. In any case this bug should be fixed in the server and not worked around in the client. Regards Michael Häckel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9bltye9KEPyN2R8URArnrAJ90nKg26CAL6htooIqEVwNFPCOKSQCffhus ZFpzLXap+TDefamVAb4Gx20= =qh1w -----END PGP SIGNATURE-----
Gertjan - is it still a problem?
Reassigning the bugs of the SMTP, IMAP and POP ioslaves to kdepim-bugs.
Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4.0 RC 2?
*** This bug has been marked as a duplicate of 40920 ***