Re: [Evolution] Use filters on emails through IMAP

[Pascal DRABIK <Pascal Drabik cec eu int>]

   Jeff,

> > tests to try to understand what is happening when the Evolution 
> > client is checking for emails on the Exchange server (once every
> > 5 minutes in my own settings). I noticed the following while the
> > client is initiating the checking.
> >
> >    The client is sending a "LSUB" message.
>
> I think you mean the STATUS command... LSUB doesn't give any info about
> #messages, it just lists the names of the subscribed folders.

   Actually the STATUS command is just used once, at the very
initial phase (authentication?). Then the client is checking every
5 minutes the server. 2 situation can happen.

   1- New emails are recognised as such. Then sequence exchanged between
Evolution and the server are like (note the NOOP, FETCH commands):

|->  sending : A00017 NOOP
|->  received: * 22 EXISTS
|->  received: * 1 RECENT
|->  received: A00017 OK NOOP completed.
|->  sending : A00018 UID FETCH 3931:* (FLAGS RFC822.SIZE INTERNALDATE
|->  BODY.PEEK[HEADER])
|->  received: * 22 FETCH (FLAGS (\Recent) RFC822.SIZE 1145 INTERNALDATE
"24-Jun-2004 22:10:11 +0200" BODY[HEADER] {732}
|->  received:  UID 3931)
|->  received: A00018 OK FETCH completed.
|->  sending : A00019 UID FETCH 3931 BODY.PEEK[]
|->  received: * 22 FETCH (BODY[] {1145}
|->  received:  UID 3931)
|->  received: A00019 OK FETCH completed.
|->  sending : A00020 LSUB "" {1+}
|->  %
|->  received: * LSUB () "/" INBOX
|->  received: A00020 OK LSUB completed.
|->  sending : A00021 LSUB "" {7+}
|->  INBOX/%
|->  received: A00021 OK LSUB completed.
|->  sending : A00022 SELECT INBOX
|->  received: * 22 EXISTS
|->  received: * 0 RECENT
|->  received: * FLAGS (\Seen \Answered \Flagged \Deleted \Draft)
|->  received: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted
\Draft)]
|->  received: * OK [UNSEEN 4] Is the first unseen message
|->  received: * OK [UIDVALIDITY 555] UIDVALIDITY value.
|->  received: A00022 OK [READ-WRITE] SELECT completed.
|->  sending : A00023 FETCH 22 UID
|->  received: * 22 FETCH (UID 3931)
|->  received: A00023 OK FETCH completed.

   2- New emails are not recognised as such. Then sequence 
exchanged between Evolution and the server are like (note
the LSUB, FETCH commands):

|-> sending : A00009 LSUB "" {1+}
|-> %
|-> received: * 21 EXISTS
|-> received: * 2 RECENT
|-> received: * LSUB () "/" INBOX
|-> received: A00009 OK LSUB completed.
|-> sending : A00010 UID FETCH 3928:* (FLAGS RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADER])
|-> received: * 19 FETCH (FLAGS () RFC822.SIZE 1668 INTERNALDATE
"24-Jun-2004 21:39:59 +0200" BODY[HEADER] {780}
|-> received:  UID 3927)
|-> received: A00010 OK FETCH completed.
|-> sending : A00011 SELECT INBOX
|-> received: * 21 EXISTS
|-> received: * 0 RECENT
|-> received: * FLAGS (\Seen \Answered \Flagged \Deleted \Draft)
|-> received: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted
\Draft)]
|-> received: * OK [UNSEEN 4] Is the first unseen message
|-> received: * OK [UIDVALIDITY 555] UIDVALIDITY value.
|-> received: A00011 OK [READ-WRITE] SELECT completed.
|-> sending : A00012 FETCH 19 UID
|-> received: * 19 FETCH (UID 3927)
|-> received: A00012 OK FETCH completed.
|-> sending : A00013 UID FETCH 3928:* (FLAGS RFC822.SIZE INTERNALDATE
|-> BODY.PEEK[HEADER])
|-> received: * 20 FETCH (FLAGS () RFC822.SIZE 4765 INTERNALDATE
"24-Jun-2004 22:05:35 +0200" BODY[HEADER] {3031}
|-> received:  UID 3929)
|-> received: * 21 FETCH (FLAGS () RFC822.SIZE 1145 INTERNALDATE
"24-Jun-2004 22:06:05 +0200" BODY[HEADER] {732}
|-> received:  UID 3930)
|-> received: A00013 OK FETCH completed.
|-> sending : A00014 LSUB "" {7+}
|-> INBOX/%
|-> received: A00014 OK LSUB completed.
|-> sending : A00015 SELECT INBOX
|-> received: * 21 EXISTS
|-> received: * 0 RECENT
|-> received: * FLAGS (\Seen \Answered \Flagged \Deleted \Draft)
|-> received: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted
\Draft)]
|-> received: * OK [UNSEEN 4] Is the first unseen message
|-> received: * OK [UIDVALIDITY 555] UIDVALIDITY value.
|-> received: A00015 OK [READ-WRITE] SELECT completed.
|-> sending : A00016 FETCH 21 UID
|-> received: * 21 FETCH (UID 3930)
|-> received: A00016 OK FETCH completed.

   As I said, in one case, the "checking" session starts with
the LSUB commands, and in the other it starts with a NOOP
command. There is a strong correlation between the LSUB case
and the fact that new emails are not recognised and NOOP case
and the fact that new emails are recognised .

   I was expecting to see the same command sequence at least
at the beginning.

> >    From what I understood from the protocol (RFC3501), I would not 
> > expect a checking session started by a "LSUB" command ( I must
> > admit that I do not fully understand its use), but instead
> > by a "NOOP" command.
>
> LSUB is not used to check new mail, it's used to probe which mailboxes
> exist. That information is then used to probe (using the STATUS command)
> for unread mail counts (not new messages).

   This is what I understood, but according to the log file,
LSUB is used sometimes at the beginning of "checking" sequence.

   Any idea with this further clarification?

   Thanks in advance,

   Regards,

Pascal.