Ehlo, checkehlo, noehlo, refuseehlo Channel Options

From MsgServerDocWiki

SMTP EHLO command (ehlo, checkehlo, noehlo, refuseehlo)

The SMTP protocol has been extended (RFC 1869) to allow for negotiation of additional commands. This is done via the new EHLO command, which replaces RFC 821's HELO command. Extended SMTP servers respond to EHLO by providing a list of the extensions they support. Unextended servers return an unknown command error and the client then sends the old HELO command instead.

This fallback strategy normally works well with both extended and unextended servers. Problems can arise, however, with servers that do not implement SMTP according to RFC 821. In particular, some incompliant servers are known to drop the connection on receipt of an unknown command. And in some cases use of facilities negotiated by EHLO will confuse a standards-incompliant proxy intermediary.

The MTA's SMTP client implements a strategy whereby it will attempt to reconnect and use HELO when any server drops the connection on receipt of an EHLO. However, this strategy still may not work if the remote server not only drops the connection but also goes into a problematic state upon receipt of EHLO.

The channel options ehlo, noehlo, and checkehlo are provided to deal with such situations. ehlo tells the MTA to use the EHLO command on all initial connection attempts. noehlo disables all use of the EHLO command. checkehlo tests the greeting banner returned by the remote SMTP server for the string "ESMTP". If this string is found EHLO is used; if not HELO is used. The default behavior is to use EHLO on all initial connection attempts, unless the banner line contains the string "fire away", in which case HELO is used; note that there is no option corresponding to this default behavior, which lies between the behaviors resulting from the ehlo and checkehlo options.

Finally, in the event of the MTA's SMTP server not working properly with a remote SMTP client due to the use of some SMTP extension that isn't understood by a broken intermediate proxy, the refuseehlo channel option can be used to simultaneously disable client use of EHLO and cause the SMTP server to refuse to accept EHLO, insisting on HELO instead. Note that this option should be used sparingly if at all: A far superior approach is to either fix or eliminate the incompliant intermediary.