Author: Tore Anderson Date: To: exim-users Subject: Re: [exim] More embedded Perl functionality
* Philip Hazel
> 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.
Well, I won't complain if I have to concatinate the headers and the
body manually from Exim::expand_string('$message_headers') and <BODY>
or whatever; that's not difficult.
> If you want to hack, you can of course just read the body file from
> the spool.
I see. Reading the file from the spool would wor, but I think it's a
tad difficult to know what the name is of the body file (considering
split_spool_directory)? If so a $message_body_spoolfilename variable
or something would be welcome, and would pretty much alleviate my needs
for <BODY>, $message_body_full, or whatever.
By the way, how evil is it exactly to actually /modify/ the body file
in the spool in this way? :) Will it work just fine, except for the
$message_size problem? (Just curious, I do not intend to.)
> 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.
Of course, I did not mean to suggest you hard code those arguments,
they were merely examples. The function should accept whatever
arguments I want it to, and it should be possible to pass in whatever
arguments I want. Just as with ${perl {foo}{$bar}{whatever}} today.
> 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.
Yes, something like that could work, too. However, that expansion
would have to be able to override the transport's success, so that I
can defer, fail, or accept a message from there.
> I have noted these ideas on the Wish List.
