[imapfilter-devel] IMAPFilter 2.1

[William Faulk]

On 11/25/2009 02:17 PM, Lefteris Chatzimparmpas wrote:
>
> I think in the IMAP RFC it is mentioned that it is not guaranteed that
> UIDs of new messages will be a contiguous range

Right.  You can't rely on UIDs to be anything.  But message IDs are 
always contiguous, even after messages in the midst of a range are 
deleted.  To be clear, by "message ID", I mean what's defined in RFC3501 
as "message sequence number" -- the first argument to FETCH, COPY, and 
STORE.

> If some searching is needed to make sure or get the UIDs of the new
> messages (behind the user's back), then IDLE won't be much more useful
> than what it is today.

Imagine this IMAP conversation:

C: A001 SELECT INBOX
S: * 11 EXISTS
S: ...
S: A001 OK [READ-WRITE] SELECT complete
C: A002 IDLE
S: + IDLE accepted
S: * 12 EXISTS
S: * 13 EXISTS
S: * 14 EXISTS
S: * 2 EXPUNGE
S: * 12 EXPUNGE
C: DONE
S: A002 OK IDLE complete

What we know from this is that when we SELECTed the INBOX, there were 
messages 1 through 11.  After we IDLEd, we received three new messages, 
12, 13, and 14.  Then message 2 was deleted (which moved messages 3 
through 14 to messages 2 through 13), then message 12 was deleted (which 
moved message 13 to message 12).  So we now know that there are two new 
messages, 11 and 12.  We can then do this:

C: A003 FETCH 11:12 UID
S: * 11 FETCH (UID 919283)
S: * 12 FETCH (UID 720472)
S: A003 OK FETCH complete

and now we have a handle on the logically recent messages, even if the 
server doesn't tag them as \Recent for us.

I honestly haven't looked at imapfilter's code enough to know if that 
sequence makes sense in its workflow paradigm.

> But I believe even as it is now IDLE
> is quite useful to have anyway.

Agreed.  Once I play with it some more, though, I may have some other 
comments.

-Bitt