I think there is certainly a case to be made for the three corner
client-server-client model and even a case to be made for the
client-server-server-client four corners model of messaging transfer. But I
would like to get away from the email model where messages bounce aimlessly
from server to server without a concrete idea of where they came from or
where they are headed.
You might not be aware of this, but the model you want to get *away*
from is the one used by TCP/IP to transmit packets from host to host.
Put another way, let's say you created a hypothetical email system
(call it dmail, for "direct mail") that provided for no
store-and-forward mechanism at all -- just direct connection from
originating client to receiving client, which is the "simplest" model
along the lines you're proposing, although clearly you are *not*
proposing that particular model.
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*. These packets do *not* have a concrete
idea of where they came from or where they are headed. All they
specify is "here are the IP address and port # from whence I came;
here are the IP/port I'd like to get to at some point; I don't really
care how I get there".
So these packets may take a variety of routes to get to their
destination, even when they represent a single connection, a single
dmail message.
And those routes can include protocol and other gateways, which
rewrite the source and destination info in those packets.
There are very sound reasons for this architecture.
So, what you have to do, to justify the model you're proposing, is one
of two things, as I see it:
1) Explain how it's going to be worth imposing at the dmail layer
when it isn't imposed on the underlying transport layers.
2) Justify changing the underlying transport layers to switch to a
"more concrete" model for routing packets.
Having personally come from the same point of view you hold in my
distant past, "rebelling" against the seemingly-ad-hoc way the
Internet does things, but giving myself time to think through the
implications of "my" models vs. the existing ones, I doubt you're
going to have much success.
Another challenge you will have on your hands is to demonstrate that
it is possible to design a usable dmail transfer protocol (call it
DTP) that *prevents* the kind of re-routing to which you object, but
is presently being done.
That is, given dmail's deployment, what prevents a recipient client
(or, in your slightly "looser" model, its server) from pretending to
"accept" a dmail message, instead just relaying it to yet another
server?
Finally, what *exactly* will be the practical benefits of whatever
measures you take to make dmail (your particular concept of it anyway)
a reality?
--
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/>