Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
Ian Eiloart wrote: > Oh, but wait. What's going on here? You upgrade ClamAV and your > configuration changes? That shouldn't happen at all. Are you using an > installer tool that overwrites your deployed configuration? Surely not! If the defaults change, then the effective configuration can change even though the config *file* stays the same. -- Kelson Vibber SpeedGate Communications ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
shuttlebox wrote: >> We were not impressed with the decision taken by the Clam developers. >> As a general principle of least surprise, new and experimental >> behaviour should need to be enabled explicitly and not "snuck in" on >> unsuspecting users. > Aren't these features only ever enabled if compiled with --experimental? No. PhishingScanURLs is compiled in by default. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Thu, Nov 15, 2007 at 01:28:39PM +0100, shuttlebox wrote: > On Nov 15, 2007 1:22 PM, David F. Skoll <[EMAIL PROTECTED]> wrote: > > > Oh, but wait. What's going on here? You upgrade ClamAV and your > > > configuration changes? That shouldn't happen at all. Are you using an > > > installer tool that overwrites your deployed configuration? Surely not! > > > > When we upgraded ClamAV, our configuration file stayed the same, BUT > > we were treated to slow and unwanted new behaviour that caused a flurry > > of support calls and significant amounts of our support time to figure > > out what the h*ll was happening. > > > Aren't these features only ever enabled if compiled with --experimental? They were at first, but after the upgrade from 0.90.x to 0.91 the "experimental" features suddenly became the default. And yes, I did notice this in the Changelog, and we did test it. At that time I trusted the developers not to make stuff default that was still giving lots of false positives. And, it's kind of hard to test the effectiveness of a virus scanner, especially in the face of false positives (or you'd need a pretty huge test set). Since we're "reasonably" protected from FPs anyway, we decided to put it in production, but found out we were tempfailing legitimate paypal mails soon after, so we disabled the URL scanning. -- Jan-Pieter Cornet <[EMAIL PROTECTED]> !! Disclamer: The addressee of this email is not the intended recipient. !! !! This is only a test of the echelon and data retention systems. Please !! !! archive this message indefinitely to allow verification of the logs. !! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
Ian Eiloart wrote: > Oh, but wait. What's going on here? You upgrade ClamAV and your > configuration changes? That shouldn't happen at all. Are you using an > installer tool that overwrites your deployed configuration? Surely not! When we upgraded ClamAV, our configuration file stayed the same, BUT we were treated to slow and unwanted new behaviour that caused a flurry of support calls and significant amounts of our support time to figure out what the h*ll was happening. We were not impressed with the decision taken by the Clam developers. As a general principle of least surprise, new and experimental behaviour should need to be enabled explicitly and not "snuck in" on unsuspecting users. Regards, David. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Nov 15, 2007 1:22 PM, David F. Skoll <[EMAIL PROTECTED]> wrote: > Ian Eiloart wrote: > > > Oh, but wait. What's going on here? You upgrade ClamAV and your > > configuration changes? That shouldn't happen at all. Are you using an > > installer tool that overwrites your deployed configuration? Surely not! > > When we upgraded ClamAV, our configuration file stayed the same, BUT > we were treated to slow and unwanted new behaviour that caused a flurry > of support calls and significant amounts of our support time to figure > out what the h*ll was happening. > > We were not impressed with the decision taken by the Clam developers. > As a general principle of least surprise, new and experimental > behaviour should need to be enabled explicitly and not "snuck in" on > unsuspecting users. Aren't these features only ever enabled if compiled with --experimental? -- /peter ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
--On 15 November 2007 10:07:22 +0100 Jan-Pieter Cornet <[EMAIL PROTECTED]> wrote: > > If we do stop using clamav, it'll be because of the surprises we find > after the next upgrade, or the upgrade after that. As I explained above, > please keep the default scanner reliable (in terms of FPs). Hmm... Well, I'd agree that the default scanner should not produce significant false positives. However, the chances of producing a false positive don't lie entirely within the software. They lie in the behaviour of the software in your environment (mainly the type of traffic through your server). Since environments differ, there's a trade-off here between providing good protection for a variety of users and limiting the damage done by false positives. Oh, and usability is an issue, too. Now, I'd expect a manager of an ISP's mail service to be able to spend half an hour or so checking the configuration before deploying an upgrade. That time will be recovered if a single support incident is avoided, so it's a useful investment. I would not expect surprises in the configuration deployed (whether it's the default or not) to result in abandonment of the software - especially if that the documentation in the configuration file makes it reasonably clear what can be expected. If the documentation is sufficiently faulty, that might be a reason to abandon the software. However, given that this is open source, you might think along these lines: "Heck, that was bad, but I can fix it. Imagine how bad this would be if the problem happened in closed software!" Can't happen? I remember a commercial AV product screwing up Macs by removing heuristically detected "trojans" that turned out to be part of the OS! Given that there were no actual trojans in the wild at all, we stopped paying our license fees for that product. Oh, but wait. What's going on here? You upgrade ClamAV and your configuration changes? That shouldn't happen at all. Are you using an installer tool that overwrites your deployed configuration? Surely not! -- Ian Eiloart IT Services, University of Sussex x3148 ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Thursday November 15, 2007 at 06:18:40 (AM) Ian Eiloart wrote: [ ... ] > Oh, but wait. What's going on here? You upgrade ClamAV and your > configuration changes? That shouldn't happen at all. Are you using an > installer tool that overwrites your deployed configuration? Surely not! Excellent point. I am using FBSD-6.2, and when clamav is updated, the configuration file is never over written. However, a new 'clamd.conf.sample' file is created for my perusal. -- Gerard pgpAJaiZQeRj0.pgp Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Wed, Nov 14, 2007 at 08:01:44PM +0200, Török Edwin wrote: > Agreed, the defaults should not generate false positives, or have a very > small chance to do so. > The default will be changed, but not to "off", see [1]. That seems to be a smart thing to do, provided the implementation doesn't cause excessive overhead. > > In fact, this very feature is the reason we are considering to stop the > > use of ClamAV. > > You'll have the possibility to turn on only parts of the checks, see [1]. > Are you considering to stop using ClamAV *entirely* or just turn off > specific features? There are some in my company who want to stop using it entirely. The reason is that what we want is an email virus scanner, giving us an accurate indication of whether a particular email contains malware or not. However, clamav seems to shift to also detecting other kinds of unwanted email, and even into "email activism". An example is in the discussion of bug #551, especially: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=551#c2 (If someone says "this is a legitimate mail flagged by clam as malware, therefore it's a FP", you cannot say "oh but that mail uses unsafe constructs". That might be true, but it's still a legitimate mail that most users would want to receive) I still think clamav gives a pretty good performance compared to how much it costs (note that it's not free: main costs are admin support costs and customer support calls in case of FPs. Extra hardware for the necessary CPU power is also a factor, although recent speed improvements helped a lot). In my opinion, the default scanner should always only detect malware that constitutes an actual security threat, and that can be identified with enough certainty to cause negligible false positives. For some people it might be nice that it also tries to detect spam and dodgy practices from legitimate but ignorant bankers or telemarketers, but as an ISP, I cannot block such emails. (But an option to block that on my mail server at home would be great!) > > Complete lack of a standard naming scheme to distinguish > > between viruses and phishing mails is also a factor here. > > ClamAV does have different names for malware and phish. > See http://wiki.clamav.net/Main/MalwareNaming. > If you know particular signatures that don't respect these rules, please > tell us. Well, there's an E-mail.Phishing.SMT rule. And I wonder what all those other 'E-?mail.' signatures are... There's Email.E-card, Email.Ecard, Email.hoax (how is that different from the Joke hierarchy?), etc. Even that wiki page doesn't seem like an authoritive document describing how malware is named, but more an after-the-fact list of names found to be present with a bit of explanation added. If you're serious about detecting various kinds of unwanted email, you should have a rigid naming scheme to accurately identify the various different types. > If you are referring to a standard naming scheme among different > anti-virus products, > it is an entirely different matter, and is just not possible generally. No, I'm aware of that problem, but that's not of my concern. > > However, spam and phishing detection has a much higher false positive > > rate, so it's very unwise to discard the mails, and it's usually bad > > to reject them (because of automatic bounce handling by legitimate bulk > > mailers), so we put such mails in a special folder. > > Why does this make you wanting to drop the use of ClamAV? > You can filter based on "virus found name", and those containing > 'Heuristics' can go to > your special folder. > Or you can turn the feature entirely off. If we do stop using clamav, it'll be because of the surprises we find after the next upgrade, or the upgrade after that. As I explained above, please keep the default scanner reliable (in terms of FPs). -- Jan-Pieter Cornet <[EMAIL PROTECTED]> !! Disclamer: The addressee of this email is not the intended recipient. !! !! This is only a test of the echelon and data retention systems. Please !! !! archive this message indefinitely to allow verification of the logs. !! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
