At 20:43 -0500 14/7/02, Derrick 'dman' Hudson wrote:
>o Treat the local_scan the same way other (dynamic) libraries, such
> as libldap or libpg, are treated. Let the system's dynamic linker
> deal with loading the local scan library at runtime.
>
> Cons:
> o only allows a single liblocal_scan to be installed at any
> time (AFAIK)
One simple way to deal with this is simply to allow a small but not 1
number of these, ie:
liblocal_scan1
liblocal_scan2
liblocal_scan3
liblocal_scan4
It could even be a make option as to how many you want with a
reasonable default of 2-4.
It adds a little user complexity in installing them, but a tool to
"install" a local_scan which copies it in to a spare "slot" and
remembers the names of the items installed in each slot for easy
removal/overwrite would be pretty trivial.
>o Create an interface that leverages existing IPC mechanisms such as
> pipes, UNIX Domain Sockets (these are the same as fifos and named
> pipes, right?), or TCP sockets to communicate with a scanner. The
> scanner would be a separate, complete, application.
> Cons:
> o Requires creating a new protocol.
> (or beating an existing one (maybe LMTP or BSMTP) into a
> shape suitable for this use)
> o Could be complex.
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
> Comments:
> o The complexity of creating and implementing a new protocol
> can be minimized by devising a sufficiently simple
> protocol.
> o If this mechanism is chosen, then additional discussion on
> the merits of each IPC mechanism and protocol choices will
> need to follow.
The protocol could be simple enough, just dump down tagged data, but
handling that for the local_scan author would be a pain. Plus what
are you going to do with the actual message data - send that whole
lot down through the pipe and back again?
> 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.
You'd also need to send the extra data like recipients and senders
and protocol and authentication and such. The local_scan author
would potentially have to parse the headers, and then figure out a
way to support debugging and logging and such. Plus it would be
rather a large extra amount of processing power, especially for large
messages.
>o Use libdl (dlopen, dlsym) to load an admin-specified .so.
>
> Pros:
> o doesn't require a lot of code
> o an initial implementation is already available
> o the scanner API is almost identical to the current one
> o no new protocols need to be devised
>
> Cons:
> o C is (very apparently) not well suited for dynamic programs
> o the libdl API doesn't provide any type checking the way
> the C compiler does (or the way python does for "dynamic"
> modules)
> o This makes it easy for an admin to shoot a 3-sided hole in
> exim. If a bad .so is specified (accidentally or
> maliciously), exim _could_ have a hard time handling it
> gracefully. It will more than likely crash if the ABI
> checking doesn't catch the mismatch.
Agreed, although the simplicity of this approach would seem to make
it the best solution (or alternatively the approach of just using a
fixed number of local_scans, which would have the advantage of
working without dynamic loading on systems that might not support
this).
Enjoy,
Peter.
--
<
http://www.interarchy.com/> <
http://download.interarchy.com/>
