From: Matthias A. <mat...@gm...> - 2016-12-18 12:51:33
|
Am 17.12.2016 um 04:48 schrieb Matthias Andree: > Greetings, > > Rick has sent me verbose traces off-list, and they show that fetchmail > 6.3.26 talks "LAST" with the server, but not UIDL, so I presume any > .fetchids are from other accounts. hmm... this might not be the case. There appears to be a corner case where the results from "LAST" are disregarded when there are saved UIDs for the account that I can reproduce. So if your an that now runs off LAST but has UIDs saved (for instance, because the LAST command ever failed and a subequent "UIDL" succeeded, that might explain the behaviour). I am not yet sure how to best tackle this in since I need to read more code to get the complte overview. The obvious workaround in my writing new code is to avoid the LAST command if there is at least one UID saved, to match the logic that the pop3_is_old() function uses to establish whether it has previously downloaded a particular message offered by the server. Rick, do you happen to have an older .fetchids file from before you switched to --uidl, perhaps in a backup? If so, I'd like to have it (off-list). Has there been at least one line in the .fetchids file related to the Yahoo account that was now re-downloading mail? At any rate, in your particular case, Rick, --uidl (or uidl in the fetchmailrc file) is the safe fix for good. The CPU time use of UIDL has always been a bit high up to and including the latest 6.3.X release, 6.4.0-beta2 improves on that and is available from <https://sourceforge.net/projects/fetchmail/files/branch_6.4/>. |