Re: [Exim] Exim 4 query: How about doing local_scan() in per…

> 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.

OK, I was thinking something more along the lines of using only one
interpreter for the entire Exim instance, in case someone wanted to use
${perl constructs to access data that had been previously stored (in memory)
by the local_scan() function. Certainly I could duplicate the entire set of
code to create a new interpreter instance and just use that one, but that's
too easy :-)

> > 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).

That's good news, it means that the local_scan() function can just do it's
normal thing, regardless of how Exim is receiving the message. I'll work on
this in the next few days and post some code up here for others to play
with/review/tear apart/etc.