ROODE@SRI-NIC.ARPA (David Roode) (02/20/84)
I sometimes wish the so-called envelope information on an SMTP transaction coming into my host were retained once the message was delivered to its appropriate mailbox. The motivation is that there are multiple names by which my mailbox may be refered to. Sometimes it would be useful to be able to identify which was used for a particular message, but that information is not listed in the standard headers. This would be the case for example when an alias had been placed on a mailing list at another site. The complete distribution is not shown in the message body because it is too long. I mention this because some people seem to feel that the user wishes to be saved from ever seeing the envelope, which is currently generally only partially available (in the form of the return path). I contend that full retention of envelope information is necessary for the user agent to function fully. -------
MRC@SU-SCORE.ARPA (Mark Crispin) (02/20/84)
You cannot retain all the envelope information in a user-accessible place, because this would defeat the purpose of bcc's. -------
ka@hou3c.UUCP (Kenneth Almquist) (02/21/84)
It seems to me that the controversy over what belongs in the envelope and stuff that "has to be in the header for the benefit of networks that don't have any concept of 'envelope' information" is due to confusion over what RFC 822 is attempting to define. If RFC 822 is supposed to define a general purpose, network independent standard for mail transfer, then it should be complete. This implies that a "Currently-To:" field should be added to it so that a piece of mail can be sent to another system without providing a destination separately. A lower level protocal must be used underneath RFC 822 to actually transfer the mail. In the case of the ARPANET, that lower level transport could remove the "Return-Path:" and "Currently-To:" fields from the header and transmit them in the envelope. The receiving process would then restore the values to the header. Is there any explanation (other than confusion on the part of the writers about what they were trying to do) why RFC 822 contains "Return-Path:" but not "Currently-To:"? Kenneth Almquist
ron@brl-vgr.ARPA (Ron Natalie) (02/21/84)
I endorse the Currently-To: idea. It can be done without destroying the BCC protection for example it could be intermixed with the Recieved lines. Delivering-To: ron@Brl-Vgr Received: From BRL.ARPA by BRL-VGR via smtp; 20 Feb 84 21:38 EST Delivering-To: info-unix@Brl-Vgr Received: From Brl-Vld.ARPA by BRL via smtp; 20 Feb 84 21:30 EST Date: Mon, 20 Feb 84 21:29:06 EST From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> To: hnij@bnl cc: info-unix@brl Subject: Re: file descriptors --> filenames In the above example the letter was Recieved on BRL from the user on the host BRL-VLD. INFO-UNIX@BRL routes to INFO-UNIX@BRL-VGR. It is the received there. INFO-UNIX is expanded and in turn delivered to me (RON@BRL-VGR). Our mail system, as well as others tries to keep the number of copies of a message down, this might be circumvented by adding these extra lines which make several slightly subtle changes. -Ron
mark@Berkeley.ARPA (02/22/84)
If we're going to go this far: Delivering-To: ron@Brl-Vgr Received: From BRL.ARPA by BRL-VGR via smtp; 20 Feb 84 21:38 EST Delivering-To: info-unix@Brl-Vgr Received: From Brl-Vld.ARPA by BRL via smtp; 20 Feb 84 21:30 EST why not just use the existing "for" subfield of Received, as provided in RFC822: Received: From BRL.ARPA by BRL-VGR for ron@Brl-Bgr via smtp; 20 Feb 84 21:38 EST Received: From Brl-Vld.ARPA by BRL for info-unix@Brl-Vgr via smtp; 20 Feb 84 21:30 EST By the way, this DOES seem like a good idea. Mark
wcwells%ucbopal.CC@Berkeley.ARPA (William C. Wells) (02/24/84)
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.wcwells%ucbopal.CC@Berkeley.ARPA (William C. Wells) (02/25/84)
Envelope Information - 1.1 correction
Oh joy. My last message:
Date: Fri, 24 Feb 84 11:30:26 pst
From: wcwells@ucbopal (William C. Wells)
Message-Id: <8402241930.AA20770@ucbopal.CC.Berkeley.ARPA>
Subject: Re: envelope information
was truncated when it was transmitted locally.
Here is the bottom part again. Sorry for the repeat.
----
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(/modifying?) this field, I think
"gateway" mail transport agents should also add/modify this field.
The "Relay-to" field tells the receiving mail transport agent that
he(/she?) is responsible only for forwarding the message to a
specific list of addressee (not all addressee in the message heading).
It takes precedence over addresses in the message heading.
It may be used by either the mail transport agent or the user agent.
One example of user agent use would be in the retransmission of
a message which was returned to the sender, and the sender does not
want to retransmit to all addressees but only to the addressee that
did not get the message.
The "Do-not-relay-to" field is intended to be used with collective
addresses where mail transport agent has or is making delivery to
specific member(s) of the collective address via other means (for
example via an alternate mail system). This assumes the mail transport
agent applying this field knows the composition of the collective
address. "header-people@mit-mc.ARPA" is an example of a collective
addresss.
"Received" - same as RFC 822.
Bill Wells, U.C. Berkeley
wcwells@Berkeley.ARPA or ucbvax!wcwellswcwells%ucbopal.CC@Berkeley.ARPA (William C. Wells) (03/01/84)
Since D.Brown has dropped by name into the pot, I guess it is time
to dust off my "Basic Message Format" again. The "Currently-to"
concept is the about the same as the "Relay-to" header field in my basic
message format. I prefer "Relay-to" since it is already defined
for military messages.
For those that have not kept a copy of my basic message format header
fields, here is a summary of the header fields.
The "envelope information" is contained in the postal heading.
-----
Basic Message Format - 2 - "Heading Components"
Version 3 - 23 Feb 84
1. Basic Message Structure:
Parts: Sub-parts:
HEADING Transmission Heading
Batch Heading
Postal Heading
Message Heading
TEXT Message Text (Body of Message)
ENDING Message Ending
Postal Ending
Batch Ending
Transmission Ending
The Internet text message format as defined by the "Standard for the
Format of ARPA Internet Text Messages" (RFC 822) has a heading and a
text. No ending is defined.
Basic message format classifies header fields into two groups, Message
Heading and Postal Heading fields. In addition to RFC 822 header
fields there are additional header for use in the Postal Heading. No
attempt has been made to define "Batch" or "Transmission" fields since
these are more the concern of the network and the transport system being
used.
"Classification", "Precedence" and "Resent-Precedence" have been added
to the Message Heading to permit user definition of these fields.
2. Basic Message Format Header Fields by Sub-Part and Component.
POSTAL HEADING
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:
_____________________________________________________
MESSAGE HEADING
SUB-PART COMPONENT FIELD
_____________________________________________________
Readdressal Date-Time Resent-Date:
Message
Heading(s) Originator's Resent-From:
Address Resent-Sender:
Resent-Reply-To:
Originator's Resent-Message-ID:
Message ID.
Precedence Resent-Precedence:
Receiver's Resent-To:
Address Resent-cc:
Resent-bcc:
Resent-Exempt:
_____________________________________________________
Original Date-Time Date:
Message
Heading Originator's From:
Address Sender:
Reply-To:
Originator's Message-ID:
Message ID.
Precedence Precedence:
Receiver's To:
Address cc:
bcc:
Exempt:
Security Classification:
Classification
Content Subject:
Information Keywords:
In-Reply-To:
References:
Encryption Encrypted:
Field
_____________________________________________________
Heading Comments Comments:
Comments Field
_____________________________________________________
Notes:
(a) Fields not defined in RFC 822 are: Posted-Date, Posted-From,
Post-ID, Postmaster, Relay-To, Do-Not-Relay-To, Resent-Precedence,
Precedence, Resent-Exempt, Exempt, Classification. The order of sub-
parts differs from RFC 822 Article 4.1 in that "source" is defined as:
source = [trace]
[resent]
originator
(b) Each sub-part of the heading begins with its corresponding date-
time field. Fields pertaining to one sub-part may not be placed in
another sub-part. With the exception of the date-time field which
begins the sub-part, the order of fields within the sub-part is not
defined. However the above order is recommended.
(c) There may be none, one or more "readdressal message heading" sub-
parts in the message heading. If there is more than one "readdressal
message heading" the later ones precede the earlier ones.
(d) "Relay-To" fields may be deleted by relaying hosts (Mail Transport
Agent programs) when delivery has been made (or protected) by that
host (MTA).
(e) Relaying hosts (MTA's) will not make changes to the Message
Heading within an mail system using basic message format. Gateways to
non-basic message format mail systems, may translate header fields
into other formats. However, if the other mail system's format is
incompatible with the basic message format, the message should be
quoted in the text of the other systems message. The same applies to
incompatible messages being entered into an a basic message format
mail system.
(f) There may be only one "Date:", "From:", "Sender:" and "Message-
ID:" field per original message. Relaying hosts may not add or change
the "Message-ID" field.
(g) "Exempt" and "Resent-Exempt" fields are optional user fields that
may be used with collective addresses to indicate that the drafter (or
user resending the message) does not want the message sent to one or
more addressees in the collective address. Syntax is same as "To":
exempt = "Exempt" ":" 1#address
resent-exempt = "Resent-Exempt" ":" 1#address
-----
Comments?
Bill Wells, RMC, USNR-R
wcwells@BERKELEY.ARPA
ucbvax!wcwells
Computing Services, 297 Evans Hall,
University of California, Berkeley CA 94720