|
Re: I-D ACTION:draft-klensin-email-envelope-00.txt
2004-01-24 13:47:36
John -- I'm glad to hear that you see this as part of a larger effort.
I am certainly not opposed to incrementalism wherever possible, it just
wasn't clear to me from this particular document, out of context, how
it fit.
For my part, I think I might slice the problem a bit differently, but I
might be wrong. So I'd like to see our efforts start with some
requirements analysis. If we're going to build email NG, we need to
make some decisions about what the goals are and then try to cut it
off, rather than let it grow indefinitely as we're trying to make
progress.
I've already suggested the following key goals:
-- internationalization, esp. of addresses
-- enhanced tracing mechanisms
-- binary transport (But what I really mean by binary transport is
probably "deprecation of historical cruft," e.g.
Content-Transfer-Encoding shouldn't be necessary where the extensions
are used.)
I also think that there's enormous potential in generalizing and
standardizing the kind of structured local-parts that people currently
use "+" for. And on and on. The list of possible additions is fairly
large, I'd like to have at least a rough consensus before we put a lot
of work into documents. -- Nathaniel
On Friday, January 23, 2004, at 07:40 PM, John C Klensin wrote:
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>
|
|