There has been a suggestion for fallback transports such that if a
transport fails somehow, leading to a "defer" state, the message is
passed to a fallback transport. This would provide more features than
fallback_hosts, because any kind of transport could be used. (There are
some cases where this is wanted after some kinds of "fail", as well as
"defer".) There are a number of possibilities, but there is one small
snag to doing any of this, and I'd like people's views before investing
any time in it.
The snag is this: Exim does does all the local deliveries first,
retaining root privilege so that when it forks a process for each
local delivery, that process can call setuid() to become the appropriate
local user. However, once all the local deliveries are complete, Exim
calls setuid() to become the Exim user, before doing the remote
deliveries. Even with remote_max_parallel set, if there is only one
remote delivery, it does it without forking.
To support a general fallback_transport scheme, Exim would have to
retain root privilege while doing remote deliveries, in case any fallback
transport was a local one. So it would always have to fork for every
remote delivery, and change to the Exim user inside the forked process.
This would add a bit of overhead to those messages that have only one
recipient, or on systems where remote_max_parallel was set to 1.
Is this going to matter? I really don't know, which is why I'm asking
for opinions....
Incidentally, the same snag is the reason why the existing
shadow_transport mechanism is available only for local transports. It
could be extended if the change were made.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
