Ну вот, из 4 издания O'Reilly Sendmail7.6.2 FEATURE(block_bad_helo)—V8.14 and Later
The HELO and EHLO client SMTP commands are eachformed by a command followed
by a hostname:
HELO client.host.domain
EHLO client.host.domain
According to RFC2821, the hostname provided by the client (following the HELO or
EHLO SMTP) must be:
• The canonical hostname of the sending client machine. That is, a host with a
domain part. For example, the name “foo” is bad because it lacks a domain. The
name “.com” is bad because it lacks a host part. But the name “foo.com” is
canonical and valid.
• The name of the sending client. That is, it must not be any of the names by
which the server knows itself, such as “localhost” or “127.0.0.1.”
Although RFC2821 requires that these characteristics be met by the client, it also
prohibits rejection based on bad values. If your site is besieged by spam, however,
the niceties of RFC2821 may not seem worth following. If you desire to reject badly
formed HELO/EHLO hostnames, you may do so by using this FEATURE(block_bad_helo):
FEATURE(`block_bad_helo´)
Note that, with this feature defined, certain clients are not checked at all:
• If the client has authenticated with AUTH, the HELO/EHLO host is not checked.
• If the client is listed with the RELAY_DOMAIN mc macro (§7.4.1.1 on page 269) or in
the file specified by the RELAY_DOMAIN_FILE mc macro (§7.4.1.2 on page 269), that
client’s HELO/EHLO hostname is not checked.
Otherwise, all other clients have the host part of the HELO/EHLO greeting checked:
• If the hostname exists as part of the server’s $=w class (§22.6.16 on page 876), the
HELO/EHLO command is rejected.
• If the hostname exists as an IP address in the server’s $=w class (§22.6.16 on page
876), the HELO/EHLO command is rejected.
• If the hostname has only an initial dot, a final dot, or no dot at all, the HELO/EHLO
command is rejected.
If the HELO/EHLO greeting is rejected, the client will receive a permanent rejection like
the following:
550 5.7.1 bogus HELO name used: client’s bogus hostname here
This FEATURE(block_bad_helo) is implemented as the last check in the check_rcpt rule
set (§7.1.3 on page 257).
Последнее преждложение наводит на мысль, что у вас в check_rcpt (через access возможно) где-то стоит разрешающее правило и оно срабатывает раньше block_bad_he
