[sylpheed:30328] Re: junk filtering not automatic

[Stefaan A Eeckels]

On Tue, 31 Oct 2006 09:55:22 -0500
Seth Kurtzberg <seth at cql.com> wrote:

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

I believe you. 

IMAP servers are designed to hold mail, and to allow it to be managed
(moved to another folder, etc).  If one only has a single, fixed (ie
not portable used in different locations) system on which mail is read,
the advantages of keeping mail on the server are negligible - like
better backups or more disk space. In effect, having the mail folders
on the workstation has the advantage (given a sufficiently advanced OS)
of making the messages available for processing by other tools; the MH
format is particularly well suited for this purpose. We can -I hope-
agree that in this situation IMAP and POP are equivalent, and only used
to download all the mail to the workstation. 

Central virus scanning and SPAM filtering remains a good thing because
the safety of the individual workstations does not depend on the
quality and up-to-dateness of tools on each workstation. Obviously, in
the case of a single workstation talking to the server it's 6 of one
kind, and half a dozen of the other, and because you need security on
the workstation anyway, the tools on the server are not indispensible.

If on the other hand one needs to access mail from different systems
that are geographically distant, and/or linked to the office/home LAN
through slow connections, then IMAP has lots of advantages. At the same
time, the importance of central security systems increases, because one
wants to avoid having to download messages to the client (downloading a
5MB message over a sluggish link to have it filtered on the client who
moves it into a SPAM folder on the server is a lot less efficient than
having the mail server place suspicious mails in that SPAM folder
directly). In the case of viruses it's even more important, because one
cannot rely that the local protection will always be optimal (imagine
you're in a hotel and you cannot contact the anti-virus update
service). 

Obviously, if you _need_ the access from different locations and/or
different systems, then (excluding Exchange or other proprietary
schemes) you have only two options - IMAP and Webmail. But wait - IMAP
uses its own set of ports, and hence it's more likely to be blocked
than HTTP/HTTPS if you're on the road.

As far as I can see, IMAP is useful in the following circumstances:

1. You're working in a LAN on different machines that don't have X
(like Windows boxes). Here you need central security services unless you
are absolutely sure all the machines are up-to-date security wise.
2. You insist on using a mail client instead of Webmail while on the
road. Here you need central security services because you cannot be sure
that your portable is always well-protected (access to updates etc).

In all other cases IMAP is either used for the wrong reasons (the
unwarranted belief that it's better than POP for bulk downloading all
mails to one's computer), or because one has no options (in which case
one can still decide to download all emails to the workstation and be
done with the bozos managing the computing infrastructure).

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

But that means that you need to download all messages in their
entirety so that you can pass them off to bogofilter. That's quite
different from merely checking the store for new messages (where you'd
only download a message if you'd want to read it). Downloading a
message to decide you don't really want to download it is more than a
bit silly. With this scheme _all_ your messages will have been
downloaded at least once to your system. So you must really, really
need that access from multiple locations/systems to make it worthwhile.

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

Indeed - it's just not very efficient.

Just my 2¢ :-)

Take care,

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