[imapfilter-devel] IMAPFilter 2.1

Lefteris Chatzimparmpas lefcha at hellug.gr
Wed Nov 25 22:33:01 EET 2009


On Wed, Nov 25, 2009 at 03:05:58PM -0500, William Faulk wrote:
> 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.

This is doable, but currently imapfilter's IDLE returns as soon as a new
message has been reported by the mail server, otherwise it will
basically wait forever (it just leaves and re-enters IDLE every 29
minutes in order to avoid the 30 inactivity timer that the server might
have).

So in your example it would leave IDLE in the "* 12 EXISTS" server
response, since it assumes that the user is interested in any new
message.  Of course it could be implemented some other way, were it
waits for some specified time and records every notification.

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

I guess anything could be implemented, and with a bit more work, it
might be done as to be configurable for what every user might expect
from IDLE...

>> 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.

Feel to free to send them, they are always useful and important.



More information about the Imapfilter-devel mailing list