Re: [Evolution] Applying filters automatically.

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

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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]