[Top] [All Lists]

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

2004-01-23 19:21:11

----- Original Message ----- 
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Nathaniel Borenstein" <nsb(_at_)guppylake(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Friday, January 23, 2004 7:40 PM
Subject: Re: I-D ACTION:draft-klensin-email-envelope-00.txt


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.

Is this one of the main reasons for the ENVL proposal?
Internationalization?   if so, this sort of answers my question on what the
ENV header includes.  It implies mime content headers are part of the ENVL
header block.  No?

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

You know, this pessimistic attitude is going to help anyone.   Fwiw,  while
I value the strong history and knowledge of SMTP/IETF gurus provide in the
forums,  what I find extremely disappointing is this "my way or highway"
mindset.  Quite frankly,  there seems to be conflictive old guru closed
minded attitude about the realities of the mail industry delimas which
perpetuates a dearth of interest to finally address the issues one way or
another.    You guys (speaking in general) need to listen and begin "opening
your minds."

With that said,  you don't need to justify why your initial draft isn't
perfect.  Its a start.    In my view, the case has been MADE for a "change
discussion" at a minimum and part of that discussion should be how to best
address backward compatibilty and to maximize acceptance and deployment.

As I mention in my previous message to Nathaniel, in my view, a change to
smtp will not have a major acceptance and deployment unless the IETF mindset
is changed on how the functional specifications are written to provide or
OFFER the possibility for stronger SMTP compliancy level system policies by
system administrators.   In my view, unless this is done, nothing will have
signfiicant impact because the specs says you don't have to follow it.
While I believe backward compatibilty is important, it should also be
allowed for developers begin to make it a possibility for offering stronger
system admin policies.

 * handling of trace information in a way that doesn't
 screw up message bodies.

In my view, this ENVL proposal can be simplified by basically making it an
alternative to constructing the RFC 822 message:


    DATA ---.> RFC 822


    ENVL + BODY (or DATA) ----> RFC 822

The point here is that ENVL can now provide developers  a way to technical
provide system policy power similar to what YAHOO is attempting doing today
using the current SMTP specification; Delay RCPT validation and verification
until it sees the headers in the DATA stage, in addition provide an
technical reason to make their YDK (Yahoo Domain Key) proposal a technical
possibility.   So ENVL will optimize performance for YAHOO and others who
use this for verification/validation and/or YDK implementation.

And more importantly, something like ENVL  can finally provide system policy
power for developers to address various mandates imposed by the US Federal
Law AKA the CAN-SPAM act without requiring the DATA transaction which is in
my view one of the CAN-SPAM loopholes spammers are patting themselves on the
back about. The CAN-SPAM Act requires the spammer to identify the topic of
the mail content.  This can't be done until the DATA is collected and for
spammers reaching the DATA stage, it it like seeing the "gold at the end of
the rainbow."

Pulling all of the headers out, so that "the envelope"

 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

I think this complicates the required solution at the SMTP level that
something like ENVL can help address.   To me, SMTP should not be in the
business of interpreting mail-content.  The presumption is RFC 822 compliant
ready data handled at both ends of the end-user mailer software with SMTP
network headers included in the process.   To me, the most important
industry issues are related to access control and mail transport integrity.
So in my view,  SMTP protocol change proposals should concentrate on
addressing these two very important and real concepts that will have a major
and direct effect on the industry concerns.

I like the ENVL proposal  if it allows for the SERVER to see/analyze RFC 822
header information before the DATA stage is reached.  To me, that is the
most important benefit it will bring to the industry.  Otherwise, I see no
benefit gained from it.

Thats my view.

Hector Santos, Santronics Software, Inc.