Re: (ITS#8618) ldapsearch - unexpected behavior with

[arekkusu@r42.ch]

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