----- Original Message -----
From: "Philip Hazel" <ph10@???>
To: "Kevin P. Fleming" <kevin@???>
Cc: <exim-users@???>
Sent: Tuesday, January 22, 2002 2:18 AM
Subject: Re: [Exim] Exim 4 query: How about doing local_scan() in perl?
> On Mon, 21 Jan 2002, Kevin P. Fleming wrote:
>
> > 1) implement a standard local_scan file that includes an embedded perl
> > interpreter, then use external perl scripts to do the work
> > 2) use Exim's built-in embedded perl interpreter, and extend its use to
> > allow a local_scan function to be called (in addition to using "${perl"
> > constructs in string expansions)
>
> 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.
>
> > - Would Philip be willing to accept patches (tested, of course :-) to
add
> > this functionality to Exim 4? I'm thinking this would be an additional
> > compile-time option, just like embedding perl is now. The local_scan
> > function would get passed some perl data structures (using
Mail::Internet
> > and other existing modules) that contain all the message information.
>
> I'm not sure this is necessary. The whole idea of making local_scan() a
> C function was that people could build interfaces from C to Perl or
> anything else, without me having to modify the base Exim source.
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.
>
> > - How often does Exim 4 exec() itself, instead of forking?
>
> Same as Exim 3, when it needs to regain privilege. Typically this is
> following the reception of a message, in order to start a delivery
> process.
OK, so that would only happen after the local_scan() function has already
been called. Cool.
>
> > Each time the
> > exec() is done, the perl interpreter gets recreated, reinitialized, and
more
> > importantly, loses any "state" information that was present in the
"master"
> > interpreter.
>
> Note that Exim processes can be started by an other local process in
> order to receive messages. They don't have to be forked off the daemon.
> Indeed, you don't even need to run a daemon.
True... but in each case, Exim will call the local_scan() function when it
is nearly finished "receiving" the message, however that may have occurred.
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.
>
> > With a fork(), the interpreter gets "copied", and still has
> > that state information. However, if Exim 4 only exec()'s itself at
points
> > _after_ which the local_scan() function could ever be called, this is a
> > non-issue.
>
> Exec will happen only after a message has been successfully received.
> But local messages aren't received via the daemon (though you may not
> care about local messages) and of course you get a new exec every time
> if you use inetd instead of a daemon.
In my case, actually I don't care about local messages, because there aren't
any "live" local users on my boxes. The messages created by daemon processes
(cron, inn, etc.) I'm not too concerned about scanning :-) And if someone
wants to use this technique when they're using Exim spawned from inetd,
they'd be asking for a very slow and resource hungry system (just image Exim
creating a perl interpreter every time an SMTP connection comes in... yuck).
