[comp.mail.headers] reply-to

Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.arpa (11/19/86)

> FROM: Scott J. Kramer <sjk@grape.ads.ARPA>
>
> When the recipient responds to a message with a REPLY-TO which also
> has CC addresses, the CC's are omitted in the reply; only the REPLY-TO
> address is used.  RFC822 isn't specific about this; it just says "if
> REPLY-TO exists, then the reply should go to the addresses indicated
> in that field and not to the address(es) indicated in the FROM field."
>
> I'm CC'ing Header-People on this since someone there may know of a way
> to do what I'm trying to do (ie, have CC's get replies if I use
> REPLY-TO).  From what I can tell, the only way is to have a valid FROM
> field.

Hear! Hear!

The solution to your problem is something I have been arguing
for for a long time, but not yet got enough people convinced
of. There should be two different "reply-to" fields, with different
names, one to serve as a replacement for the originator only, and
one to serve as a replacement for all recipients.

Thus, if your mail system, as many of them have, has two commands
to write replies, one for replies only to the originator, and one
for replies to all recipients, then the first command should use
the value from one of the two "reply-to" fields, and the
other should use the value from the other kind of "reply-to" field.

Jacob Palme, QZ Computer Center, Stockholm, Sweden

OLE@sri-nic.arpa (Ole Jorgen Jacobsen) (11/19/86)

Jakob,
	I'll have to totally disagree with you on this, Scandinavian
loyalty or not. The issue of who your reply goes to is a matter of
taste and choice depending on the circumstances. I believe it SHOULD
NOT be made part of any protocol, but SHOULD be an option in your
local User Agent. When I started to reply to your message a couple of
minutes ago, my user agent (MM) very cleverly asked me if I wanted to
reply to "sender only" or "all". I think this (thanks to Mark
Crispin!) is exactly the right thing to do. Why add new fields to RFC
822 when you can have smarter user agents?

	I assure you that I am not the only person who has been burnt
by the "reply" function over the last ten years or so. Sometimes you
want your reply to go to "all", while other times you definitely don't.
The trouble is that so many user agents decide what "The Right Thing"
is for you and don't give you the option.


Ole
-------

Jacob_Palme_QZ%QZCOM.MAILNET@mit-multics.arpa (11/19/86)

> FROM: Ole Jorgen Jacobsen <OLE@SRI-NIC.ARPA>
>
> Jakob,
>     I'll have to totally disagree with you on this, Scandinavian
> loyalty or not. The issue of who your reply goes to is a matter of
> taste and choice depending on the circumstances. I believe it SHOULD
> NOT be made part of any protocol, but SHOULD be an option in your
> local User Agent. When I started to reply to your message a couple of
> minutes ago, my user agent (MM) very cleverly asked me if I wanted to
> reply to "sender only" or "all". I think this (thanks to Mark
> Crispin!) is exactly the right thing to do. Why add new fields to RFC
> 822 when you can have smarter user agents?
>
>     I assure you that I am not the only person who has been burnt
> by the "reply" function over the last ten years or so. Sometimes you
> want your reply to go to "all", while other times you definitely don't.
> The trouble is that so many user agents decide what "The Right Thing"
> is for you and don't give you the option.

Was this a statement of disagreement with anything I wrote?

But I agree completely with you that decisions on where to send a
reply should be up to the writer of the reply, aided by his user
agent. Since two common alternatives is to send a reply to either
only the originator, or to all recipients of the commented
message, so many systems provide simple commands for those two
alternatives which is very good.

You are questioning whether the mail protocols should contain any
support for this at all. However, there may be cases where the sender
or the system of the sender wishes to indicate that replies should
be redirected. Examples:

(1) Replies to the sender only may be redirected to the secretary
of the sender, some special folder for collecting replies to a
certain question etc.

(2) Replies to all may be redirected to avoid duplicates (do not
send me a personal copy, I will get it via the list) or because
some CC recipient with only marginal interest does not want to get
all the replies.

Since there are completely different needs for redirection in
case of replies to the originator and replies to the whole group,
there is a need for two different kinds of "Reply-to" header fields,
one for each kind of reply.

It is of course always up to the writer of the reply and his
UA to decide to which extent they want to heed the advice in
the reply-to fields. No one should be forced to send a reply
to any particular address.

kre@munnari.oz (Robert Elz) (11/19/86)

Jacob is clearly right, 2 reply-to headers are needed.  This has
no implication for control of to whom users may send replies,
obviously, someone who wants to reply to mail can send the reply
to anyone he feels like (including the return-path if he wants).

What's at issue here, is that its currently undefined what the
sender means when he inserts a reply-to header, that is, what
information he's trying to pass to the recipient of the mail.

There are two reasonable meanings.  One is that the sender is
saying "Don't reply to the From: address, its not where I
want replies to go, use this address instead".  The other is
"I would prefer if you would send replies only to this address,
and not to others on the From, To and Cc lines".

RFC822 doesn't make it clear which of these meanings a Reply-To
header is intended to have.  One solution would simply be to
make that clear.  But then we'd have a useful possible meaning
with no way to generate it.  The easy way to fix that is to allow
a new header for the meaning that's left out.

The only affect any of this will have on the recipient of a message
would be the default addresses that the "reply" command in the
mailer sets up in the outgoing message.  Nothing is going to prevent
users replying to messages from modifying those addresses in any
way they see fit.  (I sometimes "reply" to a message, and end up sending
the reply to no-one who saw the original message, or whose address
was mentioned in it anywhere...)

Robert Elz			kre%munnari.oz@seismo.css.gov