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
>
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jef moskot
Sent: dinsdag 27 november 2007 13:59
To: ClamAV users ML
Subject: Re: [Clamav-users] Phishing feature defaults, naming, and 0.92
On Tue, 27 Nov 2007, Mark wrote:
> Hmm, i'm just in the pr
-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 &quo
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?
I
t: Re: [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
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
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 postponin
vember 2007 10:37
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
&
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 possi
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. further
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 beha
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
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 possib
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
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 insta
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 t
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 t
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.
>
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 develo
David F. Skoll wrote:
> 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 simula
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 mill
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 peo
--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
__
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 pre
--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.
>
> :-)
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 s
--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 person
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.
Gerard wrote:
>> On November 16, 2007 at 10:14AM Christoph Cordes wrote:
>
>> So, what do you think - is this a solution that would work for the
>> majority ? It would also be helpful - if this is a solution you could
>> agree one - if you make suggestions what to include in the different
>
> On November 16, 2007 at 10:14AM Christoph Cordes wrote:
> we thought a bit about this, and here's the solution that could
> satisfy everyone (TM):
Never going to happen!
> for clamd we could provide different configfiles, depending on the
> needs the user can choose between 3 - or more te
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:
> this is pre-version-1.0 software: it's a beta. who on earth upgrades
> from one beta to another and uses the same configfile???
Clam developers: Do you consider Clam to be in beta still? I do not.
[...]
> post v1.0 i'd agree with you. this is beta software. expect surprises.
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 h
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 whol
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
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 releases
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
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 chan
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
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 tha
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 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? Sur
--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).
H
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!
Excellen
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
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
Török Edwin wrote:
> The default will be changed, but not to "off", see [1].
Please reconsider. An upgrade (that doesn't change the config file) should
not introduce new behaviour (especially what I'd consider to be experimental
behaviour.)
If you are going to change the default *anyway*, pleas
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
48 matches
Mail list logo
