On Tue, 2 Nov 2004, Tore Anderson wrote:
> 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)?
It is documented how split_spool_directory works. If the message id is
1COt4R-0004uY-JZ and your spool directory is /var/spool/exim, then the
body of the message is in the file
/var/spool/exim/input/R/1COt4R-0004uY-JZ-D
when split_spool directory is in use. Without split_spool_directory, get
rid of the /R in the middle.
> 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.)
The only updating you could do would be to update in place. That, of
course, is subject to causing a mess if it is interrupted without
completing (power loss, for example). Exim already has the file open
(and it uses it for locking), so you cannot update by writing a new file
and renaming.
> 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.
Maybe some kind of "null" transport. Needs thought.
--
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
