[RFCI-Discuss] DSN listing of secureserver.net

[Alex van den Bogaerdt]

On Wed, Oct 25, 2006 at 05:43:10AM -0400, Alan Brown wrote:

>       <domain>".
> 
> [note the use of "DOMAIN" here and not "HOSTNAME"]

Sure.  But a hostname _is_ a domain.  One that has an A record
attached.

So: "HELO <domain>"

>          R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
>          S: HELO USC-ISIF.ARPA

a very quick google session resulted in rfc897:
[...]
       For example:  USC-ISIF.ARPA  or  USC-ISIA.DDN
 
         and:  Postel at USC-ISIF.ARPA  or  Kahn at USC-ISIA.DDN
 
         Here we expect that "USC-ISIF.ARPA" is the name of an Internet
         host and that we can send mail for "Postel" to the SMTP port on
         that host.  It may be that some backward host can still fake it
         by ignoring the ".ARPA" and looking up an address for
         "USC-ISIF".
[...]


So, I expect USC-ISIF.ARPA to have been a hostname.  Your point?


rfc 2821:
   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a valid principal host name (not a CNAME or MX
   name) for its host.  If this is not possible  [...]

Note: ...domain parameter...is a valid principle host name...

rfc 2821:
   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.

Note: ...domain name parameter...

rfc 2821:
   4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name
Note: ... identify the client...  (NOT the client's organization)
      ... fully-qualified domain name >>>OF THE CLIENT<<<.

So, about the parameter of EHLO:
a) it must be a hostname, unless one of the very refined exceptions
   applies in which case it may be a dotted quad surrounded by brackets.
   Domains that are not host names have no place here.

b) the part of 2821 that says you cannot reject based on "this reason"
   is talking about verification of incoming ip address against reported
   hostname.  However, it does not forbid rejecting messages based on
   other problems found in the HELO parameter.

   Unfortunately many people think to know better and say that this means
   you cannot reject period.


alex