idnits 2.17.1 draft-ietf-drums-kre-reply-to-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 71: '...n of some capitalised words like MUST,...' RFC 2119 keyword, line 72: '... SHOULD, etc....' RFC 2119 keyword, line 518: '...the sender field MUST be included in t...' RFC 2119 keyword, line 523: '...e mailbox, the sender header SHOULD be...' RFC 2119 keyword, line 542: '... SHOULD be used and the sender field...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1997) is 9689 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRUMS Working Group R. Elz 3 Internet Draft University of Melbourne 4 Expiration Date: April 1998 5 October 1997 7 Use of Reply-To in Internet E-Mail messages 9 draft-ietf-drums-kre-reply-to-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This draft forms part of a discussion on the appropriate use of the 32 Reply-To header in e-mail messages. This draft argues for one 33 particular proposed definition of the Reply-To header. 35 It is not intended that this document ever become anything more than 36 an Internet-Draft. If adopted, the text here, or a modified version 37 of some parts of it, would be merged into the proposed replacement 38 for RFC822. 40 Table of Contents 42 Abstract ................................................ 1 43 1 Introduction ............................................ 2 44 2 Document Conventions .................................... 2 45 3 The Problem ............................................. 3 46 3.1 Personal Replies ........................................ 3 47 3.2 Reply to Everyone ....................................... 4 48 3.3 Mailing Lists ........................................... 5 49 4 Desired Functionality ................................... 6 50 5 Possible Solutions ...................................... 7 51 5.1 Using two headers ....................................... 8 52 5.2 Many Headers ............................................ 9 53 5.3 One other option ........................................ 10 54 5.4 Resolution .............................................. 10 55 6 Suggested Text .......................................... 11 56 6.1 Field definitions. ...................................... 11 57 7 Further Work ............................................ 15 58 8 Security Considerations ................................. 15 59 9 References .............................................. 15 60 Author's Address ........................................ 15 62 1. Introduction 64 The DRUMS working group of the IETF is attempting to define the use 65 of the Reply-To header in Internet e-mail. This is a contribution to 66 that effort, and represents an argument for one position. 68 2. Document Conventions 70 This document makes use of the document conventions defined in BCP14. 71 That provides the interpretation of some capitalised words like MUST, 72 SHOULD, etc. 74 There can be many different people associated in varying ways with 75 the transmission of an Internet e-mail message. Except where 76 precision is necessary to separate these various roles, this draft 77 will use terms like "author", "sender", and "originator" 78 interchangeably, in order to make the text a little more interesting 79 to read. It will be clear where a distinction is being made between 80 the various roles that can be involved in the specification, 81 creation, approval, and transmission of a message. 83 3. The Problem 85 RFC822 does a particularly poor job of defining the Reply-To header. 86 It is clear that the intent is that automated replies should be 87 addressed to the Reply-To header instead of the From header, when a 88 Reply-To is present, but other than a few examples of how Reply-To 89 might be used, there is absolutely no indication at all of what it 90 means. 92 In particular, no explicit hint is given as to whether, when a reply 93 is sent, address in the To and Cc headers of the original message 94 should be included or not. That is true for replies with no Reply-To 95 header, where the answer no doubt depends upon the desires of the 96 user replying. However, where a Reply-To header is given, no 97 indication is given in RFC822 as to whether the addresses in that 98 header are the only addresses to which replies should be sent, or 99 simply a replacement for the address(es) in the From header. 101 Both approaches have been adopted by different mail user agents, 102 leading to confusion and non-interoperability. 104 This problem has been exacerbated by two other common use patterns. 105 The first is the tendency of some mail user agents to have exactly 106 two reply options - in the matter of selecting the destination 107 addresses, there can be other options which control things like 108 populating the reply message template with the text of the subject 109 message, which are not relevant here. These two options are 110 typically characterised as being "personal reply" or "reply to 111 author", and "reply to everyone". 113 3.1. Personal Replies 115 In the absence of a Reply-To header, a personal reply (or reply to 116 the author) is typically sent to the address or addresses in the From 117 header. Since the From header is defined as carrying the addresses 118 of the author(s) of the message, this technique generally achieves 119 the desired results. 121 However, where a Reply-To header exists, things are not nearly as 122 clear. For a generic "reply", replying to the address(es) in the 123 Reply-To header will generally achieve a satisfactory result. But 124 where it is the user's desire to actually send a personal reply, to 125 the author of the subject message, replying to the address in the 126 Reply-To header will sometimes not achieve the result desired. This 127 is because in RFC822 Reply-To is not defined as being the address of 128 the authors, but rather "a general mechanism for indicating any 129 mailbox(es) to which responses are to be sent." RFC822 actually gives 130 three different cases where Reply-To might be used, as typical cases 131 not an exhaustive list, without seeming to realise that the three 132 cases cannot reasonably be treated identically. Or perhaps, without 133 realising that not all replies are created equal. 135 For example, in RFC822 Appendix A, example A.2.4 shows a case where 136 the message is sent from one person (one address in the From header), 137 and the Reply-To header lists an entire committee. It would be 138 contrary to common sense to send a personal reply to the committee, 139 yet that is what many common mail user agents do today. On the other 140 hand, example A.2.6 shows a case where the From: address (mailbox) is 141 that of a secretary, for a user with no mailbox of their own, and 142 where the Reply-To header gives the mailbox of a friend of the user, 143 and where personal replies should clearly go to the address in the 144 Reply-To. 146 One way to avoid the seeming inconsistency of these examples is to 147 note that the "use Reply-To instead of From" rule is intended to 148 apply only to "automatic replies", and that for replies generated by 149 humans, the address choice should generally be left to the human. 150 See RFC822 section 4.4.4. 152 3.2. Reply to Everyone 154 This kind of reply is typically used where a message has been sent to 155 several people, and the user replying wishes all of those people to 156 receive the reply. Where no Reply-To header is present, this kind of 157 reply is typically sent to all addresses found in the From, To, and 158 Cc headers of the subject message. 160 Unlike personal replies, even this simple case is not trouble free 161 however. It is often the case that one, or more, of the addresses in 162 the To or Cc headers includes, but not in any transparent way, the 163 address from the From header. Where this happens, this simple reply 164 can cause the author(s) of the subject message to receive two copies 165 of the reply, which, to some users, is quite annoying. 167 One interpretation of the Reply-To header would easily allow this 168 problem to be circumvented. That is, if Reply-To were to be defined, 169 or generally regarded, as specifying all addresses which should 170 receive replies, then simply listing the set of addresses from the 171 various headers would cause, as near as practical, exactly one copy 172 of a reply to be delivered to each end-user mailbox. This would 173 normally not include the From address(es), as our assumption was that 174 one of the To or cc addresses includes the From address (but this is 175 obviously at the discretion of the author of the original message). 177 An obvious problem with this approach, apart from it not being 178 implemented that way everywhere, is that it is directly contrary to 179 the idea of sending personal replies to the addresses in the Reply-To 180 header. Doing so with a Reply-To header constructed as suggested 181 here would certainly not result in any kind of personal reply. 183 3.3. Mailing Lists 185 Mailing lists present an obvious example of the situation mentioned 186 in the previous section. They are, however, somewhat more 187 specialised, as a mailing list can have a policy, or several, and 188 where applicable, that policy can be enforced by the list itself. 189 One example may be that all messages on the list, and all replies to 190 messages on the list, should be sent to the list, and nowhere else. 192 It turns out that this is usually easy to accomplish using the 193 Reply-To header, almost regardless of which interpretation if placed 194 upon it by user agents. A list that inserts "Reply-To: the- 195 list@list.site" in every message sent to the list will generally 196 accomplish this. A initial message to the list will normally be "To: 197 the-list@list.site", and "From: user@some.where". Then, the list 198 adds the Reply-To header as above. Now, when a user replies, the 199 reply address can be generated using only the Reply-To, in which case 200 the sole destination is the-list, or using Reply-To and To, which 201 gives the-list twice, which almost always results in just a single 202 copy being sent to the list (usually with the-list just once in the 203 headers). Thus it is irrelevant whether the user replying uses a 204 personal reply, or reply-to everyone, and irrelevant how their MUA 205 treats the Reply-To header, the same result is accomplished in all 206 cases. Further, even a chain of such replies (replies to replies to 207 replies) will retain this property, which is a distinct advantage on 208 many lists. 210 Of course, should a user want to ignore the list policy, and send a 211 reply only to the author of the subject message, using most popular 212 user agents, that will often be difficult at best. This causes many 213 people to disapprove of this mailing list behaviour. On the other 214 hand, many believe strongly in this operating mode, and will not 215 change it until, at least, an alternative with similar functionality 216 is developed. That will require that essentially all users, 217 including those with old MUAs not updated to any new specification, 218 are able to use the mechanism to reply to messages as the list 219 itself, and its users, desire - at least as well as it works today. 221 4. Desired Functionality 223 When it comes to replies, there are many desires to be accommodated. 224 Considering only the addresses constructed for the reply message 225 there are, or seem to be, three different kinds of reply. First, 226 there is a reply to the message. Second, there is a reply to the 227 author of the message. And third, there is a reply to everyone who 228 received the original message. Obviously, replies can also be sent 229 to many other combinations of addresses from the original message, or 230 to addresses not included in the original message at all, however it 231 is probably safe not to attempt to consider all of those 232 possibilities. It should also be noted that it may be more correct 233 to not treat any but the first kind of reply as being a "reply" at 234 all, with the others being instead a new message sent to the author 235 of another message, or to all the recipients of another message. 236 However, it has been common to treat all of these as kinds of 237 replies, so we will continue that practice here. 239 To see that there are at least the three kinds of reply, consider a 240 message about an upcoming conference. It is sent from the organiser, 241 to a list of potential attendees (perhaps several mailing lists), and 242 with replies requested to be sent to the people handling 243 registrations. Most recipients who reply will be seeking 244 registration information, those are replies to the message. However, 245 some may desire to send a comment to the author of the message, 246 perhaps to point out an error in the text of the message that was 247 sent. Those are personal replies. Others may want to reply to 248 everyone, to point out that last year the conference was a waste of 249 time. They would be replies to everyone. And of course, some may 250 want to reply to some of the recipients only, perhaps to complain 251 about sending this announcement on one particular mailing list, and 252 to make sure that everyone who wasn't (apparently) supposed to see 253 the original message does get to see the complaint about the message. 254 Those replies we will ignore. 256 The Reply-To header is intended, must be intended, to allow the 257 sender to control, in some manner, the addresses used for these 258 replies. The header is inserted by the author of the original 259 message (cases where the header is added en route not being 260 considered here.) Thus, it must be the intent of the author which is 261 being expressed. The header contains addresses, and other than 262 comments, only addresses. So the intent being expressed must relate 263 to addresses. Then, from what RFC822 does say, and even without 264 that, the name of the header itself, it is fairly clear that the 265 Reply-To header allows the originator of a message to indicate 266 addresses to be used for replies. What isn't clear is which replies 267 should use those addresses. 269 It is clear from RFC822 that it cannot be intended that replies to 270 the author of a message should use Reply-To as an automatic choice. 271 Example A.2.4 makes that quite clear. In that example, the Reply-To 272 header indicates a committee, which is not the author of the message, 273 but which is intended to receive replies. A reply to the author 274 which sent to the addresses in the Reply-To header would thus not be 275 sent to the author of the message. A reply to the message would 276 however, and would be sent where the author requested. 278 It seems less important what is done with a reply to everyone, as by 279 its nature, the more addresses included the better. 281 Authors of messages often want to give some guidance as to which 282 addresses should receive replies, and almost as often, which should 283 not. A very common desire is to request that recipients of the 284 message reply to exactly a set of addresses specified by the author. 285 With that facility the originator of a message can direct replies to 286 specific addresses and away from others. 288 Authors sometimes also want to express conditional information as to 289 where replies should be sent. That is, for example, if you want to 290 reply to everyone, reply to this set of addresses. Or, if you don't 291 want to reply to everyone, reply to these addresses. In those cases 292 the author might not want to express a preference as to whether 293 recipients should reply to everyone or not, just to suggest reply 294 addresses depending upon the choice made by the recipient. 296 Sometimes the author may even want to say: if you want to reply to me 297 (ie: a personal reply), use this address. This seems to be a simple 298 case however, the address(es) of the author(s) of the message are in 299 the From: header already. On odd occasions though, especially where 300 there are multiple authors of the message (more than one address in 301 the From: header) it might be desirable to designate just one of 302 those, or even someone different, as the principal author, and to 303 request that personal replies go just to that one author. 305 5. Possible Solutions 307 It seems quite clear that one header cannot possibly satisfy all of 308 these desires. Therefore, and assuming that there is a requirement 309 to provide solutions for all of these problems, multiple headers will 310 be needed. One of those might be Reply-To. If not, then clearly 311 Reply-To would be useless, and should simply be deprecated. That 312 option is not considered further here. 314 There would seem to be two ways of dividing the problem in order to 315 come up with a solution. Reply address suggestions could be 316 considered unconditional or conditional, requiring at least two 317 headers, one for an unconditional reply address suggestion, and one 318 for conditional reply address suggestions. Alternatively, one header 319 could be used for unconditional reply address suggestions, and a new 320 header for each kind of conditional address suggestion that might be 321 desired. 323 5.1. Using two headers 325 In this scenario, the conditional reply address suggestion would need 326 to use a new header, as the syntax of Reply-To, which it would be 327 unreasonable to change, provides no way to indicate which conditions 328 were being indicated. A new header, which for the sake of argument 329 here, we will call Reply-Targets, could have a new syntax allowing 330 the author of the message to indicate for which classes of messages 331 various sets of addresses would be used. 333 Using ABNF, such a header might be constructed as: 335 reply-targets = cond-target *( ";" cond-target ) 336 cond-target = label ":" *address 337 label = phrase 339 Undefined non-terminals ("address" and "phrase") there are assumed 340 defined as in the current 822bis draft. 342 The intent would be that where the recipient desires to reply to the 343 class of addresses suggested by the label, the associated address(es) 344 should be used. A well known set of labels to handle the common 345 cases could be defined, which would assist in user understanding of 346 the functionality, while not limiting creativity for unusual cases. 348 For example, a simple case: 350 Reply-Targets: Author: user@some.example ; 351 Everyone: the-list@host.xx, extra@other.host ; 353 This suggests to the recipients two possible reply targets, the 354 author, or everyone, and the addresses to use to send to each of 355 those. 357 A more complex example: 359 Subject: New mailing list starting 360 Reply-Targets: Subscribe: list-request@whatever.host ; 361 Unsubscribe: list-request@whatever.host ; 362 Send To List: ; 363 Discuss: Related Lists: ietf@ietf.org, 364 drums@cs.utk.edu ;; 366 In this example, assumed to be the announcement of a new mailing 367 list, four possible reply targets are given. Nothing is suggested 368 for a reply to the author, thus the address(es) on the From: header 369 would be used for that purpose. Simple addresses are given for 370 subscribing and unsubscribing, no address exists for sending to the 371 list, which would imply that such replies are not welcome (yet), and 372 for discussion, a group containing two addresses is to be used. 374 The Reply-To header would then be used to indicate the address(es) 375 that the author of the message believes should be used for replies to 376 the message. The two headers could both be used, to give the 377 author's suggested reply address(es), and some possible alternatives. 379 With such a scheme, a user agent might have two reply buttons. The 380 first would generate a "default reply" which would be sent to the 381 Reply-To address(es) if any, or to the user's choice of From: or 382 From:+To:+Cc: (or perhaps even From:+To:) if no Reply-To header 383 exists. The second would produce a menu of reply targets taken from 384 the labels in the Reply-Targets header, with default cases of 385 "Author" and "Everyone" added if not present, or if no Reply-Targets 386 exists at all. 388 Note, there is no suggestion here that a Reply-Targets header be 389 created exactly, or even approximately, as has been illustrated here. 390 This is simply an example of what could be done. 392 5.2. Many Headers 394 In this scenario, a new header would be invented for each new kind of 395 reply that may be desired for the author of a message to be able to 396 direct to addresses of her choosing. That is, there may a headers to 397 indicate the addresses to be used for replies to the author, a 398 different header to indicate replies to everyone, and another to 399 allow the author to express her preference as to where recipients 400 should reply. 402 In this scenario there seems to be no particular reason to assign the 403 existing Reply-To header to any one of these purposes in preference 404 to the others, and the choice could be arbitrary. 406 One suggestion has been that because many User Agents already use the 407 Reply-To header as the standard address for the "personal reply" type 408 functionality, then Reply-To should be defined for this purpose. As 409 already shown, this would be directly contrary to the uses of Reply- 410 To shown in RFC822, and thus about the only guidance we have had so 411 far as to how the header should be used. 413 At least two new headers are going to be needed to follow this 414 scheme, in addition to Reply-To. That is, the one existing header, 415 and two (or more) new ones. While no real change can be made to the 416 existing header's name or syntax, the new headers could be whatever 417 is required. All but one of the new headers would be conditional 418 advice to the recipients, if you want this kind of reply, use these 419 addresses. The other, the one different one, would be the header 420 used to indicate the message author's suggested reply addresses. 421 Thus, there are two categories, header names, and header functions, 422 each of which has one special case, and some number of similar cases. 423 The obvious match is to associate the special cases, and the similar 424 cases from the two groups. 426 The conclusion would be that Reply-To, the one existing header, 427 should be used to indicate the author's suggested reply targets, and 428 new headers for the various possibilities for the author's 429 suggestions as to where recipients of the message may like to send 430 different kinds of replies. 432 5.3. One other option 434 Another suggestion for Reply-To is that it should simply be a 435 replacement for the address(es) in the From header when replies are 436 generated. This seems to be approximately equivalent to "We don't 437 know what the header means, but use it like this", which seems to be 438 a particularly poor excuse for a header definition. The argument for 439 this approach is that many user agents currently operate this way. 441 Apart from being philosophically inadequate as a definition, this 442 approach leaves the user of the header in much the same situation 443 they are in now - having no idea at all which addresses recipients 444 will use as the targets of a reply. 446 5.4. Resolution 448 It is suggested that Reply-To be defined as being the message 449 author's suggestion for the addresses (all the addresses) that 450 recipients should use when sending a normal reply to the message. 452 This has the advantage that no decision needs to be made now as to 453 which method to use to express conditional reply types. More work 454 can be done to determine whether a single header with many address 455 options, or many headers, is the better approach. Either way, 456 Reply-To would be defined with a stable meaning. 458 Another advantage is that the mailing list use of Reply-To continues 459 to function as it is now used, which will avoid the difficult upgrade 460 problems of resisting implementors (of lists). 462 The obvious disadvantage is that user agents which treat Reply-To as 463 the destination for "reply to author" (already broken as shown 464 above), or as "replacement for From" (meaningless), will need to be 465 upgraded. Of course, to fully, or even partially, handle whatever 466 specification is developed for reply handling, User Agents are going 467 to need upgrades anyway. 469 There are currently two widespread uses of Reply-To, that used by 470 lists already described, and one where users set a standard Reply-To 471 in all mail they send containing their own address. The latter is 472 done either just because it is there, or in order to compensate for 473 some actual or believed defect in the generation of the From header. 474 Catering for defective, or broken, user agents should not be our 475 objective. Any remaining cases where the user sets a standard 476 Reply-To header containing their own address are trivial for the user 477 to fix by simply deleting that header configuration. Thus this 478 definition for Reply-To has a quite simple upgrade path from current 479 uses for the generation side. 481 For recipients, user agents currently tend to treat Reply-To as to be 482 used in personal replies, already broken, and which will not become 483 more badly broken by this scheme, and typically take the Reply-To and 484 add recipients from the other headers for reply-all functionality. 485 The latter will continue to cause the problems it now does until user 486 agents are upgraded - but at least having a clear indication of 487 appropriate handling of the header should lead to those problems 488 being fixed in time. 490 6. Suggested Text 492 The text below is intended to replace section 3.6.2 of the current 493 drums 822bis (message format) draft (the -02 version). Section 6.1 494 here is roughly equivalent to section 3.6 of that document for 495 numbering purposes. 497 6.1. Field definitions. 499 This is a dummy section just to get the section numbering in this 500 document somewhat aligned with that in the message format draft. 502 6.1.1. The origination date field 504 This is another dummy section, no changes are suggested here. 506 6.1.2. Originator fields 508 The originator fields of a message consist of the from field, the 509 sender field (when applicable) and optionally the reply-to field. 510 Reply-To is not an originator field in quite the same way as the 511 others, but is commonly considered to fulfill a similar role. 513 The from field specifies the author(s) of the message, that is, the 514 mailbox(es) of the person(s) or system(s) responsible for the writing 515 of the message. It consists of the field name "From" and comma- 516 separated list of one or more mailbox specifications. If the from 517 field contains more than one mailbox specification in the mailbox- 518 list, then the sender field MUST be included in the message. 520 The sender field specifies the agent responsible for transmission of 521 the message. It is composed of the field name "Sender" and a single 522 mailbox specification. Where the sender and from headers would 523 specify exactly the same single mailbox, the sender header SHOULD be 524 omitted. 526 A reply-to field may be included in any message. It specifies the 527 complete list of all addresses suggested by the author of the message 528 as being the addresses to which replies to the message should be 529 sent. The field consists of the name "Reply-To", followed by a comma 530 specified list of addresses, in which groups are permitted. 532 from = "From:" mailbox-list CRLF 533 sender = "Sender:" mailbox CRLF 534 reply-to = "Reply-To:" address-list CRLF 536 The originator fields indicate the mailbox(es) of the source of the 537 message. For example, if a secretary were to send a message for 538 another person, the mailbox of the secretary would go in the sender 539 field, and the mailbox of the actual author would go in the from 540 field. If the originator of the message can be indicated by a single 541 mailbox and the author and transmitter are identical, the from field 542 SHOULD be used and the sender field SHOULD NOT be used. Otherwise, 543 both fields SHOULD appear. 545 The originator fields also provide information required to reply to a 546 message. When the reply-to field is present, it indicates the 547 mailbox(es) to which the author of the message suggests that replies 548 be sent. In the absence of the reply-to field, replies SHOULD be 549 sent to the mailbox(es) specified in the from field, and at the 550 user's option, to other addresses selected from the destination 551 address fields. See also section 3.6.3 [in the original] for more 552 information on forming the destination addresses for a reply. 554 In all cases, the from field SHOULD NOT contain any mailbox which 555 does not belong to the author(s) of the message. However, the user 556 SHOULD be able to set the from field to any mailbox which belongs to 557 him. User agents are not required to validate that setting. 559 6.1.3. Destination address fields 561 The destination address fields of a message consist of three possible 562 fields, each of the same form: The field name, which is either "To", 563 "Cc", or "Bcc", followed by a comma-separated list of one or more 564 addresses (either mailbox or group syntax). Both the to field and 565 the bcc field MAY occur alone, but the cc field SHOULD only be 566 present if the to field is also present. 568 to = "To:" address-list CRLF 569 cc = "Cc:" address-list CRLF 570 bcc = "Bcc:" [ address-list ] CRLF 572 The destination fields specify the recipients of the message. Each 573 destination field may have one or more addresses, the bcc field may 574 contain none. Each of the addresses receives a copy of the message. 575 The only difference between the three fields is how each is used. 577 The to field contains the address(es) of the primary recipient(s) of 578 the message. Generally persons addressed in this header are expected 579 to take particular note of the message. The cc field (where the "Cc" 580 means "Carbon Copy" in the sense of making a copy on a typewriter 581 using carbon paper, or perhaps "Courtesy Copy") contains the 582 addresses of others who should receive the message, though the 583 content of the message may not be directed at them. 585 The bcc field (where the "Bcc" means "Blind Cc") contains addresses 586 of recipients of the message whose addresses should not be revealed 587 to other recipients of the message. There are two ways in which the 588 bcc field can be processed. In the first case, when a message 589 containing a bcc field is prepared to be sent, the bcc header is 590 removed from the message, even though all of the recipients contained 591 in it are sent a copy of the message. In the second case, recipients 592 specified in the to and cc fields are each sent a copy of the message 593 with the bcc header removed as above, but the recipients named in the 594 bcc field get a separate copy of the message containing a bcc header. 595 This header may be sent in one of three ways, one copy of the message 596 containing the complete bcc header may be sent to all recipients 597 names in it, or a separate copy of the message can be sent to each 598 recipient, with the bcc header contained naming only that one 599 recipient, or one copy of the message may be sent to all the 600 recipients named in the bcc field, with the bcc field included with 601 all the addresses deleted from it. In any case the original to and 602 cc fields should be retained. Which method to use with bcc fields is 603 implementation dependent, and ideally configurable by the user. 604 Refer to the "Security Considerations" section of this document 605 [drums message format] for a discussion of each. 607 It is beyond the scope of this specification to constrain user 608 behaviour, or consequently to attempt to constrain user-agent 609 behaviour, the following is offered for guidance as a suggestion of 610 how users may comply with the spirit of the address fields when 611 generating replies. Note that nothing here is in any way intended to 612 limit the addresses to which users can send messages, be those 613 messages replies to other messages or simply new compositions. 615 When a message is a reply to another message, and there was a reply- 616 to field in that other message, the to field of the reply should 617 normally be copied from the reply-to field of the subject message. 618 Other destination fields would be omitted by default. Where there 619 was no reply-to header in the subject message, the to field of the 620 reply would normally contain addresses from the from field of the 621 subject message, and may contain addresses from the to field. A cc 622 field may be added and may contain addresses from the to or cc fields 623 of the original message. 625 If a bcc field was present in the original message, addresses in that 626 field may appear in the bcc field of the reply, but should normally 627 not appear in the to or cc fields, as doing so may reveal to 628 recipients of the original message that additional recipients were 629 sent that message without their knowledge. Of course, simply 630 replying to a message that was received because of an address in a 631 bcc header will reveal to all who receive the reply that additional 632 undisclosed recipients exist. Users receiving blind copies may 633 prefer to reply only to addresses in the from field. 635 Where a reply-to field was present in the original message, an 636 identical field should normally be copied to any reply. 638 Users may choose to add or delete addresses from these default lists, 639 or to configure their user agents to perform that task automatically. 640 Users may also prefer to ignore a reply-to field and reply to other 641 addresses, perhaps the from field addresses, or even the address from 642 the sender field, if present. the 644 6.1.4. Identification fields 646 Nothing further in the message format draft from DRUMS is intended to 647 be changed by this document. (Though the author would prefer to add 648 in this section that message-id fields should be added by any relay 649 or MTA a message passes though if the message does not already 650 contain that field.) At some future time examples showing the uses of 651 the various originator and destination fields will be added above. 653 7. Further Work 655 Work is still needed to define the precise methods to be used to 656 convey conditional reply address information. 658 Work is also required to define all aspects of processing mailing 659 lists, of which how replies should be handled is one important 660 aspect. That work will need to deal with the issue of replying to a 661 message which has been sent to multiple lists. 663 8. Security Considerations 665 The only issues even partly related to security in this document 666 concern whether is correctly being backed up at the various 667 Internet-Drafts repositories. 669 9. References 671 If you can't work out what are, and then find, the references 672 mentioned in this document, you're probably not in its intended 673 audience. 675 Author's Address 677 Robert Elz 678 University of Melbourne 679 Department of Computer Science 680 Parkville, Vic 3052 681 Australia 683 Email: kre@munnari.OZ.AU