--
On Mon, May 13, 2002 at 02:05:36PM +0100, Philip Hazel wrote:
| 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.
I think it is, to prevent code duplication. However ... (see below)
| > 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).
This makes sense. However, this external lib shouldn't dupliate exim
either. In this example, serializing the message according to
RFC2822, exim must already do this in many situations. I think the
two should cooperate -- exim provide a public interface to the
(useful) stuff it already does, and an external lib to provide other
things that a local_scan might want. Of course, if exim's
implementation of some feature is too tied into its own usage, then it
may not be a good idea to try and expose a public interface to it.
| > 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.
That sounds like a good idea! We should have thought of that already!
If this super-local_scan function is created, it can have the code to
check a switch, and thus eliminating both code duplication and the
need for you to add it to exim proper.
The biggest problem with this (from my perspective) is that I don't
know how to dynamically load modules in C. (I wouldn't be much help
until I figured it out)
| > 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).
That's what the filter is intended as (a UNIX-style one rather than a
delivery-controlling one).
| 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.
I was hoping it could be done without the extra config of the router
and transport and without the overhead of feeding the message into
exim twice. Maybe some day :-).
-D
--
the nice thing about windoze is - it does not just crash,
it displays a dialog box and lets you press 'ok' first.
GnuPG key :
http://dman.ddts.net/~dman/public_key.gpg
--
[ Content of type application/pgp-signature deleted ]
--
