Re: Another user-visible goal

I seem to have unintentionally stirred up a few hornets' nests.  Let me clarify:

o I did not give physical mail as a reference model, I used it to illustrate some
  issues that have arisen as electronic mail has evolved.  I didn't mention the
  US Postal Service at all.  If it helps, think of the example as any of the many
  available private and/or commercial delivery services -- the point is that the
  content is not readily visible in transit, and the transport system places its
  marks and notations on the container or somewhere else; specifically it does
  not muck about with the content.

o I didn't mention paper specifically either.

o Nor did I mention mailboxes.

o I intentionally did not discuss implementation details (If I recall correctly,
  delving into implementation in this exercise was declared out-of-bounds).

o I didn't invent the terms "envelope", "header" and/or "body". They are in
  widespread use.

I mentioned that email had evolved.  For those who don't remember or who weren't
around, what we now recognize as Internet email started with ftp.  Content was
sent from one place to another.  Special commands were added to (and subsequently
removed from) the ftp protocol to support "mail".  The content format was first
standardized in RFC 561 (q.v.  Really -- go look -- it's only a couple of pages).
That specified no more than what one would typically find in the heading (and
footer) of typical written communications, indeed somewhat less. Ignoring RFC
680 (which isn't online), RFC 724 came along a few years later and added several
additional header fields and defined the (minimal) body and message structure.
Note that ftp was still being used, and what RFC 724 added was still typical of
what might have appeared in the content of written communications of the day
(reference information, comments, filing information).  RFC 733 appeared shortly
thereafter with no changes relevant to the point I'm trying to make. Ftp was
still in use (RFC 765 still had the mail commands, which were in effect until
RFC 959 obsoleted it), but work was underway to produce a mail-specific transfer
protocol. The Mail Transfer Protocol (MTP) first appeared in RFC 772.  MTP
transferred the content (data) without change; sender and recipient information,
commands affecting handling were part of the MTP protocol, separate from the
message content. Likewise for RFC 780, 772's successor.  RFC 788 was the first-
generation Simple Mail Transfer Protocol (SMTP).  It introduced alteration of
the data by transport -- it specified prefixing Mail-From header fields and a
Return-Path header field to the message content.  We still have Return-Path,
but Mail-From has been replaced by Received fields.  From that beginning, a
large number of additional fields have been designed which -- unlike the RFC
561, 724, 733 fields -- caused modification of the message after leaving the
sender.

For example, consider a recent message on this mailing list.  It contained,
when it appeared in by mailbox, aside from the content-related fields:
1 Return-Path field
9 Received fields (NINE of them! Each one several lines long)
1 X-Sieve field
1 X-Authentication-Warning field
1 X-Mailer field
1 Precedence field:(which is neither standard nor user-defined)
1 List-Archive field
1 List-Unsubscribe field
1 List ID field
It also contained 1 each MIME-Version, Content-Type, and Content-Transfer-Encoding
fields, all of which were unnecessary since their values were the same as the
defaults.

Many modern MUAs by default display only a few header fields -- a user who wishes
to see one which is not displayed must wade through *all* of the others as well (and
that's assuming that he can figure out how to get the MUA to display them). So
must users of software which does not provide any filtering capability. That's
a nuisance.  As I have pointed out earlier, the practice of modifying the content
has made signing of the content all but impractical (RFC 2634 provides for triple-
wrapping of messages; I know of no MUAs that do that or that can triple-unwrap
such a message without the user forcing the MUA into doing so by extraordinary
measures).

Returning to the goal (actually goals):
1. Make digital signing of the message content (body *and* _sender-specified_ header
   fields) practical
2. Keep transport-related markings out of the message content

As I see it, the first goal is related to the message format (and therefore might be
applicable beyond mail), while the second is a transport issue largely independent
of the message format.  What they have in common is *separating* the transport-
related markings from the message content per se.