Request for Comments: 3834 University of Tennessee
Category: Standards Track August 2004
Recommendations for Automatic Responses to Electronic Mail
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo makes recommendations for software that automatically
responds to incoming electronic mail messages, including "out of the
office" or "vacation" response generators, mail filtering software,
email-based information services, and other automatic responders.
The purpose of these recommendations is to discourage undesirable
behavior which is caused or aggravated by such software, to encourage
uniform behavior (where appropriate) among automatic mail responders,
and to clear up some sources of confusion among implementors of
automatic email responders.
1. Introduction
Many programs which automatically respond to email are currently in
use. Although these programs vary widely in their function, several
problems with this class of programs have been observed, including:
significant numbers of useless or unwanted response and responses
sent to inappropriate addresses, and occasional incidences of mail
loops or "sorcerer’s apprentice" mode. This memo recommends behavior
for programs that automatically respond to electronic mail in order
to reduce the number of problems caused by such programs.
(Note: the term "sorcerer’s apprentice mode" is defined as a bug in a
protocol where, under some circumstances, the receipt of a message
causes multiple messages to be sent, each of which, when received,
triggers the same bug.) (From [I1.JARGON])
This document is limited in scope to Internet electronic mail
messages and many of its recommendations are specifically tailored
for the protocol elements and data models used in Internet electronic
mail messages and SMTP transport envelopes. Use of these
recommendations in other messaging contexts such as instant
messaging, SMS, or Usenet has not been considered, and is outside of
the scope of this document.
1.1. Types of automatic responses
There are several different types of automatic responses. At least
two types of automatic responses have been defined in IETF standards
- Delivery Status Notifications [I2.RFC3464] which are intended to
report the status of a message delivery by the message transport
system, and Message Disposition Notifications [I3.RFC3798] which are
intended to report of the disposition of a message after it reaches a
recipient’s mailbox. These responses are defined elsewhere and are
generally not within the purview of this document, except that this
document recommends specific cases where they should or should not be
used.
Other types of automatic response in common use include:
- "Out of office" or "vacation" notices, which are intended to
inform the sender of a message that the message is unlikely to be
read, or acted on, for some amount of time,
- "Change of address" notices, intended to inform the sender of a
message that the recipient address he used is obsolete and that a
different address should be used instead (whether or not the
subject message was forwarded to the current address),
- "Challenges", which require the sender of a message to demonstrate
some measure of intelligence and/or willingness to agree to some
conditions before the subject message will be delivered to the
recipient (often to minimize the effect of "spam" or viruses on
the recipient),
- Email-based information services, which accept requests
(presumably from humans) via email, provide some service, and
issue responses via email also. (Mailing lists which accept
subscription requests via email fall into this category),
- Information services similar to those mentioned above except that
they are intended to accept messages from other programs, and
- Various kinds of mail filters (including "virus scanners") which
act on behalf of a recipient to alter the content of messages
before forwarding them to that recipient, and issue responses in
the event a message is altered.
Recognizing the wide variety of response types in use, these
recommendations distinguish between several classes of automatic
responders according to the party or service on whose behalf the
responder acts:
- "Service Responders" exist to provide access to some service via
email requests and responses. These are permanently associated
with one or more email addresses, and when sending to such an
address the sender presumably expects an automatic response. An
email-based file retrieval service is an example of a Service
Responder. A calendar service that allows appointment requests to
be made via email, and which responds to such requests, would be
another example of a Service Responder.
- "Personal Responders" exist to make automatic responses on behalf
of a single recipient address, in addition to, or in lieu of, that
recipient reading the message. These responders operate according
to criteria specified on a per-recipient basis. The UNIX
"vacation" program is an example of a Personal Responder. A
responder that accepts mail sent to a single address, attempts to
analyze and classify the contents, and then issues a response
which is dependent on that classification, is also a Personal
Responder.
- "Group Responders" exist to make automatic responses on behalf of
any of a significant set of recipient addresses (say, every
recipient in a particular DNS domain), in advance of, or in lieu
of, a response from the actual recipient. Group Responders are
similar to Personal Responders except that in the case of a Group
Responder the criteria for responding are not set on a per-
recipient basis. A "virus scanner" program that filtered all mail
sent to any recipient on a particular server, and sent responses
when a message was rejected or delivered in an altered form, might
be an example of a Group Responder.
Appropriate behavior for a responder varies from one class to
another. A behavior which might be appropriate from a Service
Responder (where the sender is expecting an automatic response) might
not be appropriate from a Personal Responder. For example, a Service
Responder might send a very long response to a request, or one that
is not in a human-readable format, according to the needs of that
service. However a Personal Responder should assume that a human
being is reading the response and send only brief responses in plain
text.
1.2. Notation and Definitions
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to
be interpreted as described in [N1.RFC2119].
The term "subject message" is used to refer to a message which causes
a response to be sent.
The term "response" refers to a message that is automatically issued
on receipt of a subject message by a responder.
A "responder" is a process that automatically responds to subject
messages under some well-defined set of conditions.
Unless specified otherwise, the term "recipient" refers to the email
addresses to which a subject message was delivered (rather than, for
instance, the address to which the response was sent). A "recipient"
address might be permanently associated with a responder, or it might
be the address of a human being whose mail is, under some conditions,
answered by a responder.
2. When (not) to send automatic responses
An automatic responder MUST NOT blindly send a response for every
message received. In practice there are always reasons to refuse to
respond to some kinds of received messages, e.g., for loop
prevention, to avoid responding to "spam" or viruses, to avoid being
used as a means to launder or amplify abusive messages, to avoid
inappropriately revealing personal information about the recipient
(e.g., to avoid an automatic indication that a recipient has not read
his mail recently), and to thwart denial-of-service attacks against
the responder. The criteria for deciding whether to respond will
differ from one responder to another, according to the responder’s
purpose. In general, care should be taken to avoid sending useless
or redundant responses, and to avoid contributing to mail loops or
facilitating denial-of-service attacks.
Here are some broad guidelines:
- Automatic responses SHOULD NOT be issued in response to any
message which contains an Auto-Submitted header field (see below),
where that field has any value other than "no".
- Personal and Group responses that are intended to notify the
sender of a message of the recipient’s inability to read or reply
to the message (e.g., "away from my mail" or "too busy"
notifications) SHOULD NOT issue the same response to the same
sender more than once within a period of several days, even though
that sender may have sent multiple messages. A 7-day period is
RECOMMENDED as a default.
- Personal and Group responses whose purpose is to notify the sender
of a message of a temporary absence of the recipient (e.g.,
"vacation" and "out of the office" notices) SHOULD NOT be issued
unless a valid address for the recipient is explicitly included in
a recipient (e.g., To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-
Bcc) field of the subject message. Since a recipient may have
multiple addresses forwarded to the same mailbox, recipients
SHOULD be able to specify a set of addresses to the responder
which it will recognize as valid for that recipient.
Note: RFC 2822 section 3.6.3 permits varying uses of the Bcc
field, some of which would allow the sender of the subject message
to explicitly specify the recipient’s address as a "Bcc" recipient
without a Bcc field appearing in the message as delivered, or
without the Bcc field in the delivered message containing the
recipient’s address. However, perhaps because Bcc’s are rarely
used, the heuristic of not responding to messages for which the
recipient was not explicitly listed in a To, CC, or Bcc header
field has been found to work well in practice.
- Personal and Group Responders MAY refuse to generate responses
except to known correspondents or addresses of otherwise "trusted"
individuals. Such responders MAY also generate different kinds of
responses for "trusted" vs. "untrusted" addresses. This might be
useful, for instance, to avoid inappropriate disclosure of
personal information to arbitrary addresses.
- Responders MUST NOT generate any response for which the
destination of that response would be a null address (e.g., an
address for which SMTP MAIL FROM or Return-Path is <>), since the
response would not be delivered to a useful destination.
Responders MAY refuse to generate responses for addresses commonly
used as return addresses by responders - e.g., those with local-
parts matching "owner-*", "*-request", "MAILER-DAEMON", etc.
Responders are encouraged to check the destination address for
validity before generating the response, to avoid generating
responses that cannot be delivered or are unlikely to be useful.
- In order to avoid responding to spam and to certain kinds of
attacks, automatic responses from Service Responders SHOULD NOT be
sent for extremely malformed requests. This may include checking
that the subject message has a content-type and content
appropriate to that service.
- Because the vast majority of email is unauthenticated, and return
addresses are easily forged, in order to avoid being used as a
means of denial-of-service attacks (i.e., to flood mailboxes with
unwanted content) Service Responders SHOULD NOT return large
responses (say, more than a few kilobytes) without specific
knowledge that the request was actually authorized by the party
associated with the address to which the response will be sent.
Similarly, Service Responders SHOULD NOT cause unwanted side-
effects (such as subscribing the sender to a mailing list) without
reasonable assurance that the request was authorized by the
affected party.
NOTE: Since each responder has a different purpose and a different
set of potential threats to which it might be subjected, whether
any particular means of authentication is appropriate for a
particular responder is not in scope for this document.
- A responder MAY refuse to send a response to a subject message
which contains any header or content which makes it appear to the
responder that a response would not be appropriate. For instance,
if the subject message contained a Precedence header field
[I4.RFC2076] with a value of "list" the responder might guess that
the traffic had arrived from a mailing list, and would not respond
if the response were only intended for personal messages. For
similar reasons, a responder MAY ignore any subject message with a
List-* field [I5.RFC2369]. (Because Precedence is not a standard
header field, and its use and interpretation vary widely in the
wild, no particular responder behavior in the presence of
Precedence is recommended by this specification.)
3. Format of automatic responses
The following sections specify details of the contents of automatic
responses, including the header of the response message, the content
of the response, and the envelope in which the response is
transmitted to the email transport system.
3.1. Message header
The fields in the message header should be set as follows:
3.1.1. From field
In correspondence between humans, the From field serves multiple
purposes: It identifies the author of the message (or in some cases,
the party or parties on whose behalf the message was sent), and it is
the default destination of replies from humans. Unfortunately, some
mail systems still send non-delivery reports and other kinds of
automatic responses to the From address.
For automatic responses, the role of the From field in determining
the destination of replies to the response from humans is less
significant, because in most cases it is not useful or appropriate
for a human (or anyone) to reply to an automatic response. One
exception is when there is some problem with the response; it should
be possible to provide feedback to the person operating the
responder.
So in most cases the From address in an automatic response needs to
be chosen according to the following criteria:
- To provide an indication of the party or agent on whose behalf the
response was sent,
- To provide an address to which a recipient of an inappropriate
response can request that the situation be corrected, and
- To diminish the potential for mail loops.
The following behavior is thus recommended:
- For responses sent by Service Responders, the From field SHOULD
contain an address which can be used to reach the (human)
maintainer of that service. The human-readable portion of the
From field (the display-name preceding the address) SHOULD contain
a name or description of the service to identify the service to
humans.
- For responses sent by Personal Responders, the From field SHOULD
contain the name of the recipient of the subject message (i.e.,
the user on whose behalf the response is being sent) and an
address chosen by the recipient of the subject message to be
recognizable to correspondents. Often this will be the same
address that was used to send the subject message to that
recipient.
In the case of a recipient having multiple mail addresses
forwarded to the same mailbox (and responder), a Personal
Responder MAY use heuristics to guess, based on the information
available in various message header fields, which of several
addresses for that recipient the sender is likely to have used,
and use that address in the From field of the response. However
it MUST be possible for a recipient on whose behalf the responder
is acting to explicitly specify the human-readable name and
address to be used in the From header fields of responses.
Note: Due to privacy reasons it may be inappropriate for
responders to disclose an address that is derived, say, from the
recipient’s login information (e.g., POP or IMAP user name or
account name on a multiuser computer) or which discloses the
specific name of the computer where the response was generated.
Furthermore these do not necessarily produce a valid public email
address for the recipient. For this reason, Personal Responders
MUST allow the From field of a Personal Response to be set by the
recipient on whose behalf the responder is acting.
- For Group Responders, the From address SHOULD contain an email
address which could be used to reach the maintainer of that Group
Responder. Use of the Postmaster address for this purpose is NOT
RECOMMENDED.
The human-readable portion of the From address (the "phrase"
before the address, see [N2.RFC2822], section 3.2.6) SHOULD
contain an indication of the function performed by the Group
Responder and on whose behalf it operates (e.g., "Example Agency
virus filter")
3.1.2. Reply-To field
If a reply is expected by the responder, the Reply-To field of the
response SHOULD be set to the address at which the reply is expected,
even if this is the address of the same or another responder.
Responders which request replies to be sent to responders MUST
prevent mail loops and sorcerer’s apprentice mode. Note that since
(according to the previous section) the From field of the response
SHOULD contain the address of a human, if the Reply-To field of the
response is used to direct replies to a responder it will not be the
same as the address in the From field.
Discussion: this assumes that the human recipient’s user agent will
normally send replies to the Reply-To address (if present), as
recommended by [I6.RFC822] since 1982, but that it is still possible
for a recipient to reply to the From address if he or she finds it
useful to do so. This is consistent with the intended use of these
fields in [I6.RFC822] and [N2.RFC2822].
3.1.3. To field
The To header field SHOULD indicate the recipient of the response.
In general there SHOULD only be one recipient of any automatic
response. This minimizes the potential for sorcerer’s apprentice
mode and denial-of-service attacks.
3.1.4. Date field
The Date header field SHOULD indicate the date and time at which the
response was generated. This MUST NOT be taken as any indication of
the delivery date of the subject message, nor of the time at which
the response was sent.
3.1.5. Subject field
The Subject field SHOULD contain a brief indication that the message
is an automatic response, followed by contents of the Subject field
(or a portion thereof) from the subject message. The prefix "Auto:"
MAY be used as such an indication. If used, this prefix SHOULD be
followed by an ASCII SPACE character (0x20).
NOTE: Just as the (Latin-derived) prefix "Re:" that is commonly used
to indicate human-generated responses is sometimes translated to
other languages by mail user agents, or otherwise interpreted by mail
user agents as indication that the message is a reply, so the (Greek)
prefix "Auto:" may also be translated or used as a generic indication
that the message is an automatic response. However the "Auto:"
indication is intended only as an aid to humans in processing the
message. Mail processing software SHOULD NOT assume that the
presence of "Auto:" at the beginning of a Subject field is an
indication that the message was automatically submitted.
Note that the Subject field of the subject message may contain
encoded-words formatted according to [N3.RFC2047] and [N4.RFC2231],
and such text MAY be included in the Subject field of a response. In
generating responses containing such fields there is rarely a need to
decode and re-encode such text. It is usually sufficient to leave
those encoded-words as they were in the subject message, merely
prepending "Auto: " or other indication. However, it is still
necessary to ensure that no line in the resulting Subject field that
contains an encoded-word is greater than 76 ASCII characters in
length (this refers to the encoded form, not the number of characters
in the text being encoded). Also, if the responder truncates the
Subject from the subject message it is necessary to avoid truncating
Subject text in the middle of an encoded-word.
3.1.6. In-Reply-To and References fields
The In-Reply-To and References fields SHOULD be provided in the
header of a response message if there was a Message-ID field in the
subject message, according to the rules in [N2.RFC2822] section
3.6.4.
3.1.7. Auto-Submitted field
The Auto-Submitted field, with a value of "auto-replied", SHOULD be
included in the message header of any automatic response. See
section 5.
3.1.8. Precedence field
A response MAY include a Precedence field [I4.RFC2076] in order to
discourage responses from some kinds of responders which predate this
specification. The field-body of the Precedence field MAY consist of
the text "junk", "list", "bulk", or other text deemed appropriate by
the responder. Because the Precedence field is non-standard and its
interpretation varies widely, the use of Precedence is not
specifically recommended by this specification, nor does this
specification recommend any particular value for that field.
3.2. Message content
In general, messages sent by Personal or Group Responders SHOULD be
brief, and in text/plain format. A multipart/alternative construct
MAY be used to communicate responses in multiple languages,
especially if in doing so it is desirable to use multiple charsets.
Response messages SHOULD NOT include significant content from the
subject message. In particular, Personal and Group responses SHOULD
NOT contain non-text content from the subject message, and they
SHOULD NOT include attachments from the subject message. Neither of
these conditions applies to responders that specifically exist for
the purpose of altering or translating content sent to them (for
instance, a FORTRAN-to-C translator); however, such responders MUST
employ measures to avoid being used as a means of laundering or
forwarding undesirable content, such as spam or viruses.
Note that when text from the Subject or other fields from the header
of the subject message is included in the body of the response, it is
necessary to decode any encoded-words that appeared in those fields
before including in the message body, and to use an appropriate
content-type, charset, and content-transfer-encoding. In some cases
it may be necessary to transliterate text from the charset(s) used in
the header of the subject message, to the charset(s) used in the body
of the response. (It is much easier to implement a responder if text