Errors-to: owner-drums@CS.UTK.EDU
To: Jacob Palme <jpalme@dsv.su.se>
Cc: ietf-drums <drums@CS.UTK.EDU>
Subject: Re: "Reply-To" 
In-Reply-To: Your message of "Thu, 27 Jul 1995 11:13:35 +0200."
             <Pine.SUN.3.91.950727110617.10022E-100000@ester> 
Date: Tue, 15 Aug 1995 14:38:28 +1000
Message-Id: <10390.808461508@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Thu, 27 Jul 1995 11:13:35 +0200 (MET DST)
    From:        Jacob Palme <jpalme@dsv.su.se>
    Message-ID:  <Pine.SUN.3.91.950727110617.10022E-100000@ester>

I know this is a rather late reply, but I'm still just catching
up with post IETF mail (not being totally insane, I took a
couple of weeks vacation immediately after it...)

    RFC 822 writes the following about the Reply-To field:

    This has caused a lot of problems for implementors.

I'd phrase that as "caused implementors to be unsure of
the meaning of the field" - I doubt that many (just a few)
have actually lost much sleep over the issue.   But that's
irrelevant, sorry.

    The cause of the problem is that most mailers have two
    commands, ...

Here I think you are focussing on the wrong problem.   There
is not a lot we can do to constrain the options given to users
when replying to messages, nor should we.

I believe that the coprrect approach to this problem is to
set out a meaning for the field, and then leave it to the
implementors to make the correct choices (a good mailer should
have more than two choices anyway).

Some time ago (years ago), when faced with the same problem,
I asked Dave Crocker (as the obvious authority) I believe, who
gave an answer to this problem which has satisfied me ever since.

I'm sure he will correct me if I misrepresent him (or if by
some chance it wasn't Dave at all) - the gist of this was that
Reply-To is the sender's way of telling the recipient who the
sender believes replies should be sent to.   The sender can
add as many addresses there as needed to this field, and
that way can indicate their preference for replies to any
set of recipients they choose.

Given that interpretation of Reply-To there's really little
doubt as to the behaviour of the recipient's mailer's basic
"reply" command - it should send to the addresses in the
Reply-To header, all of those addresses, and only those
addresses.

Other "reply to these particular addresses" type commands
in the mailer can do whatever they want.  "Reply to sender
only" would simply select the From: line address.

Given that:
    
    To eliminate this problem, my suggestion is that the text in RFC 822
    is changed, to clearly indicate that "Reply-To" is *only* meant to
    be used as a replacement for the names in the "From" field.

I cannot support this recommendation.

Note that the From: field should be settable by the original
sender, if the only problem requiring Reply-To were to handle
cases where the sender's From: field was inappropriate for
replies, that would probably be better handled by making it
clear that the From: field can be altered.

Further:

    If there is a need to indicate in the heading of a message a replacement
    for all the recipients of a message, this could be handled by a new
    heading field. One possible name for such a new heading field might
    be "Followup-To",

I would support this even less.   I'm afraid I absolutely
cannot support the re-use of usenet header names for purposes
that are not identical to their use in usenet.  Followup-To
in usenet contains newsgroup names, which are nothing like
e-mail addresses (local-part@fqdn), and hence would not be
a suitable choice.

Fortunately, if we decide on Reply-To as I suggest above,
and add wording to make this usage clear, we no longer need to
invent a header for this purpose, as Reply-To does exactly
what is required.

kre