note
shockme
Excellent response. To address some of your points:
<UL>
<LI>When I downloaded Mail::Audit approximately 2 weeks ago, v1.11 was the only downloadable version. I did not know v2.0 existed, nor was I aware of the added "inbox corruption" feature. Searching CPAN now shows only v2.0 for download, so props for the heads-up.
<LI>The Razor::Clients package really needs to be on CPAN. The documentation is extremely sparse on this. Again, props for [http://razor.sourceforge.net/index.html|the URL] to get this material. I just installed it and it seems to be working well.
<LI>My original draft mentioned that, once you <tt>$item->accept()</tt>, all processing stops. However, on proof-reading and fact-checking, I <I>could not</I> locate this fact in the documentation. (Of course, <B>now that it's too late</B>, it's screaming itself from the page...) But, yes, this makes for very efficient processing, because once you've filed the email, you can forget about it.
<LI>I agree that <I>all</I> email should be filed and <I>nothing</I> dropped. Email filtering will never be "perfect" because the patterns are always in flux. Sooner or later, something would be lost in the void. That's why I emphasized the default of (in my case) the Bulk folder. If nothing else fits, it defaults to ~/mail/Bulk.
<LI>[http://search.cpan.org/search?mode=module&query=Spam%3A%3AAssassin|Spam::Assassin], implications aside, <I>is not</I> a virus scanner. It's a spam filter. While it may catch some viri, I think it foolhardy to rely upon it for anything other than filtering spam.
<LI>Again, the documentation is sparse concerning what should be submitted to the Vipul database. I don't know whether they have filters to "un-filter" the SPAM messages. Hopefully someone else will have a more definitive word on this. Until then, I think your suggestion is right way to go.
</UL>
<P>
Thanks for the great info, [jcwren].
<P>
<I>If things get any worse, I'll have to ask you to stop helping me.</I>
133023
133027