[Top] [All Lists]

Re: I-D ACTION:draft-klensin-email-envelope-00.txt

2004-01-23 17:40:29


We may be less in disagreement than you assume. Briefly, I think it is useful to write some things up separately, because, that way, it is easier to think about whether the pieces are right or there are better ways to do them. And I am not punting on internationalization at all -- it is my main concern here and I just want to see if we can build a healthy environment for it, one in which, as I've said a few times, we move aggressively toward an internationalized/multilingual Internet rather than continuing with a predominantly Roman character/ English network with various kludges, patches, and warts to permit other scripts and languages to sort of work. So, fwiw...

I would be happy, indeed delighted, to be wrong, but I see just about no hope for designing and deploying a completely new email structure. More on that in draft-klensin-emailaddr-02.txt, which I hope I can get wrapped up and posted on Monday or Tuesday (it is a fairly major revision of the ideas in -01).

The nature of the internationalization problem, as I see it, is precisely something that will need a number of interdependent changes. To try to make them independently, or to work around some of them, or to try for small incremental chunks, is likely to get us into the land of "nasty kludges forever". I don't see that as flying, and I don't see it as being successful. On the other hand, if we look at the whole picture (and if I'm right), when we get through, we have a rather different-looking email environment, but one that is built on the same general framework (avoiding hitting the wall of deploying something completely different). I see that picture as including:

        * UTF-8 addressing in both the local and domain parts
        (IDNA belongs in the application-DNS interface, not in
        the user-application interface).
        * handling of trace information in a way that doesn't
        screw up message bodies.
        * probably a fundamental rethinking of the trace
        information: While the draft hints at that, it isn't a
        can of worms I wanted to open in it.  But Received is,
        at best, badly outdated.  E.g., (i) more structure may
        be in order, (ii) it is a bad sign when we have to hide
        important information in comments, (iii) Via/With/ID
        need rethinking, (iv) it might make sense to sign the
        things or make assertions about authenticity or
        authorization, (v) the whole environment may need to be
        reconsidered in the light of common practices involving
        internal and external mail hosts,... and so on.  And, of
        course, the reason I wanted to call that command
        "envelope" and not "trace" is that, if an MTA is going
        to make an assertion that the message being transported
        is somehow virtuous and in a state of grace, maybe that
        shouldn't be done by tampering with the headers either.
        * UTF-8 (or equivalent) headers
        * probably a requirement for 8BitMIME, finally
        permitting this "next generation" environment to walk
        away from the 7bit environment.

So my goal is to clean up our most problematic technical warts, move forward aggressively with true internationalization, and to provide hooks for better originator-based, authenticatable assertion-based, permission-based, and/or authorization-based control of undesired message flows (yes, in this context, I consider spam to be a subset of a more general problem). And that is, I think, pretty close to your list of a "nice trio of goals".

That said, my concerns about deployment issues and a good deal --perhaps too much-- experience dealing with email problems leads me to be very hesitant to take two (perhaps obvious) extra steps that I think you are implying in passing:

(1) Going to true binary transport, rather than continuing with a line-oriented arrangement like 8BitMIME. We pretty much know how to do it; I'm just concerned about the interoperability and debugging nightmares.

(2) Pulling all of the headers out, so that "the envelope" becomes:

        Outer envelope:  Handshake and addressing information
        Middle envelope: Transport tracing, validation, and
        similar information.
        Inner envelope: More or less the semantic content of the
        2822-defined headers that are not part of MIME

That way, the message payload more or less starts with a content type and goes from there... or one could try to abstract MIME structuring into an envelope layer too. I could be wrong, but I just don't think the complexity and transition problems -- especially for gateways-- would be worth the costs. But, if someone feels differently, I look forward to seeing the drafts.


--On Friday, 23 January, 2004 17:52 -0500 Nathaniel Borenstein <nsb(_at_)guppylake(_dot_)com> wrote:

John -- It's a pity to say this about such a nicely-written
draft, but I fear this proposal comes remarkably close to
maximizing the cost/benefit ratio.  When you consider
distributed costs of testing and deployment, I would bet that
implementing this proposal would cost at *least* 50% of what
it would cost to deploy a far more radical set of changes to
the email infrastructure.

What we were discussing in Minneapolis was a
once-in-a-generation scale of protocol reform.  I think we
should think big, because there is a large fixed cost to
pushing any structural change through the entire Internet
community.  I'm particularly concerned that you seem to be
punting on internationalization -- I can't see putting much
energy into *any* major reform that doesn't address the most
widely-perceived failing of the current system.

At root, what I don't buy is the notion that, in this case, we
can take an incremental approach to radical change.  The
Wright Brothers didn't learn to fly by practicing the high
jump, and I don't think we're going to clean up email by
creating a new architectural entity (the extended envelope)
that only works in ASCII.

Now, if the extended envelope could be done completely in
UTF-8, with a coevolutionary model for son-of-822 header
fields and binary body transport, now *that* would be a more
compelling story.  Delivery tracing, internationalization, and
binary transport would be a nice trio of goals for a
next-generation email system.  I can certainly think of a few
others, though.  -- Nathaniel

On Friday, January 23, 2004, at 04:53  PM, John C Klensin

The draft posted/described in the attached is a bizarre idea,
partially to see if it is possible to consider a radical
solution to  an increasingly troublesome problem, and
partially to see if the  supportive comments about "Email NG"
in Minneapolis were really  serious.

I am not at all convinced that it is a _good_ idea, only
that, if we  are talking about radical changes to the mail
infrastructure to  support various extended services, this is
the sort of "clean up the  warts that get in the way" option
we might want to consider.

And even if it were a good idea, some of the details are
probably not  right -- if this looks like it received a day's
thought, you would  probably be guessing much too high.

Discussion should probably go to the SMTP list; IMAA is
copied only  because this could interact a bit with some of
the "UTF-8 header"  discussions.


From: Internet-Drafts(_at_)ietf(_dot_)org
Date: Fri Jan 23, 2004  3:59:11  PM America/Detroit
To: IETF-Announce: ;
Subject: I-D ACTION:draft-klensin-email-envelope-00.txt
Reply-To: Internet-Drafts(_at_)ietf(_dot_)org

A New Internet-Draft is available from the on-line
Internet-Drafts  directories.

        Title           : A Cleaner SMTP Envelope for Internet Mail
        Author(s)       : J. Klensin
        Filename        : draft-klensin-email-envelope-00.txt
        Pages           : 0
        Date            : 2004-1-23
During the last few years, a number of proposals for
extensions or improvements to email have run into trouble
with a side-effect of mail relaying.  In the current Internet
Mail model,  every SMTP server is required to break strict
layering by inserting  one or more additional 'trace' headers
into the message headers which  are actually part of the SMTP
payload.  Since the headers are altered in transit,
header-signing is not an available option, various anti-spam
and internationalization strategies are infeasible or much
more complex, and so on.  This document proposes to change the
Internet mail model to place the in-transit trace information
in the envelope, removing the requirement that relaying
systems modify the message payload.

A URL for this Internet-Draft is:

To remove yourself from the IETF Announcement list, send a
message to ietf-announce-request with the word unsubscribe in
the body of the  message.

Internet-Drafts are also available by anonymous FTP. Login
with the  username
"anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
        "get draft-klensin-email-envelope-00.txt".

A list of Internet-Drafts directories can be found in

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
        "FILE /internet-drafts/draft-klensin-email-envelope-00.txt".
NOTE:   The mail server at can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack"
        or a MIME-compliant mail reader.  Different MIME-compliant
        mail readers exhibit different behavior, especially when
        dealing with "multipart" MIME messages (i.e. documents which
        have been split up into multiple messages), so check your
        local documentation on how to manipulate these messages.
Below is the data which will enable a MIME compliant mail
reader implementation to automatically retrieve the ASCII
version of the Internet-Draft.
Content-Type: text/plain
Content-ID:     <2004-1-23161738(_dot_)I-D(_at_)ietf(_dot_)org>