On Mon, 15 Jul 2002, Peter N Lewis wrote:
> Very complex for the local scan author - a quick look at the
> local_scan.h shows the kinds of things you'd have to potentially
> write:
>
> Header & Recipient list processing
> Child handling
> logging and debugging
> memory management for strings
This makes me wonder whether we need exim to provide a library which
modules could use.
If so we need two sets of version numbers, one for the version of the
exim support library, and one for the version of the module interface.
(Is the support library statically linked to the module, part of the exim
binary, or another module ? Which bits can be upgraded independently of
which others ?).
At 20:43 -0500 14/7/02, Derrick 'dman' Hudson wrote:
> Additional Data:
> One idea I had for this is using a pipe. exim would open a
> pipe to the specified scanner program. The message would be
> passed to the scanner on stdin. The exit code from the
> scanner program would determine what exim should do with it --
> accept, tempreject, permreject. If the scanner rejects the
> message, its output would be the message to return to the
> other server. Otherwise its output would specify how the
> message should be modified (namely adding or modifying
> headers). The format of the header modification text is a
> detail that can be worked out later.
I'm worried that a pipe would push more data around.
Would a file handle, or even a filename make better use of memory
such as filesystem caches ?
On many OSes, the -D and -H files will already be in memory, although
if we use those we need to indicate changes in format, perhaps by
passing the exim version number to the scanner.
We may wish to allow multiple scans to be done in parallel, to reduce
latency. If so might we need to ensure that scanners only have read
access to the spool files ?
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@??? http://www.dpmms.cam.ac.uk/~werdna
