I was referring to best practice/RFC regarding what is a valid hostname.
My example was intentionally provocative. I think rejecting hostname containing
the '://' construct is actually a good idea. Those would be problematic for
parsing and such broken hostname are unlikely to ever be use.
Been reading a bit more (1) and I think internationalized domain are also not an
issue as they have a ASCII representation. So the only real concern I can think
of at this point is underscore. But I could be missing something...
I am still not convinced about having addition verification beside:
- What the DNS standard says (RFC2181)
- Prohibiting hostname that would cause cause an issue with parsing ('://')
Why do the 'host' and 'dig' command does not seem to place any restriction
querying for A records ? (would be interested to see how other software handle
Andew: Did you manage to find out why the behavior with '-h' option and both
--h' and '-p' option was different ?
PS: Andrew: In my client (evolution) your previous plain text email did show up
as base64 encoded. (had to use 'base64 -d' to read them). I did not remember
outlook making it so hard to send plain text email (!)
On Sat, 2018-03-03 at 10:29 +0000, michael(a)stroeder.com wrote:
Alexandre Rosenberg wrote:
> Micheal, you are *right* about the man page saying _hostname_. Indeed
> only accepting hostname as per best practice/RFC might be the most correct
There is no relevant RFC or best practice, only the man-page. And the -h
and -p arguments come from the old UMich LDAP times.
> However we can not change this behavior without breakable. consider:
AFAICS backward compability has only be provided to those ancient Umich
or Netscape Directory tools. So IMO LDAP URI does not have to be accepted.
> - Underscore are not that uncommon with Active Directory
> - What about
> - ... (probably more)
If you want to fix something for 2.4.x to match what the man-page says
you could effectively reject LDAP URI by simply rejecting colons and
slashes. Those chars are never in even seriously broken hostnames. If
they were they would cause more interop issues anyway.
> Therefore I believe such change could only be done in a major release. And
> that point we might just remove the depreciated '-h' option altogether.
Agreed. 2.5 release chould IMO simply remove options -h and -p.