Johannes Berg wrote:
Curtis Maloney schrieb:
Seems to me it will possibly lower the overall load, since you will only rescan/retrain messages _explicitly_ changed from/to SPAM/HAM.
Now, if only you could get some resident form of dspam, so you didn't have to keep spawning it.... or did I miss something in the docs?
Then again, there's libdspam...Yeah, though both these options kinda suck. Spawning dspam gives you all the benefit of the command line client (it reads config files etc.) while using libdspam makes it in-process. I'm looking at making another dspam library that encapsulates more functionality of the dspam client (ie. the config file reading etc.) and using that in-process with dovecot, I'll kick that idea around the dspam-dev list. Also, I'd link that library into my MTA (exim). The rationale for that idea is to centralize dspam's configuration while still using it from within multiple processes. There's one catch: This system will require that dspam stores the signature in the header (that way I can use dovecot's API to extract it and pass it to libdspam w/o retrieving the whole message).
Sounds to me like a dspam daemon would be a better option in some ways. It would mean a single task could handle work from both the MTA and Dovecot. As I said, I've not looked closely at dpsam and its interfaces, but I think I will now...
Also, dspam appears to store the messages in its database, so I was thinking of making a dspam-database dovecot storage plugin as well (or integrate that with the dspam plugin I need to write anyway). That way, those emails are only stored once. I haven't figured out what it stores though, whether all messages, to a certain limit, only spam, or ..... Needs some thinking, probably, and for a start, I'll just deliver the spam-messages to another maildir and make a namespace for it.
This could be very interesting... certainly a "unique" feature for Dovecot, afaik. Would be very interesting to see how it turns out, and will be happy to test on my home setup.
-- Curtis Maloney