Fons van der Beek wrote:
> I found "imapfilter" http://freshmeat.net/projects/imapfilter/
[...]
> A tool worth reviewing, and realy realy a lot easier as procmail.
Looks like a useful tool. It might come in handy once we start testing
and optimizing dbmail's internal sorting and filtering capabilities
since it combines features of both, and more.
It makes me wonder how dbmail would stand up under a filtering load of
100 clients simultaneously sorting through a subset of maybe 10000
accounts with each 10000 messages spread over 100 folders, each with a
couple of hundred of incoming messages per day. Crash-n-burn,
denial-of-service, or smooth-sailing...
The unique aspect of imapfilter is it's disconnection from the delivery
chains, since both procmail and dbmail's sieve implementation are
delivery bound.
--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl
> I found "imapfilter" http://freshmeat.net/projects/imapfilter/
[...]
> A tool worth reviewing, and realy realy a lot easier as procmail.
Looks like a useful tool. It might come in handy once we start testing
and optimizing dbmail's internal sorting and filtering capabilities
since it combines features of both, and more.
It makes me wonder how dbmail would stand up under a filtering load of
100 clients simultaneously sorting through a subset of maybe 10000
accounts with each 10000 messages spread over 100 folders, each with a
couple of hundred of incoming messages per day. Crash-n-burn,
denial-of-service, or smooth-sailing...
The unique aspect of imapfilter is it's disconnection from the delivery
chains, since both procmail and dbmail's sieve implementation are
delivery bound.
--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl