Saying and checking HELO

How to get Exim to say HELO properly for both call outs and smtp
transport with multiple interfaces and also check HELO.

RFC 2821 3.6 Domains requires:

- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.

Put simply by Jon Postel:

3.5. OPENING AND CLOSING

At the time the transmission channel is opened there is an
exchange to ensure that the hosts are communicating with the hosts
they think they are.

The following two commands are used in transmission channel
opening and closing:

HELO <SP> <domain> <CRLF>

QUIT <CRLF>

In the HELO command the host sending the command identifies
itself; the command may be interpreted as saying "Hello, I am
<domain>".

I get loads of email with email with bogus HELO and IPs that are not
in the DNS with envelope senders that do not exist. Though a lot of
this is spam a lot comes from boxes with multiple interfaces and MTAs
that do not know which interface they are using. Exim4, however does
know and can be made to HELO with its own name. A very handy feature.

When its spam I have to resort to WHOIS lookups which I do by hand.
It is much simpler to whack them if they use bogus HELO.

smtp_active_hostname = ${if eq{$interface_address}{}\
{$primary_hostname}{${lookup dnsdb{>: \
PTR=$interface_address}{$value}{[$interface_address]}}}}

You should only have one PTR for interface IPs otherwise this would say:
HELO cname.example.com:alias.example.com

These of course must have matching A RRs as required by RFC 2821
section 3.6.

Exim also handles spoofed HELOs, but this requires expensive reverse
DNS lookups (which require both PTR and matching A RRs to avoid being
spoofed). These could avoided if they could be deferred to after HELO
failure, but such ACLs were very complicated and hard to maintain.

I now do the expensive reverse look up in my acl_smtp_connect any way
and use a short challenge delay to guard against spamware PIPELINING.
(Tony Finch described this at Cambridge in a paper.)

To guard DEFER exploits (as wish list option defer_no or defer_never
is not in Exim) I only do the verify reverse_host_lookup in a warn and
then test string $sender_host_name later.

In my acl_smtp_connect I have a short challenge delay:

:

# Only use warn to guard against DNS RCODE 2 DEFER exploit
warn verify = reverse_host_lookup
set ACL_DELAY = 0

# Turn challenge delay on - Protected against DEFER exploit
warn condition = ${if eq{$sender_host_name}{}{yes}{no}}
set ACL_DELAY = LUSER

:

In my acl_smtp_helo I cancel the challenge delay if HELO okay:

:

# Turn challenge delay off if they say HELO
accept verify = helo
set ACL_DELAY = ${if <{$ACL_DELAY}{TEERGRUBE}{0}{TEERGRUBE}}

:

# Protected against DEFER exploit - Challenge delay off if accepted
accept condition = ${if eq{$sender_host_name}{}{no}{yes}}

: