Domain failure MTA option

Domain lookup failures
The  MTA option specifies what rewriting to apply when a rewrite rule   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  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    (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 (4yz  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 ,   ,  , etc.,  accept the message but divert it to the reprocess channel, so that the user&#x27;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&#x27;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&#x27;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&#x27;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   and    rewrite rule control sequences are used here to do a preliminary check whether the   or any "internal" channels are doing the rewriting (attempting to enqueue). Then the   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   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, 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  " "  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  or an "internal" channel (in particular, if a channel such as ,  , or  )  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,  , or  ),  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  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   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&#x27;s own users.

See also:
 * Source channel-specific rewrites
 * Channel match force truncation rewrite
 * Direct LDAP domain lookup MTA options
 * Process and reprocess channels