I have a slightly different take from John here. My strong belief is that a proposal for a new protocol that does the same thing as SMTP but slightly better is a total non starter. No matter how much better the protocol is the cost of transition will dominate. The only way that I see a new email infrastructure emerging is as a part of a more general infrastructure to support multi-modal communication, both synchronous and asynchronous, bilateral and multilateral, Instant Messaging, email, voice, video, network news all combined in one unified protocol. > -----Original Message----- > From: John C Klensin [mailto:john-ietf@xxxxxxx] > Sent: Friday, August 17, 2007 9:27 AM > To: Douglas Otis; Keith Moore > Cc: ietf@xxxxxxxx > Subject: New models for email (Re: e2e) > > (changing the subject line since this has clearly drifted off > into a more specialized discussion). > > Doug, > > I'm not convinced of the merits of the general idea you are > pushing here, mostly because I still believe in the value of > mail systems with relay (or, if you prefer, > store-and-forward) capability. If one requires that one be > online to receive actual messages, with end-to-end > connectivity to the sender's mail holding store, then sites > with no direct connectivity to the Internet are out of luck > and sides with intermittent connections or very long delay > connections (think about a lot of developing areas on earth > as well as the interplanetary problem) are in bad trouble. > > An important side-effect of the current mail model is that, > if the final delivery server is network-close to the intended > recipient, it doesn't make much difference to the recipient > whether mail flows into that server at gigabit bandwidth or > at a few kilobits/second or worse or it things flow only at > 0300 local time. The only connections that are really > network-performance-sensitive are between the sending MUA and > the submission server and between the final delivery MTA or > message store and the mail-retrieving user. We've used those > properties to very good advantage in the past and, I believe, > will continue to use them to good advantage. > > I share Dave Crocker's concern about deployment of > replacements for the current email model (see the article in > the recent issue of Internet Protocol Journal), but maybe it > isn't impossible if the need is significant enough and the > solution doesn't make other things worse (which I think yours > may, but I haven't seen enough of a proposal to evaluate). > > One could preserve the relaying by turning message > transmission and delivery into a multiple-stage handshake: > * Message notifying recipient of availability > * Message from recipient to store asking for > transmission of the real message > * Transmission of the real message > but that would be a fairly complex piece of protocol work, > with attacks possible at each step. > > I note that, while one would want to update its non-existent > security mechanisms before trying to use it today, the > capability of sending a message structured as > > [...] > Content-type: multipart/???; boundary="foo" > > --foo > Content-type: text/plain > > Hey, Doug sent a message > --foo > Content-type: message/external-body > [...] > > has existed since the very first MIME specification and has > never been significantly used. Maybe there is a message > (sic) in that for you; maybe not. > > But the main point of this message is that, if you are > serious about this, generate an I-D that specifies all of the > details, analyzes the possible attacks and how you will repel > them, and so on. IMO, you have passed the point at which > talking about > what you might propose is helpful. If the ideas have any > utility or applicability (even if that applicability isn't as > general as you believe), we need a real proposal not more > IETF-list traffic. > > Just my opinion. > > john > > > > --On Thursday, 16 August, 2007 23:45 -0700 Douglas Otis > <dotis@xxxxxxxxxxxxxx> wrote: > > > > > On Aug 16, 2007, at 3:10 PM, Keith Moore wrote: > > > >> I also think there might be some merit in holding mail on the > >> sender's outgoing mail server until the receiver's MX is > >> willing to deal with it, thus pushing more of the costs > >> toward the sender of a message. > > > > The concept of holding messages at the sender could be a > basis for a > >change in SMTP for supporting this model, but at a message > >granularity. The changes would be similar to that of BURL > but would > >be Transfer by Reference or To Be Read, TBR. > >... > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf