7Network Working Group K. Moore
8Request for Comments: 3834 University of Tennessee
9Category: Standards Track August 2004
12 Recommendations for Automatic Responses to Electronic Mail
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (C) The Internet Society (2004).
28 This memo makes recommendations for software that automatically
29 responds to incoming electronic mail messages, including "out of the
30 office" or "vacation" response generators, mail filtering software,
31 email-based information services, and other automatic responders.
32 The purpose of these recommendations is to discourage undesirable
33 behavior which is caused or aggravated by such software, to encourage
34 uniform behavior (where appropriate) among automatic mail responders,
35 and to clear up some sources of confusion among implementors of
36 automatic email responders.
40 Many programs which automatically respond to email are currently in
41 use. Although these programs vary widely in their function, several
42 problems with this class of programs have been observed, including:
43 significant numbers of useless or unwanted response and responses
44 sent to inappropriate addresses, and occasional incidences of mail
45 loops or "sorcerer's apprentice" mode. This memo recommends behavior
46 for programs that automatically respond to electronic mail in order
47 to reduce the number of problems caused by such programs.
49 (Note: the term "sorcerer's apprentice mode" is defined as a bug in a
50 protocol where, under some circumstances, the receipt of a message
51 causes multiple messages to be sent, each of which, when received,
52 triggers the same bug.) (From [I1.JARGON])
58Moore Standards Track [Page 1]
60RFC 3834 Automatic E-Mail Responses August 2004
63 This document is limited in scope to Internet electronic mail
64 messages and many of its recommendations are specifically tailored
65 for the protocol elements and data models used in Internet electronic
66 mail messages and SMTP transport envelopes. Use of these
67 recommendations in other messaging contexts such as instant
68 messaging, SMS, or Usenet has not been considered, and is outside of
69 the scope of this document.
711.1. Types of automatic responses
73 There are several different types of automatic responses. At least
74 two types of automatic responses have been defined in IETF standards
75 - Delivery Status Notifications [I2.RFC3464] which are intended to
76 report the status of a message delivery by the message transport
77 system, and Message Disposition Notifications [I3.RFC3798] which are
78 intended to report of the disposition of a message after it reaches a
79 recipient's mailbox. These responses are defined elsewhere and are
80 generally not within the purview of this document, except that this
81 document recommends specific cases where they should or should not be
84 Other types of automatic response in common use include:
86 - "Out of office" or "vacation" notices, which are intended to
87 inform the sender of a message that the message is unlikely to be
88 read, or acted on, for some amount of time,
90 - "Change of address" notices, intended to inform the sender of a
91 message that the recipient address he used is obsolete and that a
92 different address should be used instead (whether or not the
93 subject message was forwarded to the current address),
95 - "Challenges", which require the sender of a message to demonstrate
96 some measure of intelligence and/or willingness to agree to some
97 conditions before the subject message will be delivered to the
98 recipient (often to minimize the effect of "spam" or viruses on
101 - Email-based information services, which accept requests
102 (presumably from humans) via email, provide some service, and
103 issue responses via email also. (Mailing lists which accept
104 subscription requests via email fall into this category),
106 - Information services similar to those mentioned above except that
107 they are intended to accept messages from other programs, and
114Moore Standards Track [Page 2]
116RFC 3834 Automatic E-Mail Responses August 2004
119 - Various kinds of mail filters (including "virus scanners") which
120 act on behalf of a recipient to alter the content of messages
121 before forwarding them to that recipient, and issue responses in
122 the event a message is altered.
124 Recognizing the wide variety of response types in use, these
125 recommendations distinguish between several classes of automatic
126 responders according to the party or service on whose behalf the
129 - "Service Responders" exist to provide access to some service via
130 email requests and responses. These are permanently associated
131 with one or more email addresses, and when sending to such an
132 address the sender presumably expects an automatic response. An
133 email-based file retrieval service is an example of a Service
134 Responder. A calendar service that allows appointment requests to
135 be made via email, and which responds to such requests, would be
136 another example of a Service Responder.
138 - "Personal Responders" exist to make automatic responses on behalf
139 of a single recipient address, in addition to, or in lieu of, that
140 recipient reading the message. These responders operate according
141 to criteria specified on a per-recipient basis. The UNIX
142 "vacation" program is an example of a Personal Responder. A
143 responder that accepts mail sent to a single address, attempts to
144 analyze and classify the contents, and then issues a response
145 which is dependent on that classification, is also a Personal
148 - "Group Responders" exist to make automatic responses on behalf of
149 any of a significant set of recipient addresses (say, every
150 recipient in a particular DNS domain), in advance of, or in lieu
151 of, a response from the actual recipient. Group Responders are
152 similar to Personal Responders except that in the case of a Group
153 Responder the criteria for responding are not set on a per-
154 recipient basis. A "virus scanner" program that filtered all mail
155 sent to any recipient on a particular server, and sent responses
156 when a message was rejected or delivered in an altered form, might
157 be an example of a Group Responder.
159 Appropriate behavior for a responder varies from one class to
160 another. A behavior which might be appropriate from a Service
161 Responder (where the sender is expecting an automatic response) might
162 not be appropriate from a Personal Responder. For example, a Service
163 Responder might send a very long response to a request, or one that
164 is not in a human-readable format, according to the needs of that
170Moore Standards Track [Page 3]
172RFC 3834 Automatic E-Mail Responses August 2004
175 service. However a Personal Responder should assume that a human
176 being is reading the response and send only brief responses in plain
1791.2. Notation and Definitions
181 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
182 "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to
183 be interpreted as described in [N1.RFC2119].
185 The term "subject message" is used to refer to a message which causes
186 a response to be sent.
188 The term "response" refers to a message that is automatically issued
189 on receipt of a subject message by a responder.
191 A "responder" is a process that automatically responds to subject
192 messages under some well-defined set of conditions.
194 Unless specified otherwise, the term "recipient" refers to the email
195 addresses to which a subject message was delivered (rather than, for
196 instance, the address to which the response was sent). A "recipient"
197 address might be permanently associated with a responder, or it might
198 be the address of a human being whose mail is, under some conditions,
199 answered by a responder.
2012. When (not) to send automatic responses
203 An automatic responder MUST NOT blindly send a response for every
204 message received. In practice there are always reasons to refuse to
205 respond to some kinds of received messages, e.g., for loop
206 prevention, to avoid responding to "spam" or viruses, to avoid being
207 used as a means to launder or amplify abusive messages, to avoid
208 inappropriately revealing personal information about the recipient
209 (e.g., to avoid an automatic indication that a recipient has not read
210 his mail recently), and to thwart denial-of-service attacks against
211 the responder. The criteria for deciding whether to respond will
212 differ from one responder to another, according to the responder's
213 purpose. In general, care should be taken to avoid sending useless
214 or redundant responses, and to avoid contributing to mail loops or
215 facilitating denial-of-service attacks.
217 Here are some broad guidelines:
219 - Automatic responses SHOULD NOT be issued in response to any
220 message which contains an Auto-Submitted header field (see below),
221 where that field has any value other than "no".
226Moore Standards Track [Page 4]
228RFC 3834 Automatic E-Mail Responses August 2004
231 - Personal and Group responses that are intended to notify the
232 sender of a message of the recipient's inability to read or reply
233 to the message (e.g., "away from my mail" or "too busy"
234 notifications) SHOULD NOT issue the same response to the same
235 sender more than once within a period of several days, even though
236 that sender may have sent multiple messages. A 7-day period is
237 RECOMMENDED as a default.
239 - Personal and Group responses whose purpose is to notify the sender
240 of a message of a temporary absence of the recipient (e.g.,
241 "vacation" and "out of the office" notices) SHOULD NOT be issued
242 unless a valid address for the recipient is explicitly included in
243 a recipient (e.g., To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-
244 Bcc) field of the subject message. Since a recipient may have
245 multiple addresses forwarded to the same mailbox, recipients
246 SHOULD be able to specify a set of addresses to the responder
247 which it will recognize as valid for that recipient.
249 Note: RFC 2822 section 3.6.3 permits varying uses of the Bcc
250 field, some of which would allow the sender of the subject message
251 to explicitly specify the recipient's address as a "Bcc" recipient
252 without a Bcc field appearing in the message as delivered, or
253 without the Bcc field in the delivered message containing the
254 recipient's address. However, perhaps because Bcc's are rarely
255 used, the heuristic of not responding to messages for which the
256 recipient was not explicitly listed in a To, CC, or Bcc header
257 field has been found to work well in practice.
259 - Personal and Group Responders MAY refuse to generate responses
260 except to known correspondents or addresses of otherwise "trusted"
261 individuals. Such responders MAY also generate different kinds of
262 responses for "trusted" vs. "untrusted" addresses. This might be
263 useful, for instance, to avoid inappropriate disclosure of
264 personal information to arbitrary addresses.
266 - Responders MUST NOT generate any response for which the
267 destination of that response would be a null address (e.g., an
268 address for which SMTP MAIL FROM or Return-Path is <>), since the
269 response would not be delivered to a useful destination.
270 Responders MAY refuse to generate responses for addresses commonly
271 used as return addresses by responders - e.g., those with local-
272 parts matching "owner-*", "*-request", "MAILER-DAEMON", etc.
273 Responders are encouraged to check the destination address for
274 validity before generating the response, to avoid generating
275 responses that cannot be delivered or are unlikely to be useful.
282Moore Standards Track [Page 5]
284RFC 3834 Automatic E-Mail Responses August 2004
287 - In order to avoid responding to spam and to certain kinds of
288 attacks, automatic responses from Service Responders SHOULD NOT be
289 sent for extremely malformed requests. This may include checking
290 that the subject message has a content-type and content
291 appropriate to that service.
293 - Because the vast majority of email is unauthenticated, and return
294 addresses are easily forged, in order to avoid being used as a
295 means of denial-of-service attacks (i.e., to flood mailboxes with
296 unwanted content) Service Responders SHOULD NOT return large
297 responses (say, more than a few kilobytes) without specific
298 knowledge that the request was actually authorized by the party
299 associated with the address to which the response will be sent.
300 Similarly, Service Responders SHOULD NOT cause unwanted side-
301 effects (such as subscribing the sender to a mailing list) without
302 reasonable assurance that the request was authorized by the
305 NOTE: Since each responder has a different purpose and a different
306 set of potential threats to which it might be subjected, whether
307 any particular means of authentication is appropriate for a
308 particular responder is not in scope for this document.
310 - A responder MAY refuse to send a response to a subject message
311 which contains any header or content which makes it appear to the
312 responder that a response would not be appropriate. For instance,
313 if the subject message contained a Precedence header field
314 [I4.RFC2076] with a value of "list" the responder might guess that
315 the traffic had arrived from a mailing list, and would not respond
316 if the response were only intended for personal messages. For
317 similar reasons, a responder MAY ignore any subject message with a
318 List-* field [I5.RFC2369]. (Because Precedence is not a standard
319 header field, and its use and interpretation vary widely in the
320 wild, no particular responder behavior in the presence of
321 Precedence is recommended by this specification.)
3233. Format of automatic responses
325 The following sections specify details of the contents of automatic
326 responses, including the header of the response message, the content
327 of the response, and the envelope in which the response is
328 transmitted to the email transport system.
338Moore Standards Track [Page 6]
340RFC 3834 Automatic E-Mail Responses August 2004
345 The fields in the message header should be set as follows:
349 In correspondence between humans, the From field serves multiple
350 purposes: It identifies the author of the message (or in some cases,
351 the party or parties on whose behalf the message was sent), and it is
352 the default destination of replies from humans. Unfortunately, some
353 mail systems still send non-delivery reports and other kinds of
354 automatic responses to the From address.
356 For automatic responses, the role of the From field in determining
357 the destination of replies to the response from humans is less
358 significant, because in most cases it is not useful or appropriate
359 for a human (or anyone) to reply to an automatic response. One
360 exception is when there is some problem with the response; it should
361 be possible to provide feedback to the person operating the
364 So in most cases the From address in an automatic response needs to
365 be chosen according to the following criteria:
367 - To provide an indication of the party or agent on whose behalf the
370 - To provide an address to which a recipient of an inappropriate
371 response can request that the situation be corrected, and
373 - To diminish the potential for mail loops.
375 The following behavior is thus recommended:
377 - For responses sent by Service Responders, the From field SHOULD
378 contain an address which can be used to reach the (human)
379 maintainer of that service. The human-readable portion of the
380 From field (the display-name preceding the address) SHOULD contain
381 a name or description of the service to identify the service to
384 - For responses sent by Personal Responders, the From field SHOULD
385 contain the name of the recipient of the subject message (i.e.,
386 the user on whose behalf the response is being sent) and an
387 address chosen by the recipient of the subject message to be
388 recognizable to correspondents. Often this will be the same
389 address that was used to send the subject message to that
394Moore Standards Track [Page 7]
396RFC 3834 Automatic E-Mail Responses August 2004
399 In the case of a recipient having multiple mail addresses
400 forwarded to the same mailbox (and responder), a Personal
401 Responder MAY use heuristics to guess, based on the information
402 available in various message header fields, which of several
403 addresses for that recipient the sender is likely to have used,
404 and use that address in the From field of the response. However
405 it MUST be possible for a recipient on whose behalf the responder
406 is acting to explicitly specify the human-readable name and
407 address to be used in the From header fields of responses.
409 Note: Due to privacy reasons it may be inappropriate for
410 responders to disclose an address that is derived, say, from the
411 recipient's login information (e.g., POP or IMAP user name or
412 account name on a multiuser computer) or which discloses the
413 specific name of the computer where the response was generated.
414 Furthermore these do not necessarily produce a valid public email
415 address for the recipient. For this reason, Personal Responders
416 MUST allow the From field of a Personal Response to be set by the
417 recipient on whose behalf the responder is acting.
419 - For Group Responders, the From address SHOULD contain an email
420 address which could be used to reach the maintainer of that Group
421 Responder. Use of the Postmaster address for this purpose is NOT
424 The human-readable portion of the From address (the "phrase"
425 before the address, see [N2.RFC2822], section 3.2.6) SHOULD
426 contain an indication of the function performed by the Group
427 Responder and on whose behalf it operates (e.g., "Example Agency
432 If a reply is expected by the responder, the Reply-To field of the
433 response SHOULD be set to the address at which the reply is expected,
434 even if this is the address of the same or another responder.
435 Responders which request replies to be sent to responders MUST
436 prevent mail loops and sorcerer's apprentice mode. Note that since
437 (according to the previous section) the From field of the response
438 SHOULD contain the address of a human, if the Reply-To field of the
439 response is used to direct replies to a responder it will not be the
440 same as the address in the From field.
442 Discussion: this assumes that the human recipient's user agent will
443 normally send replies to the Reply-To address (if present), as
444 recommended by [I6.RFC822] since 1982, but that it is still possible
450Moore Standards Track [Page 8]
452RFC 3834 Automatic E-Mail Responses August 2004
455 for a recipient to reply to the From address if he or she finds it
456 useful to do so. This is consistent with the intended use of these
457 fields in [I6.RFC822] and [N2.RFC2822].
461 The To header field SHOULD indicate the recipient of the response.
462 In general there SHOULD only be one recipient of any automatic
463 response. This minimizes the potential for sorcerer's apprentice
464 mode and denial-of-service attacks.
468 The Date header field SHOULD indicate the date and time at which the
469 response was generated. This MUST NOT be taken as any indication of
470 the delivery date of the subject message, nor of the time at which
471 the response was sent.
475 The Subject field SHOULD contain a brief indication that the message
476 is an automatic response, followed by contents of the Subject field
477 (or a portion thereof) from the subject message. The prefix "Auto:"
478 MAY be used as such an indication. If used, this prefix SHOULD be
479 followed by an ASCII SPACE character (0x20).
481 NOTE: Just as the (Latin-derived) prefix "Re:" that is commonly used
482 to indicate human-generated responses is sometimes translated to
483 other languages by mail user agents, or otherwise interpreted by mail
484 user agents as indication that the message is a reply, so the (Greek)
485 prefix "Auto:" may also be translated or used as a generic indication
486 that the message is an automatic response. However the "Auto:"
487 indication is intended only as an aid to humans in processing the
488 message. Mail processing software SHOULD NOT assume that the
489 presence of "Auto:" at the beginning of a Subject field is an
490 indication that the message was automatically submitted.
492 Note that the Subject field of the subject message may contain
493 encoded-words formatted according to [N3.RFC2047] and [N4.RFC2231],
494 and such text MAY be included in the Subject field of a response. In
495 generating responses containing such fields there is rarely a need to
496 decode and re-encode such text. It is usually sufficient to leave
497 those encoded-words as they were in the subject message, merely
498 prepending "Auto: " or other indication. However, it is still
499 necessary to ensure that no line in the resulting Subject field that
500 contains an encoded-word is greater than 76 ASCII characters in
501 length (this refers to the encoded form, not the number of characters
506Moore Standards Track [Page 9]
508RFC 3834 Automatic E-Mail Responses August 2004
511 in the text being encoded). Also, if the responder truncates the
512 Subject from the subject message it is necessary to avoid truncating
513 Subject text in the middle of an encoded-word.
5153.1.6. In-Reply-To and References fields
517 The In-Reply-To and References fields SHOULD be provided in the
518 header of a response message if there was a Message-ID field in the
519 subject message, according to the rules in [N2.RFC2822] section
5223.1.7. Auto-Submitted field
524 The Auto-Submitted field, with a value of "auto-replied", SHOULD be
525 included in the message header of any automatic response. See
5283.1.8. Precedence field
530 A response MAY include a Precedence field [I4.RFC2076] in order to
531 discourage responses from some kinds of responders which predate this
532 specification. The field-body of the Precedence field MAY consist of
533 the text "junk", "list", "bulk", or other text deemed appropriate by
534 the responder. Because the Precedence field is non-standard and its
535 interpretation varies widely, the use of Precedence is not
536 specifically recommended by this specification, nor does this
537 specification recommend any particular value for that field.
541 In general, messages sent by Personal or Group Responders SHOULD be
542 brief, and in text/plain format. A multipart/alternative construct
543 MAY be used to communicate responses in multiple languages,
544 especially if in doing so it is desirable to use multiple charsets.
546 Response messages SHOULD NOT include significant content from the
547 subject message. In particular, Personal and Group responses SHOULD
548 NOT contain non-text content from the subject message, and they
549 SHOULD NOT include attachments from the subject message. Neither of
550 these conditions applies to responders that specifically exist for
551 the purpose of altering or translating content sent to them (for
552 instance, a FORTRAN-to-C translator); however, such responders MUST
553 employ measures to avoid being used as a means of laundering or
554 forwarding undesirable content, such as spam or viruses.
556 Note that when text from the Subject or other fields from the header
557 of the subject message is included in the body of the response, it is
558 necessary to decode any encoded-words that appeared in those fields
562Moore Standards Track [Page 10]
564RFC 3834 Automatic E-Mail Responses August 2004
567 before including in the message body, and to use an appropriate
568 content-type, charset, and content-transfer-encoding. In some cases
569 it may be necessary to transliterate text from the charset(s) used in
570 the header of the subject message, to the charset(s) used in the body
571 of the response. (It is much easier to implement a responder if text
572 from the header of the subject message never needs to appear in the
573 body of the response.)
5753.2.1. Use of DSNs and MDNs instead of this specification
577 In general, it is appropriate to use Delivery Status Notifications
578 (DSNs) for responses that are generated by the mail transport system
579 as a result of attempts to relay, forward, or deliver mail, and only
580 when the purpose of that response is to provide the sender of the
581 subject message with information about the status of that mail
582 delivery. For instance, a "virus scanner" which is activated by a
583 mail delivery process to filter harmful content prior to delivery,
584 could return a DSN with the Action field set to "failed" with a
585 Status code of 5.7.1 (Delivery not authorized, message refused) if
586 the entire message was not delivered due to security reasons; or it
587 could return a DSN with the Action field set to "relayed" or
588 "delivered" (as appropriate) with a Status code set to 2.6.4
589 (conversion with loss performed) if the message was relayed or
590 delivered with the presumably harmful content removed. The DSN
591 specification [I2.RFC3464], rather than this document, governs the
592 generation and format of DSNs.
594 Similarly, it is appropriate to use Message Disposition Notifications
595 (MDNs) only for responses generated on the recipient's behalf, which
596 are generated on or after delivery to a recipient's mailbox, and for
597 which the purpose of the response is to indicate the disposition of
598 the message. The MDN specification [I3.RFC3798], rather than this
599 document, governs the generation and format of MDNs.
601 This document is not intended to alter either the DSN or MDN
602 specifications. Responses that fit within the criteria of DSN or
603 MDN, as defined by the respective specifications, should be generated
604 according to the DSN or MDN specification rather than this document.
605 Responses which do not fit one of these sets of criteria should be
606 generated according to this document.
610 The SMTP MAIL FROM address, or other envelope return address used to
611 send the message, SHOULD be chosen in such a way as to make mail
612 loops unlikely. A loop might occur, for instance, if both sender and
618Moore Standards Track [Page 11]
620RFC 3834 Automatic E-Mail Responses August 2004
623 recipient of a message each have automatic responders - the
624 recipient's responder sends mail to the sender's responder, which
625 sends mail back to the recipient's responder.
627 The primary purpose of the MAIL FROM address is to serve as the
628 destination for delivery status messages and other automatic
629 responses. Since in most cases it is not appropriate to respond to
630 an automatic response, and the responder is not interested in
631 delivery status messages, a MAIL FROM address of <> MAY be used for
632 this purpose. A MAIL FROM address which is specifically chosen for
633 the purpose of sending automatic responses, and which will not
634 automatically respond to any message sent to it, MAY be used instead
637 The RCPT TO address will (of course) be the address of the intended
638 recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER
639 parameter of the RCPT command be specified if the SMTP server
640 supports the DSN option [N5.RFC3461].
6424. Where to send automatic responses (and where not to send them)
644 In general, automatic responses SHOULD be sent to the Return-Path
645 field if generated after delivery. If the response is generated
646 prior to delivery, the response SHOULD be sent to the reverse-path
647 from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
648 envelope return address which serves as the destination for non-
651 If the response is to be generated after delivery, and there is no
652 Return-Path field in the subject message, there is an implementation
653 or configuration error in the SMTP server that delivered the message
654 or gatewayed the message outside of SMTP. A Personal or Group
655 responder SHOULD NOT deliver a response to any address other than
656 that in the Return-Path field, even if the Return-Path field is
657 missing. It is better to fix the problem with the mail delivery
658 system than to rely on heuristics to guess the appropriate
659 destination of the response. Such heuristics have been known to
660 cause problems in the past.
662 A Service Responder MAY deliver the response to the address(es) from
663 the >From field, or to another address from the request payload,
664 provided this behavior is precisely defined in the specification for
665 that service. Services responders SHOULD NOT use the Reply-To field
668 The Reply-To field SHOULD NOT be used as the destination for
669 automatic responses from Personal or Group Responders. In general,
670 this field is set by a human sender based on his/her anticipation of
674Moore Standards Track [Page 12]
676RFC 3834 Automatic E-Mail Responses August 2004
679 how human recipients will respond to the specific content of that
680 message. For instance, a human sender may use Reply-To to request
681 that replies be sent to an entire mailing list. Even for replies
682 from humans, there are cases where it is not appropriate to respond
683 to the Reply-To address, especially if the sender has asked that
684 replies be sent to a group and/or mailing list. Since a Personal or
685 Group Responder operates on behalf of a human recipient, it is safer
686 to assume that any Reply-To field present in the message was set by a
687 human sender on the assumption that any reply would come from a human
688 who had some understanding of the roles of the sender and other
689 recipients. An automatic responder lacks the information necessary
690 to understand those roles. Sending automatic responses to Reply-To
691 addresses can thus result in a large number of people receiving a
692 useless or unwanted message; it can also contribute to mail loops.
694 Use of the From field as the destination for automatic responses has
695 some of the same problems as use of Reply-To. In particular, the
696 From field may list multiple addresses, while automatic responses
697 should only be sent to a single address. In general, the From and
698 Reply-To addresses are used in a variety of ways according to
699 differing circumstances, and for this reason Personal or Group
700 Responders cannot reliably assume that an address in the From or
701 Reply-To field is an appropriate destination for the response. For
702 these reasons the From field SHOULD NOT be used as a destination for
705 Similarly, the Sender field SHOULD NOT be used as the destination for
706 automatic responses. This field is intended only to identify the
707 person or entity that sent the message, and is not required to
708 contain an address that is valid for replies.
710 The Return-Path address is really the only one from the message
711 header that can be expected, as a matter of protocol, to be suitable
712 for automatic responses that were not anticipated by the sender.
7145. The Auto-Submitted header field
716 The purpose of the Auto-Submitted header field is to indicate that
717 the message was originated by an automatic process, or an automatic
718 responder, rather than by a human; and to facilitate automatic
719 filtering of messages from signal paths for which automatically
720 generated messages and automatic responses are not desirable.
724 The syntax of Auto-Submitted is as follows, using the ABNF notation
730Moore Standards Track [Page 13]
732RFC 3834 Automatic E-Mail Responses August 2004
735 auto-submitted-field = "Auto-Submitted:" [CFWS]
736 auto-submitted [CFWS] CRLF
738 auto-submitted = ( "no" / "auto-generated" /
739 "auto-replied" / extension )
744 opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
746 The symbols "CFWS" and "CRLF" are defined in [N2.RFC2822]. The
747 symbols "token", and "parameter" are as defined in [N7.RFC2045] (as
748 amended by [N4.RFC2231]).
750 The maximum number of Auto-Submitted fields that may appear in a
755 The Auto-Submitted header field SHOULD NOT be supplied for messages
756 that were manually submitted by a human. (However, user agents that
757 allow senders to specify arbitrary fields SHOULD NOT prevent humans
758 from setting the Auto-Submitted field, because it is sometimes useful
761 The auto-generated keyword:
763 - SHOULD be used on messages generated by automatic (often periodic)
764 processes (such as UNIX "cron jobs") which are not direct
765 responses to other messages,
767 - MUST NOT be used on manually generated messages,
769 - MUST NOT be used on a message issued in direct response to another
772 - MUST NOT be used to label Delivery Status Notifications (DSNs)
773 [I2.RFC3464], or Message Disposition Notifications (MDNs)
774 [I3.RFC3798], or other reports of message (non)receipt or
775 (non)delivery. Note: Some widely-deployed SMTP implementations
776 currently use "auto-generated" to label non-delivery reports.
777 These should be changed to use "auto-replied" instead.
779 The auto-replied keyword:
781 - SHOULD be used on messages sent in direct response to another
782 message by an automatic process,
786Moore Standards Track [Page 14]
788RFC 3834 Automatic E-Mail Responses August 2004
791 - MUST NOT be used on manually-generated messages,
793 - MAY be used on Delivery Status Notifications (DSNs) and Message
794 Disposition Notifications (MDNs),
796 - MUST NOT be used on messages generated by automatic or periodic
797 processes, except for messages which are automatic responses to
800 The "no" keyword MAY be used to explicitly indicate that a message
801 was originated by a human, if for some reason this is found to be
804 Extension keywords may be defined in the future, though it seems
805 unlikely. The syntax and semantics of such keywords must be
806 published as RFCs and approved using the IETF Consensus process
807 [N8.RFC2434]. Keywords beginning with "x-" are reserved for
808 experiments and use among consenting parties. Recipients of messages
809 containing an Auto-Submitted field with any keyword other than "no"
810 MAY assume that the message was not manually submitted by a human.
812 Optional parameters may also be defined by an IETF Consensus process.
813 The syntax of optional parameters is given here to allow for future
814 definition should they be needed. Implementations of Auto-Submitted
815 conforming to this specification MUST NOT fail to recognize an Auto-
816 Submitted field and keyword that contains syntactically valid
817 optional parameters, but such implementations MAY ignore those
818 parameters if they are present. Parameter names beginning with "x-"
819 are reserved for experiments and use among consenting parties.
821 The "comment" syntactical construct from [N2.RFC2822] can be used to
822 indicate a reason why this message was automatically submitted.
8246. Security Considerations
826 Automatic responders introduce the potential for several kinds of
829 - Use of such responders to relay harmful or abusive content (worms,
830 viruses, spam, and spymail) for the purpose of wider distribution
831 of the content or masking the source of such content;
833 - Use of such responders to mount denial-of-service attacks by using
834 responders to relay messages to large numbers of addresses, or to
835 flood individual mailboxes with a large amount of unwanted
842Moore Standards Track [Page 15]
844RFC 3834 Automatic E-Mail Responses August 2004
847 - Deliberate or accidental use of such responders to construct mail
848 loops or "sorcerer's apprentice mode", thus taxing the resources
849 of the mail transport system;
851 - Use of such responders to determine whether recipient addresses
852 are valid, especially when such information is not otherwise
853 provided (e.g., SMTP RCPT or VRFY command responses) and is not
854 intended to be disclosed;
856 - Use of such responders to obtain personal information about
857 recipients, including information about recipients' recent usage
858 of his mailbox or recent activity;
860 - In addition, the responder itself may be subject to attack by
861 sending it large numbers of requests.
863 This document attempts to reduce the vulnerability of responders to
864 such attack, in particular by
866 - Recommending that responders not relay significant content from
867 the subject message (thus minimizing the potential for use of
868 responders to launder or amplify attacker-chosen content)
870 - Recommending that responders clearly mark responses with the
871 "Auto-Submitted: auto-replied" header field to distinguish them
872 from messages originated by humans (in part, to minimize the
873 potential for loops and denial-of-service attacks),
875 - Recommending that Personal and Group Responders limit the number
876 of responses sent to any individual per period of time (also
877 limiting the potential damage caused by loops),
879 - Recommending that responders respond to at most one address per
880 incoming message (to minimize the potential for deliberate or
881 accidental denial-of-service via "multiplication" or sorcerer's
884 - Recommending that responses from Personal and Group Responders
885 should be brief and in plain text format (to minimize the
886 potential for mail responders to be used as mechanisms for
887 transmitting harmful content and/or disguising the source of
890 However, because email addresses are easily forged, attacks are still
891 possible for any email responder which does not limit access and
892 require authentication before issuing a response. The above measures
893 attempt to limit the damage which can be done, but they cannot
894 entirely prevent attacks.
898Moore Standards Track [Page 16]
900RFC 3834 Automatic E-Mail Responses August 2004
903 This section describes vulnerabilities inherent in automatically
904 responding to mail. Other vulnerabilities are associated with some
905 mail-based services which automatically respond to email messages,
906 but these are not caused by the fact that the server automatically
907 responds to incoming messages. In general, any network-based service
908 (including those accessed by email) needs to provide security that is
909 sufficient to prevent the service from being used as a means to
910 inappropriately or destructively access the resources that are
911 accessible by the service.
913 It has also been noted that Personal and Group Responders sometimes
914 inappropriately disclose recipients' personal information. This
915 might happen automatically (as when a Group Responder automatically
916 supplies a recipient's personal or mobile telephone number as
917 alternate contact information) or "manually". Automatically-
918 generated information SHOULD NOT include personal information about
919 the recipient which is not already known to, or easily available to,
920 the sender of the subject message. User interfaces which allow
921 recipients to supply response text SHOULD make it clear to the user
922 that this information will be made available not only to local
923 colleagues but also to the entire Internet, including potential
9267. Example: vacation program
928 This section illustrates how these recommendations might apply to a
929 hypothetical "vacation" program that had the purpose of responding to
930 a single recipient's mail during periods in which that recipient was
931 busy or absent and unable to respond personally. This is intended as
932 illustration only and is not a normative part of this standard.
934 The vacation program is a Personal Responder.
936 The vacation program refuses to respond to any message which:
938 - appears to be spam (for instance, if it has been labelled as
939 advertising by the sender or as potential spam by some
942 - appears to contain a virus (for instance, if it contains an
943 executable attachment),
945 - contains an Auto-Submitted header field,
947 - has been sent a response within the previous 7 days,
949 - does not contain one of the recipient's addresses in a To, CC,
950 Bcc, Resent-To, Resent-CC, or Resent-Bcc field,
954Moore Standards Track [Page 17]
956RFC 3834 Automatic E-Mail Responses August 2004
959 - contains a Precedence field with a value of "list", "junk", or
962 - does not have a Return-Path address, or
964 - has a Return-Path address of <>, or a Return-Path address of a
965 form that is frequently used by non-delivery reports.
967 The format of the vacation response is as follows:
969 - The From header field is set to a name and email address specified
970 by the user on whose behalf the responses are being sent. (On
971 some systems it may be reasonable to have a default setting for
972 the From field of vacation responses that is based on the user's
973 account name and the domain name of the system.)
975 - The Reply-To field is set only if explicitly configured by the
976 user on whose behalf the responses are being sent. For example, a
977 user might direct replies to a secretary or co-worker who has been
978 delegated to handle important matters during his absence.
980 - The To field contains the address of the recipient of the
981 response, as obtained from the Return-Path field of the subject
984 - The Date field contains the date and time at which the response
987 - The Subject field contains Auto: followed by a string chosen by
988 the user on whose behalf the responses are being sent. A default
989 setting of something like "away from my mail" might be
990 appropriate. If the Subject field contains non-ASCII characters
991 these are encoded per [N3.RFC2047].
993 - The In-Reply-To and References fields are generated from the
994 subject message per [N2.RFC2822].
996 - The Auto-Submitted field has the value "auto-replied".
998 - The message body contains some text specified by the user on whose
999 behalf the response is being sent. A brief summary of the subject
1000 message is also included, consisting of From, To, Subject, Date,
1001 and a few lines of message text from the subject message. No
1002 attachments or non-text bodyparts are included in the response.
1010Moore Standards Track [Page 18]
1012RFC 3834 Automatic E-Mail Responses August 2004
1015 The SMTP MAIL FROM address of the message envelope is <>. The RCPT
1016 TO address in the message envelope is the address of the user to whom
1017 the response is being sent. NOTIFY=NEVER is also set in the RCPT TO
1018 line if permitted by the SMTP server.
10208. IANA Considerations
1022 Section 5 of this document defines two new extension mechanisms - new
1023 keywords for the Auto-Submitted header field, and new optional
1024 parameters for the Auto-Submitted field. If at any point in the
1025 future new keywords or parameters are approved (through an IETF
1026 Consensus process) it may be appropriate for IANA to create a
1027 registry of such keywords or parameters.
1031 In the mid-1990s Jeroen Houttuin of TERENA authored a series of
1032 internet-drafts on "Behavior of Mail Based Servers", and in
1033 particular, one document on "Answering Servers". While these
1034 documents were (to this author's knowledge) never formally published,
1035 they provided the first well-reasoned argument (known to this author)
1036 as to the best way for such servers to interface with email systems
1039 The idea for the Auto-Submitted field comes from the X.400/MHS mail
1040 system [I7.X420]. [I8.RFC2156] defined an "Autosubmitted" field for
1041 use when gatewaying between X.400 and Internet mail. Jacob Palme
1042 wrote an internet-draft defining use of the "Auto-Submitted" field
1043 for Internet mail, which made it through Last Call without
1044 significant objections, but got stalled in an attempt to resolve
1045 non-substantial objections. The definition of Auto-Submitted in this
1046 document is derived (i.e., slightly simplified) from the one in that
1047 document, with some text stolen outright.
1049 Thanks are also due to those who contributed suggestions to this
1050 document: Russ Allbery, Adam Costello, Ned Freed, Lawrence
1051 Greenfield, Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera,
1052 Dan Kohn, Bruce Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg,
1053 Richard Rognlie, Markus Stumpf, Florian Weimer, and Dan Wing.
105710.1. Normative References
1059 [N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1060 Requirement Levels", BCP 14, RFC 2119, March 1997.
1066Moore Standards Track [Page 19]
1068RFC 3834 Automatic E-Mail Responses August 2004
1071 [N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
1074 [N3.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
1075 Extensions) Part Three: Message Header Extensions for
1076 Non-ASCII Text", RFC 2047, November 1996.
1078 [N4.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
1079 Encoded Word Extensions: Character Sets, Languages, and
1080 Continuations", RFC 2231, November 1997.
1082 [N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
1083 Service Extension for Delivery Status Notifications
1084 (DSNs)", RFC 3461, January 2003.
1086 [N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
1087 Syntax Specifications: ABNF", RFC 2234, November 1997.
1089 [N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
1090 Mail Extensions (MIME) Part One: Format of Internet
1091 Message Bodies", RFC 2045, November 1996.
1093 [N8.RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
1094 an IANA Considerations Section in RFCs", BCP 26, RFC
109710.2. Informative References
1099 [I1.JARGON] "Sorcerer's apprentice mode", originally from the
1100 Jargon file once maintained at MIT-AI and SAIL; now
1101 collected at various places on the net. See e.g.,
1102 http://www.jargon.net/
1104 [I2.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
1105 Format for Delivery Status Notifications", RFC 3464,
1108 [I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
1109 Notifications", RFC 3798, May 2004.
1111 [I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
1114 [I5.RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-
1115 Syntax for Core Mail List Commands and their Transport
1116 through Message Header Fields", RFC 2369, July 1998.
1122Moore Standards Track [Page 20]
1124RFC 3834 Automatic E-Mail Responses August 2004
1127 [I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet
1128 text messages", STD 11, RFC 822, August 1982.
1130 [I7.X420] CCITT Recommendation X.420 (1992 E). Information
1131 technology - Message Handling Systems (MHS):
1132 Interpersonal messaging system, 1992.
1134 [I8.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
1135 Mapping between X.400 and RFC 822/MIME", RFC 2156,
1141 Innovative Computing Laboratory
1142 University of Tennessee, Knoxville
1143 1122 Volunteer Blvd, #203
1144 Knoxville, TN 37996-3450
1146 EMail: moore@cs.utk.edu
1178Moore Standards Track [Page 21]
1180RFC 3834 Automatic E-Mail Responses August 2004
1183Full Copyright Statement
1185 Copyright (C) The Internet Society (2004). This document is subject
1186 to the rights, licenses and restrictions contained in BCP 78, and
1187 except as set forth therein, the authors retain all their rights.
1189 This document and the information contained herein are provided on an
1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1192 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1193 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1194 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1197Intellectual Property
1199 The IETF takes no position regarding the validity or scope of any
1200 Intellectual Property Rights or other rights that might be claimed to
1201 pertain to the implementation or use of the technology described in
1202 this document or the extent to which any license under such rights
1203 might or might not be available; nor does it represent that it has
1204 made any independent effort to identify any such rights. Information
1205 on the procedures with respect to rights in RFC documents can be
1206 found in BCP 78 and BCP 79.
1208 Copies of IPR disclosures made to the IETF Secretariat and any
1209 assurances of licenses to be made available, or the result of an
1210 attempt made to obtain a general license or permission for the use of
1211 such proprietary rights by implementers or users of this
1212 specification can be obtained from the IETF on-line IPR repository at
1213 http://www.ietf.org/ipr.
1215 The IETF invites any interested party to bring to its attention any
1216 copyrights, patents or patent applications, or other proprietary
1217 rights that may cover technology that may be required to implement
1218 this standard. Please address the information to the IETF at ietf-
1223 Funding for the RFC Editor function is currently provided by the
1234Moore Standards Track [Page 22]