Re: SMTP and multicasting

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.)