Network Working Group Eric S. Raymond Internet Draft draft-ietf-drums-replyto-personal-00.txt Expires: May 1998 November 1997 Reply-To Personal Proposal Status of this Document This document is an Internet-Draft. 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 as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document is a proposal for text to be incorporated in the new message format standard or published as a separate RFC. It has been prepared at the request of the DRUMS working group chair as input for discussions in the DRUMS working group and does not yet reflect a strong consensus within that group as of 21 November 1997. Abstract This proposal describes proposed language for the 822bis draft, draft-ietf-drums-msg-fmt-03.txt, that clarifies the semantics of the Reply-To header. The intention is to clarify the rather vague language in 822bis in a way which preserves compatibility with the largest possible subset of existing mail user agents. This document should be read in conjunction with Jacob Palme's Mail-Followup-To proposal (draft-ietf-drums-mail-followup-to-00.txt), which the working group chair, Jacob Palme and the author regard as a natural complement of this proposal. Table of Contents 1. Introduction 2. Originator fields 2.1 From and Sender 2.2 Reply-To 3. Destination address fields 3.1 Use of Bcc by Originators 3.2 Use of Bcc by Recipients 3.3 Use of Reply-To by Recipients 3.4 Other Assembly of Destination Fields 4. MUA Practice Summary 4.1 Summary Table 4.2 Prescriptions from Practice 5. Correspondence to 822bis draft sections 6. Security Considerations 7. Copyright 8. Acknowledgments 9. References 10. Contact Information 10.1 Author's Addresses 10.2 Working Group Chairman 10.3 Applications Area Director(s): 10.4 Area Advisor 10.5 Mailing lists: 1. Introduction While the design of RFC822 has generally well withstood the rigors of time and a vast increase in the volume and variety of email usage quite well, some ambiguities in the document have encouraged divergences in the behavior of mail user agents. Among the most disruptive of these ambiguities have been those in the the language describing the Reply-To header. When the mailer inserting this header and the mailer using the header interpret it in different ways, unexpected and distressing results can occur. For example, a message intended for the author of a previous message only may by mistake be sent to a mailing list. This proposal attempts to clarify the semantics of Reply-To in a way that is in line with the practice of the vast majority of existing mailers (including elm, Emacs rmail, the Netscape mail client, Microsoft Exchange, Eudora, Lotus Notes, and the Sun mail tool). In sections 2 and 3 we describe the intended semantics of Reply-To. In section 4 we describe the actual behavior of many existing MUAs. In Section 5 we correspond sections 2 and 3 to relevant portions of the 822bis draft. This proposal defines Reply-To as a override for the personal-reply (From) address. In order to fulfill some other functions which have been related to Reply-To (in a way that is incorrect under the intention of the 822 language), Jacob Palme's proposal describes Mail-Followup-To as an override for the address list normally assembled by an MUA's "group-reply" function. 2. Originator fields The originator fields of a message consist of the from field, the sender field (when applicable) and optionally the reply-to field. The from field consists of the field name "From" and comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name "Sender" and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field may also be included, which contains the field name "Reply-To" and a comma-separated list of one or more mailboxes. from = "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF reply-to = "Reply-To:" mailbox-list CRLF The originator fields indicate the mailbox(es) of the source of the message. The originator fields also provide the information required to reply to a message. Mail user agents typically support one or more "reply" commands which automatically assemble reply address lists from the headers of the message being replied to. Most support both "personal" replies (to the author's address only) and "group" replies (including the contents of other headers such as To, Cc, and Bcc). Although this RFC explicitly does not specify how many or what kinds of reply function must be present in a mail user agent, conforming mail user agents are constrained in how they may automatically interpret certain headers. See section 3.6.3 for information on forming the destination addresses for a reply. 2.1 From and Sender The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would go in the "Sender:" field and the mailbox of the actual author would go in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "From:" field SHOULD be used and the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. In all cases, the "From:" field SHOULD NOT contain any mailbox which does not belong to the author(s) of the message. 2.2 Reply-To When the "Reply-To:" field is present, it specifies a list of mailboxes to which the author of the message prefers that replies be sent. This list is normally interpreted as a substitute for the addresses in the "From:" field, and the author should consider this when choosing to include a "Reply-To:" field. Some mailing list management tools can be configured to add or modify the "Reply-To:" field when relaying messages from the originators to the list recipients. It is beyond the scope of this RFC to deal with mailing list issues in detail, but this practice is strongly discouraged. It makes it difficult to direct replies to the original author, and prevents the author from expressing his preference. It changes the behavior of typical user agent commands in unexpected ways, and may lead to the unintentional broadcast of private messages. The "Reply-To:" field SHOULD NOT be inserted or removed by any relaying agent except when such action is explicitly requested by the originator. See section 3.6.3.3 for uses of the "Reply-To:" field in assembly of reply address lists. 3. Destination address fields The destination fields of a message consist of three possible fields, each of the same form: The field name, which is either "To", "Cc", or "Bcc", followed by a comma-separated list of one or more addresses (either mailbox or group syntax). Both the "To:" field and the "Bcc:" field MAY occur alone, but the "Cc:" field SHOULD only be present if the "To:" field is also present. to = "To:" address-list CRLF cc = "Cc:" address-list CRLF bcc = "Bcc:" address-list CRLF The destination fields specify the recipients of the message. Each destination field may have one or more addresses, and each of the addresses receives a copy of the message. The only difference between the three fields is how each is used. The "To:" field contains the address(es) of the primary recipient(s) of the message. The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of making a copy on a typewriter using carbon paper) contains the addresses of others who should receive the message, though the content of the message may not be directed at them. The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains addresses to which the message should be sent, but which SHOULD NOT be revealed to any other recipient of the message. 3.1 Use of Bcc by Originators There are two ways in which the "Bcc:" field is used. In the first case, when a message containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is removed even though all of the recipients (including those specified in the "Bcc:" field) are sent a copy of the message. In the second case, recipients specified in the "To:" and "Cc:" lines each are sent a copy of the message with the "Bcc:" line removed as above, but the recipients on the "Bcc:" line get a separate copy of the message containing a "Bcc:" line. (When there are multiple recipient addresses in the "Bcc:" field, some implementations actually send a separate copy of the message to each recipient with a "Bcc:" containing only the address of that particular recipient.) Which method to use with "Bcc:" fields is implementation dependent, but refer to the "Security Considerations" section of this document for a discussion of each. 3.2 Use of Bcc by Recipients There are two common cases in which a "Bcc:" field appears in a message. In the first case, the message is an originator's archival copy of a message previously sent. In the second case, the message is one received from an implementation that reveals "Bcc:" to some or all of the "Bcc:" recipients, as described in section 3.6.3.1. The restrictions in this section apply only to this second case. If a "Bcc:" field is present in an original message, addresses in that field MAY be used to assemble the "Bcc:" field of a reply, but SHOULD NOT be used to assemble the "To:" or "Cc:" fields. However, the presence of a "Bcc:" field MUST NOT prevent or limit editing of any address fields in a reply, nor prevent nor limit any other form of user-specified addressing. 3.3 Use of Reply-To by Recipients If the "Reply-To" field exists, then all reply address lists assembled by the mail user agent MUST use the contents of the "Reply-To:" field in place of the contents of the "From:" field. The contents of "Reply-To:" SHOULD NOT replace any other fields (such as "To:", "Cc:", and "Bcc:") in assembling reply lists. User agents may (and typically do) permit users to edit address fields in a reply; the presence of "Reply-To:" MUST NOT prevent or limit such editing, nor prevent nor limit any other form of explicit user-specified addressing. The intent of these rules is that it be possible for a human user to override the Reply-To directive from the message originator, but only by thinking about it and taking explicit action on each message to override the mail user agent's default behavior. 3.4 Other Assembly of Destination Fields When a message is a reply to another message, the mailboxes of the authors of the original message (the mailboxes in the "From:" or "Reply-To:" fields) MAY be used to assemble the "To:" field of the reply, since that would normally be the primary recipient. If a reply is to be sent to a message that has destination fields, it is often desirable to send a copy of the reply to all of the recipients of the message in addition to the author. When such a reply is formed, addresses in the "To:" and "Cc:" fields of the original message MAY be used to assemble the "Cc:" field of the reply, since these are normally secondary recipients of the reply. 4. MUA Practice Summary In the Introduction, it was asserted that this proposal conforms to the practice of most existing mail user agents. This assertion was not made in a vacuum; the author actually collected data from DRUMS members on the behavior of different MUAs. 4.1 Summary Table The following table summarizes what we know as of November 21 1997: A = Default configuration always overrides From with Reply-To. (That is, without changing a configuration file, Reply-To always replaces From in the reply's recipient list. There is no runtime choice to override this short of manually editing recipient fields in the reply.) B = Default configuration's "group reply" command (whatever assembles From+To+Cc when Reply-To is absent) still uses To or Cc when Reply-To is present. (That is, specifying Reply-To field does not cause To+Cc to be ignored by the command that would otherwise reply to From+To+Cc.) C = Default configuration ignores Reply-To if given a non-default choice at send time. (e.g. an alternate command, a non-default answer to a dialogue question, a non-default button press in an options menu.) D = Reply-To rules can be globally reconfigured by user. (By persistent options in a GUI, or by configuration files.) E = Has `standard' two-button or two-command UI ("personal" and "group"). Exceptions are explained by a note. F = MUA allows you to edit recipient list on replies? G = MUA allows you to edit outgoing From? H = MUA allows you to add Reply-To in outgoing message. Y = yes, . = no, ? = unknown. ?? = contributor not recorded + indicates there is a footnote for this MUA Everything above the line of =s is strictly in conformance with this draft. Everything above the line of -s is arguably in conformance with this draft, and would strictly conform if the "MUST" in paragraph one of 3.3 were replaced by SHOULD. A B C D E F G H ? Reported by: - - - - - - - - - ---------------------------------- SunOS mail Y Y . . Y Y Y ? . Dan Bernstein, Robert Elz Emacs rmail Y Y . . Y Y Y Y . Eric Raymond elm Y Y . . Y Y Y ? + Eric Raymond, Matti Aarnio Netscape Y Y . . Y Y ? ? . Jamie Zawinski (the implementor) M$ Exchange Y Y . . Y Y . ? + Bill McQuillan, Larry Osterman Eudora Y Y . . Y Y Y ? . Graham Klyne, Pete Resnick Lotus Notes 4.6 Y Y . . Y Y . ? + Nick Shelness Sun MailTool Y Y . . Y Y . ? . Jamie Zawinski, John Beck dtmail Y Y . . Y Y . ? + Maurizio Codogno, John Beck Simeon Y Y . . . Y ? ? + Roger Fajman Mailstrom 2.04 Y Y . . . Y . ? + Chris Newman Emacs MH-E Y Y . . Y ? ? Y + Jamie Zawinski exmh Y Y . . Y Y Y ? + John Beck, Robert Elz xmh Y Y . . Y ? ? ? ++ Robert Elz MX (VMS) Y . . . . . . Y + Dan Wing MultiNet (VMS) Y . . . . . Y Y + Dan Wing ========================== mh Y Y . Y . Y Y ? + John Beck, Robert Elz mush Y Y . Y ? ? Y ? + Bart Schaefer (the implementor) zmail Y Y . Y Y ? Y ? + Bart Schaefer (the implementor) Emacs VM Y Y . Y Y Y Y ? + Kyle Jones (the implementor) ZmailPro ? ? ? ? Y ? ? ? + Ran Atkinson pine . Y Y Y Y Y Y ? + Eric Raymond mutt . Y Y Y . Y Y ? + Eric Raymond MailDrop 1.2d7 . Y Y . . Y . ? + Chris Newman Mulberry 1.3b3 . Y Y . . Y Y ? + Chris Newman PMDF Mail . Y Y . . Y Y ? + Chris Newman -------------------------- BSDmail . . . . . Y Y ? + Dan Bernstein, Robert Elz elm: There is no direct support for editing the From header, but once the message is composed the user can enter header editing mode, and there issue ONE "User Defined Header" -- which can be a From. The envelope address won't be altered. M$ Exchange: Exchange (and Outlook) allow sediting the From field, but you need to use View/From Field to edit it, and if you are using Exchange server, you must have send-as permissions on the account you send the mail as. This means that as a normal Exchange user, you can't put arbitrary values in the From field, but if you have the help of an administrator (or are one), you can put just about anything you want in the From field. (I count this as "no".) Lotus Notes 4.6: C&D. As shipped the Notes client contains no button for employing From: as Reply target in the presence of a Reply-to:, but the behavior of the Notes client can be customized on a site or individual basis. Such a button could be added. Simeon: a commercial IMAP4 client for Windows 3.1/95/NT, Mac, and Unix from Esys Corporation. It has one Reply button that prompts for whether you want to reply to all recipients. MH-E/exmh/xmh: all front ends to mh. You could argue that they should get Y in column D because mh allows you to prevent Reply-To overriding From via configuration. However, none of these front ends seems to include that among the options they present the user. xmh: normal reply UI is one-button, using whatever mh reply options the user has configured. mh: has a command-line interface; the reply-personal/reply-all choice is made through command-line options. MX/Multinet: These agents lack the capability to do group replies. No per-user to the reply rules modifications can be made (with either MX or MultiNet), but MultiNet does allow the system administrator to modify the behavior of the RFC822-to-VMSmail header mapping. MultiNet allows From field editing, but the feature to do it is undocumented. To edit Reply-To, both MUAs require you to exit the MUA, make a setting in the command-line environment, then re-enter the MUA. Emacs VM: you can make VM clobber Reply-To on a per-address basis via regexps. (This feature is described as "an escape chute from mailing lists that add a Reply-To:". :-)) pine: has only one reply command, but offers a group-reply option via a question when the message has multiple recipients. mutt: also has a list-reply command `L' that uses *only* To when the To address has been declared by the user to be a list. BSD mail: Most versions of BSD mail & mailx have an an `r' (reply/respond) that ignores Reply-to, and an 'R' (Reply/Respond) that uses *only* the Reply-To header if it is present; otherwise it sends to From+To+Cc. SunOS mail is an exception. Editing of recipient lists is possible but difficult, as all you get for an "editor" is the tty driver. Mailstrom: a shareware IMAP client, has "Reply to Sender", "Reply to All" and "Reply to Recipients." MailDrop: a free Macintosh IMAP client, has one reply button which brings up a dialog to adjust recipients. By default reply goes only to reply to. From may be used instead of reply-to and there is an independent "Include all recipients" checkbox. Mulberry: a commercial IMAP client, brings up a dialog to select recipients. By default it selects reply-to, to and CC addresses, but from is an option. mush: unless "edit headers" is enabled, editing of the recipient list is possible but difficult (the same tty-driver "editor" as in BSD mail). zmail: now officially "Zmail for Unix" (see next note). This is the commercial version of mush. SGI Irix's "MediaMail" is zmail under an alias. ZmailPro: officially "ZmailPro for Windows". Not actually related to zmail/mush, it's a PC-native product that was relabeled after NetManage bought zmail. PMDF mail: a MIME aware VMS mail client. An unqualified reply command will just use the reply-to header although there is a qualifier to just use the from header. Reply with the "/all" qualifier will ignore the reply-to header and use from/to/cc but there is a qualifier to use reply-to instead of from. There's also an option to use the Resent headers 4.2 Prescriptions from Practice Most existing MUAs have either the exact semantics of this proposal or those corresponding to a slight relaxation of one of its requirements (MUST to SHOULD in paragraph 1 of section 3). It is unfortunate that the one clear exception to the trend is BSD Mail, which is both popular and of sufficient historical importance to loom large in the minds of many IETF members. However, the weight of practice is clear. Mandating BSD-Mail-like semantics for Reply-To would break almost all other mailers and is thus not an acceptable alternative. 5. Correspondence to 822bis draft sections The main body of this draft contains language which is intended to replace portions of the current 822bis draft. Here is how the sections correspond: 2 -> 3.6.2 (Originator fields) 3 -> 3.6.3 (Destination address fields) Note: for those used to referring to the 02 version of the draft, these correspondences have not changed in 03. 6. Security Considerations There are no particular security risks with the "Mail-Followup-To" if implemented correctly. Instead, they will reduce the security risk of having personal messages inadvertently sent to more recipients than intended. 7. Copyright Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 8. Acknowledgments The author gratefully acknowledges the contribution of DRUMS member Bart Schaefer; most of the text in sections 2 and 3 is actually his expansion on and clarification of the original proposal language. Jamie Zawinski helped clarify the author's thinking on a number of issues. The author, however, accepts responsibility for any errors in this document. 9. References draft-ietf-drums-msg-fmt-03.txt Current draft of 822bis. draft-ietf-drums-mail-followup-to-00.txt Jacob Palme's draft on the proposed Mail-Followup-To header. 10. Contact Information 10.1 Author's Addresses Eric S. Raymond Phone: +1-610-296-5718 Thyrsus Enterprises Fax: none 22 South Warren Ave. Email: esr@thyrsus.com Malvern, PA 19355 USA 10.2 Working Group Chairman Chris Newman 10.3 Applications Area Director(s): Keith Moore Harald Alvestrand 10.4 Area Advisor Harald Alvestrand 10.5 Mailing lists: General Discussion:drums@cs.utk.edu To Subscribe: drums-request@cs.utk.edu Archive: ftp://cs.utk.edu/pub/drums/mail-archive/ -- Eric S. Raymond