RE: New models for email (Re: e2e)

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(_at_)jck(_dot_)com] 
> Sent: Friday, August 17, 2007 9:27 AM
> To: Douglas Otis; Keith Moore
> Cc: ietf(_at_)ietf(_dot_)org
> 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(_at_)mail-abuse(_dot_)org> 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(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf