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
