Re: Message Routing Philosophy

>On 1-feb-04, at 17:52, James Craig Burley wrote:
>
>> 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".
>
>[...]
>
>> (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.)
>
>I don't know where you learned TCP/IP, but the parts about the above 
>that I can even understand are mostly nonsense. A host creates IP 
>packets, puts in a destination address and then transmits them. In most 
>cases the packet will be delivered to the host indicated by the 
>destination address. There is a fair amout of routing involved here, 
>but that's not every interesting from an email perspective.

Apparently you either completely missed what I was saying (perhaps a
language barrier), or you don't know TCP/IP *at all*.

There is *no routing information whatsoever* in typical IP packets.
They contain little more than an IP address.  And they are typically
broadcast to a network segment without regard to the fact that most of
the network interfaces on that segment are connected to hosts that do
*not* care to see them.

(Otherwise, if packets were delivered *only* to the host indicated by
the destination address as you essentially claim, packet sniffing
would not be a security concern; it would be impossible.)

The routing information for IP packets is spread out, in highly
localized form, throughout the Internet.  Most hosts, routers, and
switches care little about routing beyond their own local "domain"
(not in the .com sense, in the general sense).  Packets themselves do
not generally contain routing information; nor do their originating
systems transmit such information out-of-band in conjunction with the
packets.

If you claim otherwise, I'd appreciate it if you'd educate me by
pointing me to the specifications that show that IP packets typically
contain detailed routing information that is "peeled off", hop by hop,
as they go from source to Ethernet LAN to gateway to local Broadband
LAN to Broadband high-speed switches through goodness-knows-what,
finally arriving at the destination.

(How my lowly Pentium II 233MHz w/128MB RAM manages to keep track of
routing information for the entire Internet is beyond me...yet it
manages to send emails all over the world all the time, with very
little effort!)

>> After all, the *packets* will bounce from server to server to get to
>> the destination.
>
>Since when is a router a server?

What's the relevance of your question?  The OP said he wanted NG email
to assure a concrete routing methodology for email.  It doesn't matter
that I used the term "server" in place of "router", in parallel form,
to underscore how impossible (or at least improbable) that was on
today's Internet.

>> It's therefore a case of wishing away reality to insist that, somehow
>> email messages *themselves* won't do that.
>
>If we mandate that all hosts involved with mailng must be prepared to 
>receive messages directly from other mailng hosts, there is no reason 
>why something like that can't be built. This has the advantage that 
>it's more efficient and "bad" messages can no longer be injected in 
>places where there badness can't be known or simply isn't known. (This 
>is the reason I no longer have any MX fallbacks: my server gets to talk 
>to everyone who wants to email me directly so I get to decide whether I 
>want to talk to them.)

*That* I agree with somewhat, but you're still missing the point:
there is no *concrete* route that even NG email will take to get from
one NG server to another, because the underlying Internet provides no
practical means to assure, from the outset, such a capability.

But, rather than arguing with me, or claiming that I'm clueless about
TCP/IP, why don't you answer the *questions* I asked in my previous
emails?

In particular, what is so wonderful about having a "concrete route"
worked out ahead of time for *all* (NG) email, so that it never has to
hop "from server to server"?  What *practical benefit* do you, or
anyone, derive from such a requirement?  Do you know the concrete
route for every piece of snail-mail, or every FedEx package, or every
Instant Message (IM), you send?  I certainly don't, and I'd like to be
free to continue in my ignorance after the deployment of NG mail.

If you don't have a good answer to that, please just drop this thread;
it's a waste of time.

>However the trend is in the opposite direction as more and more hosts 
>are no longer able to receive incoming sessions and the use of mobile = 
>intermittently connected devices such as laptops is increasing and 
>there are still many people using dial up.

Yup.  And those laptops, PDAs, toasters, whatever, have essentially
*no* routing information in them whatsoever.

Yet they manage to transmit canonical IP packets that magically find
their way to their destination anyway!

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

Yes they do -- I wrote about some of them already.  Further, HTTP
provides automated means for redirection, while FTP provides ad-hoc
means (via various sorts of mirroring advisories and even software).

What it boils down to is this: TCP/IP packets sent over the Internet
take arbitrary, essentially unpredictable by the sender, routes to
reach their destination.  They also are ephemeral; they are not stored
and forwarded later on in the event of a network outage, nor are they
stored on disk in the event of a system crash, nor are their contents
returned via any sort of "bounce" mechanism should the route they were
intended to follow or the service (port) they were intended to reach
be unavailable.

Email, to be useful, *needs* to be stored and forwarded, and stored on
disk, because people expect it to reach its destination, even when
networks go offline, are reconnected, or their nodes crash.

And, unlike TCP/IP packets, since email can take substantial amounts
of time to reach its destination, any *pre-routing* performed on an
email could be obsolete, even erroneous, as of some point during its
journey.

If you want to deliver a message to Joe Blow who lives in LA, it is
unwise to commit to a route for that message to travel to reach LA
without taking into account the possibility that he might move in the
meantime.  That's why we don't generally address such messages to
"Resident, 100 Maple Lane, LA, CA"; if Joe Blow has moved, we want to
give the email system the opportunity to recognize the need to forward
the message, or "bounce" it back.

Therefore, email has to have its *own* addressing and routing
capabilities above and beyond what TCP/IP offers, *or* we must stop
work on NG mail and focus instead of NG TCP/IP, which does all the
store-and-forward, pre-routing, and crash-recovery on packets that we
demand for email.

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