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]