[imapfilter-devel] IMAPFilter 2.1
Lefteris Chatzimparmpas
lefcha at hellug.gr
Thu Nov 26 20:31:04 EET 2009
On Wed, Nov 25, 2009 at 04:59:00PM -0500, William Faulk wrote:
> Still, my point is that the \Recent and \Seen flags, and, therefore, the
> is_recent() and is_seen() functions, are not guaranteed to indicate
> which messages arrived in this session.
I had a better look on the \Recent flag and EXISTS, RECENT, EXPUNGE,
etc. untagged responses, and so on.
It seems to me that relying only on untagged responses is not better
that relying on the \Recent flag, and at the end I will suggest a more
reliable way to only filter messages you haven't filtered before.
First, you will get untagged responses about the mailbox that you have
opened. Then, assuming you have selected the box you are interested in,
in order to actually receive the untagged responses you have to send
some request:
In the selected state, the server checks the mailbox for new messages
as part of command execution. Normally, this is part of the execution
of every command; hence, a NOOP command suffices to check for new
messages.
So you have for example to send once in a while at least a NOOP (does
nothing), to get those untagged responses. Then, as stated in the RFC:
If new messages are found, the server sends untagged EXISTS and RECENT
responses reflecting the new size of the mailbox.
Thus all sessions must get EXISTS and RECENT untagged responses. But in
my experimentation only the first session to sent a command (eg. a NOOP)
got the RECENT untagged response, although all of the sessions got the
EXISTS response. Then it is stated:
Server implementations that offer multiple simultaneous access to the
same mailbox SHOULD also send appropriate unilateral untagged FETCH
and EXPUNGE responses if another agent changes the state of any
message flags or expunges any messages.
This means that you are not guaranteed to get any EXPUNGE responses at
all.
This all translates to that imapfilter running with other clients
together will not always benefit from recording all these untagged
responses, and worse is that it might be error prone to trust them
blindly. In the case, where imapfilter runs alone (eg, before you run
your GUI client), then it will work fine by just relying on the \Recent
flag.
What I recommended to people in the past, when they had problems with
the \Recent flag (or even \Seen), is to use some other flag that you are
sure nobody will mess with. For example \Flagged could be set after
imapfilter filtered some mail, and then you know you should filter the
messages without this flag, since no client will change this. Also,
since most servers implement custom keywords you could even set your own
flag, eg. "Filtered" or something.
More information about the Imapfilter-devel
mailing list