[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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 <chris.newman@innosoft.com>

10.3    Applications Area Director(s):

Keith Moore  <moore+iesg@cs.utk.edu>
Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>

10.4    Area Advisor

Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>

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/

--
                <a href="http://www.ccil.org/~esr">Eric S. Raymond</a>