Quoting "David F. Skoll" <[EMAIL PROTECTED]>: > The principle of least surprise says ClamAV > should reject that. By the same token, the principle of least surprise > says that ClamAV should not break on previously-valid configuration files.
But it is a big surprise when the action that old line was supposed to take is no longer taken... Even worse if a new action is taken because a new configuration line wasn't added when it needed to be. So they had a valid line which said "BlockAllZips yes" and it is no longer valid. So clamav continues to run, but doesn't block zips anymore. But the admin still thinks zips are being blocked! Worse, if the command was "AllowAllZips yes" and now they are all being blocked, the admin could really be in trouble. User's may be depending on those zips, and if they are being (e.g.) thrown in the bit bucket with no warning, then users could really be in trouble because the admin couldn't be bothered to take the time to read the docs and do a proper install. Why do you think that software which is running and doing something other than is expected/wanted is better than software which refuses to run when there is a bad configuration given to it? I sure don't want my software upgrade to change my policy without my knowing it... > Regards, > > David. -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
