Loopcheck, noloopcheck Channel Options
The XLOOP SMTP extension for blocking message loops (
The SMTP server unconditionally includes the XLOOP extension and an identifying string in its EHLO response.
loopcheck channel option tells the SMTP client to make use of XLOOP if advertised by a "remote" server. An SMTP client can then check a hash (of the configuration file), to compare with that advertised by the SMTP server to which it is connected to see if it, too, is on the same system. If so, the SMTP client bounces the message, generating a notification message with a "SMTP client-server loop detected" reason and a "5.4.6 (SMTP client-server loop detected)" error status in the notification message. Note that this rejection is done by the SMTP client itself, immediately upon processing the SMTP server's EHLO response. Thus using
loopcheck causes certain sorts of looping messages to be immediately bounced, rather than looping until they become
In terms of logging of such cases if the
logging channel option is used, note that the SMTP server does not generate a "J" record rejecting the message, since the SMTP server did not in fact reject the message, but rather it was the SMTP client that decided to abort sending of the message. And the SMTP client's "R" record for the rejection of the message(s) does not show an SMTP error (such as the 5.4.6 error shown in the notification message itself) issued from the SMTP server; (the SMTP server did not in fact issue that error). The fact that it was a rejection due to
loopcheck is instead implicit in the fact that the host connected to was the same as the SMTP client host. This may be seen via the transport information in the "R" record, if bit 1 (value 2) of the
log_connection MTA option was enabled.
noloopcheckis the default.
See also the (new in 6.3)
IP_ACCESS mapping table, which provides an alternate way to block connecting to specified destination IP addresses (e.g., 127.0.0.1).