(*** This bug was imported into bugs.kde.org ***) Package: kio-pop3 Version: KDE 3.0.0 Severity: normal Installed from: RedHat RPMs Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified I've one POP3 account on a server (profimail.telda.net) which seems to have an invalid POP3 implementation. When there's no mail the conversation using telnet looks like this: +OK POP3 server ready <541066364.1018734871@TDN.GeoNet.de> user **** +OK **** is a real hoopy frood pass **** +OK ****'s maildrop has 0 messages (0 octets) list +OK 0 messages (0 octets) quit +OK POP3 server TDN signing off (0 messages left) The problem is that the server doesn't send a '.' after the list command. This leads to an infinite loop in pop3.cc starting line 698. (Submitted via bugs.kde.org)
That looks like a valid bug. But I worry the server is too broken to support. Did you try sending a bug report to profimail.telda.net? Don. On Sunday 14 April 2002 06:05 ingo@fivemile.org wrote: > Package: kio-pop3 > Version: KDE 3.0.0 > Severity: normal > Installed from: RedHat RPMs > Compiler: Not Specified > OS: Linux > OS/Compiler notes: Not Specified > > I've one POP3 account on a server (profimail.telda.net) which seems > to have an invalid POP3 implementation. When there's no mail the > conversation using telnet looks like this: > > +OK POP3 server ready <541066364.1018734871@TDN.GeoNet.de> > user **** > +OK **** is a real hoopy frood > pass **** > +OK ****'s maildrop has 0 messages (0 octets) > list > +OK 0 messages (0 octets) > quit > +OK POP3 server TDN signing off (0 messages left) > > The problem is that the server doesn't send a '.' after the list > command. This leads to an infinite loop in pop3.cc starting line > 698. > > > (Submitted via bugs.kde.org)
In the past (KDE2) I fixed this problem by breaking the loop when ReadLine returned an empty string. It still took some time to check this server but after that it returned instead of looping with 100% CPU. Maybe this is a possibility to compensate the broken server code... I'm not sure whether this fix is correct but it worked here for a long time. Unfortunatly I'm unable to compile kio_pop3 at the moment so I can't test it with KDE3/CVS code... > That looks like a valid bug. But I worry the server is too broken to > support. Did you try sending a bug report to profimail.telda.net? > > Don. > > On Sunday 14 April 2002 06:05 ingo@fivemile.org wrote: > > Package: kio-pop3 > > Version: KDE 3.0.0 > > Severity: normal > > Installed from: RedHat RPMs > > Compiler: Not Specified > > OS: Linux > > OS/Compiler notes: Not Specified > > > > I've one POP3 account on a server (profimail.telda.net) which seems > > to have an invalid POP3 implementation. When there's no mail the > > conversation using telnet looks like this: > > > > +OK POP3 server ready <541066364.1018734871@TDN.GeoNet.de> > > user **** > > +OK **** is a real hoopy frood > > pass **** > > +OK ****'s maildrop has 0 messages (0 octets) > > list > > +OK 0 messages (0 octets) > > quit > > +OK POP3 server TDN signing off (0 messages left) > > > > The problem is that the server doesn't send a '.' after the list > > command. This leads to an infinite loop in pop3.cc starting line > > 698. > > > > > > (Submitted via bugs.kde.org)
As far as I can tell, the code remains unchanged in pop3.cc. Is this going to be fixed? IMHO, the code is too optimistic in expecting that every server will behave correctly. Entering an infinite loop because of a poorly implemented server is not a good thing. Shouldn't it at least detect incorrect replies and notify the user?
As I'm the reporter of this bug: The server has been fixed to return the missing '.\r\n' so MY problem has been solved :o) But: as the myReadLine method in POP3Protocol returns a zero length buffer in case of an error (read fails), the possibility of entering this endless loop is still there - even worse: in line 713 (buf[bufStrLen - 2] = '\0';) bufStrLen will be 0 making the array index -2... As a quick fix I'd change (line 708) from if (strcmp(buf, ".\r\n") == 0) { break; } to if (strcmp(buf, ".\r\n") == 0 || strlen(buf) ==0) break; This will not introduce correct error handling, however; but it'll fix the above problem...
Let's increase the bug severity to "major", as it is about an endless loop. Have a nice day!
Hope I got the right line as pop3.cc has changed quite a bit since the above "quick fix" was posted. Here is it in patch form. Being this has been marked "Major" for a while now I hope this is fixed soon. --- kdebase-3.5.5/kioslave/pop3/pop3.cc.old 2006-11-02 15:02:22.000000000 -0600 +++ kdebase-3.5.5/kioslave/pop3/pop3.cc 2006-11-02 14:58:38.000000000 -0600 @@ -495,8 +495,8 @@ myReadLine(buf, sizeof(buf) - 1); // HACK: This assumes fread stops at the first \n and not \r - if (strcmp(buf, ".\r\n") == 0) { - break; // End of data + if (strcmp(buf, ".\r\n") == 0 || strlen(buf) == 0) { + break; // End of data or Invalid response } // sanders, changed -2 to -1 below buf[strlen(buf) - 2] = '\0';
Reassigning the bugs of the SMTP, IMAP and POP ioslaves to kdepim-bugs.
*** Bug 47045 has been marked as a duplicate of this bug. ***
SVN commit 1008036 by mkoller: BUG: 141699 BUG: 40920 Handle the case when the POP server closes the connection after returning the result, e.g. +OK 0 messages after the LIST command M +2 -2 pop3.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1008036