Re: [Imap-protocol] QRESYNC & Long Command Lines

Michael M Slusarz <[email protected]>
Newsgroups gmane.mail.imap.general
Message-ID <20130302210212.Horde.q66x7X5K6O_eEUdg-T5_zg1@bigworm.curecanti.org>
Quoting Timo Sirainen <[email protected]>:

> On 18.2.2013, at 9.24, Michael M Slusarz <[email protected]> wrote:
>
>> There seems to be a conflict between the recommendations in RFC  
>> 2683 [3.2.1.5] and the QRESYNC extension to the SELECT/EXAMINE  
>> command.
>>
>> A user recently reported an issue involving an overly long UID list  
>> passed to the FETCH command.  Although not using caching  
>> themselves, while analyzing the issue I quickly realized that there  
>> could potentially be issues in passing a lengthy cached UID list to  
>> SELECT/EXAMINE.
>>
>> This particular user's mailbox contained 6-digit UIDs that were not  
>> sequential.  In this hypothetical:
>>
>> - 1500 cached messages
>> - non-sequential UIDs
>> - All UIDs are 6 digits
>>
>> ...the UID string alone would be approximately 10500 characters  
>> (1500 UIDs * 6 characters + 1499 ',' characters).  This doesn't  
>> factor in the rest of the command - or even the optional 4th  
>> sequence match parameter.  Obviously, the 1000 character limit for  
>> outgoing client IMAP commands suggested in RFC 2683 has pretty much  
>> been obsoleted.
>
> I don't think the idea was to provide all the known UIDs. The first  
> UID range is about giving FLAGS replies only those ones listed. I  
> think it's basically always 1:<last UID you know of>. Or if you  
> happen to be doing something more special where you're caching only  
> a partial state of the mailbox, you could decide to create for  
> example max. 1000 bytes of UID string and then start merging the UID  
> ranges. You'll get a few bytes of more data but it shouldn't matter  
> that much.

Our client NEVER caches the entire mailbox - only tiny view windows  
(100 messages/slice).  I have a trash mailbox with 100,000+ messages.   
I am never going to load that entire mailbox into memory/cache.  At  
best, I will open the mailbox (loading, say, 100 message in the  
slice), do a search to find what I need (loading up to another 100  
unique messages), and maybe move around the search results a bit  
(possibly loading another 100-200 messages as I do a bit of  
scrolling).  So I only have 400 messages in my cache.  I most  
certainly do not want flag changes for the entire mailbox.

But with the command size limitations I do have to make some  
compromises for long UID lists.  So I picked an arbitrary sequence-set  
length which, when exceeded, we necessarily fall-back to a <first  
known UID>:<last known UID> range.  I guess I could get fancier and  
try to optimize this more -- e.g. cut out UID "holes" over a certain  
length -- but seems like a waste of time since I've never actually  
heard of a SELECT/EXAMINE failing with our software due to a long UID  
string in the 4 years we have implemented QRESYNC.  So this is more of  
a theoretical exercise than anything else.

michael

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.