I can appreciate both sides. However, the general opinion I have heard seems to echo what I would expect, and that is that the product let me know if there is an error. Whether that be in a log file, an GUI display, or an email message are just ways of implementing that solution.
Yes many operate with "out of the box" configurations. Should these not get an indication of an error just because they don't know how to fix it? For the sake of the low(non-existing) budget install and implementation, the software should provide "Some" sort of reporting that an error occurred. I agree that "Silent" failure is a general failure since most will not know that a failure has/is happening. I am not sure that there is a "Best" way, but the option(s) to setup either way or ways should be implemented and configurable without the need to get another software product (that may need to be purchased) to support this product. Just my opinion, John. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Peterson Sent: Monday, October 06, 2008 11:05 AM To: ClamAV users ML Subject: Re: [Clamav-users] [0.0] Re: Handling of unknown configuration lines (was Re: Stop it!) Charles Gregory wrote: > On Sat, 4 Oct 2008, Eric Rostetter wrote: >>> The principle of least surprise says.... >> But it is a big surprise when the action that old line was supposed to take >> is no longer taken... > > But NOT as big a surprise as NO FILTERING AT ALL. That's the sticking > point here. Unless we are all expected to tempfail mail when ClamAV > aborts, and then deal with irate users who have been waiting all weekend > to get their critical mail, then ClamAV should NOT abort unless it very > literally cannot figure out what to do. And honestly, is it really that > hard to have it interpret the *old* config items for a release or two? ClamAV can fail for a number of reasons having nothing to do with configuration changes. What is your default policy for mail processing in the event of a ClamAV failure (Tempfail or at-risk delivery)? What have you put in place for notification and recovery in the event of a ClamAV failure? If this is done right you should have no problems recovering from config file changes. dp _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
