[sylpheed:30336] Re: junk filtering not automatic

[Seth Kurtzberg]

On Tue, 31 Oct 2006 16:50:38 +0100
Stefaan A Eeckels <Stefaan.Eeckels at ecc.lu> wrote:

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

Absolutely, it's horribly inefficient.  However, the reality of it is that I am either:

1.  On my own network and the inefficiency isn't noticable because the server and client have a high speed connection or...

2.  On someone else's network with god knows what restrictions, and it's inefficient but they have every sensible way to do it efficiently blocked, and POP (which I can't use anyway, since I'm often forced to use the client's machines when connected to the client's network) wouldn't be much better.

> 
> Just my 2¢ :-)
> 
> Take care,
> 
> -- 
> Stefaan
> -- 
> As complexity rises, precise statements lose meaning,
> and meaningful statements lose precision. -- Lotfi Zadeh 
>