[Top] [All Lists]

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

2004-01-23 18:03:51

Hello John,

In general,  I have much to say about any SMTP proposal that suggests SMTP
change at the software level. To me, a change in software opens the door for
other possible concepts that may address a particular needs in the email
industry.   IMTV, acceptance and deployment aspects of the proposal are
important and major considerations of any SMTP change proposal.  IMTV,
that's a matter of a having a strong functional specification dictation.

With that said,  I am putting my "Software Engineering Hat" on as if I was
going to implement your ENVL proposal today to see what would be the
technical implementations issues.  Based on this technical point of view,
here are my specific comments about your draft:

What does this ENVL proposal attempt to address?  (What problem(s) does it

Excuse me if I missed it in the draft, but I see only three (3) concepts
that addresses a "problem is solved:"

1) Proposal provides a cleaner SMTP envelope or proposal to create a cleaner
RFC 822 trace header?

2) Cleaner SMTP envelope minimizes mail relay issues.

3) Syntax Error checking.

Is this correct?

What is it about the headers today that makes it problematic?

You touch base with section 3, item 6 indicating "Syntax Error."   Syntax
Error needs to be clarified, i.e,  can (or may) this include an
implementation that attempts to perform some sort of sender/machine

What is considered the ENVL header?

The term "Trace Fields" are used.  This needs to be clarified for the
software engineer who may not be in the same league as protocol police or
IETF gurus.  It seems to indicate only the Received: and Return-Path: lines
are considered and are the ENVL transaction.

Lets ask this another way:

Does this proposal basically attempts to separate the transmission of a RFC
822 formatted message normally done at the DATA state into two separate
state transactions?   For example:

    C: ENVL
    S: 250 Start Mail Header input; end with <CRLF>.<CRLF>
    C: [sends header followed by "." line]
    S: 250 Mail Header OK. Continue with Data Command

    C: DATA
    S: 354 Start Mail Body input; end with <CRLF>.<CRLF>
    C: [send message body only (no header) followed by "." line]
    S: 250 Message accepted for delivery.

or are we just adding a new state that allows a client to provide a server
with access to "DATA" header (all or specific) information using the ENVL
before the actual DATA transaction takes place?

    C: ENVL
    S: 250 Start Mail (Trace??) Header input; end with <CRLF>.<CRLF>
    C: [sends mail header (all or just some specific headers??) followed by
"." line]
    S: 250 Mail Header OK. Continue with Data Command

    C: DATA
    S: 354 Start Mail Header/Body input; end with <CRLF>.<CRLF>
    C: [sends mail header again and body followed by "." line]
    S: 250 Message accepted for delivery.

In short,  an example for the "laymen" would be nice :-)

Anyway, I personally believe your ENVL is a good start.  It has promise.
Off hand, without grasping yet the true intent this proposal (what does it
solve),  what defines the ENVL "headers", etc,  I believe the answer to this
will have a major factor on the acceptance and deployment aspect of the
proposal.  Besides other impact considerations which I don't wish to muddy
the water just yet without getting the answer to the above,  if this ENVL or
another other SMTP change proposal proves to be useful,  I'll be among the
first to implement such a new SMTP feature like this in our SMTP product   I
will be interested on providing an immediate  "proof of concept" wide test
bed of customers.

Hector Santos, Santronics Software, Inc.

----- Original Message ----- 
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: <ietf-imaa(_at_)imc(_dot_)org>; <ietf-smtp(_at_)imc(_dot_)org>
Sent: Friday, January 23, 2004 4:53 PM
Subject: FWD: I-D ACTION:draft-klensin-email-envelope-00.txt

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.


<Prev in Thread] Current Thread [Next in Thread>