ietf-smtp
[Top] [All Lists]

Re: [long] commnets on draft-crocker-email-arch-01

2004-12-22 15:18:02

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