Re: [Evolution-hackers] The Junk problem and IMAP

[Ron Smits <ron ronsmits com>]

Solutions that I would think of for this:

      * during account initialization, if imap is chosen, query the
        server and react according to known servers. (BTW the openwave
        imap server cannot do custom flags either I supported them for 3
        years)
      * Have the option to only filter mail that enters the INBOX. This
        is already done for normal filters so why not here.
      * Server side filtering is not perfect, just as this client side
        filtering is not perfect. I do serverside and still spam gets
        thru. So this second layer of defence is great

just my two eurocents

Ron

On Wed, 2004-02-25 at 20:01 +0800, Not Zed wrote:

> Ok, there's a lot of problems with this:
> 
>  - first, its just F***n slow, but there's nothing that can be done
> about that
>  - second, it filters all folders.  We rely on the server to tell us
> when we have new mail ('Recent'), but we get Recent whenever we copy
> from local to imap, between imap servers, and possibly between folders
> on the same imap server (the imap spec doesn't specify this).  i.e. as
> soon as you move messages around, it re-filters.  Yucko.
> 
> So I tried:
>  - adding a couple of new flags, Junk and NotJunk
> 
>    So that once we've done junk processing, we dont need to do it again
>    We can set the flags on most servers (but not all) when we append
> messages, and the server should keep the flags when we copy between
> servers.
> 
>   Except, at least for uwimapd, it wont let you set custom flags during
> an APPEND, even when it is part of the PERMANENTFLAGS response.  Fun eh.
> 
> The other alternative
>  - use UIDPLUS to find out what the newly appended UID is, and STORE the
> flags manually
> 
>   Drawback is even fewer servers support UIDPLUS than custom flags, so
> its kind of pointless.
> 
> The only other possibility
>  - assume the server will copy the flags with COPY (probably not
> entirely safe to assume)
>  - when we do APPEND, set a specific one-off header in the message to
> say its been junk filtered/the junk filter result.
> 
> But, the later could lead to inconsistencies if we later change the junk
> state, and it just doesn't seem very clean anyway.
> 
> I propose we ONLY do junk processing on INBOX, as we do with other
> filters.  At least that gets around most of the issues without more
> nasty server-specific (or worse) hacks.  Or well, we do it in a totally
> different way (but we'll still have the issue of re-junk testing
> everything anyway, so it wont fix anything).
> 
> If people are already doing server-side filtering, they really should be
> doing server-side junk filtering too ... (well, i did suggest we had
> per-server junk settings so we could deal with this somehow in the ui,
> but ...).
> 
>  Z
> 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers
-- 
Ron Smits <ron ronsmits com>