'MAIL" definition

[Einar Stefferud <Stef@xxxxxxxxxxx>]

Recent comments about the meaning of the terms "MAIL" and "MESSAGING"
prompt me attempt a careful definition of what we mean by "MAIL", vice
what we mean by "MESSAGE".  I am afraid I got carried away here, but
at least this is separate from my voting message.  My intent here is
to try to clarify some of our terminology.

Mail implies a POSTAL SERVICE of some kind, where created objects are
placed in envelopes with the recipient's address(es) "imprinted" on
the envelope, which addresses are used by a "trusted" THIRD PARTY to
identify the recipient, and to then calculate a ROUTE (or partial
route) to be used to transport the MAIL ITEM in the direction of the
recipient address for purposes of delivery.

I know the SECURITY RFC POLICE (at TIS) will question my use of the
word "TRUSTED" above!  What I mean there is that users pragmatically
"trust" it enough to post mail with the 3rd party service in order
that their posted items should be delivered as well and the 3rd party
is able and willing to do.  I DO NOT mean that they are CERTIFIED by
some SECURITY POLICE OFFICER according to rules from some brightly
colored book.

There are TWO (2) primary boundary crossings for each posted MAIL
ITEM, as it travels from an originator to its recipient delivery
"slot".  These are well articulated in the X.400 conceptual model
which identifies the MUA => MTS => MUA transfer system (where MTS may
be a collection of relaying MTA systems).  POSTING transfers
responsibility for delivery to the MTS, and DELIVERY transfers
responsibility from the MTS to the MUA.

One of the rules in this game is that the MTS does not mess with the
content of the information objects carried inside the ENVELOPE.  This
is contrary to some of the practices in the INTERNET MAIL REALM, where
addresses in the RFC822 HEADERS are rewritten.  This rewriting, as I
see it, is a historical accident due to a lack of clarity in the
original standards.  The original internet mail realm standards were
not fully articulated in the terms now used by X.400.

In X.400 the envelope includes the equivalent of what we call the
"RFC822 Headers" in its P2 PDU, but does not include what our
SMTP(RFC821) inserts among the RFC822 headers (e.g., RECEIVED
headers).  This X.400 trace (and other envelope) information is
carried in an explicit P1 PDU.

In the internet, the two information objects are not kept entirely
separate, for the pragmatic reason that there was no handy way to
create and carry a separate set of headers without a big redesign, and
because it seemed harmless enough at the time to let them be mixed
together in the RFC822 object.

	(e.g., WE DID NOT THEN FULLY UNDERSTAND OUR OWN MODEL!)

I regretfully must take an excursion into history at this point.  I
must note that the X.400 model was carefully articulated for CCITT by
IFIP WG 6.5, (BEFORE the MHS QUESTION was placed on the CCITT
"DOCKET"), based almost entirely on the experiences of various
INTERNET people who led the effort to develop the model and get CCITT
to take the question.  In short, the appropriateness of the model was
discovered from ARPANET experience back in 1978-79, and became the
Conceptual Framework of the CCITT MHS work.  (Yes, puppies often grow
up to be dogs which attack their mothers.)

Left to their own devices and ideas, most of CCITT would have
preferred to develop some kind of UPSCALE TELEX, which in fact was
TELETEX and which was very strongly favored back in 1981 when CCITT
took up the MHS Question.  TELETEX is a terminal-terminal "wire
service" at base, though it has some store and forward facilities.

Now then, as I understand things, the IFIP WG 6.5 work was called
International Computer Messaging (The text name for WG 6.5) for
international political reasons, while the conceptual framework was
being developed as a POSTAL ANALOGY, which it is today.  The MOTIS
term is a descendant of that early work, so I would not attribute much
significance to the apparent MOTIS focus on MESSAGING.  It is entirely
historical.  MOTIS subscribes to the POSTAL SERVICE MODEL.  It ain't
UPSCALE-TELEX!

It is mildly important to realize that TELEX is a circuit service, at
its base, though it has acquired some "store and forward" switching
facilities over the years.  But it still maintains the fiction that
the ANSWERBACK that is echoed on behalf of the eventual recipient by
the first store and forward switch, is actually coming from the
eventual recipient.  They then go to great lengths to track and
acknowledge passage of the message through the store and forward
switching net, to emulate circuit service assurance that the
originator is really "talking to" the destination terminal device.
TELEX and TELETEX ain't MAIL.  Indeed, TELEX and AUTODIN TWX style
services tend to be called MESSAGE SYSTEMS more often than not.

X.400 and SMTP are POSTAL SERVICES.  In the postal analogy, there is a
'trusted" third party, and there is a designated place for this third
party (and no other party) to deliver mail in the form of a file
placement or file-append action which transfers responsibility from
MTS(MTA) to MUA.

So, SMTP and X.400 are mail, as I have written my definition.

FTP and FTAM are not MAIL!  They require that the instigator of a
transfer have privileged access to both ends of any transfer.  This is
more like U-Drive-Rent-A-Truck!  It requires that I get into your
plant via your loading dock, with your specific permission to pick up,
and then I must have the same kind of permission at the destination so
I can deliver.  Typically I own one or the other ends of this
transaction.  There is no third party!

(Lets not discuss using FTP in place of mail any more, PLEASE!)

I will grant you that I can use MAIL services to accomplish File
Transfers, and make them look a bit like FTP, but if you look deeply
into the underlying technology, you will see the issues clearly.

Hopefully Yours...\Stef