Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!wales@UCLA-LOCUS.ARPA
From: wales@UCLA-LOCUS.ARPA (Rich Wales)
Newsgroups: net.mail.headers
Subject: Re: Subject: Ambiguity with the REPLY-TO field
Message-ID: <11584@brl-tgr.ARPA>
Date: Mon, 15-Jul-85 12:21:14 EDT
Article-I.D.: brl-tgr.11584
Posted: Mon Jul 15 12:21:14 1985
Date-Received: Wed, 17-Jul-85 21:12:45 EDT
Sender: news@brl-tgr.ARPA
Lines: 85

Jacob --

I thought of another way of describing the RFC822 semantics of REPLY-TO
last night, after I sent my reply to your original message.  It may seem
a bit backwards at first, but I think it makes the situation somewhat
clearer than the traditional perspective.

(1) Think of *every* message as *always* having a REPLY-TO field -- at
    least conceptually.

    Consider that RFC822 has provided a short-cut in the interests of
    brevity and non-redundancy in message headers.  Namely, if the
    "Reply-to:" header line contents are identical to the "From:" line
    contents, then the "Reply-to:" line can be (and probably will be)
    omitted from the header when the message is sent.  The receiving
    end, on finding that a message has no "Reply-to:" line in its
    header, will implicitly create a REPLY-TO field by copying the FROM
    field.

    If you assume in this way that *all* messages have REPLY-TO fields,
    the rules for constructing the recipient lists for replies suddenly
    become much simpler and more straightforward.

(2) Automatic replies *always* go to the addresses in the REPLY-TO field
    (which, by the above assumption, always exists in every message).

    The FROM field is *never* considered when addressing a reply.  To be
    sure, the REPLY-TO field may have been implicitly derived from the
    FROM field when the message was originally read and the header was
    parsed -- but once this operation has been done, we simply concen-
    trate on the fact that the message has a REPLY-TO field, forgetting
    completely about where it came from.

(3) You can then distinguish, if you wish to, between "personal" and
    "group" replies in the following way:

    (a) "Personal" replies would go only to the address(es) in the
	REPLY-TO field.

    (b) "Group" replies would go to the address(es) in the REPLY-TO, TO,
	and CC fields.

	It is debatable, by the way, whether a "group" reply should also
	go to the SENDER address(es); Section 4.4.4 (page 22) of RFC822
	states that the SENDER field should never be used automatically
	when replying to a message.  I would suggest that the SENDER
	field be included in the address list of a "group" reply only
	through invocation of a non-default option, if indeed at all.

You expressed some confusion/concern over whether RFC822's semantics of
the REPLY-TO field envision the use of this field in "personal" replies
or in "group" replies.  I think what happened was that RFC822 assumed
that the message *author* -- *not* the recipient -- would make the deci-
sion as to who would receive replies.

At the time (and probably even now), most people were accustomed to mail
systems where the only kind of reply was what you term a "personal"
reply (i.e., to the author of the message and no one else).  The REPLY-
TO field was apparently envisioned as a way to allow the message sender
to specify a wider audience for any replies to his message, without
having to assume that the person at the other end had a mail system
capable of automatically constructing a "group" reply (since most people
didn't have such mail systems anyway).

Hence, RFC822 does not really seem to provide for the kind of distinc-
tion between "personal" and "group" replies which you would like to
make.  Clearly, the issues involved were not fully appreciated, and had
not been thoroughly thought out, when the standard was written.  My
making this observation is not so much an indictment of the people
responsible for RFC822 (who, I think, did a very good job considering
the constraints they were working under) as it is a realization that
our understanding of the possibilities of electronic mail has kept on
expanding.

I think this is a good occasion to renew my suggestion that some person
or group should investigate issues such as these, and make sure that the
various kinds of recipient lists (personal replies, group replies, con-
ferences, etc.) can be adequately represented in X.400 or other appro-
priate international standards.

--
Rich Wales // UCLA Computer Science Department // +1 213-825-5683
	3531 Boelter Hall // Los Angeles, California 90024 // USA
	ARPA:   wales@UCLA-LOCUS.ARPA  -or-  wales@LOCUS.UCLA.EDU
	UUCP:   ...!(ihnp4,ucbvax)!ucla-cs!wales