On 26-feb-04, at 0:29, Bonatti, Chris wrote:
What I meant originally was that it would be very effective, in
some environments, to have the e-mail exchange protocol (whatever
it ends up being) have the property of being able to be run over
IP layer multicasting. This would effectively mean that the
protocol would need to run over UDP (or perhaps some flavor of
RMT), and handle acknowledgement via separate unicast UDP, RTP,
or even TCP associations. This has enormous potential in
environments (such as satellite wireless) where there is a common
broadcast-based data link. When SMTP splits that message at the
last common server, it still makes n separate TCP transmissions
of the message over the common broadcast data link. If the
protocol were mappable onto IP multicast, only one transmission
is required.
Hm, one problem with this is that mail is still mostly one-to-one or
one-to-few on the wire, even for mailing list messages, and multicast
isn't exactly widely available either. So if we define something like
this it's unlikely we'll see it implemented widely.
What we can do instead is define a standardized way to bundle and
unbundle mail, similar to what happens in UUCP and Fidonet. Then the
mail bundle can be transported through any means deemed desirable in
between two mail servers. (Which could be your favorite reliable
multicast file transfer protocol.) Other applications for this would be
backing up mail, even if it's still in transit, or retrieving mail
efficiently from a host that is no longer connected to the network by
dumping it on removable media.
And as long as we're doing this, it would be a good idea to define a
solid mailbox format that can be used to share access to messages by
different applications. (For instance, I'm very fond of Apple Mail but
I really want a lighter-weight client when I'm dialing in over GPRS but
the two have to be integrated closely for this to be worthwhile.)