Chuck Swiger wrote:
Bill Landry wrote:
[ ... ]
You are preaching to the choir here, as you have no argument from me. I
raised the same issue the last time this happened to me a few weeks ago
and clamd died twice on me in one day. The script work-around to check
the databases before
Christopher X. Candreva wrote the following on 12/30/2006 1:39 PM -0800:
On Sat, 30 Dec 2006, Bill Landry wrote:
The MSRBL-Images.hdb database started showing up corrupted yesterday and
This is not the only reason I ask, but the most recent. I have a script that
checks that
Bill Landry wrote:
[ ... ]
You are preaching to the choir here, as you have no argument from me. I
raised the same issue the last time this happened to me a few weeks ago
and clamd died twice on me in one day. The script work-around to check
the databases before implementing them has saved my
At 11:31 AM 12/31/2006, Chuck Swiger wrote:
Agreed-- it would be nice if clamd was more robust, either by
continuing to run with the other DBs (as available) and either drop
the bad line or the entire bad DB file, until a new update comes
along which is OK.
An option to drop the bad database
Chuck Swiger wrote:
Bill Landry wrote:
[ ... ]
You are preaching to the choir here, as you have no argument from me. I
raised the same issue the last time this happened to me a few weeks ago
and clamd died twice on me in one day. The script work-around to check
the databases before
Is there a compelling reason for clam to die on a malformed database,
instead of just ignoring the bad line and continuing with all the other
sigs ?
==
Chris Candreva -- [EMAIL PROTECTED] -- (914) 948-3162
WestNet Internet Services of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher X. Candreva wrote:
Is there a compelling reason for clam to die on a malformed database,
instead of just ignoring the bad line and continuing with all the other
sigs ?
Because doing otherwise is a recipe for disaster.
A malformed
On Sat, 30 Dec 2006, Sander Holthaus wrote:
A malformed database points to:
- - serious system malfunction
- - security breach
- - security breach / system malfunction between you and (or at) the
database provider
In my experience, it means a database maintainer who made a simple
At 09:19 AM 12/30/2006, Christopher X. Candreva wrote:
How exactly is this better then a possibe false-positive, if a corrupted sig
happens to match some valid piece of mail ?
The maintainers don't distribute corrupted signatures, so if the sig
database is corrupted something is seriously
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher X. Candreva wrote:
On Sat, 30 Dec 2006, Sander Holthaus wrote:
A malformed database points to:
- - serious system malfunction - - security breach - - security
breach / system malfunction between you and (or at) the database
Christopher X. Candreva wrote:
In my experience, it means a database maintainer who made a simple mistake
in one line.
I don't think this'll really add anything useful to the discussion
but I've seen that happen in one of the mrsbl
databases.. but there are some small things the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Basford wrote:
Christopher X. Candreva wrote:
In my experience, it means a database maintainer who made a
simple mistake in one line.
I don't think this'll really add anything useful to the
discussion but I've seen that happen in one
Noel Jones wrote:
At 09:19 AM 12/30/2006, Christopher X. Candreva wrote:
How exactly is this better then a possibe false-positive, if a
corrupted sig
happens to match some valid piece of mail ?
The maintainers don't distribute corrupted signatures, so if the sig
database is corrupted
Christopher X. Candreva wrote the following on 12/30/2006 5:50 AM -0800:
Is there a compelling reason for clam to die on a malformed database,
instead of just ignoring the bad line and continuing with all the other
sigs ?
The MSRBL-Images.hdb database started showing up corrupted yesterday
On Saturday 30 December 2006 1:50 pm, Bill Landry wrote:
The MSRBL-Images.hdb database started showing up corrupted yesterday and
have continued to show up that way so far today, as well. Use something
like the script I posted here a few weeks ago to test SaneSecurity and
MSRBL databases
On Sat, 30 Dec 2006, Bill Landry wrote:
The MSRBL-Images.hdb database started showing up corrupted yesterday and
This is not the only reason I ask, but the most recent. I have a script that
checks that evidenly has a bug. I can either spend time fixing that, or
fixing clam so it ignores the
Christopher X. Candreva wrote:
On Sat, 30 Dec 2006, Sander Holthaus wrote:
There is no point in using a malformed database and could even spell
disaster. (Imagine it starts generating FP's en masse, which could be
a side effect of a corrupted database).
Having clam die spells disaster.
Sander Holthaus wrote:
A tempfail is not a disaster in most scenarios. You may not be able to
receive mail until it is fixed, but you still get the mail after it is
fixed.
I think that attitude works fine in trivially small email environments.
I don't think it works at all in environments
On Sat, 30 Dec 2006 14:13:14 -0800
John Rudd [EMAIL PROTECTED] wrote:
For a mission critical environment, it seems like the better behavior
would be:
1) keep the previous db
2) download the new db
3) if the new db is bad, throw an error in the logs/stdout, and keep
functioning propperly
Tomasz Kojm wrote:
On Sat, 30 Dec 2006 14:13:14 -0800
John Rudd [EMAIL PROTECTED] wrote:
For a mission critical environment, it seems like the better behavior
would be:
1) keep the previous db
2) download the new db
3) if the new db is bad, throw an error in the logs/stdout, and keep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Rudd wrote:
Sander Holthaus wrote:
A tempfail is not a disaster in most scenarios. You may not be
able to receive mail until it is fixed, but you still get the
mail after it is fixed.
I think that attitude works fine in trivially small
Sander Holthaus wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Rudd wrote:
Sander Holthaus wrote:
A tempfail is not a disaster in most scenarios. You may not be
able to receive mail until it is fixed, but you still get the
mail after it is fixed.
I think that attitude works fine
On Sat, 30 Dec 2006, Tomasz Kojm wrote:
Freshclam provides this and much more.
Except the ability to operate from a given specific URL pointing to a file.
If the only updates come from freshclam-verified sources it wouldn't be so
bad. The problem comes up that other mechanisims are necessry
Christopher X. Candreva wrote:
On Sat, 30 Dec 2006, Tomasz Kojm wrote:
Freshclam provides this and much more.
Except the ability to operate from a given specific URL pointing to a file.
If the only updates come from freshclam-verified sources it wouldn't be so
bad. The problem comes up
On Sat, 30 Dec 2006, Dennis Peterson wrote:
There's no limitation for choosing a URL - you can put anything you like in
the freshclam.conf file. Using the --config-file=FILE option of freshclam in
The only option I see in man freshclam.conf is for a database mirror
server name, not a URL.
Hello Christopher,
Having clam die spells disaster. If you've set your system to tempfail on
clam failure, you can't receive mail until it is fixed.
[snip]
How exactly is this better then a possibe false-positive, if a corrupted sig
happens to match some valid piece of mail ?
It's
On Sun, 31 Dec 2006, Luca Gibelli wrote:
How exactly is this better then a possibe false-positive, if a corrupted
sig
happens to match some valid piece of mail ?
It's better to delay N emails rather than delete N emails.
A false-positive won't delete the mail - it will cause an
* On 30/12/06 08:50 -0500, Christopher X. Candreva wrote:
|
| Is there a compelling reason for clam to die on a malformed database,
| instead of just ignoring the bad line and continuing with all the other
| sigs ?
Nice question. I was going to ask the same after mine kept dying for the
same
28 matches
Mail list logo
