I went through a similar optimisation process with our qmail install a little while ago. We use qmail-qfilter, which stores the entire message on disk before calling the list of filters with the file descriptor of the message. I patched clamd (subsequently accepted into the codebase) to accept a file descriptor for scanning.
Thanks for the suggestion. As it turns out, after discussion with the other qpsmtpd developers, I patched the core to write the entire in-coming message (headers and body) into a spool file, then noted the offset where the body itself started. From that point, it is trivial to scan with clamd, and we can create a fresh header (with additional Received: line and any other X-headers) without rewriting the disk file when queuing the message for delivery.
I still think that it is suboptimal that the only public interface to libclamav requires you to go through the heuristics. No matter how good those heuristics are (and I have no doubt they are *very* good), there is no reason to spend the time to execute them, _if the external system already knows what type of file is to be scanned_. Sure, it's an edge case, but ignoring external information means more work has to be done than is strictly necessary.
John
_______________________________________________ http://lurker.clamav.net/list/clamav-devel.html
