Pete Maclean <[EMAIL PROTECTED]> writes: > I noticed a while ago that Eudora (specifically version 5.1 for > Windows) can be very slow when searching IMAP folders. I wondered if > it could be pulling down messages and searching them itself rather > than using the SEARCH command. Yesterday I decided to investigate and > discovered what is really going on. Eudora performs searches over > messages in batches of 60 messages at a time, as exemplified by this > command: > > 00015 UID SEARCH UID > >1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60 > BODY target > > This organization is intelligent and user-friendly in that it allows > Eudora to display a progress bar and a "Stop" button. (There seems to > be a bug though in that the progress bar sometimes does not appear.) > It's a small matter, but one must wonder however why Eudora does not > express this command as: > > 00015 UID SEARCH UID 1:60 BODY target > > The trouble is that Eudora sends SEARCH commands for every possible > UID from the lowest to the highest irrespective of whether or not the > UID is actually represented in the selected mailbox. Which means, in > the worst pathological case of a mailbox containing just two messages, > one with a UID of 1 and one with a UID of 4294967295 (the highest > possible), a search would take 2 weeks or more. (This is calculated > based on timings made with my own server with the client running on > the same computer.)
How would you propose to do it more efficient then? I can sympathize with the Eudora design. I am using UID SEARCH UID to find all valid UIDs on the server, but this isn't very bandwidth friendly in large mailboxes. It is also extremely slow on some servers that actually iterates (open+close) through all messages in the mailbox. An alternative would be to not use UID SEARCH at all, but instead use the SEARCH command and then do a FETCH <range-returned-by-SEARCH> (UID), but this is also not very bandwidth friendly if the matches data set is large (like when you do SEARCH UNREAD).
