On Wed May 25 2005 22:49, John C Klensin wrote:
--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.
John, that wasn't my impression (maybe we have a failure to
communicate), nor was my alternate suggestion in any way "a
redesign/replacement ...". Indeed, it's independent of SMTP.
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.
As was my thumbnail sketch.
It was motivated by some internationalization
considerations, not spam.
I hope we're talking about the same draft. draft-klensin-email-envelope-00
talks about signing, anti-spam, and internationalization. My
brief sketch of a scheme that does not involve an SMTP extension
was based on the concept already documented for S/MIME "triple-
wrapping" (RFCs 2633,3851), which explicitly provides for signing and
encrypting message content, including the originator header fields,
which are protected from transport by a MIME wrapper. Transport
can put its markings in the header of that wrapper, rearrange field
order, slice, dice, bend, fold, spindle, and otherwise mutilate that
wrapper's header without invalidating the (encrypted and/or signed)
originator's content.
And, as you may have noticed, the
whole email address internationalization effort lost traction.
That wasn't a consideration in my discussion. It's really
orthogonal to the discussion, I think.
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.
I didn't.
It may well be that
time, and there may be far better reasons, but, as always, good
luck getting it deployed.
Wholehearted agreement.
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.
Perhaps -- a secretary or some mechanical aid make take the place
of an MUA in the paper world.
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".
I'm not sure I see the distinction. Whether delivery is to a
flat file (/bin/mail model) or to a more complicated structure
(e.g. an IMAP message store), it seems that delivery can be said to
occur at some point, and access by a UA may occur at any subsequent
time (or maybe never). I do see a difference from simpler, direct-
connect days to the present case, where "final" delivery to a POP,
IMAP, etc. message store at an ISP's site may be followed by retrieval
and reprocessing for "local" storage, rerouting, etc.
Indeed, it is in large part due to the changes that have occurred that
many of the anti-spam schemes are unreliable and may cause damage (in
particular, the assumptions that HELO/EHLO parameters are always
domain names and/or are always meaningful).
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 would lean toward user-to-user (analogous to "in response to
your letter of 28 February...") with the understanding that
rather than being *directly* generated or used by the end-users,
in either case the annotation may be generated and/or used by an
assistant (MUA or secretary). It's information related to the
message per se rather than transport/routing markings.
A more nebulous case would be the proposed "Archived-At" field. I
suspect that what is desirable is separate "bundles" of information
within a generic "message": here's the body content, here's the
originator header information, here's a package of transport markings,
here's some list-related stuff, etc.. And I think that can be achieved
within the MIME framework without making changes to SMTP or other
pure transport mechanisms (mailing lists which do add annotations
might need to place those in a MIME container of some sort added
to original content -- indeed, some lists might wish to separately
sign and/or encrypt what they add, with some assurance that the
signatures would survive subsequent transport).
And, in the real world of
email operations, believing that message IDs are really
invariant borders on the inexperienced if not delusional.
It's unclear what you're getting at; can you give more specifics
or an example?