idnits 2.17.1 draft-moore-auto-email-response-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 187: '...omatic responder MUST NOT blindly send...' RFC 2119 keyword, line 202: '...omatic responses SHOULD NOT be issued ...' RFC 2119 keyword, line 209: '... SHOULD NOT issue the same respons...' RFC 2119 keyword, line 211: '...s. A 7-day period is RECOMMENDED as a...' RFC 2119 keyword, line 216: '... office" notices) SHOULD NOT be issued...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (29 January 2004) is 7392 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) -- Missing reference section? 'CFWS' on line 626 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft K. Moore 2 Expires: 29 July 2004 University of Tennessee 3 29 January 2004 5 Recommendations for Automatic Responses to Electronic Mail 7 draft-moore-auto-email-response-05 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions of 12 Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute 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 material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This document is not associated with any working group. Comments on 30 this document should be sent to the mailing list , or 31 to the author. Such comments should cite the Internet-Draft identifier 32 draft-moore-auto-email-response-05 so others can be sure you are 33 commenting on the same version they read. 35 Abstract 37 This memo makes recommendations for software that automatically responds 38 to incoming electronic mail messages, including "out of the office" or 39 "vacation" response generators, mail filtering software, email-based 40 information services, and other automatic responders. The purpose of 41 these recommendations is to discourage undesirable behavior which is 42 caused or aggravated by such software, to encourage uniform behavior 43 (where appropriate) among automatic mail responders, and to clear up 44 some sources of confusion among implementors of automatic email 45 responders. 47 Intended status: Once it appears that this document has received 48 sufficient review, comment, and community support, the author intends to 49 submitted it as an individual submission for Proposed Standard status. 50 Proposed Standard seems more appropriate than BCP because this document 51 describes protocols more than operational practices. [[NOTE TO RFC 52 EDITOR: This paragraph should be removed prior to publication as an 53 RFC.]] 55 1. Introduction 57 Many programs which automatically respond to email are currently in use. 58 Although these programs vary widely in their function, several problems 59 with this class of programs have been observed, including: significant 60 numbers of useless or unwanted response and responses sent to 61 inappropriate addresses, and occasional incidences of mail loops or 62 "sorcerer's apprentice" mode. This memo recommends behavior for 63 programs that automatically respond to electronic mail in order to 64 reduce the number of problems caused by such programs. 66 (Note: the term "sorcerer's apprentice mode" is defined as a bug in a 67 protocol where, under some circumstances, the receipt of a message 68 causes multiple messages to be sent, each of which, when received, 69 triggers the same bug.) (From [I1.JARGON]) 71 This document is limited in scope to Internet electronic mail messages 72 and many of its recommendations are specifically tailored for the 73 protocol elements and data models used in Internet electornic mail 74 messages and SMTP transport envelopes. Use of these recommendations in 75 other messaging contexts such as instant messaging, SMS, or Usenet has 76 not been considered, and is outside of the scope of this document. 78 1.1 Types of automatic responses 80 There are several different types of automatic responses. At least two 81 types of automatic responses have been defined in IETF standards - 82 Delivery Status Notifications [I2.RFC3464] which are intended to report 83 the status of a message delivery by the message transport system, and 84 Message Disposition Notifications [I3.RFC2298] which are intended to 85 report of the disposition of a message after it reaches a recipient's 86 mailbox. These responses are defined elsewhere and are generally not 87 within the purview of this document, except that this document 88 recommends specific cases where they should or should not be used. 90 Other types of automatic response in common use include: 92 - "Out of office" or "vacation" notices, which are intended to inform 93 the sender of a message that the message is unlikely to be read, or 94 acted on, for some amount of time, 96 - "Change of address" notices, intended to inform the sender of a 97 message that the recipient address he used is obsolete and that a 98 different address should be used instead (whether or not the 99 subject message was forwarded to the current address), 101 - "Challenges", which require the sender of a message to demonstrate 102 some measure of intelligence and/or willingness to agree to some 103 conditions before the subject message will be delivered to the 104 recipient (often to minimize the effect of "spam" or viruses on the 105 recipient), 107 - Email-based information services, which accept requests (presumably 108 from humans) via email, provide some service, and issue responses 109 via email also. (Mailing lists which accept subscription requests 110 via email fall into this category), 112 - Information services similar to those mentioned above except that 113 they are intended to accept messages from other programs, and 115 - Various kinds of mail filters (including "virus scanners") which 116 act on behalf of a recipient to alter the content of messages 117 before forwarding them to that recipient, and issue responses in 118 the event a message is altered. 120 Recognizing the wide variety of response types in use, these 121 recommendations distinguish between several classes of automatic 122 responders according to the party or service on whose behalf the 123 responder acts: 125 - "Service Responders" exist to provide access to some service via 126 email requests and responses. These are permanently associated 127 with one or more email addresses, and when sending to such an 128 address the sender presumably expects an automatic response. An 129 email-based file retrieval service is an example of a Service 130 Responder. A calendar service that allows appointment requests to 131 be made via email, and which responds to such requests, would be 132 another example of a Service Responder. 134 - "Personal Responders" exist to make automatic responses on behalf 135 of a single recipient address, in addition to, or in lieu of, that 136 recipient reading the message. These responders operate according 137 to criteria specified on a per-recipient basis. The UNIX 138 "vacation" program is an example of a Personal Responder. A 139 responder that accepts mail sent to a single address, attempts to 140 analyze and classify the contents, and then issues a response which 141 is dependent on that classification, is also a Personal Responder. 143 - "Group Responders" exist to make automatic responses on behalf of 144 any of a significant set of recipient addresses (say, every 145 recipient in a particular DNS domain), in advance of, or in lieu 146 of, a response from the actual recipient. Group Responders are 147 similar to Personal Responders except that in the case of a Group 148 Responder the criteria for responding are not set on a per- 149 recipient basis. A "virus scanner" program that filtered all mail 150 sent to any recipient on a particular server, and sent responses 151 when a message was rejected or delivered in an altered form, might 152 be an example of a Group Responder. 154 Appropriate behavior for a responder varies from one class to another. 155 A behavior which might be appropriate from a Service Responder (where 156 the sender is expecting an automatic response) might not be appropriate 157 from a Personal Responder. For example, a Service Responder might send 158 a very long response to a request, or one that is not in a human- 159 readable format, according to the needs of that service. However a 160 Personal Responder should assume that a human being is reading the 161 response and send only brief responses in plain text. 163 1.2. Notation and Definitions 165 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 166 "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as 167 described in [N1.RFC2119]. 169 The term "subject message" is used to refer to a message which causes a 170 response to be sent. 172 The term "response" refers to a message that is automatically issued on 173 receipt of a subject message by a responder. 175 A "responder" is a process that automatically responds to subject 176 messages under some well-defined set of conditions. 178 Unless specified otherwise, the term "recipient" refers to the email 179 addresses to which a subject message was delivered (rather than, for 180 instance, the address to which the response was sent). A "recipient" 181 address might be permanently associated with a responder, or it might be 182 the address of a human being whose mail is, under some conditions, 183 answered by a responder. 185 2. When (not) to send automatic responses 187 An automatic responder MUST NOT blindly send a response for every 188 message received. In practice there are always reasons to refuse to 189 respond to some kinds of received messages, e.g. for loop prevention, to 190 avoid responding to "spam" or viruses, to avoid being used as a means to 191 launder or amplify abusive messages, to avoid inappropriately revealing 192 personal information about the recipient (e.g. to avoid an automatic 193 indication that a recipient has not read his mail recently), and to 194 thwart denial-of-service attacks against the responder. The criteria 195 for deciding whether to respond will differ from one responder to 196 another, according to the responder's purpose. In general, care should 197 be taken to avoid sending useless or redundant responses, and to avoid 198 contributing to mail loops or facilitating denial-of-service attacks. 200 Here are some broad guidelines: 202 - Automatic responses SHOULD NOT be issued in response to any message 203 which contains an Auto-Submitted header field (see below), where 204 that field has any value other than "no". 206 - Personal and Group responses that are intended to notify the sender 207 of a message of the recipient's inability to read or reply to the 208 message (e.g. "away from my mail" or "too busy" notifications) 209 SHOULD NOT issue the same response to the same sender more than 210 once within a period of several days, even though that sender may 211 have sent multiple messages. A 7-day period is RECOMMENDED as a 212 default. 214 - Personal and Group responses whose purpose is to notify the sender 215 of a message of a temporary absence of the recipient (e.g. 216 "vacation" and "out of the office" notices) SHOULD NOT be issued 217 unless a valid address for the recipient is explicitly included in 218 a recipient (e.g. To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc) 219 field of the subject message. Since a recipient may have multiple 220 addresses forwarded to the same mailbox, recipients SHOULD be able 221 to specify a set of addresses to the responder which it will 222 recognize as valid for that recipient. 224 Note: RFC 2822 section 3.6.3 permits varying uses of the Bcc field, 225 some of which would allow the sender of the subject message to 226 explicitly specify the recipient's address as a "Bcc" recipient 227 without a Bcc field appearing in the message as delivered, or 228 without the Bcc field in the delivered message containing the 229 recipient's address. However, perhaps because Bcc's are rarely 230 used, the heuristic of not responding to messages for which the 231 recipient was not explicitly listed in a To, CC, or Bcc header 232 field has been found to work well in practice. 234 - Personal and Group Responders MAY refuse to generate responses 235 except to known correspondents or addresses of otherwise "trusted" 236 individuals. Such responders MAY also generate different kinds of 237 responses for "trusted" vs. "untrusted" addresses. This might be 238 useful, for instance, to avoid inappropriate disclosure of personal 239 information to arbitrary addresses. 241 - Responders MUST NOT generate any response for which the destination 242 of that response would be a null address (e.g. an address for which 243 SMTP MAIL FROM or Return-Path is <>), since the response would not 244 be delivered to a useful destination. Responders MAY refuse to 245 generate responses for addresses commonly used as return addresses 246 by responders - e.g. those with local-parts matching "owner-*", 247 "*-request", "MAILER-DAEMON", etc. Responders are encouraged to 248 check the destination address for validity before generating the 249 response, to avoid generating responses that cannot be delivered or 250 are unlikely to be useful. 252 - In order to avoid responding to spam and to certain kinds of 253 attacks, automatic responses from Service Responders SHOULD NOT be 254 sent for extremely malformed requests. This may include checking 255 that the subject message has a content-type and content appropriate 256 to that service. 258 - Because the vast majority of email is unauthenticated, and return 259 addresses are easily forged, in order to avoid being used as a 260 means of denial-of-service attacks (i.e. to flood mailboxes with 261 unwanted content) Service Responders SHOULD NOT return large 262 responses (say, more than a few kilobytes) without specific 263 knowledge that the request was actually authorized by the party 264 associated with the address to which the response will be sent. 265 Similarly, Service Responders SHOULD NOT cause unwanted side- 266 effects (such as subscribing the sender to a mailing list) without 267 reasonable assurance that the request was authorized by the 268 affected party. 270 NOTE: Since each responder has a different purpose and a different 271 set of potential threats to which it might be subjected, whether 272 any particular means of authentication is appropriate for a 273 particular responder is not in scope for this document. 275 - A responder MAY refuse to send a response to a subject message 276 which contains any header or content which makes it appear to the 277 responder that a response would not be appropriate. For instance, 278 if the subject message contained a Precedence header field 279 [I4.RFC2076] with a value of "list" the responder might guess that 280 the traffic had arrived from a mailing list, and would not respond 281 if the response were only intended for personal messages. For 282 similar reasons, a responder MAY ignore any subject message with a 283 List-* field [I5.RFC2369]. (Because Precedence is not a standard 284 header field, and its use and interpretation vary widely in the 285 wild, no particular responder behavior in the presence of 286 Precedence is recommended by this specification.) 288 3. Format of automatic responses 290 The following sections specify details of the contents of automatic 291 responses, including the header of the response message, the content of 292 the response, and the envelope in which the response is transmitted to 293 the email transport system. 295 3.1 Message header 297 The fields in the message header should be set as follows: 299 3.1.1 From field 301 In correspondence between humans, the From field serves multiple 302 purposes: It identifies the author of the message (or in some cases, the 303 party or parties on whose behalf the message was sent), and it is the 304 default destination of replies from humans. Unfortunately, some mail 305 systems still send nondelivery reports and other kinds of automatic 306 responses to the From address. 308 For automatic responses, the role of the From field in determining the 309 destination of replies to the response from humans is less significant, 310 because in most cases it is not useful or appropriate for a human (or 311 anyone) to reply to an automatic response. One exception is when there 312 is some problem with the response; it should be possible to provide 313 feedback to the person operating the responder. 315 So in most cases the From address in an automatic response needs to be 316 chosen according to the following criteria: 318 - To provide an indication of the party or agent on whose behalf the 319 response was sent, 321 - To provide an address to which a recipient of an inappropriate 322 response can request that the situation be corrected, and 324 - To diminish the potential for mail loops. 326 The following behavior is thus recommended: 328 - For responses sent by Service Responders, the From field SHOULD 329 contain an address which can be used to reach the (human) 330 maintainer of that service. The human-readable portion of the From 331 field (the display-name preceding the address) SHOULD contain a 332 name or description of the service to identify the service to 333 humans. 335 - For responses sent by Personal Responders, the From field SHOULD 336 contain the name of the recipient of the subject message (i.e. the 337 user on whose behalf the response is being sent) and an address 338 chosen by the recipient of the subject message to be recognizable 339 to correspondents. Often this will be the same address that was 340 used to send the subject message to that recipient. 342 In the case of a recipient having multiple mail addresses forwarded 343 to the same mailbox (and responder), a Personal Responder MAY use 344 heuristics to guess, based on the information available in various 345 message header fields, which of several addresses for that 346 recipient the sender is likely to have used, and use that address 347 in the From field of the response. However it MUST be possible for 348 a recipient on whose behalf the responder is acting to explicitly 349 specify the human-readable name and address to be used in the From 350 header fields of responses. 352 Note: Due to privacy reasons it may be inappropriate for responders 353 to disclose an address that is derived, say, from the recipient's 354 login information (e.g. POP or IMAP user name or account name on a 355 multiuser computer) or which discloses the specific name of the 356 computer where the response was generated. Furthermore these do 357 not necessarily produce a valid public email address for the 358 recipient. For this reason the From field of a Personal Response 359 MUST be settable by the recipient on whose behalf the responder is 360 acting. 362 - For Group Responders, the From address SHOULD contain an email 363 address which could be used to reach the maintainer of that Group 364 Responder. Use of the Postmaster address for this purpose is NOT 365 RECOMMENDED. 367 The human-readable portion of the From address (the "phrase" before 368 the address, see [N2.RFC2822], section 3.2.6) SHOULD contain an 369 indication of the function performed by the Group Responder and on 370 whose behalf it operates (e.g. "Example Agency virus filter") 372 3.1.2 Reply-To field 374 If a reply is expected by the responder, the Reply-To field of the 375 response SHOULD be set to the address at which the reply is expected, 376 even if this is the address of the same or another responder. 377 Responders which request replies to be sent to responders MUST prevent 378 mail loops and sorcerer's apprentice mode. Note that since (according 379 to the previous section) the From field of the response SHOULD contain 380 the address of a human, if the Reply-To field of the response is used to 381 direct replies to a responder it will not be the same as the address in 382 the From field. 384 Discussion: this assumes that the human recipient's user agent will 385 normally send replies to the Reply-To address (if present), as 386 recommended by [I6.RFC822] since 1982, but that it is still possible for 387 a recipient to reply to the From address if he or she finds it useful to 388 do so. This is consistent with the intended use of these fields in 389 [I6.RFC822] and [N2.RFC2822]. 391 3.1.3 To field 393 The To header field SHOULD indicate the recipient of the response. In 394 general there SHOULD only be one recipient of any automatic response. 395 This minimizes the potential for sorcerer's apprentice mode and denial- 396 of-service attacks. 398 3.1.4 Date field 400 The Date header field SHOULD indicate the date and time at which the 401 response was generated. This MUST NOT be taken as any indication of 402 the delivery date of the subject message, nor of the time at which the 403 response was sent. 405 3.1.5 Subject field 407 The Subject field SHOULD contain a brief indication that the message is 408 an automatic response, followed by contents of the Subject field (or a 409 portion thereof) from the subject message. The prefix "Auto:" MAY be 410 used as such an indication. If used, this prefix SHOULD be followed by 411 an ASCII SPACE character (0x20). 413 NOTE: Just as the (Latin-derived) prefix "Re:" that is commonly used to 414 indicate human-generated responses is sometimes translated to other 415 languages by mail user agents, or otherwise interpreted by mail user 416 agents as indication that the message is a reply, so the (Greek) prefix 417 "Auto:" may also be translated or used as a generic indication that the 418 message is an automatic response. However the "Auto:" indication is 419 intended only as an aid to humans in processing the message. Mail 420 processing software SHOULD NOT assume that the presence of "Auto:" at 421 the beginning of a Subject field is an indication that the message was 422 automatically submitted. 424 Note that the Subject field of the subject message may contain encoded- 425 words formatted according to [N3.RFC2047] and [n3.5], and such text MAY 426 be included in the Subject field of a response. In generating responses 427 containing such fields there is rarely a need to decode and re-encode 428 such text. It is usually sufficient to leave those encoded-words as 429 they were in the subject message, merely prepending "Auto: " or other 430 indication. However, it is still necessary to ensure that no line in 431 the resulting Subject field that contains an encoded-word is greater 432 than 76 ASCII characters in length (this refers to the encoded form, not 433 the number of characters in the text being encoded). Also, if the 434 responder truncates the Subject from the subject message it is necessary 435 to avoid truncating Subject text in the middle of an encoded-word. 437 3.1.6 In-Reply-To and References fields 439 The In-Reply-To and References fields SHOULD be provided in the header 440 of a response message if there was a Message-ID field in the subject 441 message, according to the rules in [N2.RFC2822] section 3.6.4. 443 3.1.7 Auto-Submitted field 445 The Auto-Submitted field, with a value of "auto-replied", SHOULD be 446 included in the message header of any automatic response. See section 447 5. 449 3.1.8 Precedence field 451 A response MAY include a Precedence field [I4.RFC2076] in order to 452 discourage responses from some kinds of responders which predate this 453 specification. The field-body of the Precedence field MAY consist of 454 the text "junk", "list", "bulk", or other text deemed appropriate by the 455 responder. Because the Precedence field is non-standard and its 456 interpretation varies widely, the use of Precedence is not specifically 457 recommended by this specification, nor does this specification recommend 458 any particular value for that field. 460 3.2 Message content 462 In general, messages sent by Personal or Group Responders SHOULD be 463 brief, and in text/plain format. A multipart/alternative construct MAY 464 be used to communicate responses in multiple languages, especially if in 465 doing so it is desirable to use multiple charsets. 467 Response messages SHOULD NOT include significant content from the 468 subject message. In particular, Personal and Group responses SHOULD NOT 469 contain non-text content from the subject message, and they SHOULD NOT 470 include attachments from the subject message. Neither of these 471 conditions applies to responders that specifically exist for the purpose 472 of altering or translating content sent to them (for instance, a 473 FORTRAN-to-C translator); however, such responders MUST employ measures 474 to avoid being used as a means of laundering or forwarding undesirable 475 content, such as spam or viruses. 477 Note that when text from the Subject or other fields from the header of 478 the subject message is included in the body of the response, it is 479 necessary to decode any encoded-words that appeared in those fields 480 before including in the message body, and to use an appropriate content- 481 type, charset, and content-transfer-encoding. In some cases it may be 482 necessary to transliterate text from the charset(s) used in the header 483 of the subject message, to the charset(s) used in the body of the 484 response. (It is much easier to implement a responder if text from the 485 header of the subject message never needs to appear in the body of the 486 response.) 488 3.2.1 Use of DSNs and MDNs instead of this specification 490 In general, it is appropriate to use Delivery Status Notifications 491 (DSNs) for responses that are generated by the mail transport system as 492 a result of attempts to relay, forward, or deliver mail, and only when 493 the purpose of that response is to provide the sender of the subject 494 message with information about the status of that mail delivery. For 495 instance, a "virus scanner" which is activated by a mail delivery 496 process to filter harmful content prior to delivery, could return a DSN 497 with the Action field set to "failed" with a Status code of 5.7.1 498 (Delivery not authorized, message refused) if the entire message was not 499 delivered due to security reasons; or it could return a DSN with the 500 Action field set to "relayed" or "delivered" (as appropriate) with a 501 Status code set to 2.6.4 (conversion with loss performed) if the message 502 was relayed or delivered with the presumably harmful content removed. 503 The DSN specification [I2.RFC3464], rather than this document, governs 504 the generation and format of DSNs. 506 Similarly, it is appropriate to use Message Disposition Notifications 507 (MDNs) only for responses generated on the recipient's behalf, which are 508 generated on or after delivery to a recipient's mailbox, and for which 509 the purpose of the response is to indicate the disposition of the 510 message. The MDN specification [I3.RFC2298], rather than this document, 511 governs the generation and format of MDNs. 513 This document is not intended to alter either the DSN or MDN 514 specifications. Responses that fit within the criteria of DSN or MDN, 515 as defined by the respective specifications, should be generated 516 according to the DSN or MDN specification rather than this document. 517 Responses which do not fit one of these sets of criteria should be 518 generated according to this document. 520 3.3 Message envelope 522 The SMTP MAIL FROM address, or other envelope return address used to 523 send the message, SHOULD be chosen in such a way as to make mail loops 524 unlikely. A loop might occur, for instance, if both sender and 525 recipient of a message each have automatic responders - the recipient's 526 responder sends mail to the sender's responder, which sends mail back to 527 the recipient's responder. 529 The primary purpose of the MAIL FROM address is to serve as the 530 destination for delivery status messages and other automatic responses. 531 Since in most cases it is not appropriate to respond to an automatic 532 response, and the responder is not interested in delivery status 533 messages, a MAIL FROM address of <> MAY be used for this purpose. A 534 MAIL FROM address which is specifically chosen for the purpose of 535 sending automatic responses, and which will not automatically respond to 536 any message sent to it, MAY be used instead of <>. 538 The RCPT TO address will (of course) be the address of the intended 539 recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER 540 parameter of the RCPT command be specified if the SMTP server supports 541 the DSN option [N5.RFC2003]. 543 4. Where to send automatic responses (and where not to send them) 545 In general, automatic responses SHOULD be sent to the Return-Path field 546 if generated after delivery. If the response is generated prior to 547 delivery, the response SHOULD be sent to the reverse-path from the SMTP 548 MAIL FROM command, or (in a non-SMTP system) to the envelope return 549 address which serves as the destination for nondelivery reports. 551 If the response is to be generated after delivery, and there is no 552 Return-Path field in the subject message, there is an implementation or 553 configuration error in the SMTP server that delivered the message or 554 gatewayed the message outside of SMTP. A Personal or Group responder 555 SHOULD NOT deliver a response to any address other than that in the 556 Return-Path field, even if the Return-Path field is missing. It is 557 better to fix the problem with the mail delivery system than to rely on 558 heuristics to guess the appropriate destination of the response. Such 559 heuristics have been known to cause problems in the past. 561 A Service Responder MAY deliver the response to the address(es) from the 562 >From field, or to another address from the request payload, provided 563 this behavior is precisely defined in the specification for that 564 service. Services responders SHOULD NOT use the Reply-To field for this 565 purpose. 567 The Reply-To field SHOULD NOT be used as the destination for automatic 568 responses from Personal or Group Responders. In general, this field is 569 set by a human sender based on his/her anticipation of how human 570 recipients will respond to the specific content of that message. For 571 instance, a human sender may use Reply-To to request that replies be 572 sent to an entire mailing list. Even for replies from humans, there are 573 cases where it is not appropriate to respond to the Reply-To address, 574 especially if the sender has asked that replies be sent to a group 575 and/or mailing list. Since a Personal or Group Responder operates on 576 behalf of a human recipient, it is safer to assume that any Reply-To 577 field present in the message was set by a human sender on the assumption 578 that any reply would come from a human who had some understanding of the 579 roles of the sender and other recipients. An automatic responder lacks 580 the information necessary to understand those roles. Sending automatic 581 responses to Reply-To addresses can thus result in a large number of 582 people receiving a useless or unwanted message; it can also contribute 583 to mail loops. 585 Use of the From field as the destination for automatic responses has 586 some of the same problems as use of Reply-To. In particular, the From 587 field may list multiple addresses, while automatic responses should only 588 be sent to a single address. In general, the From and Reply-To 589 addresses are used in a variety of ways according to differing 590 circumstances, and for this reason Personal or Group Responders cannot 591 reliably assume that an address in the From or Reply-To field is an 592 appropriate destination for the response. For these reasons the From 593 field SHOULD NOT be used as a destination for automatic responses. 595 Similarly, the Sender field SHOULD NOT be used as the destination for 596 automatic responses. This field is intended only to identify the person 597 or entity that sent the message, and is not required to contain an 598 address that is valid for replies. 600 The Return-Path address is really the only one from the message header 601 that can be expected, as a matter of protocol, to be suitable for 602 automatic responses that were not anticipated by the sender. 604 5. The Auto-Submitted header field 606 The purpose of the Auto-Submitted header field is to indicate that the 607 message was originated by an automatic process, or an automatic 608 responder, rather than by a human; and to facilitate automatic filtering 609 of messages from signal paths for which automatically generated messages 610 and automatic responses are not desirable. 612 5.1 Syntax 614 The syntax of Auto-Submitted is as follows, using the ABNF notation of 615 [N6.RFC2234]: 617 auto-submitted-field = "Auto-Submitted:" [CFWS] 618 auto-submitted [CFWS] CRLF 620 auto-submitted = ( "no" / "auto-generated" / 621 "auto-replied" / extension ) 622 opt-parameter-list 624 extension = token 626 opt-parameter-list = *( [CFWS] ";" [CFWS] parameter ) 628 The symbols "CFWS" and "CRLF" are defined in [N2.RFC2822]. The symbols 629 "token", and "parameter" are as defined in [N7.RFC2045] (as amended by 630 [N4.RFC2231]). 632 The maximum number of Auto-Submitted fields that may appear in a message 633 header is 1. 635 5.2 Semantics 637 The Auto-Submitted header field SHOULD NOT be supplied for messages that 638 were manually submitted by a human. (However, user agents that allow 639 senders to specify arbitrary fields SHOULD NOT prevent humans from 640 setting the Auto-Submitted field, because it is sometimes useful for 641 testing.) 643 The auto-generated keyword: 645 - SHOULD be used on messages generated by automatic (often periodic) 646 processes (such as UNIX "cron jobs") which are not direct responses 647 to other messages, 649 - MUST NOT be used on manually generated messages, 651 - MUST NOT be used on a message issued in direct response to another 652 message, 654 - MUST NOT be used to label Delivery Status Notifications (DSNs) 655 [I2.RFC3464], or Message Disposition Notifications (MDNs) 656 [I3.RFC2298], or other reports of message (non)receipt or 657 (non)delivery. Note: Some widely-deployed SMTP implementations 658 currently use "auto-generated" to label nondelivery reports. These 659 should be changed to use "auto-replied" instead. 661 The auto-replied keyword: 663 - SHOULD be used on messages sent in direct response to another 664 message by an automatic process, 666 - MUST NOT be used on manually-generated messages, 668 - MAY be used on Delivery Status Notifications (DSNs) and Message 669 Disposition Notifications (MDNs), 671 - MUST NOT be used on messages generated by automatic or periodic 672 processes, except for messages which are automatic responses to 673 other messages. 675 The "no" keyword MAY be used to explicitly indicate that a message was 676 originated by a human, if for some reason this is found to be 677 appropriate. 679 Extension keywords may be defined in the future, though it seems 680 unlikely. The syntax and semantics of such keywords must be published 681 as RFCs and approved using the IETF Consensus process [N8.RFC2434]. 682 Keywords beginning with "x-" are reserved for experiments and use among 683 consenting parties. Recipients of messages containing an Auto-Submitted 684 field with any keyword other than "no" MAY assume that the message was 685 not manually submitted by a human. 687 Optional parameters may also be defined by an IETF Consensus process. 688 The syntax of optional parameters is given here to allow for future 689 definition should they be needed. Implementations of Auto-Submitted 690 conforming to this specification MUST NOT fail to recognize an 691 Auto-Submitted field and keyword that contains syntactically valid 692 optional parameters, but such implementations MAY ignore those 693 parameters if they are present. Parameter names beginning with "x-" are 694 reserved for experiments and use among consenting parties. 696 The "comment" syntactical construct from [N2.RFC2822] can be used to 697 indicate a reason why this message was automatically submitted. 699 6. Security Considerations 701 Automatic responders introduce the potential for several kinds of 702 attack, including: 704 - Use of such responders to relay harmful or abusive content (worms, 705 viruses, spam, and spymail) for the purpose of wider distribution 706 of the content or masking the source of such content; 708 - Use of such responders to mount denial-of-service attacks by using 709 responders to relay messages to large numbers of addresses, or to 710 flood individual mailboxes with a large amount of unwanted content, 711 or both; 713 - Deliberate or accidental use of such responders to construct mail 714 loops or "sorcerer's apprentice mode", thus taxing the resources of 715 the mail transport system; 717 - Use of such responders to determine whether recipient addresses are 718 valid, especially when such information is not otherwise provided 719 (e.g. SMTP RCPT or VRFY command responses) and is not intended to 720 be disclosed; 722 - Use of such responders to obtain personal information about 723 recipients, including information about recipients' recent usage of 724 his mailbox or recent activity; 726 - In addition, the responder itself may be subject to attack by 727 sending it large numbers of requests. 729 This document attempts to reduce the vulnerability of responders to such 730 attack, in particular by 732 - Recommending that responders not relay significant content from the 733 subject message (thus minimizing the potential for use of 734 responders to launder or amplify attacker-chosen content) 736 - Recommending that responders clearly mark responses with the 737 "Auto-Submitted: auto-replied" header field to distinguish them 738 from messages originated by humans (in part, to minimize the 739 potential for loops and denial-of-service attacks), 741 - Recommending that Personal and Group Responders limit the number of 742 responses sent to any individual per period of time (also limiting 743 the potential damage caused by loops), 745 - Recommending that responders respond to at most one address per 746 incoming message (to minimize the potential for deliberate or 747 accidental denial-of-service via "multiplication" or sorcerer's 748 apprentice mode), 750 - Recommending that responses from Personal and Group Responders 751 should be brief and in plain text format (to minimize the potential 752 for mail responders to be used as mechanisms for transmitting 753 harmful content and/or disguising the source of harmful content). 755 However, because email addresses are easily forged, attacks are still 756 possible for any email responder which does not limit access and require 757 authentication before issuing a response. The above measures attempt to 758 limit the damage which can be done, but they cannot entirely prevent 759 attacks. 761 This section describes vulnerabilities inherent in automatically 762 responding to mail. Other vulnerabilities are associated with some 763 mail-based services which automatically respond to email messages, but 764 these are not caused by the fact that the server automatically responds 765 to incoming messages. In general, any network-based service (including 766 those accessed by email) needs to provide security that is sufficient to 767 prevent the service from being used as a means to inappropriately or 768 destructively access the resources that are accessible by the service. 770 It has also been noted that Personal and Group Responders sometimes 771 inappropriately disclose recipients' personal information. This might 772 happen automatically (as when a Group Responder automatically supplies a 773 recipient's personal or mobile telephone number as alternate contact 774 information) or "manually". Automatically-generated information SHOULD 775 NOT include personal information about the recipient which is not 776 already known to, or easily available to, the sender of the subject 777 message. User interfaces which allow recipients to supply response text 778 SHOULD make it clear to the user that this information will be made 779 available not only to local colleagues but also to the entire Internet, 780 including potential attackers. 782 7. Example: vacation program 784 This section illustrates how these recommendations might apply to a 785 hypothetical "vacation" program that had the purpose of responding to a 786 single recipient's mail during periods in which that recipient was busy 787 or absent and unable to respond personally. This is intended as 788 illustration only and is not a normative part of this standard. 790 The vacation program is a Personal Responder. 792 The vacation program refuses to respond to any message which: 794 - appears to be spam (for instance, if it has been labelled as 795 advertising by the sender or as potential spam by some 796 intermediary), 798 - appears to contain a virus (for instance, if it contains an 799 executable attachment), 801 - contains an Auto-Submitted header field, 803 - has been sent a response within the previous 7 days, 805 - does not contain one of the recipient's addresses in a To, CC, Bcc, 806 Resent-To, Resent-CC, or Resent-Bcc field, 808 - contains a Precedence field with a value of "list", "junk", or 809 "bulk", 811 - does not have a Return-Path address, or 813 - has a Return-Path address of <>, or a Return-Path address of a form 814 that is frequently used by nondelivery reports. 816 The format of the vacation response is as follows: 818 - The From header field is set to a name and email address specified 819 by the user on whose behalf the responses are being sent. (On some 820 systems it may be reasonable to have a default setting for the From 821 field of vacation responses that is based on the user's account 822 name and the domain name of the system.) 824 - The Reply-To field is set only if explicitly configured by the user 825 on whose behalf the responses are being sent. For example, a user 826 might direct replies to a secretary or co-worker who has been 827 delegated to handle important matters during his absence. 829 - The To field contains the address of the recipient of the response, 830 as obtained from the Return-Path field of the subject message. 832 - The Date field contains the date and time at which the response was 833 generated. 835 - The Subject field contains Auto: followed by a string chosen by the 836 user on whose behalf the responses are being sent. A default 837 setting of something like "away from my mail" might be appropriate. 838 If the Subject field contains non-ASCII characters these are 839 encoded per [N3.RFC2047]. 841 - The In-Reply-To and References fields are generated from the 842 subject message per [N2.RFC2822]. 844 - The Auto-Submitted field has the value "auto-replied". 846 - The message body contains some text specified by the user on whose 847 behalf the response is being sent. A brief summary of the subject 848 message is also included, consisting of From, To, Subject, Date, 849 and a few lines of message text from the subject message. No 850 attachments or non-text bodyparts are included in the response. 852 The SMTP MAIL FROM address of the message envelope is <>. The RCPT TO 853 address in the message envelope is the address of the user to whom the 854 response is being sent. NOTIFY=NEVER is also set in the RCPT TO line if 855 permitted by the SMTP server. 857 8. IANA Considerations 859 Section 5 of this document defines two new extension mechanisms - new 860 keywords for the Auto-Submitted header field, and new optional 861 parameters for the Auto-Submitted field. If at any point in the future 862 new keywords or parameters are approved (through an IETF Consensus 863 process) it may be appropriate for IANA to create a registry of such 864 keywords or parameters. 866 9. Acknowledgments 868 In the mid-1990s Jeroen Houttuin of TERENA authored a series of 869 internet-drafts on "Behavior of Mail Based Servers", and in particular, 870 one document on "Answering Servers" [I7.BOMBS]. While these documents 871 were (to this author's knowledge) never formally published, they 872 provided the first well-reasoned argument (known to this author) as to 873 the best way for such servers to interface with email systems and 874 protocols. 876 The idea for the Auto-Submitted field comes from the X.400/MHS mail 877 system [I8.X420]. [I9.RFC2156] defined an "Autosubmitted" field for use 878 when gatewaying between X.400 and Internet mail. Jacob Palme wrote an 879 internet-draft [I10.AUTOSUB] defining use of the "Auto-Submitted" field 880 for Internet mail, which made it through Last Call without significant 881 objections, but got stalled in an attempt to resolve non-substantial 882 objections. The definition of Auto-Submitted in this document is 883 derived (i.e. slightly simplified) from the one in that document, with 884 some text stolen outright. 886 Thanks are also due to those who contributed suggestions to this 887 document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield, 888 Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera, Dan Kohn, Bruce 889 Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg, Richard Rognlie, 890 Markus Stumpf, Florian Weimer, and Dan Wing. 892 10. Author's Address 894 Keith Moore 895 Innovative Computing Laboratory 896 University of Tennessee, Knoxville 897 1122 Volunteer Blvd, #203 898 Knoxville, TN 37996-3450 900 moore@cs.utk.edu 901 11. Normative References 903 [N1.RFC2119] 904 Bradner, S. Key words for use in RFCs to Indicate Requirement 905 Levels. RFC 2119, March 1997. 907 [N2.RFC2822] 908 Resnick, P. (ed.) Internet Message Format. RFC 2822, April 2001. 910 [N3.RFC2047] 911 Moore, K. MIME (Multipurpose Internet Mail Extensions) Part 912 Three: Message Header Extensions for Non-ASCII Text. RFC 2047, 913 November 1996. 915 [N4.RFC2231] 916 Freed, N., Moore., K. MIME Parameter Value and Encoded Word 917 Extensions: Character Sets, Languages, and Continuations. RFC 918 2231, November 1997. 920 [N5.RFC2003] 921 Moore, K. SMTP Service Extension for Delivery Status 922 Notifications. RFC 3461, January 2003. 924 [N6.RFC2234] 925 Crocker, D. (ed.), Overell, P. Augmented BNF for Syntax 926 Specifications: ABNF. RFC 2234, November 1997. 928 [N7.RFC2045] 929 Freed, N. Borenstein, N. Multipurpose Internet Mail Extensions 930 (MIME) Part One: Format of Internet Message Bodies. RFC 2045, 931 November 1996. 933 [N8.RFC2434] 934 Narten, T., Alvestrand, H. Guidelines for Writing an IANA 935 Considerations Section in RFCs. RFC 2434, October 1998. 937 12. Informative References 939 [I1.JARGON] 940 "Sorcerer's apprentice mode", originally from the Jargon file 941 once maintained at MIT-AI and SAIL; now collected at various 942 places on the net. See e.g. http://www.jargon.net/ 944 [I2.RFC3464] 945 Moore, K. Vaudreuil, G. An Extensible Message Format for 946 Delivery Status Notifications. RFC 3464, January 2003. 948 [I3.RFC2298] 949 Fajman, R. An Extensible Message Format for Message Disposition 950 Notifications. RFC 2298, March 1998. 952 [I4.RFC2076] 953 Palme, J. Common Internet Message Headers. RFC 2076, February 954 1997. 956 [I5.RFC2369] 957 Neufeld, G., Baer, J. The Use of URLs as Meta-Syntax for Core 958 Mail List Commands and their Transport through Message Header 959 Fields. RFC 2369, July 1998. 961 [I6.RFC822] 962 Crocker, D. Standard for the format of ARPA Internet text 963 messages. RFC 822, August 1982. 965 [I7.BOMBS] 966 Houttuin, J. BoMBS series: Behavior of Mail Based Servers / Part 967 2: A-BoMBS / Answering Servers. Expired Internet-Draft "draft- 968 rare-msg-a-bombs-01.txt", December 1994. (reference included only 969 for attribution) 971 [I8.X420] 972 CCITT Recommendation X.420 (1992 E). Information technology - 973 Message Handling Systems (MHS): Interpersonal messaging system, 974 1992. 976 [I9.RFC2156] 977 Kille, S. MIXER (Mime Internet X.400 Enhanced Relay): Mapping 978 between X.400 and RFC 822/MIME. RFC 2156, January 1998. 980 [I10.AUTOSUB] 981 Palme, J. "The Auto-Submitted and Expires Headers in E-mail". 982 Expired Internet-Draft "draft-ietf-mailext-new-fields-15.txt", 983 February 1999. (reference included only for attribution) 985 13. Copyright Notice 987 Copyright (C) The Internet Society (2003). All Rights Reserved. 989 This document and translations of it may be copied and furnished to 990 others, and derivative works that comment on or otherwise explain it or 991 assist in its implementation may be prepared, copied, published and 992 distributed, in whole or in part, without restriction of any kind, 993 provided that the above copyright notice and this paragraph are included 994 on all such copies and derivative works. However, this document itself 995 may not be modified in any way, such as by removing the copyright notice 996 or references to the Internet Society or other Internet organizations, 997 except as needed for the purpose of developing Internet standards in 998 which case the procedures for copyrights defined in the Internet 999 Standards process must be followed, or as required to translate it into 1000 languages other than English. 1002 The limited permissions granted above are perpetual and will not be 1003 revoked by the Internet Society or its successors or assigns. 1005 This document and the information contained herein is provided on an "AS 1006 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1007 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1008 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1009 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1010 FITNESS FOR A PARTICULAR PURPOSE. 1012 14. Changes since version -04 (not intended for inclusion in the RFC) 1014 - Stated that this document is limited in scope to email messages, 1015 not instant messaging, SMS, Usenet, etc. 1017 - Added text regarding applicability of Auto-Submitted to DSNs and 1018 MDNs. 1020 - Added section illustrating applicability to a hypothetical 1021 "vacation" program. 1023 - Other minor wording changes and grammar fixes. 1025 15. Notes to RFC Editor (not intended for inclusion in the RFC) 1027 - The format used for references in this document is a compromise 1028 between the desire to (a) have informative and normative references 1029 in separate sections (b) have reference tags be meaningful to those 1030 who know the documents (e.g. RFC822), and (c) have references 1031 appear in the order they were referenced. Unfortunately, the 1032 result is ugly. Feel free to change the format of reference tags 1033 as you see fit. 1035 - If you see the text ">From" appearing at the beginning of a line in 1036 the document; this is due to a glitch in somebody's mail system. 1037 Please change it to "From". Thanks. 1039 - The internet-draft of this document has been produced in PostScript 1040 and PDF versions in addition to the plain text version. This was 1041 done as an experiment. The author does not claim that these 1042 versions offer any improvement in readability over the plain text 1043 version. In fact the author believes that (due to the formatting 1044 conventions used, paper size, etc) the text version is more 1045 readable than the alternatives. 1047 - To reduce the potential for transcription errors, nroff source code 1048 for this document is available at 1049 http://www.cs.utk.edu/~moore/nroff/draft-moore-auto-email-response-05.ms