The proposal does not really address "cleaner" or "more detailed" message
routing data or define standards for it. What it does is to separate the
actual message from the routing/envelope/trace data being added by mail
servers while the message is in transit. Additional proposals would have
to build on this one to define more trace data or more information about
message routing, etc.
One possible benefit is that mail filtering systems would be able to deny
message or bounce it if data is not acceptable to it (not properly signed,
bad origin, etc). This has certain processing/bandwidth benefits as
message would not have had to be processed or tranmitted in full (and then
bounced back to "envelope-from" address which may not even exist) and
could be bounced immediatly oe possibly certain authentication data could
be requested and immediatly check on.
In general to other remarks I have to agree, it is not perfectly clear if
its better to add number of additional extensions that may solve (close
holes) in current email transport system or if its better to just design
new mail transport protocol all together. However it maybe of benefit to
everybody if we work on both approaches at the same time for now and
decide what is better in the future (several prcidents to that - CRISP has
worked on both FIRS/LDAP and IRIS/XML variants; LEMONADE is working on
extensions for IMAP to do both do remote mail editing & submission and
different approach to reference parts of imap message in message being
submitted direct from end-user computer)
On Fri, 23 Jan 2004, Hector Santos wrote:
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
solve?)
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
validation?
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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net