[Top] [All Lists]

Re: "Envelope", yet again

2005-05-25 19:49:38

--On Tuesday, 24 May, 2005 12:25 -0400 Bruce Lilly
<blilly(_at_)erols(_dot_)com> wrote:

   Were we starting from scratch [...]

Well, John's draft expired in July 2004, so we might as well,
as it appears that the idea lacked traction.

Bruce, my impression of John Leslie's note was that, when he
made the comment above, he was talking about "starting from
scratch" as a redesign/replacement of the SMTP, and
SMTP-compatible, mail environment.  The draft to which you refer
was an attempt to explore whether or not we could separate,
_within_ the SMTP environment, all of the information supplied
or used by the MTA from that used in MUA-MUA or user-user
communication.   It was motivated by some internationalization
considerations, not spam.  And, as you may have noticed, the
whole email address internationalization effort lost traction.
IMO, that occurred both because it was hard and because the
folks who seems to dominate these discussions, posting tens of
messages a day or more, appear to be more interested in spam and
nit-picking than in such broader and, IMO, ultimately more
important, issues as address internationalization.

I don't think you should draw the inference from the fact that I
haven't pursued that draft any further that it is time to start
redesigning Internet mail from scratch.  It may well be that
time, and there may be far better reasons, but, as always, good
luck getting it deployed.

So, my first question to the group is, "Is there anything
beyond SMTP commands and trace headers (however defined)
that we want to be included when we talk of "envelope

Everything that isn't end-to-end, user-to-user

   That definition is facile, but I don't find it useful.
   (You prove my point about vagueness, BTW.)

Believe it or not, there is a reason that components are
separated into "envelope", "header", and "body", and why the
application is called "electronic mail" and not "electronic
foo".  The header and body are part of user-to-user
communication (as with non-electronic mail) and the envelope
is where various markings pertaining to transport, filing, etc.
of unopened messages are placed.

And, as always, the model is fuzzy at the edges.  Design
decisions made even before 822 create a difference between
MUA-MUA information and user-user information, a distinction
that does not exist in traditional paper mail.  We have also
always had an ambiguity about what end-to-end means with
Internet mail, an ambiguity that got worse when "delivery to
user's mailbox" was replaced in many environments with "delivery
to mail store" or "delivery to storage agent".   To take just
one handy example, do you think Message-ID and In-Reply-To are
part of user-to-user communication or information about
"transport, filing, etc."?  I think the answer is "maybe", and
that it gets even worse if the MSA  or post-MSA processors
attempt to do message threading in the mail store.

   I believe there's rough consensus that a MailingList
   "re-inserts" messages,

To the extent that any other part of the store-and-forward
transport process also does so.  The message (as indicated by
invariant message identifier) is the same message (RFC 2822
section 3.6.4).

and that List-* fields are meaningful for list management -- 
at both the sending and receiving end.

Yes, in the same way that routing or filing instructions,
postmarks, etc. are meaningful on physical mail envelopes.

Similar comments to those above apply to List-* fields, etc.,
especially with List managers/ exploders which try to be as
low-impact as possible with regard to the message body headers,
as we generally try to recommend.  And, in the real world of
email operations, believing that message IDs are really
invariant borders on the inexperienced if not delusional.