I'm inclined to talk about message submission in the abstract, with some
functions typically implemented by the MUA (e.g. preparing the envelope)
and some by the MSA (header fix-ups and policy enforcement).
well, the intent was to permit the exact venue for some of these
functions (mua vs. msa) to be fluid.)
I agree, though I'm not sure this comes across very clearly in the draft.
I conclude that there's no detailed, precise definition of which parts of
the message header might constitute "handling information", and might
therefore constitute part of the Crocker-envelope. The Finch-envelope, on
the other hand, is well-defined and commonly understood.
not by crocker (...)
Just a convenient label :-)
I had not thought of my assessment on this as being particular to me,
although i know there is variation within the community. I do not have
any sense of a solid consensus within the community. If I did, I'd use
it.
I don't think I have ever seen "envelope" used to include parts of the
header before I read your document. Hmm, time for a survey I think. To
summarize the following, it seems to me that "envelope" in the context of
internet email always means the MAIL and RCPT commands preceding DATA, and
does not include any of the header. It's only when you stray into
gatewaying and other non-internet email protocols that the line gets
blurred.
RFC 2821 (SMTP) and its predecessors RFC 1123 (application requirements)
and RFC 1869 (SMTP service extensions), RFCs 3461/3464 etc. (delivery
status notifications), RFC 2076 (common header fields), RFCs 3028 etc.
(sieve) all clearly use the "not DATA" envelope. RFC 2476 (submission),
RFC 3834 (auto-responses) implicitly use the same definition.
RFC 822 explicitly states that it does not have anything to do with the
envelope. Its predecessor RFC 724 (before SMTP) describes the concept of
the envelope, using examples analogous to the SMTP MAIL and RCPT commands.
It says that "envelope-like" information may be attached to the message
header but this is evidently not strictly part of the envelope.
The X.400 gatewaying RFCs (2156 etc.) describe a rather more elaborate
envelope than SMTP. They describe the same layering of envelope and data,
the latter comprising header and body. The main difference (as I
understand it from a brief glance) is that the more elaborate X.400
envelope has space for trace fields, which internet email puts in the
message header instead.
RFC 1711 (classifications in email routing) leaves the word "envelope"
deliberately vague so that it can be applied to seven different early
1990s email systems.
IMAP (RFC 3501 etc.) is an anomaly: it has its own "envelope" which is
explicitly not the same as the SMTP envelope. The IMAP envelope is a
subset of the message header, comprising "user-to-user" fields which have
very little to do with message transmission; therefore they are not an
envelope in the usual sense. (The fields are: date, subject, from, sender,
reply-to, to, cc, bcc, in-reply-to, and message-id.)
"gateway"/"firewall":
My own preference is to have a single manglers, and then try to define
sub-categories. So, a security gateway is a firewall. a mail protocol
gateway is something like x.400/internet.
I think that gateways to other messaging environments are rather different
from manglers within an internet system, because the former try to
preserve semantics whereas the latter deliberately do not.
adding footers, such as list unsubscription instructions or stupid legal
disclaimers or ads
well, that's not a firewall. that's a mailing list and i model that as
a separate user, creating a new message...
Legal disclaimers and ads are often added by border-MTA manglers (e.g.
http://www.goldmark.org/jeff/stupid-disclaimers/). I was not thinking of
mailing lists exclusively - I was trying to be as broad as possible.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: WEST 5 TO 7. RAIN
CLEARING LATER. GOOD OR MODERATE. ROUGH TO VERY ROUGH BECOMING VERY ROUGH TO
HIGH.