Elliot F wrote:
Am I missing something? There would be some trickiness with what user is used when scanning, but that could be determined via the recipient, or via some sort of directory/db hook.
Yes it is possible to do it that way; it is inelegant and there are still issues that have to be addressed. One sticking point is that if you are running dspam in TEFT mode (train everything), each message may take anywhere from a couple seconds to almost a minute to process (depending on server capabilities and load). This is too much to do during the SMTP transaction itself (unless it is a post_data hook). The other issue is that messages with multiple local recipients need to be processed once for each recipient (so their own tokens signatures are updated). I'm wavering on whether it is ever going to be practical to do the scan within qpsmtpd, but I know that launching a client process and capturing the STDOUT is never going to be as good as directly feeding the message to the dspam library via XS code.
Ah. As I am not familiar with Dspam, I did not realize how long it took to process messages. Couple that with the clamav and whatever other scanning (spamassassin), and it could be a significant delay.
It would be ideal to perform dspam scanning after the message was received but before it was delivered, which may mean a late plugin in qpsmtpd or it may mean (in my personal environment) a qmail-queue replacement.
John
How are you using it as a qmail-queue replacement?
