Well, at the point in Exim 4 that local_scan() gets called, the message does
not exist as a single stream of text the way it was originally transmitted.
It's already been broken apart into the -H and -D files, and the
local_scan() function does not get a handle to the -H file, only the -D
file. Its gets pointers to structures containing the headers and recipients,
and this is good, because it means Exim doesn't have to reparse the message
text when local_scan() returns.
If you wanted to pass a complete raw text message to the scan function that
could be _modified_, it'd be better to just stick with the current way of
doing things (pipe it out, and then receive it back in as a new message).
----- Original Message -----
From: "Greg Ward" <gward@???>
To: <exim-users@???>
Sent: Monday, January 21, 2002 1:54 PM
Subject: Re: [Exim] Exim 4 query: How about doing local_scan() in perl?
> On 21 January 2002, Kevin P. Fleming said:
> > I'd like to use perl for these functions, but this leaves me with two
> > options:
> >
> > 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)
> >
> > Option 2 seems far more efficient to me, but there are couple of issues
I'd
> > like to get answers to before I proceed down this road:
> >
> > - 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.
>
> IMHO, it would be better to just pass the message to the Perl
> interpreter as text (or an open filehandle, or whatever), and let it
> parse the message itself. What if someone doesn't want to use the
> standard way of working with email messages? Some applications will
> care about the headers only, some will want headers+body -- let the
> external code make that choice. Yes, make the standard way easy, but
> don't force it on anyone.
>
> In a related note, has anyone whipped up the code to link in a *Python*
> interpreter via local_scan()? That's my current high-level language of
> choice...
>
> Greg
> --
> Greg Ward - software developer gward@???
> MEMS Exchange http://www.mems-exchange.org
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
>
>
>
>
