Re: X.400 vs. SMTP

Dave Crocker <dcrocker@mordor.stanford.edu> Wed, 02 November 1994 23:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13770; 2 Nov 94 18:06 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13766; 2 Nov 94 18:06 EST
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa19506; 2 Nov 94 18:06 EST
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02045; Thu, 3 Nov 1994 09:55:30 +1100
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02020; Thu, 3 Nov 1994 09:43:58 +1100
Precedence: list
Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09867; Thu, 3 Nov 1994 07:41:55 +1100 (from dcrocker@mordor.stanford.edu)
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA09638; Wed, 2 Nov 1994 12:41:10 -0800
Message-Id: <v03000502aadda6e89830@[128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 02 Nov 1994 12:41:13 -0800
To: Paul Robinson <PAUL@tdr.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker@mordor.stanford.edu>
Subject: Re: X.400 vs. SMTP
Cc: ericf@atc.boeing.com, Big-Internet@munnari.oz.au

At 9:05 AM 11/2/94, Paul Robinson wrote:
>Or because they needed specialized services (such as sending Facsimile)
>that isn't easily done via SMTP.  (You can do it now by using mailbox

If you look at the raw technical details, I doubt you'll find much difference.
The reality is that this is something that is value-added by the sending
and receiving UAs.  It should have nothing to do with the underlying email
transport service.

>There are people working on defining a means of using SMTP to do EDI.
>The problems are related to the fact that with X.400 you (usually)

The gotcha in your statement is the 'usually'.  The 'accountability' and
'logging' approach to non-repudiation is a matter of operational
configuration.  It has -- quite literally -- nothing to do with choice of
technology.  Hence, it does not show up any differences between X.400 and
Internet mail.

>recipient, thus ensuring nonrepudiation and nondeniability.  With SMTP,
>the sender connects directly to the recipient and there is nobody else to

The same is possible (and done) for X.400.  Going through a VAN is the same
effort for both technologies.

>Sendmail does support having a return receipt, it's an "undocumented
>feature" but in such a case you are depending on the recipient of a
>message - who may want to deny reception - verifying receipt of a
>message; there can be a conflict of interest.

Turns out, the same is true for X.400 delivery receipt.

>say $1 each or so.  SMTP collapses those transaction costs to *zero*.

No it doesn't.  It may collapse the per-transaction INCREMENTAL charge to
zero, but attaching to the Internet and using it is not free.

>Since SMTP is usually from originator computer to destination computer,
>it's probably more reliable than the relay-based X.400.

To repeat:  BOTH technologies are relay-based.  The required functions for
an SMTP relay are fewer than for an X.400 relay.

>The best mailing list program in the world was written for SMTP
>technology.  Listserv by Eric Thomas, of Swedish University.

Gee.  I thought that listserv was a bitnet (IBM mainframe) service, though
there are now Internet-based clones of it.

>In typical SMTP transfers, the material between DATA and . is an RFC-841

wow.  haven't seen a reference to 841 in many years.  But sorry, it's NOT
what goes into the SMTP data section.  RFC822 (with RFC1153 modifications)
objects do.  (And Mime, as appropriate.)  In fact, the NBS FIPS spec that
was published as RFC841 was strong input to the X.400 process.  But it has
nothing to do with Internet mail.  It was published as a convenience to the
Internet community, as is true for many other RFCs that are not standards.

As to the possibility of puting X.400 objects into Data, that's been
discussed.  But I assumed that the current round of discussion had to do
with the OSI email suite and the Internet email suite, rather than picking
and choosing pieces from among them.

d/

--------------------
Dave Crocker
Brandenburg Consulting                          Phone:  +1 408 246 8253
675 Spruce Dr.                                  Fax:    +1 408 249 6205
Sunnyvale, CA  94086               Email:  dcrocker@mordor.stanford.edu