On Mon, 1 Nov 2004, Tore Anderson wrote:
> First off, I'd like to be able to process the whole message inside the
> embedded Perl functions. I'm happy with it being some read-only
> variable or file handle (or even an intrinsic Exim variable that can
> be passed along as a parameter), just so that I can actually do spam
> filtering and return a string fit for headers_add or something.
This is not entirely straightforward because the body of the message is
in a file, whereas the headers are in main memory. They are, of course,
already available in $message_headers. If you want to hack, you can of
course just read the body file from the spool.
> Secondly, I'd like to have a "perl" transport.
> and the deliver_localstore() function got $local_part and
> $message_size as $_[0] and $_[1] and was then responsible for updating
> the quota counter, saving the message (found in <MESSAGE> or wherever,
> according to wish #1) to disk somewhere, fsync'ing, and return 0 if
> everything went fine.
There are a lot more parameters than $local_part and $message_size if
one wants to be general. There is $domain for a start, and all the
envelope information.
> I wonder how hard it would be to implement something like this? :)
I'm not sure how hard it would be, but I am sure that it is something
that is very, very special-purpose.
There is a WishList item that calls for a string expansion to be obeyed
on transport success. If that existed, you could use a transport that
does nothing (e.g. appendfile => /dev/null) and use the "on success"
expansion, provided that your previous wish (above) is done.
I have noted these ideas on the Wish List.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
