Tony,
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.
Not quite "only", as I'll note below. Major point was that this is an issue
that has been at best extremely muddled over the life of Internet history.
Periodically, we get lost in the muddle of it.
RFC 2821 (SMTP) and its predecessors RFC 1123 (application requirements)
RFC2821 introduces the term as "SMTP envelope". My guess is that this was not
meant to suggest that the usage was peculiar to SMTP, but still, it's careful
to delimit the scope of the term.
More generally, yes, all of the transmission-related specs view the issue as
transmission-information versus non-trasmission information.
RFC 822 explicitly states that it does not have anything to do with the
envelope.
Well, not quite. Yes, it has an initial statement to that effect, but then:
4.7.3. ENCRYPTED
....
Note: Unfortunately, headers must contain envelope, as well
as contents, information.
So, I'm not kidding. We really screwed up on this issue.
Over the years the problem has come up periodically, but never got resolved in
any definitive way (or at all.) I'd like the architecture document to lock
down the concept of envelope more precisely. That is why I am suggesting the
definition:
The envelope comprises handling information
that is created
for consumption by the handling service or
created by the
handling service, primarily for consumption y
email operators
or for operational analysis.
Its predecessor RFC 724 (before SMTP) describes the concept of
Just to quibble, RFC 733 was 822's predecessor.
Everything before 733 was folks' personal comments (except, of course, the
original FTP specification.) 822 was the first email 'standard'.
The X.400 gatewaying RFCs (2156 etc.) describe a rather more elaborate
envelope than SMTP.
I think that the main lesson from gatewaying specs is to demonstrate that
envelope information is broader than the SMTP commands.
> > "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.
interesting point.
> 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.
I'm inclined to class dislcaimer-type information as representing local policy,
so that their attachment comes under the umbrella of MSA. That's a bit of a
reach, but I do not think it unreasonable.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com