[sylpheed:30327] Re: junk filtering not automatic

[Seth Kurtzberg]

On Tue, 31 Oct 2006 15:13:27 +0100
Stefaan A Eeckels <Stefaan.Eeckels at ecc.lu> wrote:

> Please do not send copies to my address - I read the list, and it is
> confusing (to me at least :).
> 
> On Tue, 31 Oct 2006 08:41:47 -0500
> Seth Kurtzberg <seth at cql.com> wrote:
> 
> > On Tue, 31 Oct 2006 13:39:01 +0100
> > Stefaan A Eeckels <Stefaan.Eeckels at ecc.lu> wrote:
> > 
> > > On Tue, 31 Oct 2006 13:16:07 +0100
> > > Colin Leroy <colin at colino.net> wrote:
> > > 
> > > > Probably about the same order of market share as Linux on the
> > > > desktop, in other words.
> > > 
> > > But surely not all Linux users use IMAP :) - when used simply to
> > > download messages it has no advantages over POP3. It's only when you
> > > want to leave (most of) your mail on the server that IMAP starts to
> > > make sense. And then it makes sense to do the SPAM filtering and
> > > virus checking _before_ the messages are placed on the IMAP server. 
> > 
> > Let me answer the first misstatement (on the first line) first, and
> > then get to the substantive issue of IMAP.
> > 
> > He said absolutely _nothing_ about what fraction of linux users do,
> > or do not, use IMAP.
> 
> Of course not - that's why there was a smiley.
> 
> > His point was that claiming IMAP is insignificant is similar to
> > claiming Linux email clients are insignificant, since the _magnitude_
> > of the user base is similar.
> 
> I know. I also never claimed that the IMAP user base is insignificant -
> it's just not big enough to register on Hiroyuki's radar, and Colin's
> figures substantiate that much better than my assumptions.
> 
> > This has NOTHING whatsoever to do with whether linux users choose
> > IMAP.
> 
> Where did I say that? It was a quip, for crying out loud - and it even
> had a smiley for the humor-challenged among us :-)
> 
> > It's absolutely FALSE to say that IMAP has no advantages.  In fact,
> > unless you receive email with ONLY one machine, ever, IMAP is
> > essential.
> 
> I did not say that - I said that _if_ you use IMAP only to download
> your mails to your machine, _then_ it had no advantages over POP3.

Who ever suggested doing that?

>  
> > Incidentally, sure it makes sense to do SPAM filtering on the server
> > side for IMAP.  It equally makes sens to do SPAM filtering on the
> > server side for POP.  Server side filtering is always preferable.
> 
> Which is why I do just that.
> 
> > Many people use a mail server that they do not control, and
> > implementing anything at all on the server side is not an option.
> > That's why spam filtering on the client side is needed in the first
> > instance.
> 
> Yes - but if you're using a server that you do not control, and you
> want to access it via IMAP (which has as purpose to leave the mail on
> the server), server-side filtering is not optional.

I don't believe that's true.  Certainly there are advantages to doing it on the server, which we've agreed apply to POP and IMAP.  The case for doing it on the server with IMAP is stronger.  However it is quite possible to do an acceptable job of spam filtering entirely on the client side.

In fact, client side filtering of junk email with IMAP is working perfectly.  The problem with it is related to when the filtering is triggered.

Junk mail filtering initiated from a menu (e.g. Tools/Filter junk mail in folder) is working.  The client tells the IMAP server to move the message to the designated junk folder.  It then resynchronizes with the IMAP store and, magic, spam is filtered.

Only a few small changes are necessary.  With IMAP mails are (at least potentially) delivered to folders other than the inbox folder.  Sylpheed scans the IMAP store and determines whether there are new messages in each folder.  It is straightforward to create a data structure that records this information.  Then, for each IMAP folder with new mail, use the same functionality used by the "Filter junk mail in selected messages" command on the Tools menu.

Of course it's not precisely the same; the messages aren't selected in the GUI sense, certainly, and other details will come up.

Such a strategy is perfectly workable and can be implemented on the client side.

> 
> Take care,
> 
> -- 
> Stefaan
> -- 
> As complexity rises, precise statements lose meaning,
> and meaningful statements lose precision. -- Lotfi Zadeh 
>