Steve wrote:
In my opinion, dspam should store everything in the database, rather
than some things in the database, and some things (quarantine,logs) in
files. It would make everything dspam (again, my opinion) easier to
replicate, manage, backup, and scale.
Storing human created white list entries would then rather need to be created
in clear text (currently the automatic white list is implemented with tokenized
entries). Not because DSPAM needs it in that way but because managing such
lists would be done by humans and they can not handle the tokanized entries.
Such lists could grow big. Would that be a problem?
Why would human created clear text non-tokenized white list entries grow
big? Or, are you saying that human created clear text white list
entries would be tokenized entries? In that case I don't see why the
entries would need to be tokenized.
In any case how big is big?
One other issue needs to be looked at as well: DSPAM does not only have
databases as backend. Some classifier/tokenizers use other formats then a DBMS.
For example Markovian uses CSS files. There you can not implement white listing
inside the CSS file without changing the format of the container.
I"m not familar with CSS.
Perhaps for whitelisting there could be a choice (a dspam.conf option?)
to enable/seek per user whitelist information from file or DB. Then
document both in the dspam.conf and docs that only file can be used for
whitelist managment if CSS is the backend DB in use.
-Troy
// Steve
!DSPAM:1011,486f85d0150921218517945!
