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]