[comp.mail.headers] rmail-reply-to-sender

sjk%grape.ads.arpa@BRL.ARPA (Scott J. Kramer) (11/18/86)

Speaking of mail replies, there's an annoyance related to using a
REPLY-TO field, which I currently use because the host I'm sending
from isn't recognized on the Internet.

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.

scott

mrose@nrtc-gremlin.arpa (Marshall Rose) (11/18/86)

Well, only Dave Crocker knows for sure, but I think this interpretation is
correct:

New message (reply)		Old message (being replied to)
------------------		------------------------------
To:				use Reply-To: if present,
				otherwise use From: if present,
				otherwise use Sender: if present
				otherwise use Return-Path: (gag)

cc:				use To: and cc: if present
(including a cc: is at the
user's option-- some people
prefer to omit the cc:)

For an example of the rules that MH uses, look at the standard "replcomps"
file distributed with MH.  This is a "simple" formatting facility which
builds the reply draft for the user.

Note that the answer to your "have CC's get replies if I use REPLY-TO" query
depends on the recipient of the message, NOT the sender.

/mtr

MRC%PANDA@sumex-aim.arpa (Mark Crispin) (11/18/86)

NO!!!!!

A mail composition program must NEVER, repeat, NEVER!! generate a reply
to a Sender or a Return-Path.

A valid From field is required in all Internet messages.  The Reply-To
field overrides a From for reply purposes, but that does not eliminate
the need for a valid From field.  Nor does the presence of Sender and
Return-Path fields (neither of which have anything to do with a reply
address).

In this day and age when certain vendors are "certifying" their TCP/IP
implementations by testing them against random Unix systems, it is
vitally important that implementations which take excessive liberties
with the protocols be firmly suppressed.

-- Mark --
-------

mrose@nrtc-gremlin.arpa (Marshall Rose) (11/18/86)

Mark - there is a difference between working correctly and working.  Working
correctly is to ignore sender and return-path.  However this is not often
working.  In a perfect world with a diligent protocol police, we would
only worry about working correctly.  This proceeds from a false assumption:
there is neither perfection nor diligence in the Internet.  It is better
to know that you can fall back on sender and/or return path in case you have
to (when working on a poorly constructed message), than to just say "you
can't reply to that".  

/mtr

Alpern@ibm.com (David Alpern) (11/18/86)

I don't believe the SENDER field should ever be used when developing
the list of addressees for a reply.  See RFC822 on this.  (Although,
I'll agree, there are times....  My own reply code will use the SENDER
field only if an explicit option is given by the replying human.)

- Dave