On Thu, 24 Sep 2020, Bill Cole wrote:
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
Is there a good reason to use both checks?
What is your risk tolerance? Mine is high, so I use both.
Sounds good to me as well :)
reject_invalid_helo_hostname is generally safe. I've never seen it hit a
generally legitimate sending system that was not fixed within a few hours,
and only a tiny handful of such transiently misconfigured ones in ~15 years.
reject_non_fqdn_helo_hostname is slightly less safe. It is entirely unusable
on a smtpd instance handling initial submission from personal machines, where
MUAs often do odd wrong things with HELO/EHLO. On a port 25 smtpd, I've had
to whitelist 3 misconfigured sources of desired mail using a bare hostname in
EHLO/HELO in ~15 years, but it has been some years since any of those were
still needed. I suspect that there has been enough environmental pressure to
largely eliminate the use of bare hostnames by anyone running a serious mail
system.
When is one rule triggered and not the other?
Invalid means that the name cannot be a hostname, i.e. it contains characters
other than strings of ASCII alphanumerics and hyphens, delimited by single
dots. The most common violation historically has been the use of underscores,
which are valid in DNS labels that are NOT hostnames.
Non-FQDN means a bare hostname without dots.
'HELO _foo_' hits both rules.
'HELO foo' only hits reject_non_fqdn_helo_hostname.
'HELO mail_foo.dom.ain' only hits reject_invalid_helo_hostname.
Thank you for taking time to explain the difference! Highly appreciated.
If I use both, what is the recommended order?
Not important. There's not really much overlap and they are computationally
cheap. Since reject_non_fqdn_helo_hostname hits more often, I suppose putting
it first makes sense.
OK, thanks again Bill!
-me
