To: ClamAV users ML
Subject: Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Mon, 19 Nov 2007, Dennis Peterson wrote:
Perhaps they should issue a warning or advisory against re-using the
config files from previous versions as this has the potential to
introduce surprises
Mark writes:
Hmm, i'm just in the process of upgrading from 0.88.7 to 0.91.2 (FreeBSD).
The difference in accuracy between what we were used to and the newer
version was so large that it fundamentally changed the nature of the
product, do you mean that in a bad way? I've been postponing an
Mark schrieb:
Hmm, i'm just in the process of upgrading from 0.88.7 to 0.91.2 (FreeBSD).
The difference in accuracy between what we were used to and the newer
version was so large that it fundamentally changed the nature of the
product, do you mean that in a bad way?
He does. ;-)
I've been
: [Clamav-users] Phishing feature defaults, naming, and 0.92
I am using 0.91.2 on three production FreeBSD servers two of which
process about 1,000,000 mail messages a day. I have seen no real
problems with either the anti-virus or anti-phishing features.
There are a number of new configuration file
On Tue, 27 Nov 2007, Mark wrote:
Hmm, i'm just in the process of upgrading from 0.88.7 to 0.91.2
(FreeBSD). The difference in accuracy between what we were used to and
the newer version was so large that it fundamentally changed the nature
of the product, do you mean that in a bad way?
It
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tilman Schmidt
Sent: dinsdag 27 november 2007 13:50
To: ClamAV users ML
Subject: Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
It's not something that's going to be solved. The new
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jef moskot
Sent: vrijdag 16 november 2007 17:27
To: ClamAV users ML
Subject: Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
If you're using clamscan, the config file doesn't enter into it, but the
default behavior
Christoph Cordes wrote:
- after a new release ClamAV should mimic the behavior of the
preceding version by default unless it's a major release (.x0) or the
user enabled possible new features explicitly. furthermore the
default behavior should be as conservative as possible. Did i get
Christoph Cordes wrote:
Hello,
so in the end it boils down to this:
- after a new release ClamAV should mimic the behavior of the
preceding version by default unless it's a major release (.x0) or the
user enabled possible new features explicitly. furthermore the
default behavior
Hello,
so in the end it boils down to this:
- after a new release ClamAV should mimic the behavior of the
preceding version by default unless it's a major release (.x0) or the
user enabled possible new features explicitly. furthermore the
default behavior should be as conservative as
Steve Wray wrote:
Christoph Cordes wrote:
Hello,
so in the end it boils down to this:
- after a new release ClamAV should mimic the behavior of the
preceding version by default unless it's a major release (.x0) or the
user enabled possible new features explicitly. furthermore the
On Thu, 22 Nov 2007, Christoph Cordes wrote:
- after a new release ClamAV should mimic the behavior of the preceding
version by default unless it's a major release (.x0) or the user enabled
possible new features explicitly. furthermore the default behavior
should be as conservative as
On Mon, 19 Nov 2007, Dennis Peterson wrote:
Perhaps they should issue a warning or advisory against re-using the
config files from previous versions as this has the potential to
introduce surprises.
The surprise would still exist if you use clamscan and not clamdscan.
This config file talk is
--On 16 November 2007 13:47:58 -0500 Gerard [EMAIL PROTECTED] wrote:
Hold on here. Are you stating that you expect users to actually RTFM? I
think you are expecting way too much.
No, it's not. Not when the users are professional IT people.
The default configuration should suit personal
Ian Eiloart wrote:
Hold on here. Are you stating that you expect users to actually RTFM? I
think you are expecting way too much.
No, it's not. Not when the users are professional IT people.
:-) I don't think we hang around the same Professional IT people
The default configuration should
--On 19 November 2007 07:23:57 -0500 David F. Skoll
[EMAIL PROTECTED] wrote:
Ian Eiloart wrote:
Hold on here. Are you stating that you expect users to actually RTFM? I
think you are expecting way too much.
No, it's not. Not when the users are professional IT people.
:-) I don't think
Ian Eiloart wrote:
Because ordinary users and IT staff have different needs. Regardless of
what professionals actually do, they bloody well ought to think about it
first.
You are absolutely, 100% correct.
I am also correct when I say that expecting that to happen in the real
world is
--On 19 November 2007 08:41:59 -0500 David F. Skoll
[EMAIL PROTECTED] wrote:
I shouldn't have to read
source code to decide whether or not to use a new feature.
Of course not. That's why the documentation has to be good.
--
Ian Eiloart
IT Services, University of Sussex
x3148
David F. Skoll wrote:
Ian Eiloart wrote:
Hold on here. Are you stating that you expect users to actually RTFM? I
think you are expecting way too much.
No, it's not. Not when the users are professional IT people.
:-) I don't think we hang around the same Professional IT people
The
Dennis Peterson wrote:
All of these problems are best discovered during the test stage in any event.
Yes, but you know as well as anyone that you can't always simulate a
production environment in a test environment. We simply don't have
the hardware to simulate an environment processing 5
Dennis Peterson wrote:
That which you can't test you are obliged to understand. If you
can't understand a thing because of time constraints, complexity, or
inadequate documentation, then you turn it off until circumstances
change. You finally kinda did that.
Yes. However, the Clam
David F. Skoll wrote:
Dennis Peterson wrote:
That which you can't test you are obliged to understand. If you
can't understand a thing because of time constraints, complexity, or
inadequate documentation, then you turn it off until circumstances
change. You finally kinda did that.
Yes.
Dennis Peterson wrote:
They didn't turn it on and they didn't install it. They provided a
sample config that is incapable of running and which requires
administrative attention in order to use. What finally ends up
running on the system is your job and mine to manage.
The sample config that
David F. Skoll wrote:
Dennis Peterson wrote:
They didn't turn it on and they didn't install it. They provided a
sample config that is incapable of running and which requires
administrative attention in order to use. What finally ends up
running on the system is your job and mine to manage.
Dennis Peterson wrote:
[David Skoll = DS]
If you do an upgrade, you keep your old configuration file.
[DP]
No - I don't, actually.
I mean the default behaviour if you do an upgrade is to keep the old
configuration file. This is the default for source installations and
(I believe) RPM
I feel problem is not in config, but what clamd does when no config has
been set on that new function (tipical situation when you upgrade and
new features are available).
Even when example configs keep the state OFF, what happens when no
config has been set for that feature?
On minor
Christoph Cordes wrote:
we thought a bit about this, and here's the solution that could
satisfy everyone (TM):
for clamd we could provide different configfiles, depending on the
needs the user can choose between 3 - or more templates, like:
But you are missing the point. The problem is
On 11/16/07, rick pim [EMAIL PROTECTED] wrote:
David F. Skoll writes:
But you are missing the point. The problem is not the
configfiles. Anyone
can easily edit a config file.
The problem is that new behaviour suddenly appears when using an *old*
configfile. It's the hard-coded
On Fri, 16 Nov 2007, rick pim wrote:
who on earth upgrades from one beta to another and uses the same
configfile???
If you're using clamscan, the config file doesn't enter into it, but the
default behavior still changes. You need to pass a flag to turn off the
phishing checks.
I get the whole
David F. Skoll writes:
But you are missing the point. The problem is not the configfiles. Anyone
can easily edit a config file.
The problem is that new behaviour suddenly appears when using an *old*
configfile. It's the hard-coded defaults in the source that are the problem.
i'm
Hello,
we thought a bit about this, and here's the solution that could
satisfy everyone (TM):
for clamd we could provide different configfiles, depending on the
needs the user can choose between 3 - or more templates, like:
failsafe - most reliable
standard - higher chance for a fp but also
rick pim wrote:
who on earth upgrades
from one beta to another and uses the same configfile???
Who on earth uses clamav in a way that requires a config file!? how
barbaric!
Any solution which only solves this problem via config file and/or
command line switches is an unacceptable solution.
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
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!
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,
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
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
Jan-Pieter Cornet wrote:
PhishingScanURLs should be off, in my opinion, for every mailserver
installation that actually cares about delivering legitimate mails to
its users. So that would imply the default to be off.
Agreed, the defaults should not generate false positives, or have a very
On Wednesday November 14, 2007 at 01:01:44 (PM) Török Edwin wrote:
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.
[1] http://lurker.clamav.net/message/20071114.165015.e815b938.en.html
39 matches
Mail list logo
