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

[william@xxxxxxxx]

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@xxxxxxxx