On Sat, Dec 21, 2019 at 10:28:50PM +0000, 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".
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>.
On the public Internet, a Postfix MTA that expects to deliver mail to
others will often have an explicitly configured name, an explicitly
configured domain suffix, or both.
So, if it's a host name, it has to resolve. So,
'shortname.localdomain' wouldn't be valid.
It is valid enough for private networks.
On Sat, Dec 21, 2019 at 05:50:45PM -0500, Keith Moore wrote:
I expect that there are a lot of MTAs advertising EHLO
raspberry.localdomain or debian.localdomain or some such.
That's fine, they generally relay via a smarthost, which won't care
about their EHLO name.
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.
Only in theory. In practice, you use an FQDN.
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.
In practice MTAs already record the IP address in Received headers (in a
comment after "from <heloname>"). So the IP-literal EHLO is largely
redundant, while the EHLO name caries useful additional information.
An EHLO tag based on a boilerplate hostname and
boilerplate suffix is essentially useless for that purpose.
Perhaps, in theory, but not in practice.
Seen in that light, the IETF operators' filtering policy is looking
less valid all the time.
Except for the part where it works well enough.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp