ietf-asrg
[Top] [All Lists]

Re: [Asrg] is SMTP still really store-and-forward ?

2008-12-01 10:47:30


David Nicol wrote:
On Fri, Nov 28, 2008 at 9:06 AM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
Also, SMTP is store-and-forward and [...] multiple hops.

It was designed that way, for UUCP bang-paths, but in practice for a

Email technology developed over a series of independent paths. (Feel free to take that as some sort of pun.) The first inter-machine email was in 1971 by Ray Tomlinson of BBN, for the Arpanet. Others for dial-up, such as Fidonet and uunet came later, as did an IBM-oriented service. delivermail/sendmail was an early example of needing MTA functionality in order to support relaying. By 1980 there were at least 4 independently developed multi-hop email services in operation. Perhaps more. The reference to "independently" means everything from concept to technology to operation. Interconnections came quickly, but most had completely unrelated origins.

I have to make the pro forma reference to the Internet Mail Architecture specification:

   <http://bbiw.net/specifications/draft-crocker-email-arch-11.html>

(which is really and truly about to start through the IETF formalizations of standards approval, after 4 years of community discussion and modification. honest!)

Less pro-forma is to encourage looking at:

  <http://bbiw.net/specifications/draft-crocker-email-arch-11.html#relay>

which makes a distinction that is needed for this thread, namely that store-and-forward occurs at different levels. And especially that email MTA-based "relaying" is not the same as re-posting by a Mediator such as a mailing list. The examples cited on this thread have been for Mediator-based re-posting, not for SMTP-level relaying.

Since David raised the question about SMTP, the focus needs to be on the scenario from posting to delivery. Are there multiple hops from the originator's posting machine to the recipient's delivery machine?

Arpanet/Internet mail has always tended to be dominated by the sort of "direct" scenario David cites, but "dominant" is not the same as "exclusive". For example, larger organizations have department MSA/MDA servers that interact with border MTA servers. That's an internal hop. It well might be repeated at the receiver's organization, making a common sequence of 3 SMTP relaying steps.

Some examples from mail sent on this thread...

John Day's posting from his machine to the mailing list:
Received: from mail.ietf.org ([64.170.98.32])
        by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id IxjH0KqzpsGZ for <ietf(_at_)core3(_dot_)amsl(_dot_)com>;
        Sun, 30 Nov 2008 19:42:33 -0800 (PST)
Received: from QMTA05.westchester.pa.mail.comcast.net
        (qmta05.westchester.pa.mail.comcast.net [76.96.62.48])
        by core3.amsl.com (Postfix) with ESMTP id EEA883A68A9
        for <ietf(_at_)ietf(_dot_)org>; Sun, 30 Nov 2008 19:42:32 -0800 (PST)
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12])
        by QMTA05.westchester.pa.mail.comcast.net with comcast
        id le3Y1a03v0Fqzac55fiVCK; Mon, 01 Dec 2008 03:42:29 +0000
Received: from [10.0.1.45] ([71.192.250.235])
        by OMTA08.westchester.pa.mail.comcast.net with comcast
        id lfiT1a01255V49j3UfiUfk; Mon, 01 Dec 2008 03:42:28 +0000


Michael Dillon's note:
Received: from mail.ietf.org ([64.170.98.32])
        by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id mEVcGoR2p+P4 for <ietf(_at_)core3(_dot_)amsl(_dot_)com>;
        Mon,  1 Dec 2008 06:44:03 -0800 (PST)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151])
        by core3.amsl.com (Postfix) with ESMTP id C09933A67F6
        for <ietf(_at_)ietf(_dot_)org>; Mon,  1 Dec 2008 06:44:02 -0800 (PST)
Received: from E03MVZ2-UKDY.domain1.systemhost.net ([193.113.30.65]) by
smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 14:43:58 +0000


Stephane's note:
Received: from mail.ietf.org ([64.170.98.32])
        by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
        with ESMTP id T6Dcuf3AWdw8 for <ietf(_at_)core3(_dot_)amsl(_dot_)com>;
        Sun, 30 Nov 2008 07:53:25 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232])
        by core3.amsl.com (Postfix) with ESMTP id 222A93A67B0
        for <ietf(_at_)ietf(_dot_)org>; Sun, 30 Nov 2008 07:53:24 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10)
        id B52EB94AF6; Sun, 30 Nov 2008 16:53:18 +0100 (CET)
Received: by mail.sources.org (Postfix, from userid 1000)
        id 928F2190701; Sun, 30 Nov 2008 16:49:19 +0100 (CET)

Each of these had MTA-level relaying from originator to the mailing list 
Mediator.

In more constrained networking environments, such as developing nations and networks supporting mobility -- especially for emergency services -- multiple hops at the email level is fairly common. Also for value-added uses, such as EDI and facsimile over email.


very long time now, especially since running open relays began being
poor form, SMTP has been sender-realm systems communicating directly
to recipient-realm systems.

I believe that the requirement "support store-and-forward
transparently" may be safely dropped from the needs of the FUSSP;


1. It's always worthwhile to review architectural assumptions. If recent data confirms that an architecture is too complicated, it can be helpful to consider streamlining it.

2. When doing that review, the dangers are in poor sampling or inadequate prioritization. In other words, make sure your data cover the full range of the real world and make sure that you give proper weight to the inconvenient cases. For a global, diverse service is too easy to see only the most common cases, close at hand.

3. Simplification reduces the potential for innovative uses. Be careful not to lock out useful enhancements.

For all of its global scale, email technology is still pretty limited. For example, notice the complete absence of any meaningful quality of service mechanism at the SMTP level. Most of the real innovation in email is in how people lay human-operated logical layers on top of it, such as for for group collaboration and transaction processing. These, an others, have very rich functional requirements, in the non-email world, and their lack of support in email, IMO, constrains how we use email. I tend to compare the email relaying service with the lower IP packet forwarding service and observe that QOS remains a hot concern down there. It should be up for email, too.

Simply put, David, the global email transfer service is richer than you -- and many, many others -- appear to believe.

The fact that the most common scenario is a direct transfer between two huge servers is misleading. Much of the recent discussions about anti-abuse have been distorted by the failure to appreciate the real and extensive diversity of email transfer scenarios we still rely on.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>