Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!wcwells%ucbopal.CC@Berkeley.ARPA From: wcwells%ucbopal.CC@Berkeley.ARPA (William C. Wells) Newsgroups: net.mail.headers Subject: Re: envelope information Message-ID: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA> Date: Fri, 24-Feb-84 14:30:26 EST Article-I.D.: hou3c.329 Posted: Fri Feb 24 14:30:26 1984 Date-Received: Tue, 28-Feb-84 00:28:50 EST Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 67 To: header-people@mit-mc.ARPA Envelope Information - 1.1 Now that I have sent out my summary of basic message format header fields I would like to limit the discussion to "envelope information" (ie. my "postal heading" fields) in this discussion group (header-people@mit-mc/net.mail.headers). Discussion of the format in general and other headings should be in the "MsgGroup@brl/ net.mail.msggroup" where basic message format was discussed last year. To forestall some comments: Yes, I know that "stacked" Resent headings are incompatible with RFC 822. Now back to "envelope information". In defining the "postal heading" I was concerned with making a distinction between mail transport agent functions and user agent functions (a distinction that is not clear in RFC 822). At the time I was aware that the mail formatting/generation program could be different from the mail transport program(s) and that the mail formatting/generating program might be spooling output to the mail transport program for posting. I was thinking of the programs being on the same host, but the introduction of smart workstations (and personal microcomputers [pc]) adds a new twist to the problem. That is, how to identify mail transmissions and handle error messages when the user originates the message on a work station or pc and the mail transport agent (ie. "post office") is on another host. I do not think this latest twist is a problem if we make a clear distinction between mail transport agent header fields and user agent header fields. We will also have fewer problems if the fields that are allowed to be changed by the mail transport agent are limited. (Note: header munging or refiling messages across mail system gateways is a separate issue.) I think my postal heading fields can solve a number of these problems. In my postal heading I have defined the following fields: SUB-PART COMPONENT FIELD _____________________________________________________ Postal Postmark Posted-Date: Heading Posted-From: Post-ID: Postmaster: Return Field Return-Path: Relay Instructions Relay-To: Do-Not-Relay-To: Trace Fields Received: _____________________________________________________ The "Postmark" fields serve to identify each message transmission. --- My assumption is that a unique message identified by "Date" "From" and "Message-ID" (fields added by the user agent mail formatting/generation program) might be retransmitted to one or more addresses of the original message (for example, when the original message was returned to sender due to a host being down). The "Postmaster" field serves to identify the Postmaster of the of the originating mail transport agent. This is needed where one mail transport agent is serving several hosts, workstations and microcomputers. (This should handle the case where the originator of a message is not in the same mail domain as the Postmaster of the originating mail transport agent.) "Return-path" - same as RFC 822, with one note: In addition to the last mail transport agent adding this field, I think "gateway" mail transport agents should also add/modify this field.