|
Re: I-D ACTION:draft-klensin-email-envelope-00.txt
2004-01-23 17:40:29
Nathaniel,
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.
john
--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
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.
john
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:
http://www.ietf.org/internet-drafts/draft-klensin-email-envel
ope-00.txt
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
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv(_at_)ietf(_dot_)org(_dot_)
In the body type:
"FILE /internet-drafts/draft-klensin-email-envelope-00.txt".
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 Internet-Draft.
Content-Type: text/plain
Content-ID: <2004-1-23161738(_dot_)I-D(_at_)ietf(_dot_)org>
|
|