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

Versions: 00                                                            
DRUMS Working Group                                               R. Elz
Internet Draft                                   University of Melbourne
Expiration Date: April 1998
                                                            October 1997


              Use of Reply-To in Internet E-Mail messages


                  draft-ietf-drums-kre-reply-to-00.txt

Status of this Memo

   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), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This draft forms part of a discussion on the appropriate use of the
   Reply-To header in e-mail messages.  This draft argues for one
   particular proposed definition of the Reply-To header.

   It is not intended that this document ever become anything more than
   an Internet-Draft.  If adopted, the text here, or a modified version
   of some parts of it, would be merged into the proposed replacement
   for RFC822.












kre                       [Expires April 1998]                  [Page 1]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997




Table of Contents

          Abstract  ................................................   1
    1     Introduction  ............................................   2
    2     Document Conventions  ....................................   2
    3     The Problem  .............................................   3
    3.1   Personal Replies  ........................................   3
    3.2   Reply to Everyone  .......................................   4
    3.3   Mailing Lists  ...........................................   5
    4     Desired Functionality  ...................................   6
    5     Possible Solutions  ......................................   7
    5.1   Using two headers  .......................................   8
    5.2   Many Headers  ............................................   9
    5.3   One other option  ........................................  10
    5.4   Resolution  ..............................................  10
    6     Suggested Text  ..........................................  11
    6.1   Field definitions.  ......................................  11
    7     Further Work  ............................................  15
    8     Security Considerations  .................................  15
    9     References  ..............................................  15
          Author's Address  ........................................  15




1. Introduction

   The DRUMS working group of the IETF is attempting to define the use
   of the Reply-To header in Internet e-mail.  This is a contribution to
   that effort, and represents an argument for one position.

2. Document Conventions

   This document makes use of the document conventions defined in BCP14.
   That provides the interpretation of some capitalised words like MUST,
   SHOULD, etc.

   There can be many different people associated in varying ways with
   the transmission of an Internet e-mail message.  Except where
   precision is necessary to separate these various roles, this draft
   will use terms like "author", "sender", and "originator"
   interchangeably, in order to make the text a little more interesting
   to read.  It will be clear where a distinction is being made between
   the various roles that can be involved in the specification,
   creation, approval, and transmission of a message.




kre                       [Expires April 1998]                  [Page 2]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


3. The Problem

   RFC822 does a particularly poor job of defining the Reply-To header.
   It is clear that the intent is that automated replies should be
   addressed to the Reply-To header instead of the From header, when a
   Reply-To is present, but other than a few examples of how Reply-To
   might be used, there is absolutely no indication at all of what it
   means.

   In particular, no explicit hint is given as to whether, when a reply
   is sent, address in the To and Cc headers of the original message
   should be included or not.  That is true for replies with no Reply-To
   header, where the answer no doubt depends upon the desires of the
   user replying.  However, where a Reply-To header is given, no
   indication is given in RFC822 as to whether the addresses in that
   header are the only addresses to which replies should be sent, or
   simply a replacement for the address(es) in the From header.

   Both approaches have been adopted by different mail user agents,
   leading to confusion and non-interoperability.

   This problem has been exacerbated by two other common use patterns.
   The first is the tendency of some mail user agents to have exactly
   two reply options - in the matter of selecting the destination
   addresses, there can be other options which control things like
   populating the reply message template with the text of the subject
   message, which are not relevant here.  These two options are
   typically characterised as being "personal reply" or "reply to
   author", and "reply to everyone".

3.1. Personal Replies

   In the absence of a Reply-To header, a personal reply (or reply to
   the author) is typically sent to the address or addresses in the From
   header.  Since the From header is defined as carrying the addresses
   of the author(s) of the message, this technique generally achieves
   the desired results.

   However, where a Reply-To header exists, things are not nearly as
   clear.  For a generic "reply", replying to the address(es) in the
   Reply-To header will generally achieve a satisfactory result.  But
   where it is the user's desire to actually send a personal reply, to
   the author of the subject message, replying to the address in the
   Reply-To header will sometimes not achieve the result desired.  This
   is because in RFC822 Reply-To is not defined as being the address of
   the authors, but rather "a general mechanism for indicating any
   mailbox(es) to which responses are to be sent." RFC822 actually gives
   three different cases where Reply-To might be used, as typical cases



kre                       [Expires April 1998]                  [Page 3]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   not an exhaustive list, without seeming to realise that the three
   cases cannot reasonably be treated identically.  Or perhaps, without
   realising that not all replies are created equal.

   For example, in RFC822 Appendix A, example A.2.4 shows a case where
   the message is sent from one person (one address in the From header),
   and the Reply-To header lists an entire committee.  It would be
   contrary to common sense to send a personal reply to the committee,
   yet that is what many common mail user agents do today.  On the other
   hand, example A.2.6 shows a case where the From: address (mailbox) is
   that of a secretary, for a user with no mailbox of their own, and
   where the Reply-To header gives the mailbox of a friend of the user,
   and where personal replies should clearly go to the address in the
   Reply-To.

   One way to avoid the seeming inconsistency of these examples is to
   note that the "use Reply-To instead of From" rule is intended to
   apply only to "automatic replies", and that for replies generated by
   humans, the address choice should generally be left to the human.
   See RFC822 section 4.4.4.

3.2. Reply to Everyone

   This kind of reply is typically used where a message has been sent to
   several people, and the user replying wishes all of those people to
   receive the reply.  Where no Reply-To header is present, this kind of
   reply is typically sent to all addresses found in the From, To, and
   Cc headers of the subject message.

   Unlike personal replies, even this simple case is not trouble free
   however.  It is often the case that one, or more, of the addresses in
   the To or Cc headers includes, but not in any transparent way, the
   address from the From header.  Where this happens, this simple reply
   can cause the author(s) of the subject message to receive two copies
   of the reply, which, to some users, is quite annoying.

   One interpretation of the Reply-To header would easily allow this
   problem to be circumvented.  That is, if Reply-To were to be defined,
   or generally regarded, as specifying all addresses which should
   receive replies, then simply listing the set of addresses from the
   various headers would cause, as near as practical, exactly one copy
   of a reply to be delivered to each end-user mailbox.  This would
   normally not include the From address(es), as our assumption was that
   one of the To or cc addresses includes the From address (but this is
   obviously at the discretion of the author of the original message).

   An obvious problem with this approach, apart from it not being
   implemented that way everywhere, is that it is directly contrary to



kre                       [Expires April 1998]                  [Page 4]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   the idea of sending personal replies to the addresses in the Reply-To
   header.  Doing so with a Reply-To header constructed as suggested
   here would certainly not result in any kind of personal reply.

3.3. Mailing Lists

   Mailing lists present an obvious example of the situation mentioned
   in the previous section.  They are, however, somewhat more
   specialised, as a mailing list can have a policy, or several, and
   where applicable, that policy can be enforced by the list itself.
   One example may be that all messages on the list, and all replies to
   messages on the list, should be sent to the list, and nowhere else.

   It turns out that this is usually easy to accomplish using the
   Reply-To header, almost regardless of which interpretation if placed
   upon it by user agents.  A list that inserts "Reply-To: the-
   list@list.site" in every message sent to the list will generally
   accomplish this.  A initial message to the list will normally be "To:
   the-list@list.site", and "From: user@some.where".  Then, the list
   adds the Reply-To header as above.  Now, when a user replies, the
   reply address can be generated using only the Reply-To, in which case
   the sole destination is the-list, or using Reply-To and To, which
   gives the-list twice, which almost always results in just a single
   copy being sent to the list (usually with the-list just once in the
   headers).  Thus it is irrelevant whether the user replying uses a
   personal reply, or reply-to everyone, and irrelevant how their MUA
   treats the Reply-To header, the same result is accomplished in all
   cases.  Further, even a chain of such replies (replies to replies to
   replies) will retain this property, which is a distinct advantage on
   many lists.

   Of course, should a user want to ignore the list policy, and send a
   reply only to the author of the subject message, using most popular
   user agents, that will often be difficult at best.  This causes many
   people to disapprove of this mailing list behaviour.  On the other
   hand, many believe strongly in this operating mode, and will not
   change it until, at least, an alternative with similar functionality
   is developed.  That will require that essentially all users,
   including those with old MUAs not updated to any new specification,
   are able to use the mechanism to reply to messages as the list
   itself, and its users, desire - at least as well as it works today.










kre                       [Expires April 1998]                  [Page 5]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


4. Desired Functionality

   When it comes to replies, there are many desires to be accommodated.
   Considering only the addresses constructed for the reply message
   there are, or seem to be, three different kinds of reply.  First,
   there is a reply to the message.  Second, there is a reply to the
   author of the message.  And third, there is a reply to everyone who
   received the original message.  Obviously, replies can also be sent
   to many other combinations of addresses from the original message, or
   to addresses not included in the original message at all, however it
   is probably safe not to attempt to consider all of those
   possibilities.  It should also be noted that it may be more correct
   to not treat any but the first kind of reply as being a "reply" at
   all, with the others being instead a new message sent to the author
   of another message, or to all the recipients of another message.
   However, it has been common to treat all of these as kinds of
   replies, so we will continue that practice here.

   To see that there are at least the three kinds of reply, consider a
   message about an upcoming conference.  It is sent from the organiser,
   to a list of potential attendees (perhaps several mailing lists), and
   with replies requested to be sent to the people handling
   registrations.  Most recipients who reply will be seeking
   registration information, those are replies to the message.  However,
   some may desire to send a comment to the author of the message,
   perhaps to point out an error in the text of the message that was
   sent.  Those are personal replies.  Others may want to reply to
   everyone, to point out that last year the conference was a waste of
   time.  They would be replies to everyone.  And of course, some may
   want to reply to some of the recipients only, perhaps to complain
   about sending this announcement on one particular mailing list, and
   to make sure that everyone who wasn't (apparently) supposed to see
   the original message does get to see the complaint about the message.
   Those replies we will ignore.

   The Reply-To header is intended, must be intended, to allow the
   sender to control, in some manner, the addresses used for these
   replies.  The header is inserted by the author of the original
   message (cases where the header is added en route not being
   considered here.) Thus, it must be the intent of the author which is
   being expressed.  The header contains addresses, and other than
   comments, only addresses.  So the intent being expressed must relate
   to addresses.  Then, from what RFC822 does say, and even without
   that, the name of the header itself, it is fairly clear that the
   Reply-To header allows the originator of a message to indicate
   addresses to be used for replies.  What isn't clear is which replies
   should use those addresses.




kre                       [Expires April 1998]                  [Page 6]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   It is clear from RFC822 that it cannot be intended that replies to
   the author of a message should use Reply-To as an automatic choice.
   Example A.2.4 makes that quite clear.  In that example, the Reply-To
   header indicates a committee, which is not the author of the message,
   but which is intended to receive replies.  A reply to the author
   which sent to the addresses in the Reply-To header would thus not be
   sent to the author of the message.  A reply to the message would
   however, and would be sent where the author requested.

   It seems less important what is done with a reply to everyone, as by
   its nature, the more addresses included the better.

   Authors of messages often want to give some guidance as to which
   addresses should receive replies, and almost as often, which should
   not.  A very common desire is to request that recipients of the
   message reply to exactly a set of addresses specified by the author.
   With that facility the originator of a message can direct replies to
   specific addresses and away from others.

   Authors sometimes also want to express conditional information as to
   where replies should be sent.  That is, for example, if you want to
   reply to everyone, reply to this set of addresses.  Or, if you don't
   want to reply to everyone, reply to these addresses.  In those cases
   the author might not want to express a preference as to whether
   recipients should reply to everyone or not, just to suggest reply
   addresses depending upon the choice made by the recipient.

   Sometimes the author may even want to say: if you want to reply to me
   (ie: a personal reply), use this address.  This seems to be a simple
   case however, the address(es) of the author(s) of the message are in
   the From: header already.  On odd occasions though, especially where
   there are multiple authors of the message (more than one address in
   the From: header) it might be desirable to designate just one of
   those, or even someone different, as the principal author, and to
   request that personal replies go just to that one author.

5. Possible Solutions

   It seems quite clear that one header cannot possibly satisfy all of
   these desires.  Therefore, and assuming that there is a requirement
   to provide solutions for all of these problems, multiple headers will
   be needed.  One of those might be Reply-To.  If not, then clearly
   Reply-To would be useless, and should simply be deprecated.  That
   option is not considered further here.

   There would seem to be two ways of dividing the problem in order to
   come up with a solution.  Reply address suggestions could be
   considered unconditional or conditional, requiring at least two



kre                       [Expires April 1998]                  [Page 7]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   headers, one for an unconditional reply address suggestion, and one
   for conditional reply address suggestions.  Alternatively, one header
   could be used for unconditional reply address suggestions, and a new
   header for each kind of conditional address suggestion that might be
   desired.

5.1. Using two headers

   In this scenario, the conditional reply address suggestion would need
   to use a new header, as the syntax of Reply-To, which it would be
   unreasonable to change, provides no way to indicate which conditions
   were being indicated.  A new header, which for the sake of argument
   here, we will call Reply-Targets, could have a new syntax allowing
   the author of the message to indicate for which classes of messages
   various sets of addresses would be used.

   Using ABNF, such a header might be constructed as:

        reply-targets = cond-target *( ";" cond-target )
        cond-target   = label ":" *address
        label         = phrase

   Undefined non-terminals ("address" and "phrase") there are assumed
   defined as in the current 822bis draft.

   The intent would be that where the recipient desires to reply to the
   class of addresses suggested by the label, the associated address(es)
   should be used.  A well known set of labels to handle the common
   cases could be defined, which would assist in user understanding of
   the functionality, while not limiting creativity for unusual cases.

   For example, a simple case:

        Reply-Targets:   Author: user@some.example ;
                         Everyone: the-list@host.xx, extra@other.host ;

   This suggests to the recipients two possible reply targets, the
   author, or everyone, and the addresses to use to send to each of
   those.

   A more complex example:

        Subject:         New mailing list starting
        Reply-Targets:   Subscribe: list-request@whatever.host ;
                         Unsubscribe: list-request@whatever.host ;
                         Send To List: ;
                         Discuss: Related Lists: ietf@ietf.org,
                                 drums@cs.utk.edu ;;



kre                       [Expires April 1998]                  [Page 8]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   In this example, assumed to be the announcement of a new mailing
   list, four possible reply targets are given.  Nothing is suggested
   for a reply to the author, thus the address(es) on the From: header
   would be used for that purpose.  Simple addresses are given for
   subscribing and unsubscribing, no address exists for sending to the
   list, which would imply that such replies are not welcome (yet), and
   for discussion, a group containing two addresses is to be used.

   The Reply-To header would then be used to indicate the address(es)
   that the author of the message believes should be used for replies to
   the message.  The two headers could both be used, to give the
   author's suggested reply address(es), and some possible alternatives.

   With such a scheme, a user agent might have two reply buttons.  The
   first would generate a "default reply" which would be sent to the
   Reply-To address(es) if any, or to the user's choice of From: or
   From:+To:+Cc: (or perhaps even From:+To:) if no Reply-To header
   exists.  The second would produce a menu of reply targets taken from
   the labels in the Reply-Targets header, with default cases of
   "Author" and "Everyone" added if not present, or if no Reply-Targets
   exists at all.

   Note, there is no suggestion here that a Reply-Targets header be
   created exactly, or even approximately, as has been illustrated here.
   This is simply an example of what could be done.

5.2. Many Headers

   In this scenario, a new header would be invented for each new kind of
   reply that may be desired for the author of a message to be able to
   direct to addresses of her choosing.  That is, there may a headers to
   indicate the addresses to be used for replies to the author, a
   different header to indicate replies to everyone, and another to
   allow the author to express her preference as to where recipients
   should reply.

   In this scenario there seems to be no particular reason to assign the
   existing Reply-To header to any one of these purposes in preference
   to the others, and the choice could be arbitrary.

   One suggestion has been that because many User Agents already use the
   Reply-To header as the standard address for the "personal reply" type
   functionality, then Reply-To should be defined for this purpose.  As
   already shown, this would be directly contrary to the uses of Reply-
   To shown in RFC822, and thus about the only guidance we have had so
   far as to how the header should be used.





kre                       [Expires April 1998]                  [Page 9]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   At least two new headers are going to be needed to follow this
   scheme, in addition to Reply-To.  That is, the one existing header,
   and two (or more) new ones.  While no real change can be made to the
   existing header's name or syntax, the new headers could be whatever
   is required.  All but one of the new headers would be conditional
   advice to the recipients, if you want this kind of reply, use these
   addresses.  The other, the one different one, would be the header
   used to indicate the message author's suggested reply addresses.
   Thus, there are two categories, header names, and header functions,
   each of which has one special case, and some number of similar cases.
   The obvious match is to associate the special cases, and the similar
   cases from the two groups.

   The conclusion would be that Reply-To, the one existing header,
   should be used to indicate the author's suggested reply targets, and
   new headers for the various possibilities for the author's
   suggestions as to where recipients of the message may like to send
   different kinds of replies.

5.3. One other option

   Another suggestion for Reply-To is that it should simply be a
   replacement for the address(es) in the From header when replies are
   generated.  This seems to be approximately equivalent to "We don't
   know what the header means, but use it like this", which seems to be
   a particularly poor excuse for a header definition.  The argument for
   this approach is that many user agents currently operate this way.

   Apart from being philosophically inadequate as a definition, this
   approach leaves the user of the header in much the same situation
   they are in now - having no idea at all which addresses recipients
   will use as the targets of a reply.

5.4. Resolution

   It is suggested that Reply-To be defined as being the message
   author's suggestion for the addresses (all the addresses) that
   recipients should use when sending a normal reply to the message.

   This has the advantage that no decision needs to be made now as to
   which method to use to express conditional reply types.  More work
   can be done to determine whether a single header with many address
   options, or many headers, is the better approach.  Either way,
   Reply-To would be defined with a stable meaning.

   Another advantage is that the mailing list use of Reply-To continues
   to function as it is now used, which will avoid the difficult upgrade
   problems of resisting implementors (of lists).



kre                       [Expires April 1998]                 [Page 10]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   The obvious disadvantage is that user agents which treat Reply-To as
   the destination for "reply to author" (already broken as shown
   above), or as "replacement for From" (meaningless), will need to be
   upgraded.  Of course, to fully, or even partially, handle whatever
   specification is developed for reply handling, User Agents are going
   to need upgrades anyway.

   There are currently two widespread uses of Reply-To, that used by
   lists already described, and one where users set a standard Reply-To
   in all mail they send containing their own address.  The latter is
   done either just because it is there, or in order to compensate for
   some actual or believed defect in the generation of the From header.
   Catering for defective, or broken, user agents should not be our
   objective.  Any remaining cases where the user sets a standard
   Reply-To header containing their own address are trivial for the user
   to fix by simply deleting that header configuration.  Thus this
   definition for Reply-To has a quite simple upgrade path from current
   uses for the generation side.

   For recipients, user agents currently tend to treat Reply-To as to be
   used in personal replies, already broken, and which will not become
   more badly broken by this scheme, and typically take the Reply-To and
   add recipients from the other headers for reply-all functionality.
   The latter will continue to cause the problems it now does until user
   agents are upgraded - but at least having a clear indication of
   appropriate handling of the header should lead to those problems
   being fixed in time.

6. Suggested Text

   The text below is intended to replace section 3.6.2 of the current
   drums 822bis (message format) draft (the -02 version).  Section 6.1
   here is roughly equivalent to section 3.6 of that document for
   numbering purposes.

6.1. Field definitions.

   This is a dummy section just to get the section numbering in this
   document somewhat aligned with that in the message format draft.

6.1.1. The origination date field

   This is another dummy section, no changes are suggested here.








kre                       [Expires April 1998]                 [Page 11]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


6.1.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.
   Reply-To is not an originator field in quite the same way as the
   others, but is commonly considered to fulfill a similar role.

   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.  It 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 MUST be included in the message.

   The sender field specifies the agent responsible for transmission of
   the message.  It is composed of the field name "Sender" and a single
   mailbox specification.  Where the sender and from headers would
   specify exactly the same single mailbox, the sender header SHOULD be
   omitted.

   A reply-to field may be included in any message.  It specifies the
   complete list of all addresses suggested by the author of the message
   as being the addresses to which replies to the message should be
   sent.  The field consists of the name "Reply-To", followed by a comma
   specified list of addresses, in which groups are permitted.

        from     = "From:" mailbox-list CRLF
        sender   = "Sender:" mailbox CRLF
        reply-to = "Reply-To:" address-list CRLF

   The originator fields indicate the mailbox(es) of the source 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.

   The originator fields also provide information required to reply to a
   message.  When the reply-to field is present, it indicates the
   mailbox(es) to which the author of the message suggests that replies
   be sent.  In the absence of the reply-to field, replies SHOULD be
   sent to the mailbox(es) specified in the from field, and at the
   user's option, to other addresses selected from the destination
   address fields.  See also section 3.6.3 [in the original] for more
   information on forming the destination addresses for a reply.




kre                       [Expires April 1998]                 [Page 12]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   In all cases, the from field SHOULD NOT contain any mailbox which
   does not belong to the author(s) of the message.  However, the user
   SHOULD be able to set the from field to any mailbox which belongs to
   him.  User agents are not required to validate that setting.

6.1.3. Destination address fields

   The destination address 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, the bcc field may
   contain none.  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.  Generally persons addressed in this header are expected
   to take particular note 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, or perhaps "Courtesy Copy") 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 Cc") contains addresses
   of recipients of the message whose addresses should not be revealed
   to other recipients of the message.  There are two ways in which the
   bcc field can be processed.  In the first case, when a message
   containing a bcc field is prepared to be sent, the bcc header is
   removed from the message, even though all of the recipients contained
   in it are sent a copy of the message.  In the second case, recipients
   specified in the to and cc fields are each sent a copy of the message
   with the bcc header removed as above, but the recipients named in the
   bcc field get a separate copy of the message containing a bcc header.
   This header may be sent in one of three ways, one copy of the message
   containing the complete bcc header may be sent to all recipients
   names in it, or a separate copy of the message can be sent to each
   recipient, with the bcc header contained naming only that one
   recipient, or one copy of the message may be sent to all the
   recipients named in the bcc field, with the bcc field included with
   all the addresses deleted from it.  In any case the original to and



kre                       [Expires April 1998]                 [Page 13]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   cc fields should be retained.  Which method to use with bcc fields is
   implementation dependent, and ideally configurable by the user.
   Refer to the "Security Considerations" section of this document
   [drums message format] for a discussion of each.

   It is beyond the scope of this specification to constrain user
   behaviour, or consequently to attempt to constrain user-agent
   behaviour, the following is offered for guidance as a suggestion of
   how users may comply with the spirit of the address fields when
   generating replies.  Note that nothing here is in any way intended to
   limit the addresses to which users can send messages, be those
   messages replies to other messages or simply new compositions.

   When a message is a reply to another message, and there was a reply-
   to field in that other message, the to field of the reply should
   normally be copied from the reply-to field of the subject message.
   Other destination fields would be omitted by default.  Where there
   was no reply-to header in the subject message, the to field of the
   reply would normally contain addresses from the from field of the
   subject message, and may contain addresses from the to field.  A cc
   field may be added and may contain addresses from the to or cc fields
   of the original message.

   If a bcc field was present in the original message, addresses in that
   field may appear in the bcc field of the reply, but should normally
   not appear in the to or cc fields, as doing so may reveal to
   recipients of the original message that additional recipients were
   sent that message without their knowledge.  Of course, simply
   replying to a message that was received because of an address in a
   bcc header will reveal to all who receive the reply that additional
   undisclosed recipients exist.  Users receiving blind copies may
   prefer to reply only to addresses in the from field.

   Where a reply-to field was present in the original message, an
   identical field should normally be copied to any reply.

   Users may choose to add or delete addresses from these default lists,
   or to configure their user agents to perform that task automatically.
   Users may also prefer to ignore a reply-to field and reply to other
   addresses, perhaps the from field addresses, or even the address from
   the sender field, if present.  the

6.1.4. Identification fields

   Nothing further in the message format draft from DRUMS is intended to
   be changed by this document.  (Though the author would prefer to add
   in this section that message-id fields should be added by any relay
   or MTA a message passes though if the message does not already



kre                       [Expires April 1998]                 [Page 14]


Internet Draft    draft-ietf-drums-kre-reply-to-00.txt      October 1997


   contain that field.) At some future time examples showing the uses of
   the various originator and destination fields will be added above.

7. Further Work

   Work is still needed to define the precise methods to be used to
   convey conditional reply address information.

   Work is also required to define all aspects of processing mailing
   lists, of which how replies should be handled is one important
   aspect.  That work will need to deal with the issue of replying to a
   message which has been sent to multiple lists.

8. Security Considerations

   The only issues even partly related to security in this document
   concern whether is correctly being backed up at the various
   Internet-Drafts repositories.

9. References

   If you can't work out what are, and then find, the references
   mentioned in this document, you're probably not in its intended
   audience.

Author's Address

   Robert Elz
   University of Melbourne
   Department of Computer Science
   Parkville, Vic   3052
   Australia

   Email: kre@munnari.OZ.AU

















kre                       [Expires April 1998]                 [Page 15]