Re: [Imap-protocol] QRESYNC & Long Command Lines
Timo Sirainen <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[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. For the known sequence ranges the idea is to provide some kind of small snapshots around the mailbox, again not everything. _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol