On 8/04/2023 10:31 am, raf via Postfix-users wrote:
On Thu, Apr 06, 2023 at 11:28:07AM +1000, Sean Gallagher <s...@teletech.com.au>
wrote:
On 6/04/2023 10:39 am, raf via Postfix-users wrote:
On Thu, Apr 06, 2023 at 07:33:28AM +0800, Corey Hickman via Postfix-users
<postfix-users@postfix.org> wrote:
Hello
for these two statements,
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
what are the differences between them? does the second one hold the first
one already?
Thanks.
reject_invalid_helo_hostname rejects malformed HELO or
EHLO hostnames.
reject_non_fqdn_helo_hostname rejects non
fully-qualified domain (or address) HELO or EHLO
hostnames.
I would assume that the second one subsumes the first,
since a malformed hostname can't be a fully-qualified
domain name.
cheers,
raf
From reading the code, these two restrictions seem equivalent except when
SMTPUTF8 extension is used.
when the SMTPUTF8 is in play, reject_non_fqdn_helo_hostname will convert a
hostname containing UTF to an internationalized domain name
before checking. https://en.wikipedia.org/wiki/Internationalized_domain_name
So reject_invalid_helo_hostname will reject hostnames that contain UTF8 but
are otherwise valid.
It seems likely that reject_non_fqdn_helo_hostname was added to postfix to
replace reject_invalid_helo_hostname when emails containing UTF8 became a
thing.
Intuitively, you might think that reject_non_fqdn_helo_hostname is MORE
restrictive than reject_invalid_helo_hostname,
but in fact reject_non_fqdn_helo_hostname is LESS restrictive than
reject_invalid_helo_hostname.
At least, this is my understanding from reading the code. I may be wrong..
Sean.
Hi Sean,
I based my comments only on the documentation, not the code.
But looking at the code, they both check that the hostname
is valid, but reject_non_fqdn_hostname() also checks that
there is a '.' character in the hostname (strchr(test_name, '.')).
That's the additional fqdn check.
But you are right that reject_invalid_hostname() calls
valid_hostname() while reject_non_fqdn_hostname() calls
valid_utf8_hostname(). I wonder if that is correct, or
if they should both be calling valid_utf8_hostname().
It's probably correct and probably more efficient the
way it is.
I think the outcome of the discussion in this thread was that
valid_utf8_hostname() really has no "official" use case. It allows RAW
UTF8 in hostnames - which should never happen. Hostnames that contain
Unicode (non ASCII) code-points should be encoded with punycode with the
ACE prefix. Any name encoded this way should pass the valid_hostname()
check.
In summary, all "normal" systems should be using
"reject_invalid_helo_hostname" and leave "reject_non_fqdn_helo_hostname"
to isolated systems whose names never appear on the internet.
The latter is LESS restrictive, in that it allows illegally encoded
domain names containing raw UTF8 encoded unicode code points. i.e. names
containing "U-labels" as defined in RFC5890 2.3.2.1.
The latter is MORE restrictive, in that it does NOT allow names without
any dots.
Few people would be concerned with the "must contain a dot" restriction
and should therefore consider "reject_non_fqdn_helo_hostname" as less
restrictive than "reject_invalid_helo_hostname" in a way that is not
generally useful. That said, it is not is any way dangerous to use the
"reject_non_fqdn_helo_hostname" restriction - unless downstream mail
handling software contains bugs that may lead to a crash if it was given
a non-standard domain name.
There does not seem to be any checks in Postfix that can decode random
IDNA names and verify that they are well formed. Specific names can be
checked for by using names containing "A-labels" as defined in RFC5890
2.3.2.1, i.e. punycode, as you would any other name in the various
Postfix maps.
After going through this, my advice would be to always use
"reject_invalid_helo_hostname" unless you really think you need the
extra flexibility of "reject_non_fqdn_helo_hostname". Or if at some
stage, a better test is added to Postfix that can "look inside"
internationalized domain names and reject invalid names as defined by
RFC5892.
Hope this clears things up. I agree that the documentation on this is
somewhat lacking.
Sean
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
