🚀 go-pugleaf

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.