Domain_failure MTA option

From MsgServerDocWiki

Domain lookup failures (domain_failure)

The domain_failure MTA option specifies what rewriting to apply when a rewrite rule $V LDAP lookup encounters an LDAP error. The default is

reprocess-daemon$Mtcp_local$1M$1~-error$4000000?Temporary lookup failure

This means that if the rewrite rule $V LDAP lookup encounters a (presumably temporary) LDAP error such as the LDAP server failing to allow connections, or an LDAP query timing out without a response, then the MTA will either: (a) for attempted submissions via tcp_local (attempted submisssions from the Internet) or from channels "internal" to the MTA (such as reprocess or conversion channels), reject the submission attempt with a temporary error (400 error) so that the message remains where it was (on the external, Internet host, or on the internal channel) which can re-attempt submisssion later, or (b) for all other messages (in particular, messages submitted by "internal" user e-mail clients or "internal" hosts via channels such as tcp_intranet, tcp_auth, tcp_submit, etc., accept the message but divert it to the reprocess channel, so that the user's message submission is completed, leaving it up to the MTA (via the reprocess channel) to later go to the work of re-trying the LDAP lookup. In case (a), for attempted submissions from the Internet, one typically does not want to accept a message that one cannot process at the moment (and for which, in particular, one cannot even validate that the domain is one one wants to accept). Accepting such messages merely clutters one's own queues which at best cannot be processed immediately, and which at worst may need to be rejected (once domain validiation can be performed) as invalid domains. Instead, sites usually prefer to refuse such messages with a temporary rejection (so that the remote host knows to continue with additional submission attempts later). And in case (a), for attempted submissions from "internal" channels, the messages might as well stay in their current "internal" channel and await additional lookup attempts from there. In contrast, in case (b), for attempted submissions from one's own, "internal" user e-mail clients, user e-mail clients cannot usually handle making an automated resubmission attempt "later". So it is friendlier to one's own users to go ahead and accept the messages, even if the messages will end up needing to be rejected later.

In more detail, the $M and $1M rewrite rule control sequences are used here to do a preliminary check whether the tcp_local or any "internal" channels are doing the rewriting (attempting to enqueue). Then the $1~ rewrite rule control sequence is used to override that initial channel match success or failure with a forced success, while truncating the rewrite rule at this point if the initial channel match failed.

So the effect is that when the tcp_local or an "internal" channel is attempting to enqueue, a rewrite rule template of the form

$U%$H@reprocess-daemon-error$4000000?Temporary lookup failure
  is used.  Because (normally) there is no channel with official host name reprocess-daemon-error, this rewrite rule template has the effect of forcing a channel match failure, so the  $? rewrite rule control sequence comes into play, specifying that a "400 Temporary lookup failure" error be returned for the address.  The MTA does not enqueue the message; the message remains where it was (and the remote host or internal channel can re-attempt submission later). 

But if any channel other than tcp_local or an "internal" channel (in particular, if a channel such as tcp_intranet, tcp_auth, or tcp_submit) is attempting to enqueue, a rewrite rule template of the form

$U%$H@reprocess-daemon
  is used.  Thus in this case (messages being submitted from channels such as tcp_intranet, tcp_auth, or tcp_submit), the rewrite rule succeeds in directing the message to the reprocess channel; the MTA accepts the message and routes it to the reprocess channel for further processing (in particular, for further attempts to do the domain lookup in LDAP).  The reprocess channel will then continue to try to process the message (in particular, reattempt the rewrite rule $V LDAP lookup) until either the LDAP lookup is completed and then the message can be processed further, or the message eventually times out (time out as controlled by the  final value of the notices channel option applying to the reprocess channel) causing the message to be returned to the original sender.  Accepting the message onto the MTA, for the MTA to later re-try the domain lookup typically makes sense in the case of messages submitted from one's own users. 

See also: MTA options, Option value syntax, Getting option changes to take effect, MTA options, listed alphabetically, MTA options, listed by functional groups, Direct LDAP domain lookup options, Rewrite rule $V LDAP lookup, Reprocess channel, Rewrite rule source channel-specific templates ($M, $N, $1M, $1N), Rewrite rule error templates ($?), Rewrite rule truncation template ($1~).