cs at zip.com.au
Fri Oct 31 00:51:23 GMT 2014
On 29Oct2014 14:05, Romain Pelisse <belaran at gmail.com> wrote:
>Ok, to sum up - yes I need filtering on the client side. So no feature to do
>that with offline-imap (which is a good thing IMHO), so the question which
>other tool could do the work. I know a bit fetchmail, but I was not seduced,
>to say the least.
>The other tool mention earlier operating directly on the imap server does not
>really matches my need. I don't mind having the filtering done locally, and
>then propagate by offline-imap on the next sync.
>So, I guess the question is - does anyone know a good alternative to
>fetchmail ? :)
Did you see my earlier reply? I do client-side filtering.
Fetchmail itself does not filter; it only collects. The convention is usually
to deliver via procmail, which filters.
I use getmail instead of fetchmail, and deliver to a "spool" Maildir.
I don't filter with procmail, whose rule syntax I find burdensome and whose
address matching is a crude string/regexp match instead of anything involving a
sensible parse of the mail address, and which reloads and parses the ruleset
anew for every message (very expensive).
I've got my own filter program which watches a Maildir of my choice (in an
offline-imap scenario that would probably be the INBOX folder) and filters any
new messages which appear. It loads the rules once at startup and again if the
rules file ever changes (you don't need to restart the filter program). Most
rules are one line long, eg:
mutt offline-imap offlineimap-project at lists.alioth.debian.org
mutt offline-imap sender:offlineimap-project-bounces+cs=zip.com.au at lists.alioth.debian.org
These two rules file to my "mutt" folder with the X-Label "offline-imap".
The install threshold is a little high; you need a bunch of my python modules.
There are other filtering programs I believe.
Let me know if you want further details.
Cameron Simpson <cs at zip.com.au>
More information about the OfflineIMAP-project