It can act as a proxy for POP3 (this would be filtering on the client side), but also supports IMAP: it regularly accesses the IMAP server and checks the relevant folders (e.g. INBOX) for new mail, classifies it and moves it to the folder configured for the determined bucket.
The user can re-classify mails by moving them into another IMAP folder associated with a bucket.
E.g., when a mail gets classified as “personal”, but is really “work”, you can move it from the folder associated with the “personal” bucket to the one for “work” and POPFile will re-classify it.

This works really great!

POPFile for IMAP should run as a daemon on the IMAP server itself, if possible (for bandwidth/performance reasons), but it’s possible to have it on a remote system, e.g. when using it with GMail’s IMAP interface.

See http://getpopfile.org/

Its Delivery -> sorting -> reading kind of workflow, where the first step is blackbox.

From the perspective of the IMAP server, there is no meaningful difference between manual and automated mail filing as performed by the client, so MUA changes are inherently safe, and will be visible to alternate MUAs using the same IMAP store. On the other hand, these changes must be submitted and confirmed over the network, so such an approach is inherently slow, despite other advantages, and may cause user confusion if the MUA performing changes is temporarily offline or multiple MUAs attempt to apply the same automated filters.

From the perspective of the IMAP client, there is no meaningful difference in updates made by the MDA as compared to another MUA pointing at the same store, so MDA changes are inherently safe, and will be visible to all MUAs using the same IMAP store. On the other hand, these changes are typically somewhat invisible to the user, and so strong automation can be frustrating, for instance when the user moves a message manually and finds that it has been put back by the server (although any case of two competing IMAP clients can cause this).

In an ideal world, there are three types of interesting IMAP client. The MDA (which may use something other than IMAP to update the store), which imposes initial filtering rules on received mail, and drops the mail as “new” in the corresponding folders. The MUA which allows the user to move mail however they want (although this should be manual or once-off scripted) to match their preferences. The MPA (Mail Processing Agent), which allows the user to impose automated rules for mail filtering (e.g. messages over three months old migration from the foo-list to the foo-list-archive folder), and acts as an IMAP client.

Note that a given tool may act in several of these roles. A “full-featured” client might have a means by which it can pull messages by various means (POP, RSS, etc.), and perform an MDA role to insert these into the IMAP store; a means by which the user can configure deep automation as to how their mail should be presented, acting as an MPA; and a means by which the user can read and review mail. Leaving such a client active somewhere should allow the user to benefit from the IMAP store from any MUA.

On the other hand, such a tool carries a high overhead, an other users may wish to handle initial population of the IMAP store with a traditional MDA, perhaps in combination with a traditional remote sync tool (e.g. fetchmail). Automation would be handled by a low-footprint client with highly-reliable power / network-access / etc. User interaction with mail would be with a variety of IMAP clients as the user may find convenient (which may include the “full-featured” client described above, with MDA and MPA functions inactive.

A common use case that kills me, is that I have a couple of Evolution delivery rules on an IMAP account, but when I access that account through webmail, all hell breaks loose and I have to parse a couple hundred messages by hand… Not pretty (damned procmail/courier-imap bugs that break some rules ).

Think about it — your mail server is by design a centralized application, as you have all your mails on one place. Thanks to that, you can access your mails form anywhere, with any compliant client. It makes perfect sense to attach rules governing what happens with incoming messages to the same data store.

Of course, if you use some nice protocol for managing your filtering rules (like Sieve/managesieve), any compliant client will let you modify your filtering moods.

Anyway, if you ever access your mails from more than one place (most people do), you want filtering rules stored on your mail server.

As it’s kind of… nonstandardized how this is done I can live with the way thunderbird does this (download Mailheader, filter, move mail if necessary).

With KMail this isn’t really possible, as KMail will, as soon as there are filters set for IMAP-Accounts: Download new mail, delete it from the server, check for filters, reupload the mail if it doesn’t need to be filtered. This behaviour makes KMail unusable with filters, if you want to use IMAP-filters.

The IMHO best way would be filters set by MUA on the server, which can be read and altered by another MUA. So it doesn’t matter where I am, i always have the same filters without needing SSH/SCP to alter procmailrc-files or whatever.