Jhonny Vargas wrote:

The performance couldnt be better if run dspam as a daemon and then the plugin just comunicates with it than make the plugin start the dspam driver every time that comes an email?

The 3.4 series already runs with a resident process (and for that matter, the kernel will only load the library once if I have enough RAM for caching), but the issue is that even with the client/server paradigm, the basic design of dspam is that it expects to be at the end of the delivery path, not in the middle of the SMTP transaction.


John

Reply via email to