|
Re: I-D ACTION:draft-klensin-email-envelope-00.txt
2004-01-23 19:36:12
Replying to ietf-smtp only...
Hector,
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.
Optional.
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.
<tirade>
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.
</tirade>
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.
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.
best,
john
|
|