Re: lynx-dev Lynx support for 'one part' addresses

[Klaus Weide]

On Fri, 19 Mar 1999 address@hidden wrote:

> Lynx doesn't support these weird URL types...  I realize I only see them
> in spam, but I thought it would be good if they really worked.
> 
> 
> >What the heck is it with spams with things like:
> >For FREE debt consultation goto:
> >http://3516237521/768.htm
> >
> >They don't have a phone # or anything in them..  What is the point of these
> >fake URLs?  I see spam like this every once in a while.  [ ... ]
> 
> It's not fake.  From the inet_ntoa man page:
> 
> -----
> INTERNET ADDRESSES
>      Values specified using the `.'  notation  take  one  of  the
>      following forms:
> 
>           a.b.c.d
>           a.b.c
>           a.b
>           a
> [...]
> -----
> 
> It is, in effect, a "one-part" address.  If you stuff it into a long,
> do some shifts, and format it, it comes out as 209.149.134.209
> (cmpsource.com).

You have shown that this kind of address is well-defined for (your system's
implementation of) inet_ntoa().  That's a completely different question
from whether it is well-defined in an URL's host part.  The relevant specs
don't say anything about what it might mean (please prove me wrong), they
certainly don't say to feed such a string directly to inet_ntoa().

So in my view only (a) dotted-quad IP addresses and (b) Fully Qualified
Domain Names have a well-defined universal meaning; everything else is up
for speculation.  Lynx's decision to feed it to gethostbyname() and see
what the system (resolver library) makes of it seems the most reasonable.
On some systems 3516237521 may then be interpreted according to inet_ntoa(),
on others /etc/hosts may come into play or some other lookup service, on
yet others it is unresolvable.  But this way different applications on
the same systems can behave more uniformly.

> What they're counting on is that, while people will definitely know
> how to complain about "http://www.cmpsource.com/";, and might be able
> to figure out how to complain about "http://209.149.134.209/";, they
> won't go through the extra step needed to convert 3516237521 into
> something recognizeable.

Feeding the string directly to inet_ntoa() or similar without input
checking is arguably a bug, and those folks are then exploiting a bug.
Be glad that lynx isn't (unconditionally) subject to it, instead of
asking that lynx be always bugward-compatible. :)

 ----

If you have "3516237521", it doesn't take much to get to the
"209.149.134.209" form.  Try
   ping 3516237521
   traceroute 3516237521
   telnet 3516237521
They all give a line with the address in canonical form (for me, and
I expect practically on any Unix-like system).

(Is this inconsistent with what I claim above, about 3516237521 being
not well-defined?  No, theses Unix commands don't take URLs as arguments,
the rules can be different here.)


   Klaus