Internet-Draft K. Moore
Expires: 24 February 2005 University of Tennessee
24 August 2004
NoReply Header Fields for Internet Mail
draft-moore-mail-nr-fields-00
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This memo introduces new header fields for use in Internet email, to
allow the author of a message to specify primary (To) and secondary (Cc)
recipients who, in the author's opinion, should not be recipients of a
reply to the message. These new fields are designed to be highly
compatible with pre-existing mail handling programs, and to facilitate a
graceful transition.
If this document is favorably received, it is the author's intent to
submit this document (as an individual submission) for consideration for
Proposed Standard status. Unless IESG directs otherwise, public
discussion of this document should be on the ietf-822@imc.org mailing
list. Comments may also be sent to the author.
Moore NoReply Fields [Page 1]
Internet-Draft 24 August 2004
1. Introduction
A common problem in long electronic mail conversations is for recipients
who are included on early messages to receive a copy of every subsequent
message in the conversation, regardless of whether it is appropriate for
them to be included. In many cases a recipient will only need a copy of
the first message in the conversation. For instance, if A sends a
request to B, who then delegates the request to C, it is generally clear
and polite for there to be a "handshake" message sent to all of A, B,
and C indicating that the request has been delegated - not just so that
A, B, and C are all aware of the change, but also so that they are aware
that the others are aware of the change. However, subsequent messages
in that conversation might be appropriate for only A and C - since B may
well have delegated the request in order to "get out of the loop".
Another common variation on this theme is for an individual D to send a
message to a mailing list, and to receive a reply from one of the list
members E with a CC to the list address. It may be useful and
appropriate for E to CC the list on his first reply, if only to let the
list know that someone has responded to D's message. However, D and E
might continue their conversation for several more messages, copying the
list each time. If their conversation is too peripheral to the list's
topic, or too detailed for general discussion on the list, the copies of
the messages between D and E will annoy the list subscribers and may
disrupt other conversation on the list.
In an ideal world, every author of a reply would check the To and CC
fields of his reply and make sure that the reply is going to the right
set of recipients. In the real world, for a variety of reasons, this
doesn't happen. Sometimes the author of a reply doesn't know everyone
who was a recipient of the subject message and whether it is appropriate
for each of them to each get a reply. Sometimes the mail user agent
does not make it convenient for authors to edit the recipient lists of
their replies - or (to put it another way), it's too easy for the author
of the reply to accept the user agent's default recipient list without
question.
The purpose of the new header fields defined in this memo is to provide
a message author with a way to send a message to recipients while
indicating a preference that those recipients not be recipients of
replies to that message.
1.1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [N1.RFC2119].
Moore NoReply Fields [Page 2]
Internet-Draft 24 August 2004
The new fields defined in this document will collectively be referred to
as "NoReply" fields. Recipients named in NoReply fields will be
referred to as "NoReply" recipients.
Within this document the term "legacy" is used to refer to software
which predates this document's adoption, or does not attempt to
implement this specification.
Various forms of the verb "present" are used to describe the process by
which a mail user agent communicates portions of a message to a user.
"Present" is used instead of "display" because a mail user agent may
communicate such information using other than visual means, e.g.,
audibly or via a Braille terminal.
Most of this document is informational in nature, supplying background
material and/or analysis of the anticipated impact of this extension to
the mail protocols. Normative sections of this document - those which
impose requirements on implementations which claim to conform to this
specification - are marked with the notation "(N)" in the section title.
Subsections of normative sections are normative.
2. The To-NoReply and Cc-NoReply fields
2.1. Purpose
Like other recipient header fields, the To-NoReply and Cc-NoReply fields
serve different functions at different phases in the processing of a
message. In describing the purpose of these new fields it is necessary
to distinguish between these phases: "composition" (by the message
author), "submission" (by the author's mail user agent (MUA) to the
message transport system), "presentation" (display of the message to a
recipient), and "reply" (when a message is composed by a recipient in
response to the original message).
a. During the "composition" phase, the author may use the To-NoReply
and/or Cc-NoReply fields to indicate (a) that the listed addresses
should receive a copy of the message being composed, and (b) the
author's preference that the listed addressees not be included in
any reply to the message being composed.
NOTE: Internet Mail specifications generally do not define the
"user interface" by which an author composes a message or specifies
the recipients of that message. In particular, there is no
requirement that an MUA allow the author of a message to specify
the recipient list in the form of header fields. However, it is
assumed that MUAs for which the author specifies recipients by
typing in To or CC fields, may (once modified to support this
specification) also allow the author to specify To-NoReply and
Moore NoReply Fields [Page 3]
Internet-Draft 24 August 2004
Cc-NoReply recipients in a similar fashion.
b. During the "submission" phase, the To-NoReply and Cc-NoReply fields
may be used to derive the list of envelope recipients (e.g. the set
of recipients to be included in MAIL FROM commands in the SMTP
[N2.SMTP] or SUBMISSION [N3.SUBMISSION] protocol), similar to the
way that recipients listed in the To and Cc fields are also
extracted for inclusion in the message envelope.
c. During the "presentation" phase, the To-NoReply and Cc-NoReply
fields indicate to the recipient (a) that the addresses in these
fields were also sent a copy of the same message and (b) that the
sender's preference is that these addresses not be included in
replies.
d. During a "reply" phase, the To-NoReply and Cc-NoReply fields are
used by the reply author's MUA to determine which recipients should
not, by default, receive a copy of the reply. (However the MUA
should allow the reply author to change the default).
2.2. Specification (N)
2.2.1. Syntax
The syntax of the To-NoReply and Cc-NoReply fields is given by the
following ABNF [N4.ABNF] fragment:
to-noreply = "To-NoReply:" address-list CRLF
cc-noreply = "Cc-NoReply:" address-list CRLF
where the nonterminal symbols "address-list" and "CRLF" are as defined
in [N5.RFC2822] and [N4.ABNF], respectively.
A minimum of 0 and a maximum of 1 of each of these fields is permitted
in a message header.
Encoded-words as specified in [N6.EWORD] MAY be used in the "display-
name" portion of a "mailbox" or "group" (as defined in [N5.RFC2822])
within a To-NoReply or Cc-NoReply field, or within a "comment".
2.2.2. Composition of messages
MUAs which allow authors to specify recipients in the form of RFC2822
header fields SHOULD allow them to specify To-NoReply and Cc-NoReply
fields also.
Moore NoReply Fields [Page 4]
Internet-Draft 24 August 2004
A different interface MAY be provided to permit the author to specify
NoReply recipients. For example, an MUA might provide a "check box" for
each recipient address to permit the author to specify whether that
recipient should receive a reply.
2.2.3. Submission of messages with NoReply recipients
After message composition and prior to message submission, if there are
any recipients which the author has indicated should not receive
replies, the MUA MUST include these recipients in To-NoReply and/or
Cc-NoReply fields, as appropriate. These fields MUST be included in the
message as submitted to the mail transport system.
During message submission, any recipients listed in To-NoReply or
Cc-NoReply fields MUST be included in the envelope recipient list (e.g.
SMTP or SUBMISSION MAIL FROM command).
Note: this has implications for MUAs which use a separate program (e.g.
"sendmail -t") to extract envelope addresses from the message header,
and submit the resulting message and envelope to the mail transport
system. An MUA MUST NOT use such a program to derive the message
envelope unless that program is reliably known to implement this
specification. (See section 3.2.)
2.2.3.1. Blind copy recipients
A message MAY be addressed to one or more "blind copy" (Bcc) recipients.
In such cases it is generally appropriate for an MUA to send slightly
different versions of a message to the "blind copy" recipients than that
sent to the other recipients, so that that the "blind copy" recipients
see their addresses in the Bcc field, and the other recipients will not
see the addresses of "blind copy" recipients. An MUA MAY alter the copy
of the message sent to "blind copy" recipients to remove the To and CC
fields and to include those addresses in the To-NoReply and Cc-NoReply
fields, respectively.
Note: Since an earlier version of the mail specification [I1.RFC822]
required at least one recipient field, and some mail filters were known
to reject messages lacking such a field, MUAs that move To and CC
recipients to NoReply fields for "blind" copies of messages should
include a Bcc: field in those copies. This is also desirable for other
reasons, even though it is not required. However since Bcc fields are
sometimes deleted by legacy mail transports, it may also be prudent to
add a dummy To or CC field. (e.g. "To: non-bcc-recipients:;")
Moore NoReply Fields [Page 5]
Internet-Draft 24 August 2004
2.2.4. Presentation of messages containing NoReply fields
When presenting a message with a To-NoReply and/or Cc-NoReply field in
its message header, an MUA SHOULD present the addresses in those fields
in a fashion similar to the way that the addresses from the To and Cc
fields are presented. An MUA SHOULD present NoReply addresses in a way
that they can be distinguished from the other recipient addresses, and
that it is obvious to the recipient that these addresses will not, by
default, be copied on replies.
Processing of MIME encoded-words SHOULD be performed when presenting
To-NoReply and Cc-NoReply fields.
2.2.5. Composition of Replies to messages containing NoReply fields
To-NoReply and Cc-NoReply fields of a subject message MUST be ignored by
default when composing a reply to that message, even if the same
addresses occur in To or Cc or other recipient fields of the subject
message.
A MUA SHOULD provide a means for a user to override the default address
list used in a reply.
2.2.6. Processing by Message Transfer Agents and Intermediaries
In general, to preserve the transparency of the mail system, MTAs and
other intermediaries are expected to leave message headers unchanged,
except for the addition of Received and Return-Path fields as required
by [N2.SMTP]. However, it is recognized that in practice some MTAs and
intermediaries do modify addresses in message header fields,
occasionally for defensible reasons. An MTA or intermediary that
modifies addresses in To or CC fields MAY also modify addresses from
To-NoReply or Cc-NoReply fields in a similar manner. An MTA or
intermediary may claim support for this specification if its
implementors have explicitly considered the effect of NoReply fields on
the function of the intermediary and have performed and tested any
modifications necessary to accommodate them.
Mailing lists and other special-purpose agents which make decisions
about how to process a message based on recipient header fields (for
instance, whether a particular recipient is listed, or based on the
number of recipients listed), MAY include To-NoReply and Cc-NoReply
fields in their analysis. The appropriate handling of these fields in
special-purpose agents must be determined on a case-by-case basis. A
mailing list program or special-purpose mail handling agent may claim
support for this specification if its implementors have explicitly
considered the effect of NoReply fields on the function of the agent and
Moore NoReply Fields [Page 6]
Internet-Draft 24 August 2004
have performed and tested any modifications necessary to accommodate
them.
3. Effect on legacy software
This section attempts to describe the effects of introducing To-NoReply
and Cc-NoReply on the vast installed base of mail handling software.
3.1. Effect on legacy mail user agents
When presenting a message containing To-NoReply or Cc-NoReply fields,
legacy mail user agents (MUAs) will not present those fields by default.
Some MUAs can be configured to present arbitrary header fields. Such
MUAs might or might not perform encoded-word processing before
presenting them. MUAs that do perform encoded-word processing of
arbitrary fields can be expected to present some To-NoReply and
Cc-NoReply fields incorrectly, as processing of encoded-words varies
between unstructured fields and structured fields, and the legacy MUA
will not be aware that NoReply fields are structured.
When replying to a message containing To-NoReply or Cc-NoReply fields,
legacy mail user agents will ignore these fields and not include the
addresses in the destination fields of replies. This is the desired
behavior.
When composing a message, a legacy mail user agent that provides a fill-
in-the-blank style interface for specific fields will not provide such
an interface for To-NoReply and Cc-NoReply fields. This will serve to
deter use of NoReply fields by users of MUAs that would not handle them
properly during message composition or submission.
Some MUAs allow arbitrary fields to be specified by the message author.
These MUAs will permit the author to specify the To-NoReply and
Cc-NoReply fields; however, the legacy MUA will not realize that these
fields contain addresses to which copies of the message should be sent.
Legacy MUAs will not recognize To-NoReply or Cc-NoReply fields as
recipient address fields when searching stored messages.
3.2. Effect on message transport and intermediaries
In general, no changes to pure message transport agents (MTAs) are
necessary or appropriate.
Some programs that primarily provide MTA functionality also provide an
interface that implements part of the MUA's function by parsing message
headers and deriving an envelope recipient list from those headers.
("sendmail -t" is the most obvious example.) Legacy programs of this
Moore NoReply Fields [Page 7]
Internet-Draft 24 August 2004
type will not recognize the To-NoReply and Cc-NoReply fields as
recipient fields, and therefore will not add addresses from these fields
to envelope recipient lists. This is a problem, especially if an MUA
that does recognize To-NoReply or Cc-NoReply tries to use the
"sendmail -t" interface to send a message for which the user has
included such fields. It is recommended that new MUAs which provide the
To-NoReply or Cc-NoReply interface not use a "sendmail -t" or similar
interface, but instead derive the recipient lists themselves and supply
that recipient list to the initial MTA or mail submission agent.
3.3. Effect on legacy message stores and archives
Legacy message stores and archives will not recognize To-NoReply or
Cc-NoReply fields as recipient fields. If a user specifies search
criteria that include recipient addresses, such message stores or
archives will not search the To-NoReply or Cc-NoReply fields unless the
user explicit directs the software to do so. Not all archives or
message stores provide a means of doing this. Even then, encoded-word
text in such fields may not be searchable.
3.4. Effect on legacy mail gateways
Legacy mail gateways will into other systems will not recognize
To-NoReply or Cc-NoReply fields as address fields. Such fields might or
might not be preserved as text, or in a form which can be restored
should the message be forwarded back into an Internet mail world.
3.5. Effect on other legacy programs which examine message headers
In general, programs which examine address headers (e.g. mailing lists,
automatic responders) as part of their processing will not recognize
To-NoReply or Cc-NoReply fields as containing recipient addresses. Such
software may treat a message differently depending on whether some
addresses appear in the To-NoReply or Cc-NoReply fields versus the To or
CC fields. In some cases, this is appropriate - for example, a
"vacation" program might not respond to a message for which the
recipient address appeared in a To-NoReply or Cc-NoReply field, when it
would have responded had the address appeared in a To or CC field. In
other cases, this can cause surprising or annoying behavior. For
instance, a message with a large number of Cc-NoReply addresses might
get forwarded to a list when the same message would have been filtered
if those addresses had been in the CC field.
4. Modifications needed to support NoReply fields
Moore NoReply Fields [Page 8]
Internet-Draft 24 August 2004
4.1. Modifications needed by Mail User Agents
MUAs should have their "compose" interfaces modified to allow authors to
specify whether individual recipients should not receive replies to the
message being composed. This may be done by allowing the author to
specify a "noreply" option for each To and CC recipient, or by allowing
the author to supply NoReply fields, or by some other means.
MUAs that allow authors to supply message headers for messages being
composed should be modified to recognize NoReply fields as containing
recipients, and extract recipients from those fields for inclusion in
the envelope when the message is submitted to mail transport.
MUAs should have their message display routines modified to parse
NoReply fields according to the syntax indicated in this memo, to
perform encoded-word processing on those fields for display purposes,
and to present these addresses to the recipient. The particulars of how
such addresses are displayed will vary from one MUA to another. For
instance, an MUA might display the To-NoReply recipients along with the
To recipients (and similarly for CC) with some visual or other
convention to distinguish the "noreply" recipients; or it might display
them as separate header fields.
MUAs that use the "sendmail -t" interface (or a similar interface) to
submit mail to the mail transport system should be modified to instead
perform their own recipient list extraction, because of the possibility
that the "sendmail " or other program will not recognize NoReply fields.
(They can still use "sendmail", or a similar program, to submit
messages, provided that the MUA supplies the envelope recipient list and
the submission program is invoked in a way that it will not attempt to
derive the envelope recipient list from the message header.)
It may also be desirable to modify MUAs to use NoReply fields for all To
and CC recipients in messages sent to blind copied recipients. (See
section 2.2.3.1.)
4.2. Modifications needed by message transport agents and intermediaries
MTAs and other intermediaries that extract information from recipient
address fields for logging, filtering, or other purposes, may need to be
modified to examine NoReply fields also.
MTAs that rewrite header recipient addresses (even though this is not
recommended) should be modified to also rewrite addresses in NoReply
fields, for the sake of consistency.
Moore NoReply Fields [Page 9]
Internet-Draft 24 August 2004
4.3. Modifications needed by message stores and archives
Message stores and archives which provide search capability need to be
modified to treat NoReply fields as recipient fields for indexing and
searching purposes.
4.4. Modifications needed by mail gateways
Mail gateways accepting Internet mail for relaying into a different mail
system may need to recognize NoReply fields and map them into other
fields that exist in the destination system. There are two goals in
doing so: The first is to discourage the automatic construction of
replies to "noreply" recipients. The second is to disclose the
addresses of "noreply" recipients to the recipients of the gatewayed
message, as naturally as possible.
In some cases it might be reasonable to treat "noreply" recipients from
Internet mail as "blind copy" recipients in the destination mail system,
especially if those recipients' addresses will still be visible by the
recipients of the gatewayed message.
In the event a message is routed from Internet mail transport through a
gateway into a different mail system, and then forwarded back through a
gateway into Internet mail, it will be useful to preserve the NoReply
fields at the first gateway so that they can be restored at the second.
4.5. Modifications needed by other programs
Other mail-processing programs may need to be modified to understand
NoReply fields, but the specifics must be determined on a per-program
basis.
5. Rationale for design decisions and comparison with other approaches
5.1. "Group Reply-To" fields
Various proposals (e.g. [I2.MAIL-FOLLOWUP-TO]) have been made for a
"group reply to" field, which would be used by a MUA instead of the
"reply-to" field of the subject message when composing a "group reply"
or "reply to all". These proposals have some common goals with the new
fields described in this memo - in particular, the desire to permit the
author of a message to specify that certain recipients should not
receive replies. However, since these new fields are not recognized by
recipients' legacy MUAs, there is little incentive for senders to supply
them. By comparison, the NoReply fields do more-or-less the "right
thing" with legacy MUAs.
Moore NoReply Fields [Page 10]
Internet-Draft 24 August 2004
For MUAs that allow authors to specify recipients as header fields, the
author also believes it is more natural for a message author to specify
"don't reply to these recipients" than to specify "reply to addresses X
and Y if the recipient is replying to just the author, and to A, B, and
C if the recipient is replying to all".
However, the NoReply field do not allow the message author to specify
different sets of recipients for "replies to author" and "replies to
all". In that sense this proposal is less flexible than the "group
reply" proposals.
5.2. "Do-Not-Reply:" field
The author also considered defining a field which would cancel the
"reply-ability" of addresses appearing in other fields. Such a field
would be no more compatible with legacy recipient MUAs than the "group
reply" proposals, since legacy MUAs would ignore the Do-Not-Reply field
and send replies to the full set of From (or Reply-To), To, and CC
recipients. It would also be a departure from a longstanding practice
in Internet mail architecture - in that existing header fields do not
change the meanings of other header fields.
6. Security Considerations
The introduction of NoReply fields is not believed to introduce new
security risks.
There is a risk that NoReply fields will be hidden from users of legacy
MUAs, and thus, that recipients will act on the assumption that the
NoReply recipients did not receive copies of the message. However, a
similar risk already exists in connection with Bcc processing. In
general Internet mail provides no way for a recipient to know whether or
not the same information was disclosed to others via a separate message
transmission, or via other means.
7. References
7.1. Normative References
[N1.RFC2119]
Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels. BCP 14, RFC 2119, March 1997.
[N2.SMTP]
Klensin, J., ed., Simple Mail Transfer Protocol. RFC 2821,
April 2001.
Moore NoReply Fields [Page 11]
Internet-Draft 24 August 2004
[N3.SUBMISSION]
Gellens, R., Klensin, J., Message Submission. RFC 2476,
December 1998.
[N4.ABNF]
Crocker, D., ed., Overell, P. Augmented BNF for Sytnax
Specifications: ABNF. RFC 2234, November 1997.
[N5.RFC2822]
Resnick, P., ed., Internet Message Format. RFC 2822, April 2001.
[N6.EWORD]
Moore., K., MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text. RFC 2047,
November 1996.
7.2. Informative References
[I1.RFC822]
Crocker, D., Standard for the format of ARPA Internet text
messages. STD 11, RFC 822, August 1982.
[I2.MAIL-FOLLOWUP-TO]
Bernstein, D., Mail-Followup-To and Mail-Reply-To.
http://cr.yp.to/proto/replyto.html
8. Author's Address
Keith Moore
Computer Science Department
University of Tennessee, Knoxville
1122 Volunteer Blvd, #203
Knoxville TN 37996-3450
USA
9. Copyright Notice
Copyright (C) The Internet Society 2004. This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
Moore NoReply Fields [Page 12]
Internet-Draft 24 August 2004
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Moore NoReply Fields [Page 13]