[RFCI-Discuss] about FQDN for our smtp servers

[Alex van den Bogaerdt]

On Fri, Apr 14, 2006 at 12:17:04AM +0300, Yiorgos Adamopoulos wrote:

> And I think the list participants need to read
> 
> http://groups.google.gr/group/comp.mail.misc/browse_thread/thread/b2d5af8b081e9e3f/ff40113a821308a9?lnk=st&q=mark+crispin+ncp+smtp+helo&rnum=1&hl=el#ff40113a821308a9
> 
> to see (in Mark Crispin's words) why it was decided to have the HELO 
> verb the way it is.

In that thread (but not by Mark Crispin) the same mistake is made.

This time it's david skoll, but others make the same, crucial, mistake:

"Although the RFC's say that you shouldn't reject a connection based
on HELO/EHLO"...

The RFCs say no such thing.  The RFCs say it is not allowed to reject
based on you noticing the calling IP address does not match the
mentioned host name.  Somehow people refuse to parse the part of this
sentence starting with "based on" and further.

"cannot reject based on <x>" does not imply I cannot reject based on <y>.

RFC821 mentions rejecting when the HELO is unacceptable.
RFC1123 mentions rejecting when the HELO is unacceptable.
RFC2821 menttions rejecting when the EHLO is unacceptable.

I say this is pretty strong evidence that one can reject based on HELO...

The best description is found in rfc2821 (not yet a standard):

   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.

So, a system claiming to be "www.example.com" but clearly named
"mail.example.net" (according to DNS) is not to be rejected based
on this check.  Emphasis on "based on this check".

But also in 2821, just two paragraphs above:
   If the EHLO command is not acceptable to the SMTP server, 501, 500,
   or 502 failure replies MUST be returned as appropriate.  The SMTP
   server MUST stay in the same state after transmitting these replies
   that it was in before the EHLO was received.

The system calling itself "www.example.com" has the guts to be talking
to a machine under "example.com" management.  In this case, it is
perfectly OK, even from an RFC point of view, to reject the HELO:

   500 You are not www.example.com, goodbye.

With SPF, and possibly other experimental protocols, example.com can
announce to the world which servers are allowed to use a certain
HELO parameter.  This means not only example.com itself has reliable
knowledge, other hosts can also know if a host can or cannot use
"www.example.com" as helo parameter.