After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 234322 - Slow POP3 checking in 1.2, where 1.0.8 was fast
Slow POP3 checking in 1.2, where 1.0.8 was fast
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other other
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2002-11-20 05:40 UTC by ckreddan
Modified: 2003-03-06 09:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ckreddan 2002-11-20 05:40:44 UTC
Description of Problem:
Evolution 1.2 is very slow to check POP3 account,
downloading and checking the headers rather than
using UIDL to look for already-read mail. It
doesn't use UIDL in a case where 1.0.8 does.

Akin to bug#233750, except I ran before-and-after
traces to verify that the POP3 server is 
providing identical responses to the first
few commands from the slow 1.2 and the fast
1.0.8. It is what THEY do afterward that 
makes the difference.

Steps to reproduce the problem:
1. Turned on verbose debugging, captured the
dialog between 1.2 and the POP3 server.
2. De-install 1.2 and reinstalled 1.0.8 (from
Redhat 8.0)
3. Turned on verbose debugging again and 
captured the (shorter) dialog between 1.0.8 
and the same POP3 server.

Actual Results:
Both versions start with a CAPA command to 
the remote POP3 server (an MS-Exchange server's 
POP3 port). The Exchange server replies 
'-ERR Protocol Error' to the CAPA command 
in either (1.0.8, 1.2) case.

The next events in both cases are that Evolution
logs in with the userid and password. 

After those commands and responses, identical 
so far in both cases, 1.0.8 issues a STAT 
and then a UIDL, both of which are accepted.
Evolution 1.2 instead issues a LIST and 
then begins slowly and painfully issuing
'TOP nn 0' commands for each header in the
list.


Expected Results:
Use UIDL when the POP3 server gave the same
responses that allowed 1.0.8 to use UIDL.

How often does this happen? 
Every time one polls the POP3 server, if there
are any messages left on the server.

Additional Information:

Running Redhat 8.0, using either Evolution 1.0.8
from RH, or the new 1.2 release from Ximian.
Comment 1 Bert van Leeuwen 2003-03-06 09:21:58 UTC
The mailer sends a CAPA request, and upon receipt of the -ERR seems to assume that UIDL does not work either. Manually checking my pop3 server via telnet confirms that UIDL works just fine. 

IMHO this is a major bug since it can unnecessarily cause massive bandwidth and time wastage if you leave your pop3 messages on the server.

Suggestion: In the event of CAPA not being supported, try to issue UIDL anyway, the overhead of that is much less than assuming it is not supported and then always issuing TOP for all the messages saved on the server...