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 wrote:
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.
Date: Fri Jan 23, 2004 3:59:11 PM America/Detroit
To: IETF-Announce: ;
Subject: I-D ACTION:draft-klensin-email-envelope-00.txt
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
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
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:
NOTE: The mail server at ietf.org 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