By far the most flexible way to use any of the spam filters is to use "fetchmail" + an entry in your .forward file. The advantages I have found include:
* when I accidentally wipe out my Evo config I can still get mail and its spam filtered * if I'm reading mail remotely with MUTT my mail still gets fetched and filtered * mail gets fetched even when Evo isn't active * filtering out stuff you never want to see anyway doesn't put a load on Evo * I can manage my virtual account IDs - what you see in the "From" and "reply-to" - quite separately from where I collect my mail from. * I don't have to worry about Evo hanging on a failed PPP link to a remote IMAP box * I don't have to worry that a later revision to Evo will alter the way external commands are handled. * I can use other spam filters and malware filters and HTML strippers * I can use external filters that don't give good exit codes. * I can use it when my mail server and the machine I run Evo on are different and gain the advantage of hardware parallelism. There are probably others. These are mine, but not necessarily in that order. The last one means I can make use of an old Pentium-1 box as a mail-hub. Just smart enough to run fetchmail, postfix and IMAP. In an ideal world there would be OAF wrappers so that things like spam filters could be "plugged in" as are all the other components. Shelling out is a compromise which puts demands on Evo and may eventually turn it into a programming language rather than a MUA, and while that might appear cool, we've ll seen what it did to Outlook. UNIX built well on the "each thing does one thing and does it well" approach, and the component approach may not quite be the pipe & filters of shell programming, but it does offer the same modularization. Of course fetchmail only applies if your site doesn't have incoming SMTP. If it does, you can still use the .forward version of you spam filter of choice. This all works, works well an is very simple to set up. It offers a great deal of flexibility and means my mail is always safe, no matter what beta or daily build of Evo I run. Hence most of the complaints I see in this list simply don't apply. For me, IMAP is "slow" because it runs on a slow box, but its fast because there's nothing else runnin on that box. As people much wiser than me have commented, performance has more to do with architecture and design than with power and coding. I don't believe in making things more complicated than they have to be. /anton > On Tue, 2002-11-19 at 15:09, Ing. Vladimir M. Kerka wrote: > > > I use Spamassassin (http://www.spamassassin.org/). I run it as a daemon, > > > and have an Evolution rule that pipes the message to "/usr/bin/spamc > > > -c", and if it does not return 0, files the message as Spam. > > Please, can you explain it with more details? Where can I create > > Evolution rules and how? I am sorry, I am new in using Evolution and > > cannot handle it? > > Many thanks > > Vlsda > > I second this! Can someone explain in detail, perhaps even in steps, how > to do this? I really need this, I get more spam than real e-mail. > > > -- > Steve Schaper <[EMAIL PROTECTED]> _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution