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 when querying for A records ? (would be interested to see how other software handle this)
Andew: Did you manage to find out why the behavior with '-h' option and both ' --h' and '-p' option was different ?
Best, Alex
(1) https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have- an-underscore-in-it
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@stroeder.com wrote:
Alexandre Rosenberg wrote:
Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP only accepting hostname as per best practice/RFC might be the most correct behavior.
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 at that point we might just remove the depreciated '-h' option altogether.
Agreed. 2.5 release chould IMO simply remove options -h and -p.
Ciao, Michael.