I _almost_ promised Dave I'd stop beating this horse, but he's asking
for consensus. Bottom line: I can live with his current text, but it
worries me. (If that's all you want to know, you can skip the rest of
this message.)
Dave Crocker <dcrocker(_at_)bbiw(_dot_)net> wrote:
[Tony Finch <dot(_at_)dotat(_dot_)at> wrote:]
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
Note, this says "headers" "contain" "envelope information" (which does
not contradict the RFC2821 usage of "envelope").
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.
RFC2821 is clear that it uses "envelope" to refer to information in
SMTP commands. I entirely agree that that is not a sufficient definition
for an architectural overview. I merely would prefer using "extended
envelope" or some other term (different from "envelope) to refer to the
"envelope information" concept in an architectural overview.
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.
IMHO, our problem stems from trying to separate "envelope" from
"content" in the architectural overview. This would make sense if we
were talking about stuff which is _always_ removed before delivery;
but in practice, are talking about stuff which is only _sometimes_
removed before delivery. And, to make matters worse, it's information
_very_ useful for spam identification (so the trend would seem to be
to remove less of it).
The problem I see is that vagueness in a specification almost always
comes back to haunt us. (Vagueness in an architectural overview, OTOH,
very seldom comes back to haunt us.)
I'd much prefer to see clarity about what's included in "envelope"
and vagueness about what's included in "content" in a document which
is likely to sometime be cited as a _normative_ reference. "Content"
is delivered between parties with an ongoing relationship; "envelope"
information is exchanged between parties with no prior arrangement.
That is, the draft is trying to make "message content" refer only to
MUA-MUA information.
As I said, this is where I'd rather see the vagueness.
discarded on final delivery. (Therefore IMAP and POP don't provide
access to it because it isn't there.)
Return-path?
As I said, this is where I'd rather see vagueness.
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.
Surprise! I see MUAs (trying to) generate NDNs all the time. :^(
Any feature that must be implemented by a user agent (e.g. MDNs)
must be signalled in the header not the envelope.
(Tony is sticking with the RFC2821 usage; Dave isn't...)
Failure to provide an MUA with envelope information -- notably the
RCPT-TO that produced delivery to it -- sometimes causes problems.
(Note how much it helps, even just using "envelope information" to
clarify the difference...)
Interestingly, some MUAs do take note of that (approximate)
information, by implication: When doing a POP or IMAP pickup, the[y]
note the account through which the message was retrieved, and they
default to having a reply use the email address associated with that
account.
Vagueness about "content" is your friend!
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.
(Note, they _do_ have to examine trace headers to detect forwarding
loops. Of course, such loops are not "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.
Academic points are our friend!
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"
There's room for improvement.
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.
My preference, provided that we retain the "envelope information"
concept -- under a name different from "envelope" to refer to at least
RFC2821 "envelope" plus trace headers.
--
John Leslie <john(_at_)jlc(_dot_)net>