71 lines
3.3 KiB
Plaintext
71 lines
3.3 KiB
Plaintext
MBOX-Line: From slusarz at curecanti.org Sat Mar 2 20:02:12 2013
|
|
To: imap-protocol@u.washington.edu
|
|
From: Michael M Slusarz <slusarz@curecanti.org>
|
|
Date: Fri Jun 8 12:34:50 2018
|
|
Subject: [Imap-protocol] QRESYNC & Long Command Lines
|
|
In-Reply-To: <8100D6D4-66F1-40C4-A9B2-6A03F8CCC175@iki.fi>
|
|
References: <20130218002432.Horde.oHbZYiST0vPMI_hKIDlLvg1@bigworm.curecanti.org>
|
|
<8100D6D4-66F1-40C4-A9B2-6A03F8CCC175@iki.fi>
|
|
Message-ID: <20130302210212.Horde.q66x7X5K6O_eEUdg-T5_zg1@bigworm.curecanti.org>
|
|
|
|
Quoting Timo Sirainen <tss@iki.fi>:
|
|
|
|
> On 18.2.2013, at 9.24, Michael M Slusarz <slusarz@curecanti.org> 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
|
|
|
|
|