[CLUE-Tech] Sending mail using an IP address?

[Jed S. Baer]

On Tue, 19 Mar 2002 16:55:27 -0700 (MST)
Jim Ockers <ockers at ockers.net> wrote:

'Elo, Jim.

> > Speaking from total ignorance of the relevant RFCs, I can only assert
> > that a dotted-quad shouldn't require a walk down the DNS lane, or up
> > it's tree, as the case might be. I mean, traceroute happily notices
> > that I've given it an IP address, instead of a server name, and scoots
> > right along. We'd be in a world of hurt, wouldn't we, if we couldn't
> > tell whether 207.217.96.29 was an IP address or a domain name?
> 
> This is easy for you to say.  There is no guarantee that this will
> always be the case.  Consider the following IP address:
> 
> CF.D9.60.1D
> 
> That is the same IP address as you give in your example, but using
> hexadecimal numbers.  I've seen it done and in fact many kernel data
> structures etc. represent the IP address in hexadecimal.

Well, I did say I was speaking from total ignorance. ;-) Like the plumber
I once worked for used to say: The less you know about something, the
easier it looks.

FWIW, I've seen only decimal dotted quads. Whenever I've seen a hex IPA,
it's always been a string, like 1D60D9CF - I actually don't remember, but
once knew, whether it was reversed or not. Mostly, I've seen this a few
times from spammers: make money fast - http://CFD9601D/

> There is no ruleset that you could make that would make sense and would
> work all the time for software to recognize an IP address and be able
> to always distinguish it from a domain name.  Just because you are used
> to things being a certain way right now doesn't mean they are always
> going to stay this way.  For instance, "1d" is not a valid top-level
> domain right now but it could become one in the future.  (There is no
> technical reason why it could not be a top-level domain, you see.)

Well, I think it would be foolish for ICANN, or whoever is in power for
such rulings, to allow a tld which could be confused with a hex, decimal,
or octal number notation. But then I've already admitted to a limited
perception. Still, knowing whether what you've got is an address, or a
name feels like it has value. A "black box" observation of the behaviour
of the host command, and other things, leads the casual IP poker to
conclude that any dotted quad which represents 0-255.0-255.0-255.0-255 is
an address, either in decimal or hex. (Yes, I'm ignoring the finer
syntactic points of IP address ranges. 127?)

> Furthermore, in your example "29" would need to be the top-level domain.
> Again, there is no technical reason why "29" could not be a top-level
> domain (that I know of, anyway).  Who is to say that it might not become
> a TLD in the future?

Dunno, except that I hope it doesn't happen. Not knowing whether you need
to perform a DNS lookup on it? 99.999% of the time, it isn't a concern.
Whether it's RFC compliant or not, but both Netscape and Galeon go to the
right places when I type an IP address in the location bar. If that could
be a hostname instead, how do we know whether to use it as one or the
other?

> The mail software is designed for maximum compatibility with the
> standards in use now and perhaps the standards that might be in use
> in the future.  (As well as fault tolerance.)  This means a compromise 
> and perhaps some lowest-common-denominator functionality, which seems 
> to be the core of your argument.

I'm uncertain my argument has a core, except that if I know that
postmaster, or root, or jillbob is at a particular machine, I should be
able to choose to forgoe the convenience of using the MX record, and just
mail them there. Understanding that the receiving MTA might bounce me
anyway for not using proper channels, or for some other reason.

> Also, traceroute takes an IP address or a hostname-that-resolves-to-an-
> IP-address as an argument, and it has only one main function.  E-mail is
> vastly more complex an application.

Only some e-mail is vastly more complex. It's easy to envision an e-mail
system which simply sends mail to a host, without worrying about the MX
record. Also, even if the MTA queries DNS first, it still winds up being
sent to a specific host. In that sense, it's no different from traceroute,
as both need to get a host IP address to work with. The fact that a dns
record identifies a specific mail exchanger doesn't change that.

> > However, to have internet e-mail wholly reliant on DNS seems a poor
> > decision as well, since DNS problems are possible. As Charlie and
> > Kevin
> 
> Actually most DNS problems are due to mis-configured DNS zones (or
> incom- petent DNS or network administrators).  The DNS is actually a
> major Internet success story in terms of scalability, fault
> tolerance/reliability, and functionality.  In general the DNS works
> really well.
...
> Hopefully they will eventually notice if they broke their DNS. 

Oh, certainly, until it doesn't, which is what I'm trying to work around
(and the hostmasters have finally fixed - for which I'm certainly
grateful).

> > I don't really understand the MX records in inverse zones thing, and
> > I'm not at the point of wanting too. But then, I'm still stuck on the
> > notion of being able to use the actual mailserver name or IPA, when
> > necessary, so I wouldn't want to use a DNS lookup for an MX record in
> > that case.
> 
> I bet you did a DNS lookup to get the IP address of the host that is
> supposed to handle the mail?  Unless you already knew it for some
> reason.

Well, sure. From the command line, I can point the MX query at the
nameserver I got from the whois record. But when sending an e-mail over
that way, I need to stop the MTA from trying to do it, and failing on that
account, thus nullifying the usage of the address I've discovered.

I suppose it's a whole 'nother topic, but does IPv6 get around the
question of recognizing whether something is a  name or an address?

Cheers,
jed
-- 
"Those who expect to reap the blessings of freedom must, like men,
 undergo the fatigue of supporting it."
 - Thomas Paine