GNOME Bugzilla – Bug 234322
Slow POP3 checking in 1.2, where 1.0.8 was fast
Last modified: 2003-03-06 09:21:58 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.
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...