[Top] [All Lists]

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

2004-01-23 19:36:12

Replying to ietf-smtp only...


As I indicated in my response to Nathaniel, this proposal is one of a group, most of whole elements are still to come (and some of the elements of which are small variations of work already done by others). Also, the draft assumes that one has read carefully and understood 2821 and its terminology. If this goes anywhere --and the purpose for posting it and some of its pending relatives is to start some discussion, not necessarily to have this result come out-- then it may be desirable to make it more self-contained... or it may make better sense to combine it with some other proposals.

I'll respond to a few of your other questions/ comments below.

--On Friday, 23 January, 2004 20:03 -0500 Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:

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 solve?)

Mentioned in the text, and discussed many times, in different contexts, over the last decade or two: the narrow purpose of this proposal is to separate the "trace" information from the [rest of] the header information. The impact of doing that is that in-transit (including relay) MTAs no longer have to inspect or take any other action with regard to (other) message headers. Looked at from the other end, that also implies that the headers as they leave the originating MUA (or the combination of the originating MUA and the submission MTA-- see 2821) can be (and can be required to be) identical to the headers as they reach the delivery MTA and, local post-SMTP-delivery decisions aside, the message store and receiving MUA. That has a number of potentially useful implications, which, again, are mentioned in the text.

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?

This proposal moves the 822 (actually [2[821) trace headers from the headers (i.e., part of the message body / payload) into the SMTP envelope. By doing so, it provides what I think of as a cleaner envelope because, today, SMTP servers work with both the envelope (as defined in SMTP transactions) and also with the headers (because they need to push the trace information into them). See Nathaniel's notes and my response to them.

2) Cleaner SMTP envelope minimizes mail relay issues.

See above and the draft.

3) Syntax Error checking.


Is this correct?

See above, Nathaniel's notes, and my response.

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

See above and the draft.

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 validation?

Unless information additional to that which 2821 requires/ permits in Received is provided somehow, there is no meaningful and reliable way to do such validation, especially using envelope (plus Received field) information only. See my response to Nathaniel and, if you think such validation would be useful, please start writing --not email but an internet-draft.

What is considered the ENVL header?

It is not a header, it is, under this proposal, an SMTP command.

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.

Please see the section called "Trace Information" (4.4, I think) in RFC 2821. Also please read section 5, item 2, of the posted draft -- it is really very clear about this.

Much more generally, "software engineers" and others who choose to start implementing -- or even to start commenting on -- documents they haven't taken the time to read and make a serious attempt to understand are a menace to themselves and to their employers (if any) and users. Many times, a first-draft proposed protocol specification is not as clear as it should be (and certainly mine are often not): that is one of the many reasons we post drafts for comment and review and why both the IESG and the RFC Editor review them (at least the standards-track subset) for clarity. But, in this case, I deliberately used the 2821 (and 821 and earlier) terminology of "trace fields" (or "trace information") rather than saying "Received: and Return-path:" and then I wrote a paragraph explaining why I did that. Expecting people to read, and keep track of, every word and provision would probably be unreasonable if this draft were the length of 2821, but, exclusive of boilerplate and structural elements, this one is only about 4 1/2 pages long -- and trying to keep it short was precisely the reason I didn't bundle this proposal with others in the group (again, see the discussion with Nathaniel). It really does no one any good if someone has to repeat the comments of an I-D on the mailing list (and, often, again in an WG or BOF session) because someone has reacted to it without reading it, whether the person who isn't reading the text identifies him or herself as a "software engineer", an "IETF guru", or something else.

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

    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.

First of all, the text is very explicit (section 3 (5)) that there is no "good ahead" handshake after the ENVL command. It also specifies (same section) that what is sends is _only_ trace field information, not miscellaneous headers.

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?

Since I don't know what a "DATA header" is, I have no idea what you are asking about.

    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.

See above.

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.

That is very encouraging, although I would encourage you to read and understand the proposal, and probably to follow the discussion that is likely to unfold on this list (and, for part of the work, the ietf-imaa one) before committing yourself to implement anything.


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