Steve wrote:
Sorry but this is so wrong in many aspects. Johnathan has not wrote DSPAM to be complicated but to do a job. He has not modeled DSPAM for baysian algorithm specialists or database specialists or web application developers or or or but for filtering spam and ham for users. And to be honest: he has done a very decent job.
Thas exactly what I was saying. LOL... thanks for clearing it up.
Have you ever looked at the code of DSPAM? It is very well structured and not that bad as you state. It is pretty much already split in the areas you mention.
Excellent.
I am totally against dropping the other storage engines. And the hash driver has a reason it is there: You can not save fast enough SBPH into any other storage backend then into hash. If you ever looked into CRM114 and SBPH or Markovian then you would know why the hash driver is there in DSPAM.
But the hash driver isn't thread safe, and thus can't be used on anything other than a low volume system. Its a current open bug. Even the documentation is misleading in this regard.
And since when is DSPAM a LDA? It only speaks SMTP or LMTP (DLMTP). It does not try to replace procmail or maildrop. It even uses the two but no where does it try to replace them.
I'm merely quoting the documentation..... no need to bite.
No! That's only the half of the game. You need a goal as well. A global picture, a target or something like that. You need someone to draw the target where DSPAM is going. Someone capable to push DSPAM to evolve and not just a project leader, a release manager and a bunch of developers fixing bugs and maintaining documentation.
The goal is inherent in the need for the fork, we need a solution which will be mainteined and bug fixed. There are enough open bugs against dspam as is to define the goal. Roadmapping of features is a looooong way off yet.
Brian.
