dspam data sizes

[Christian Damm]

Doug Hardie schrieb:
> 
> On Mar 18, 2005, at 02:50, Christian Damm wrote:
> 
>>
>> this was discussed in detail (several times) on the dspam mailing list 
>> - search the archives: 'http://dspam.nuclearelephant.com/search.shtml'.
>>
>> you can extremely cut down your db size using different 
>> methods...which training method you are currently using? - once dspam 
>> is "mature" enough (training wise) it is (for example) a good idea to 
>> switch to TOE mode (train on error) if your user base is large - your 
>> db shrinks and the performance gain is big.
>>
>> Doug Hardie schrieb:
>>
>>> After seeing the recommendations here I am testing dspam.  I 
>>> currently have 2 users testing it.  They are at both extreme ends of 
>>> mail demands.  My account gets about 1000 emails a day of which about 
>>> 25-30% are spam.  The other account gets about 100 emails a day of 
>>> which about 90% are spam.  So far, dspam is quarantining about 1/3rd 
>>> of the spam I receive.  Is basically the same as Apple's mail 
>>> filtering.  My mail is being sent to both.  However, the storage of 
>>> the data used by dspam is a bit overwhealming.  The storage is at 250 
>>> MB for me and 20 MB for the other account.  I have cut way down the 
>>> purge retention intervals which appears to help somewhat but not 
>>> enough.  I have thousands of users and at 250 MB per user (it would 
>>> probably be a bit below that)  its just not practical.  How do other 
>>> users of dspam deal with this issue?  Is there some setting I have 
>>> wrong (or at least not set most efficently)?
> 
> 
> Thanks.  I dug through the archives and it appears the recommend 
> approach is to use BDB4 as the backend with TOE mode, chained disabled, 
> and frequent dspam_clean -p0, and -s0 purges.  My current setup is:

from what i have seen/heard in the past: stay away from BDB - regarding 
dspam its really unreliable! dont know much about dspam`s quite new 
sqlite support, the postgresql support seems to have improved 
too...anyway, mysql is for sure the best choice if you wanna stay out of 
trouble.

> 
> sqlite backend
> TOE mode
> nightly purges using the provided script but with the days reduced to 3.
> Will have about 3K users when in production
> chained has been disabled
> I believe all other settings are default except that I have to use Home 
> directories for the data storage.

sounds ok

> 
> _______________________________________________
> freebsd-isp at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
> 
> !DSPAM:423be1a7903811228318292!
> 

-- 

mfg.

christian damm
technische leitung
phone: dw 42
email: christian.damm at diewebmaster.at
icq at work: 124464652

die webmaster - flötzerweg 156 - 4030 linz - austria

phone: +43-732-381242
fax: +43-732-381242-22
isdn (leonardo): +43-732-381242-33

homepage: www.diewebmaster.at, public email: office at diewebmaster.at


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 7.0.3 for non-commercial use

mQGiBD6BdjoRBAD6ZEPqO2y3jbudyWuMfj+84mOAOFa13d+bHjNsx5M3IXl0KDjL
LJZe7mO4aVX5Uo6zWskuVztXk4EdvIt96XkPweazYX7SN3w41QD6/lHGkQr5PO/b
Qp/G2KLFLQXjXUJibXMbNK8j4RtSHPFwJAXVVVO2uigsCnanMbr5KXqQmQCg/w/q
srHviHQuJXcfpTKB4ys2xnsEAOkLTDwQ5Z5SjRoAkxJywneOyG11uRqvlBaBNjyx
5mb0T+zh5ed0jmu1a91F5VRrXzAKyWfA4jc1/jpYpHpDW72bk8eF/WltxQ5LMfaJ
nqPcNEukMkm/lGCfk+Prtktz9/MoRnhxHreEasEqhYILlPFjG0Tg4yd618TPuRdf
qkR4A/0VCGzBPK289npn1ssIiNntOd0Dtu8UnbZGx4uPOP3jJP8awNH/XpV4Q8VZ
ePoZnjamYjPGDPIiBtLI60Wx7z4tDXlqKSUy7GkddGw0dGnNyiiHu/ESjd2cYX8y
/WkRnWyHcBRb4aEe4vYAt2PwP3Iemt9VMoPXJRQU6e6BkUzsbLQvQ2hyaXN0aWFu
IERhbW0gPGNocmlzdGlhbi5kYW1tQGRpZXdlYm1hc3Rlci5hdD6JAFgEEBECABgF
Aj6BdjoICwMJCAcCAQoCGQEFGwMAAAAACgkQjWTAFtIJONrURgCfWAdk77WMgOIL
GAkzXJGUghdSufUAn2BNvaFF8f4SnqyVAX6MSCeZFQsouQINBD6BdjoQCAD2Qle3
CH8IF3KiutapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSG
SfgMg71l6RfUodNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJ
Zv8V+bv9kV7HAarTW56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgN
RR0PfIizHHxbLY7288kjwEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv88
4bEpQBgRjXyEpwpy1obEAxnIByl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsi
GSa6q6Jew1XpMgs7AAICCADV9CD8D0TdkGRs7bKIzh8pc7uWAprhqLF6B/KdVo+k
URDNWLVzpuR1ZVu612xLK/a7Q875P2DTdAuc1eBc0/5Q/jXH6pzo/lDmNbrFvJtu
p+GRGyC3hJF25TBDRNhKfIQYT+9pm6sOyLw+mh+ruHKi+PEwvTQK/gPHr5GAGKor
0EmYdfIGm2t1kFSifCm+/1jeITtQedDAlcN8ESBY+b+gONa1H/7LdPrWHVUPUs9k
WDwHFvTh8u28ixCcRaiT2wOkk7n+a2NPIe8LIznlbgwB8GK/7axIEXOBd0XyCyft
pJxYDZ4kxtRAD6CnpqswCzSaGJmllGwFD4QyWKKIFgCwiQBMBBgRAgAMBQI+gXY6
BRsMAAAAAAoJEI1kwBbSCTjaiC8AoKfArhjrTMto6hm7gQFc7hh+9W6RAKDqZloe
VR7EixSKaBhw5bZ5WUYM0Q==
=l3K/
-----END PGP PUBLIC KEY BLOCK-----