Re: [Evolution] Applying filters automatically.

["Octavio Alvarez" <alvarezp alvarezp ods org>]

On Sat, 02 Feb 2008 08:51:10 -0800, Patrick O'Callaghan <poc usb ve> wrote:
> On Sat, 2008-02-02 at 15:37 +0000, Gavin Simpson wrote:
> > On Sat, 2008-02-02 at 12:40 +0000, Pete Biggs wrote:
> > > On Fri, 2008-02-01 at 17:19 -0700, Steve Karmesin wrote:
> > > > On Feb 1, 2008 5:08 PM, Pete Biggs <pete biggs org uk> wrote:
> > > >
> > > >         BUT - I do think it needs to be sorted out - I regularly
> > > >         answer this
> > > >         same question on the list and it is clearly not intuitive to
> > > >         people.  It
> > > >         may be an issue with particular IMAP clients or particular
> > > >         combinations
> > > >         of setups, but it does need to be documented.
> > > >
> > > > I just want to reiterate:  this isn't just not intuitive, it is not
> > > > nearly as useful to many users.  Why not have the mode that mimics
> > > > what t-bird does as an option?
> > > >
> > > But what *does* Thunderbird do?  A few people have said that it's  
> > better
> > > at doing it, but no one has actually enumerated the logic that it goes
> > > through.  i.e. does it only filter 'unread' or unseen to that  
> > particular
> > > client instance or does it mark a message as having been filtered?
> I think it might be helpful to enumerate the various flags that messages
> can have, so we can define exactly what we would like Evo to do. This is
> a first attempt; please correct it if necessary:
>
> Unseen: this is an IMAP server state which only the server can
> manipulate. Messages which have never been opened by any client are
> marked Unseen, otherwise they're not.
>
> New: the IMAP client marks as New those messages which *it* hasn't seen
> before. Thus the client can set/unset this flag as it likes, but the
> state is not reflected on the server so other clients will not be aware
> of it. (I may be wrong about this).
>
> Read: the IMAP client marks messages which it has shown to the user as
> being Read, but this is highly configuration and client-dependant. Most
> clients set the Read state after a configurable number of seconds. Some
> allow you to turn this off completely (Evo does, TB doesn't). In any
> case, this state *is* reflected on the server so other clients can see
> it, depending on when a server sync is done. (I may also be wrong about
> this).

The RFC 3501, section 2.3.2 says that the \Seen means that the message  
"has been read", while the \Recent flag means that the session is the  
first one to be notified about the message. There are no other relevant  
flags defined.

There is no RFC defined "new" status saved on the IMAP servers, so it  
looks like Evo assumes "New" means \Recent.

So:
Your "Unseen" is the RFC \Recent.
Your "New" is stored in the client, so each can say "This message is new  
to me".
Your "Read" is the RFC \Seen.

To deeply fix this, MUAs would need to agree on a \Filtered flag in the  
IMAP protocol, because only the \Recent flag guarantees that the message  
has not been filtered by any other MUA so far. Even if the message is not  
marked as \Seen, this doesn't mean that other MUAs have already processed  
the messages and have decided that the message should stay in the Inbox. A  
non-filtering webmail is such a case, where the user just wants to "query"  
its Inbox for urgent or important messages without actually reading the  
whole new mail.

On the short run, messages that stay on the Inbox can be interpreted as  
"maybe filtered by other MUAs without actually matching any criteria". So  
an option like "Apply filters to incoming messages on the Inbox in  
addition to the \Recent messages" whether seen or not, sounds sane to me,  
if defaulting to disabled. (Otherwise, it would break when setting the  
account on another Evolution with already defined filters).


--
Octavio.