On Tue, 22 Jan 2002, Kevin P. Fleming wrote:
> > From within the C function that is local_scan(), you can call the Perl
> > interpreter yourself, without having to use the ${perl construct. Take a
> > look at the perl.c module in Exim. It is not very long. (But don't ask
> > me about it - I was sent it by a Perl expert.)
>
> I've looked at it... the perl interpreter instance that it creates is not
> accessible from the local_scan() function, at least not without some other
> modifications to Exim. I'll look at that again.
Sorry, I wasn't clear. What I was thinking was that you could put
identical code in your local_scan() function, *instead* of using the
code in perl.c, and thereby get yourself a Perl interpreter you can call
in any way you like, without having to use Exim's ${perl construct.
> True, I could certainly make my local_scan() function (module, really)
> create its own perl interpreter instance, but that will be far less
> efficient than using the one that already exists.
I was thinking that there was no need for the other one to exist at all.
> I assume (only because I haven't tested it) that if an Exim process is
> started to receive a message via standard input (instead of via an SMTP
> dialog) that it would exit with an error code if the local_scan() function
> returned an appropriate error.
It is handled like any other error while receiving a non-SMTP message,
depending on the -oe... option (the choice is either to exit with an
error code, or to send a message to the sender).
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.