GNOME.org
 

Re: [Evolution] Applying filters automatically.

On Sun, 2008-02-03 at 13:59 -0800, Octavio Alvarez wrote:

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.


Correct.


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.


Yes, I was working from memory. Note that my description didn't mean to
imply that New was an IMAP flag ("... the state is not reflected on the
server ...), rather that it's a state maintained by the MUA.


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.


Even a \Filtered flag could cause trouble. One of the problems with
client-side filtering is keeping the various MUA filters consistent with
each other. Most of them, including Evo, don't even allow you to
synchronize your filters with other clients.

Server-side filtering is the way to go, but of course that's not going
to happen anytime soon. In the meantime, Evo should at least support
Sieve, which after a hiatus of several years seems to be making a
comeback.


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


I would vote for that, even if only to reduce the number of times people
ask this question :-)

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