On Fri, 2007-08-17 at 09:27 -0400, John C Klensin wrote: > 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. The option will need to be negotiated at every stage. It should be rather easy to translate "transfer by reference" into the current behavior at any point within the SMTP store-and-forward chain. When the MTA confronts a down stream MTA or MDA where the user is without access to http, or not yet upgraded, then at this point the message would be fetched. Delivery reliability from that point forward needs to be high. One might assume messages will have been vetted by publisher reputation prior to fetching and that the message is near the last stage. > 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. As have I. The MDA could easily offer both modes to the user agent, assuming the MDA has been upgraded to support transfer by reference. > 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). Yes, I read the article. Unlike Dave, I don't see SPF/Sender-ID helping, but instead path registration by address creates serious problems. I agree with Keith, the use of IP addresses as authentication tokens needs to change, especially when there is a desire to introduce the use of IPv6 with email. In addition, the trust model does not work when vetting prior to the critical acceptance of responsibility for message delivery occurs at the MSA. This operation might be by millions of small and large organizations operating at a flat rate, free of charge, or gratis. The bad actors have access to essentially all MSAs. Reasonable vetting will not happen at this stage, although we might all agree that it should. The MSA can not be trusted. Transfer by reference permits every stage subsequent to the MSA to apply their own vetting. The reference can not be falsified. In most cases, less that 10% of the message will end up being transferred. A co-worker sent me his latest stats. His MTA currently finds 1% of the message received are not spam, where the overall volume of spam has increased by more than a order of magnitude in just the last year. He is also someone currently blocking several AS networks in his seemingly futile efforts in controlling MTA bandwidth. > 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 What vetting can occur? What element within a message can be trusted? A message reference when accessed through a different channel can not be falsified. Even with DKIM, there is little that can be trusted. Perhaps there might be exceptionally restricted MSAs shielded from bad-actors, but this would not be the typical situation. SMTP needs to change into a system that delivers an outside channel message reference. Outside channel message references can not be spoofed. Fetching the message though an outside channel provides content security and a reliable indication the message was received. SMTP normally working in a transfer by reference would be far more reliable and far more suitable for commerce. > but that would be a fairly complex piece of protocol work, with > attacks possible at each step. Yes, and to what end? > 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. Perhaps. It seems less is more with respect to what might be included with the reference. The vetting must be limited to the reputation of the publisher and not include what some filter process might conclude. > 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. I'd be happy to flesh-out a draft and bring it to some other mailing-list. What would be the right venue? -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf