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 648468 - POP3 doesn't recover or claim error after lost connection
POP3 doesn't recover or claim error after lost connection
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.0.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[pop]
: 650027 653526 653891 653893 655373 657614 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-22 13:34 UTC by Sebastian Keller
Modified: 2011-09-05 17:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
CAMEL_DEBUG=pop3 (425.30 KB, application/octet-stream)
2011-04-22 13:34 UTC, Sebastian Keller
  Details
eds patch (15.78 KB, patch)
2011-06-21 10:09 UTC, Milan Crha
committed Details | Review
evo patch (1006 bytes, patch)
2011-06-21 10:11 UTC, Milan Crha
committed Details | Review

Description Sebastian Keller 2011-04-22 13:34:48 UTC
Created attachment 186479 [details]
CAMEL_DEBUG=pop3

After starting Evolution fetching pop3-mails works without problems. Then after some time somehow it breaks as Evolution no longer seems to get replys from the server. This seems to be related rather to the time Evolution has been running than the number of pop3 requests as i have only been able to trigger this after Evolution has been running for a couple of minutes but not by simply clicking on "Send/Receive" several times. Maybe the connection times out without Evolution noticing it or something like that.

Whenever this happens Evolution displays the following dialog:

Error while Fetching Mail:
Cannot get POP summary: Success

Also because of those seemingly empty replies evolution empties the uids-cache file which causes all the mails to be downloaded again after Evolution has been restarted.

This problem started right after I switched from Ubuntu (Evo 2.32.3) to Fedora (Evo 3.0.0), so it is probably not a problem with the server.

The configuration of the according account:
<?xml version="1.0"?>
<account name="GMX" uid="1303215978.29490.1@sebastian" enabled="true"><identity><name>Sebastian Keller</name><addr-spec>sebastian-keller@gmx.de</addr-spec><signature uid=""/></identity><source save-passwd="true" keep-on-server="true" auto-check="true" auto-check-timeout="10"><url>pop://2617572@pop.gmx.net/;keep_on_server;use_ssl=when-possible;filter;use_lsub;cachedconn=5;command=ssh%20-C%20-l%20%25u%20%25h%20exec%20/usr/sbin/dovecot%20--exec-mail%20imap;check_all;use_idle;use_qresync</url></source><transport save-passwd="true"><url>smtp://2617572;auth=PLAIN@mail.gmx.net:587/;use_ssl=when-possible</url></transport><drafts-folder>maildir:/home/sebastian/.local/share/evolution/mail/local;need-summary-check=no#Drafts</drafts-folder><sent-folder>maildir:/home/sebastian/.local/share/evolution/mail/local;need-summary-check=no#Sent</sent-folder><auto-cc always="false"><recipients></recipients></auto-cc><auto-bcc always="false"><recipients></recipients></auto-bcc><receipt-policy policy="never"/><pgp encrypt-to-self="true" always-trust="false" always-sign="false" no-imip-sign="false"/><smime sign-default="false" encrypt-default="false" encrypt-to-self="true"/></account>
Comment 1 Milan Crha 2011-06-21 10:06:26 UTC
Confirming, I just reproduced this with my server. You got it right, though the reason is interesting. Evolution keeps connection to pop3 server open forever, and the pop3 camel provider doesn't recover one it's lost, but the server can disconnect in any time, which prevents pop3 from any further updates. It was "connection reset by peer" for me, and after this error the pop3 didn't claim any error, but also didn't update its local cache. The list of known UIDs was kept as is till the error, and even after it, but because the next message fetching from the server failed silently, then the evolution thought there are no left UIDs in the folder, and it erased local uid cache (not the message cache). The next evolution start, when new connection to the pop3 server was established, the pop3 provider got complete list of UIDs on the server, but evolution itself thought that all messages are new (because it erased the uid-cache file), thus all messages were fetched to On This Computer/Inbox again (note that they were not fetched from the server when they were available in the local pop3 message cache), but here comes duplicates from.
Comment 2 Milan Crha 2011-06-21 10:09:58 UTC
Created attachment 190352 [details] [review]
eds patch

for evolution-data-server;

Report errors to caller when there are any.
Comment 3 Milan Crha 2011-06-21 10:11:28 UTC
Created attachment 190353 [details] [review]
evo patch

for evolution;

Disconnect from the server when mail fetching is done. There is no need to keep the connection open forever.
Comment 4 Milan Crha 2011-06-21 10:33:07 UTC
Created commit 3d2a277 in eds master (3.1.3+)
Created commit b7982fc in evo master (3.1.3+)

Created commit 75c691d in eds gnome-3-0 (3.0.3+)
Created commit 10710cd in evo gnome-3-0 (3.0.3+)
Comment 5 Milan Crha 2011-06-21 10:36:00 UTC
*** Bug 650027 has been marked as a duplicate of this bug. ***
Comment 6 Matthew Barnes 2011-07-03 12:33:42 UTC
*** Bug 653891 has been marked as a duplicate of this bug. ***
Comment 7 Matthew Barnes 2011-07-03 12:35:38 UTC
*** Bug 653893 has been marked as a duplicate of this bug. ***
Comment 8 Akhil Laddha 2011-07-27 03:50:05 UTC
*** Bug 655373 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2011-08-25 10:02:16 UTC
*** Bug 653526 has been marked as a duplicate of this bug. ***
Comment 10 Conor 2011-08-26 17:12:18 UTC
Good fix!
I was suffering from the failure to retrieve emails after the first connect. My pop server appears to cache the list and not update with new emails. It NEEDS a quit and close before providing new info.
Comment 11 Paul Menzel 2011-09-05 17:41:00 UTC
*** Bug 657614 has been marked as a duplicate of this bug. ***