On Tue, 7 May 2002, dman wrote:
> exim should provide an API for option gathering. (I know this is on
> the wishlist already)
Yup.
> exim should provide a condition flag for calling local_scan rather
> than each local_scan implementation checking it.
Is it really worth is? It's only a couple of lines of code for those
local_scan functions that want it.
> A function to convert the entire message into a RFC2822 stream would
> be helpful. A fair amount of Marc's code deals with converting the
> in-memory message to a stream to feed to spamc. exiscan does this
> too.
I do not want to fill up Exim with a library of functions to do things
that it does not normally need to do in the course of its operation. It
seems to me that a better approach for this is for somebody else to
implement a "local_scan lib" which is separately and independently
maintained (thus, not on my critical timeline).
> Dynamic loading of local_scan. This would allow the various
> local_scans to be packaged separately from exim itself and
Again, this is extra work for me. Why not write a local_scan() function
that itself loads the other functions? That takes me out of the loop.
> I'd also like to see a hook added for a filter that would be run after
> accepting the message but before routing it.
Not easy to do within Exim if you want to change the message (as you
seem to want to do). You can implement this already by making the first
delivery go through a filter (with all addresses batched so there's only
one copy) in the same way that you can send incoming messages through a
virus scanner. That does mean that the message goes through Exim twice,
but otherwise it should work just fine.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
