From: Matthias A. <mat...@gm...> - 2010-02-01 20:29:14
|
Am 28.01.2010 10:04, schrieb Sunil Shetye: > I am thinking of making some improvements to imap search in fetchmail. > Please check which of these improvements are acceptable for fetchmail > 6.3 series. Dear Sunil, great! All proposed changes are acceptable, with comments below, and I definitely trust your code. All past contributions that passed through my hands were of excellent quality, so thanks a bunch! > ============================================================================================ > 1. In r3838, the "SEARCH UNSEEN" was changed to "SEARCH UNSEEN NOT > DELETED". Some imap servers do not support such a complex search > phrase. I could find only one reference for that: > > http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008897.html > > I propose that that change should be undone. > > Note that "SEARCH UNSEEN NOT DELETED" gives different result from > "SEARCH UNSEEN" only when > > - another e-mail client has marked some mails for deletion without > seeing, > - that e-mail client has not expunged the deleted mails, and > - fetchmail is keeping mails (so that fetchmail also has not expunged > the deleted mails). > > The comment in the code reads: > > /* don't count deleted messages, in case user enabled keep last time */ > > This comment is incorrect. This is because fetchmail always marks the > mail as \Seen irrespective of whether fetchmail deletes it or keeps > it. So, that mail will not show up in the next "SEARCH UNSEEN". Fixing comments is appreciated and always acceptable for supported versions. The issue reported 5 years ago refers to a regression on IMAP2 servers, and a regression fix is also always acceptable (though 6.2.X remains unsupported by me, I'm not releasing another 6.2.X - the fix will go into 6.3.X then). In the implementation of the fix, could you switch by protocol version to use the "... NOT DELETED" form for newer servers (IMAP4r1, not sure if IMAP4 also supports it), and the older "SEARCH UNSEEN" only in IMAP2? That would give us the best of both approaches -- or perhaps we could just fall back to SEARCH UNSEEN if SEARCH UNSEEN NOT DELETED fails? > ============================================================================================ > 2. Some servers do not support "SEARCH" at all. Here are some > references for that: > > http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008675.html > http://lists.ccil.org/pipermail/fetchmail-friends/2005-January/009351.html > > In this case, as a fallback, fetchmail should use something like: > > FETCH 1:1000 FLAGS > > and process all mails without \Seen as unseen. Much appreciated. OK since it extends fetchmail's audience. > ============================================================================================ > 3. The reply to "SEARCH UNSEEN" overflows fetchmail buffer when there > are more than 1860 unseen mails. fetchmail should do a range search: > > SEARCH 1:1000 UNSEEN > SEARCH 1001:2000 UNSEEN > ... Desirable bug fix. Hope that helps. Looking forward to your patches! Best regards Matthias |