Re: Message Routing Philosophy

>James Craig Burley <[email protected]> writes:
>> So, at the dmail "layer", all connections are direct, and you could
>> say that "dmail messages go from one server to another with a very
>> concrete idea of where they came from and where they are headed".
>> 
>> But what are these dmail messages composed of, at the lower layers
>> doing the actual transport?
>> 
>> They're composed of *packets*.
>
>This is exactly the point, isn't it?  The Internet provides a way to
>route information from any part of the net to any other part[...]

That's exactly the point *indeed*: the OP was pining for an email
system that had messages somehow "concretely knowing" where they were
going and how to get there.

Such a system *cannot* be built on today's Internet, because, though
you say "the Internet provides a way to route information", that way
does *not* involve any "concrete" routing at all.

If you decide to drive from NYC to LA, you are likely to consult a
map, figure out the best route, and take that, using detours as
necessary.  Naturally, people tend to assume packets on the Internet
work the same way: before they're sent out, some sort of map is
consulted, an optimal route chosen, and that route is somehow
transmitted along with the packet's contents.

But that is exactly how the Internet does *not* work.  It's much more
like starting in NYC, driving to every house in the neighborhood
asking "am I at 100 Maple Lane in LA?" until someone says "I know how
you can get there, just drive east on this road right here for a few
miles".

Then, after you drive that few miles, you stop and drive to every house
in *that* neighborhood asking the same question.

Repeat until you reach your destination.

So, the *packet* has no concept of where it's going or how it's going
to get there.  (An IP address is *not* a destination; it's merely an
address that could denote a network interface in the same neighborhood
or on the other side of the world.  There's basically nothing about it
that inherently says "this is on the other side of the world" to a
packet.)

And the system *forming* the packet has no concept of where it's going
or how it's going to get there.

All that system and that packet "know" is that, hopefully, somehow,
the packet will be copied over and over again, from local network to
local network, across routers, switches, and carrier pigeons, until
someone claims responsibility for it.

To say this means "the Internet provides a way to route information"
misses the point in the context of what the OP wanted: a concrete way
for email messages to get from point A to point B, without bouncing
from server to server in the meantime.

After all, the *packets* will bounce from server to server to get to
the destination.

It's therefore a case of wishing away reality to insist that, somehow
email messages *themselves* won't do that.

>and so it's a mistake to re-engineer that capability into the
>protocol layer above.  AIUI it's in email because it was originally
>designed around a UUCP-based network in which most connections are
>intermittent.

How exactly a) is it a mistake and b) do you propose to *avoid* that
capability in the protocol layer above?

Compare email to file transfer, web hosting, instant messagings,
anything else built on TCP/IP.  Don't they *all* include mechanisms
for having requests "hop" from server to server?  I'm not sure about
IM offhand, but aren't there ftp and http port redirectors that handle
(virtual) connections by relaying them, essentially, to other hosts?

So, what exactly are you proposing: that MTA administrators be
forbidden to run gateways for internal LANs?  That they must run their
email servers on the exact same machines that the packets containing
incoming email would arrive on, instead of forwarding those packets to
other machines?

>I wish that the IM2000 mailing list were publically archived
>somewhere; I'd be very interested to know what's come out of that
>discussion.

I'm pretty sure it is, though I remember having trouble finding it in
the first place.

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>
--Fix qmail's qmail-smtpd so it doesn't crash on a big header line:--
		   <http://www.qmail.org/netqmail/>