Bug#438605: dspam: HASH db maintenance bugs

2008-03-09 Thread Matthijs Mohlmann 
Hi,

Can you clarify about 'Signatures are NEVER deleted, ...' because there
is a tool dspam_clean which periodically runs for the hash and db
driver... see /etc/cron.daily/dspam

Regards,

Matthijs Mohlmann



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#438605: dspam: HASH db maintenance bugs

2008-03-09 Thread Gunter Ohrner 
Am Sonntag, 9. März 2008 schrieb Matthijs Mohlmann:
 Can you clarify about 'Signatures are NEVER deleted, ...' because there
 is a tool dspam_clean which periodically runs for the hash and db
 driver... see /etc/cron.daily/dspam

That's of no use as the hash driver simply does not support deleting 
signatures, just as I wrote.

Have a look at dspam_clean's source code, the signature processing loop 
starts as follows:


#ifdef DEBUG
printf (Processing sigs; age: %d\n, age);
#endif

  ss = _ds_get_nextsignature (CTX);
  while (ss != NULL)
  {
#ifdef DEBUG
printf (Signature: %s\nCreated: %s\n, ss-signature,
ctime (ss-created_on));
#endif


and goes on to build a list of signatures to be deleted.

Now have a look at the hash_drv code:


struct _ds_storage_signature *
_ds_get_nextsignature (DSPAM_CTX * CTX)
{
  return NULL;
}


So you can invoke dspam_clean as often as you like, you'll need to resort 
to a plain find / rm combination invoked by cron to avoid your disk 
filling up by an unbounded signature directory growth.

As its not documented, I consider that to be a bug in dspam 3.6.4, but 
it's a bug which was not fixed or worked around in the Debian package 
when I opened the bug report and which has rather serious consequences 
for real-life installations.

Greetings,

  Gunter


signature.asc
Description: This is a digitally signed message part.

Bug#438605: dspam: HASH db maintenance bugs

2007-08-18 Thread Gunter Ohrner 
Package: dspam
Version: 3.6.8-5
Severity: important


Two issues with the hash db driver:

* Signatures are NEVER deleted, this feature is not implemented in the hash 
driver.
  The docs should feature this limitation more prominently, and maybe also a 
not should
  be added to the sample / default config file, together with a suggested 
workaround.

* cssclean / csscompress will fail if /tmp resides on a different partition 
than the
  *.css files. csscompress will spit out an error while cssclean will fail 
SILENTLY!
  A patch for csscompress is available at 
http://mailing-list.nuclearelephant.com/3863.html
  a patch for cssclean would look similar.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages dspam depends on:
ii  libc6  2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii  libdspam7  3.6.8-5   DSPAM is a scalable and statistica
ii  libldap2   2.1.30-13.3   OpenLDAP libraries
ii  procmail   3.22-16   Versatile e-mail processor

Versions of packages dspam recommends:
pn  clamav-daemon none (no description available)
ii  dspam-doc 3.6.8-5Documentation for dspam

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]