non_fqdn vs invalid helo hostname

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

non_fqdn vs invalid helo hostname

Markus E.
Hi!
I have a few questions regarding the HELO/EHLO checks.

According to the documentation:

reject_non_fqdn_helo_hostname

  Reject the request when the HELO or EHLO hostname is not in
  fully-qualified domain or address literal form, as required by the RFC.

reject_invalid_helo_hostname

  Reject the request when the HELO or EHLO hostname is malformed.


Is there a good reason to use both checks?
When is one rule triggered and not the other?
If I use both, what is the recommended order?


Thanks!

-me
Reply | Threaded
Open this post in threaded view
|

Re: non_fqdn vs invalid helo hostname

Bill Cole-3
On 24 Sep 2020, at 5:49, Markus E. wrote:

> Hi!
> I have a few questions regarding the HELO/EHLO checks.
>
> According to the documentation:
>
> reject_non_fqdn_helo_hostname
>
>  Reject the request when the HELO or EHLO hostname is not in
>  fully-qualified domain or address literal form, as required by the
> RFC.
>
> reject_invalid_helo_hostname
>
>  Reject the request when the HELO or EHLO hostname is malformed.
>
>
> Is there a good reason to use both checks?

What is your risk tolerance? Mine is high, so I use both.

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.

> 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.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Reply | Threaded
Open this post in threaded view
|

Re: non_fqdn vs invalid helo hostname

Markus E.
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