Exim already has a "fallback on defer" feature through the use of
the "fallback_hosts" list.
The patch below adds 4 lines to exim to enable "fallback on fail"
as well, under control of the configuration file. It has no impact
on existing installations.
It would be nice if this patch (or a variation) was included in exim.
I believe that RFC 2821 allows this feature, as discussed below.
4.2.1 Reply Code Severities and Theory
4yz Transient Negative Completion reply
<snip>
A rule of thumb to determine
whether a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)
Thus a 5yz reply does not imply that the commands will fail if repeated
to a receiver with new properties. 5yz is "permanent" only with respect
to a specific receiver implementation. The "fallback on fail" feature
should only be used when there are reasons for the fallback host to have
an implementation that should accept the mail.
5yz Permanent Negative Completion reply
<snip>
The SMTP client is discouraged from repeating the exact
request (in the same sequence).
In light of the above, the expression "the exact request (in the same
sequence)" also implies that the properties of the sender or receiver
have not changed. If the receiver is changed, retrying isn't discouraged.
The RFC then applies the reply code theory to one specific case,
confirming the previous interpretation:
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
<snip>
When an SMTP server returns a permanent error status (5yz) code after
the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
any subsequent attempt to deliver the message. As with temporary
error status codes, the SMTP client retains responsibility for the
message, but SHOULD not again attempt delivery to the same server
without user review and intervention of the message.
Here we see that retrying to another server is explicitly permitted
after 5yz (presumably only if the properties of the new receiver are
different, as per the theory above), as it is after 4yz. Exim already
checks that the fallback server differs from the original one, meeting
the requirement.
This feature would be useful to fallback on a smarthost when the original
message is blocked (e.g. due to blacklisting of the client).
Something like that has been requested several times on the list.
--- deliver.c.orig 2003-12-01 05:15:42.000000000 -0500
+++ deliver.c 2004-03-07 12:46:08.000000000 -0500
@@ -2860,11 +2860,15 @@ while (addr != NULL)
processing the main hosts and there are fallback hosts available, put the
address on the list for fallback delivery. */
- if (addr->transport_return == DEFER &&
- addr->fallback_hosts != NULL &&
+ if (addr->fallback_hosts != NULL &&
+ (addr->transport_return == DEFER ||
+ (addr->transport_return == FAIL &&
+ !Ustrcmp(addr->fallback_hosts->name, "+FAIL") &&
+ (addr->fallback_hosts = addr->fallback_hosts->next))) &&
!fallback &&
msg == NULL)
{
+ addr->transport_return = DEFER;
addr->host_list = addr->fallback_hosts;
addr->next = addr_fallback;
addr_fallback = addr;
It's a bit of a hack because it fallbacks on FAIL only if the list of hosts
starts with "+FAIL" (to differentiate from fallback only on DEFER).
It would be cleaner to have a fallback_on_fail configuration variable.
Pierre
