(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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf