[Mimedefang] Non-routable addresses in HELO

[Jan-Pieter Cornet]

On Mon, Jul 10, 2006 at 10:26:40AM -0700, John Rudd wrote:
> If you're going to be a stickler about what the RFC says, in what you 
> require about the sender, then it's probably a good idea to be a 
> stickler about the RFC in how your server operates as well.  
> Specifically, you may not refuse the message based upon the HELO 
> argument.

No, that is not correct. This points comes up repeatedly, and proponents
of the "you cannot reject based on HELO name" usually quote this
paragraph from RFC 2821, section 4.1.4 Order of Commands:

   An SMTP server MAY verify that the domain name parameter in the EHLO
   command actually corresponds to the IP address of the client.
   However, the server MUST NOT refuse to accept a message for this
   reason if the verification fails: the information about verification
   failure is for logging and tracing only.

However, this explicitly says that you MUST NOT reject because of an
IP address mismatch, when the incoming IP connection has another IP
address as the hostname given as the EHLO argument.

However, this says nothing about rejecting based on other criteria,
for example, malformedness of the argument. Both RFC 2821 (defining
EHLO) and RFC 821 (defining HELO) are quite strict about what that
argument should look like. To quote RFC 2821 again:

   -  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.

(look up section 4.1.1.1 yourself if you must, it describes address
literals like [194.109.21.6], or [IPv6:2001:888:0:1::666]).

So, based on this latter paragraph, it is entirely OK to reject
after "EHLO 127.0.0.1", since that is not a properly formatted EHLO
argument. RFC821 has similar restrictions on the HELO argument,
which should be a "domain" (no IP allowed).

But while on the subject of RFC strictness... the RFCs are lagging
behind a little bit. According to the RFC, you MUST reject the HELO
or EHLO argument with a 501 error if the argument is invalid.

In practice, however, any reject reason is often delayed until
the RCPT command, to allow specific users (like postmaster) to
override certain checks. This usually also results in better error
messages to users. This practice is not allowed by the RFCs, but
is generally consired the better thing to do.

Also note that I'm not aware of any SMTP server implementation that
actually enforces syntactic checks on the HELO or EHLO argument out
of the box (resulting in lots of clients sending utter crap). Also
note that blocking based on EHLO will produce some false positives:
there are legitimate mail servers out there that EHLO as, eg.
"lan.local" or something silly.

-- 
Jan-Pieter Cornet <johnpc at xs4all.nl>
!! Disc lamer: The addressee of this email is not the intended recipient. !!
!! This is only a test of the echelon and data retention systems. Please  !!
!! archive this message indefinitely to allow verification of the logs.   !!