Sam Varshavchik wrote: > Robert J. Cups writes: > >> Basically, 4 and 5 should return data for at least one message (the >> highest UID message). Instead, they return data for no messages. >> >> RFC 3501, page 60 (6.4.8 UID Command): > > > That paragraph isn't in RFC 2060. Mark Crispin added it after he had > a major cow when Courier-IMAP followed the RFC 2060 behavior to the > letter, which he apparently privately thought it was a mistake, but > wasn't willing to admit it. > >> Courier-IMAP does not seem to treat the range as being independent of >> the order of the range endpoints, nor does it include the UID of the >> last message in the mailbox. > > > Correct. This is mostly academical hairsplitting and bellyaching, and > nobody else in the world, besides Crispin, gives a fig. > > Actually, it's not academic hairsplitting. I'm trying to calculate the next valid UID, so I issued a UID FETCH 2147483647:* (UID), which should give me the highest UID currently assigned. Instead, I get OK Completed, and I waste a good deal of time trying to figure out what's breaking where.
I realize that if I had X EXISTS cached somewhere I could do a fetch with that, but I didn't have convenient access to that value and capturing it would require additional processing, the overhead of which I wished to avoid. Obviously I've touched on a political subject here, which was certainly not my intent. I realize that that paragraph does not exist in 2060, but it is in 3501, which is listed as obsoleting 2060, so I would hope that you could understand that someone who is external to the debate could think that RFC3501 should be followed, rather than the obsoleted 2060. I am aware that I could request STATUS <mailboxname> (UIDNEXT), but this is not guaranteed to be fast. Courier also does not seem to send an untagged UIDNEXT on SELECT either. If you have any suggestions on a better way to get the highest (or next highest) UID that is reasonably efficient on Courier as well as the other major IMAP servers, I would be all ears. I'm not trying to split hairs, I'm honestly trying to accomplish something. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
