On 12/21/19 5:28 PM, Paul Smith wrote:
There's always a hostname. It defaults to the return value of gethostname().
And if that contains no dots, and "mydomain" is not set, then the domain
defaults to "localdomain". So worst case you get "shortname.localdomain".
I expect that there are a lot of MTAs advertising EHLO
raspberry.localdomain or debian.localdomain or some such.
But RFC 5321 says:
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 <https://tools.ietf.org/html/rfc5321#section-4.1.3> and
discussed further in the EHLO discussion of
Section 4.1.4 <https://tools.ietf.org/html/rfc5321#section-4.1.4>.
So, if it's a host name, it has to resolve. So, 'shortname.localdomain'
wouldn't be valid.
The interesting thing to me is that if you don't have a valid DNS name,
an IP address literal seems like the right thing to use. Even if behind
a NAT at least it's some identifier that is associated with the sending
host that can go in a Received header, still potentially useful for
tracing if the server has logs showing the source IP address. An EHLO
tag based on a boilerplate hostname and boilerplate suffix is
essentially useless for that purpose.
Seen in that light, the IETF operators' filtering policy is looking less
valid all the time.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp