Re: Reply-to and what the standards have to say about it.
Hi,
I scanned the following RFC's; and gleaned (in strict
chronological order), what they say about the reply-to field. The
standards scanned were: 822 987 1026 1123 1137 1138 1148 1327 1495
1838 2157 2156
In all of these, Reply-to is explicitly said to be set by the
originator or the author of the message. There is an example that
says the originator may put the mailing list address there if they
wish to. But they may not. And it was never ``designed to be used for
mailing lists'', as someone has claimed here.
I use a MUA, as I said before, that correctly allows *ME* to
be in control, and I may reply solely to the list on any list I so
choose.
I hope this clarifies things.
manoj
______________________________________________________________________
August 13, 1982 - 19 - RFC #822
Note: The "Reply-To" field is added by the originator and
serves to direct replies, whereas the "Return-Path"
field is used to identify a path back to the origina-
tor.
4.4. ORIGINATOR FIELDS
The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.
4.4.3. REPLY-TO / RESENT-REPLY-TO
This field provides a general mechanism for indicating any
mailbox(es) to which responses are to be sent. Three typical
uses for this feature can be distinguished. In the first
case, the author(s) may not have regular machine-based mail-
boxes and therefore wish(es) to indicate an alternate machine
address. In the second case, an author may wish additional
persons to be made aware of, or responsible for, replies. A
somewhat different use may be of some help to "text message
teleconferencing" groups equipped with automatic distribution
services: include the address of that service in the "Reply-
To" field of all messages submitted to the teleconference;
then participants can "reply" to conference submissions to
guarantee the correct distribution of any submission of their
own.
Note: The "Return-Path" field is added by the mail transport
service, at the time of final deliver. It is intended
to identify a path back to the orginator of the mes-
sage. The "Reply-To" field is added by the message
originator and is intended to direct replies.
4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
For systems which automatically generate address lists for
replies to messages, the following recommendations are made:
o The "Sender" field mailbox should be sent notices of
any problems in transport or delivery of the original
messages. If there is no "Sender" field, then the
"From" field mailbox should be used.
o The "Sender" field mailbox should NEVER be used
automatically, in a recipient's reply message.
o If the "Reply-To" field exists, then the reply should
go to the addresses indicated in that field and not to
the address(es) indicated in the "From" field.
August 13, 1982 - 22 - RFC #822
Standard for ARPA Internet Text Messages
o If there is a "From" field, but no "Reply-To" field,
the reply should be sent to the address(es) indicated
in the "From" field.
Sometimes, a recipient may actually wish to communicate with
the person that initiated the message transfer. In such
cases, it is reasonable to use the "Sender" address.
This recommendation is intended only for automated use of
originator-fields and is not intended to suggest that replies
may not also be sent to other recipients of messages. It is
up to the respective mail-handling programs to decide what
additional facilities will be provided.
APPENDIX
A.2.4. Committee activity, with one author
George is a member of a committee. He wishes to have any
replies to his message go to all committee members.
From: George Jones <Jones@Host.Net>
Sender: Jones@Host
Reply-To: The Committee: Jones@Host.Net,
Smith@Other.Org,
Doe@Somewhere-Else;
Note that if George had not included himself in the
August 13, 1982 - 37 - RFC #822
^L
Standard for ARPA Internet Text Messages
enumeration of The Committee, he would not have gotten an
implicit reply; the presence of the "Reply-to" field SUPER-
SEDES the sending of a reply to the person named in the "From"
field.
A.2.5. Secretary acting as full agent of author
George Jones asks his secretary (Secy@Host) to send a
message for him in his capacity as Group. He wants his secre-
tary to handle all replies.
From: George Jones <Group@Host>
Sender: Secy@Host
Reply-To: Secy@Host
A.2.6. Agent for user without online mailbox
A friend of George's, Sarah, is visiting. George's
secretary sends some mail to a friend of Sarah in computer-
land. Replies should go to George, whose mailbox is Jones at
Registry.
From: Sarah Friendly <Secy@Registry>
Sender: Secy-Name <Secy@Registry>
Reply-To: Jones@Registry.
A.3.3. About as complex as you're going to get
Date : 27 Aug 76 0932 PDT
From : Ken Davis <KDavis@This-Host.This-net>
Subject : Re: The Syntax in the RFC
Sender : KSecy@Other-Host
Reply-To : Sam.Irving@Reg.Organization
To : George Jones <Group@Some-Reg.An-Org>,
Al.Neuman@MAD.Publisher
cc : Important folk:
Tom Softwood <Balsa@Tree.Root>,
"Sam Irving"@Other-Host;,
Standard Distribution:
/main/davis/people/standard@Other-Host,
"<Jones>standard.dist.3"@Tops-20-Host>;
Comment : Sam is away on business. He asked me to handle
his mail for him. He'll be able to provide a
more accurate explanation when he returns
next week.
In-Reply-To: <some.string@DBM.Group>, George's message
X-Special-action: This is a sample of user-defined field-
names. There could also be a field-name
"Special-action", but its name might later be
preempted
Message-ID: <4231.629.XYzi-What@Other-Host>
August 13, 1982 - 39 - RFC #822
Standard for ARPA Internet Text Messages
______________________________________________________________________
RFC 987 June 1986
Mapping between X.400 and RFC 822
Reply-To:
Mapped to P2.Heading.replyToUsers.
______________________________________________________________________
Kille [Page 11]
^L
RFC 1138 Mapping X.400(88) and 822 December 1989
RFC 1148 Mapping X.400(88) and 822 March 1990
RFC 1327 Mapping between X.400(1988) and RFC 822 May 1992
Kille Standards Track [Page 89]
RFC 2156 MIXER January 1998
2.2.1. Origination in RFC 822
A mechanism of mapping, used in several cases, is to map the RFC 822
header into a heading extension in the IPM (InterPersonal Message).
This can be regarded as partial support, as it makes the information
available to any X.400 implementations which are interested in these
services. Communities which require significant RFC 822 interworking
should require that their X.400 User Agents are able to display these
heading extensions. Support for the various service elements
(headers) is now listed.
Date:
Supported.
From:
Supported. For messages where there is also a sender field,
the mapping is to "Authorising Users Indication", which has
subtly different semantics to the general RFC 822 usage of
From:.
Sender:
Supported.
Reply-To:
Supported.
___2.2.2. Reception by RFC 822
This considers reception by an RFC 822 User Agent of a message
originated in an X.400 system and transferred across a gateway. The
following standard services (headers) may be present in such a
message:
Date:
From:
Sender:
Reply-To:
4.7.3.5. Phrase form
In "Reply-To:" and "References:", the encoding 822.phrase may be used
as an alternative to 822.msg-id. To map from 822.phrase to
IPMS.IPMIdentifier, assign IPMS.IPMIdentifier.user-relative-
identifier to the phrase. When mapping from IPMS.IPMIdentifier for
"Reply-To:" and "References:", if IPMS.IPMIdentifier.user is absent
and IPMS.IPMIdentifier.user-relative-identifier does not parse as
822.msg-id, generate an 822.phrase rather than adding the domain
___________________________________________________________________
2.2.2. Reception by RFC 822
This considers reception by an RFC 822 User Agent of a message
originated in an X.400 system and transferred across a gateway. The
following standard services (headers) may be present in such a
message:
Date:
From:
Sender:
Reply-To:
______________________________________________________________________
--
It is no the shortcomings of others, nor what others have done or not
done that one should think about, but what one has done or not done
oneself. 50
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: