[Top] [All Lists]

Re: comments on draft-crocker-email-arch-01

2004-12-22 17:20:14

On Wed December 22 2004 17:17, Dave Crocker wrote:

  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

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.

Yes.  I remarked on that a half-year ago on the mail-ng
list (,
and the issue came up recently on the ietf-822 list

So, I'm not kidding. We really screwed up on this issue.  

Only about a week left to catch the "understatement of
the year" prize :-)
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.

That would certainly include Return-Path (which is
supposed to be generated from MAIL FROM on "final"
delivery in any case) and Received (nee Mail-From)
fields. Also Disposition-Notification-{To, Options},
the newfangled Caller-ID, etc.
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'.

Well, as long as we're in quibbling mode... while
822 is the current full Standard, 733's title says
it's a standard (the RFC Index says status is UNKNOWN),
and RFC 561 (the first in the 561-680-724-733-822-2822
chain of message format RFCs) speaks of standardization.
On the transfer protocol side of the aisle, 821 is a
full standard, whereas its SMTP predecessor, RFC 788,
has status unknown and doesn't claim to be a standard
(merely a specification of protocol). Its non-simple
predecessors, RFCs 780 and 772 have similar status and
character. Likewise for the versions of FTP (RFC 765
and earlier) which included the MAIL and/or MLFL