Folks,
The STANDARD (RFC 822, RFC 1123) definition is just the MAIL and RCPT
commands and excludes all message data. The only other meaning of
envelope in Internet Mail specifications is the IMAP envelope which is
just the basic header fields that MUAs usually display, and has nothing to
do with transport or tracing. i.e. the definition in
draft-crocker-email-arch is an entirely new invention.
The distinction is something I've asserted for a long time. So, if I invented
it, it was a long time ago:
RFC822:
4.7.3. ENCRYPTED
...
Note: Unfortunately, headers must contain envelope, as well
as contents, information. Consequently, it is neces-
sary that they remain unencrypted, so that mail tran-
sport services may access them. Since names,
addresses, and "Subject" field contents may contain
My recollection is that the distinction was more commonly held, back then.
(And I'm not citing the above 822 text as resolving what the current draft
should say, merely trying to highlight that the issue is long-standing.)
I think that restricting 'envelope' to refer only to SMTP-level information
perpetuates a failure in Internet Mail, to characterize MHS-related
information that is in the RFC2822 header as not being part of the envelope --
it loses the distinction between MUA-MUA information and MUA-MHS (and
intra-MHS) information.
The envelope is for consumption by transport-level agents, and is
You used the language "for consumption by transport-level agents".
The language the draft uses is "used by the MHS, or generated by it."
Obviously what the current draft is trying to do is to categorize information
that is generated by the MHS as being part of the envelope, rather than part
of the message content.
That is, the draft is trying to make "message content" refer only to MUA-MUA
information.
discarded on final delivery. (Therefore IMAP and POP don't provide access
to it because it isn't there.)
Return-path?
This means that user agents can't see the
envelope. Any feature that depends on envelope information to work (e.g.
DSNs) must therefore be implemented by a transport agent. Any feature that
must be implemented by a user agent (e.g. MDNs) must be signalled in the
header not the envelope.
Failure to provide an MUA with envelope information -- notably the RCPT-TO
that produced delivery to it -- sometimes causes problems.
Interestingly, some MUAs do take note of that (approximate) information, by
implication: When doing a POP or IMAP pickup, the note the account through
which the message was retrieved, and they default to having a reply use the
email address associated with that account.
There used to be a fairly firm architectural principle that MTAs should
not have to examine the message data in order to perform their function in
the usual case.
The current draft does not change that. (Hmmm. Probably worth having the
draft include some text to that effect, since it really is an architectural
point.)
But my perspective on all this could merely be an academic point.
The purpose of the current document is to record the current model, and that
requires current consensus.
So:
CONSENSUS CALL -- Folks need to speak up about this:
1. Retain the current language about "envelope"
2. Modify the language, to restrict the term "envelope" to refer only to
the information contained in an SMTP exchange -- "consumed by", to use Tony's
language -- starting with a MailFrom and excluding its corresponding DATA.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net