from the header of the subject message never needs to appear in the
body of the response.)
3.2.1. Use of DSNs and MDNs instead of this specification
In general, it is appropriate to use Delivery Status Notifications
(DSNs) for responses that are generated by the mail transport system
as a result of attempts to relay, forward, or deliver mail, and only
when the purpose of that response is to provide the sender of the
subject message with information about the status of that mail
delivery. For instance, a "virus scanner" which is activated by a
mail delivery process to filter harmful content prior to delivery,
could return a DSN with the Action field set to "failed" with a
Status code of 5.7.1 (Delivery not authorized, message refused) if
the entire message was not delivered due to security reasons; or it
could return a DSN with the Action field set to "relayed" or
"delivered" (as appropriate) with a Status code set to 2.6.4
(conversion with loss performed) if the message was relayed or
delivered with the presumably harmful content removed. The DSN
specification [I2.RFC3464], rather than this document, governs the
generation and format of DSNs.
Similarly, it is appropriate to use Message Disposition Notifications
(MDNs) only for responses generated on the recipient’s behalf, which
are generated on or after delivery to a recipient’s mailbox, and for
which the purpose of the response is to indicate the disposition of
the message. The MDN specification [I3.RFC3798], rather than this
document, governs the generation and format of MDNs.
This document is not intended to alter either the DSN or MDN
specifications. Responses that fit within the criteria of DSN or
MDN, as defined by the respective specifications, should be generated
according to the DSN or MDN specification rather than this document.
Responses which do not fit one of these sets of criteria should be
generated according to this document.
3.3. Message envelope
The SMTP MAIL FROM address, or other envelope return address used to
send the message, SHOULD be chosen in such a way as to make mail
loops unlikely. A loop might occur, for instance, if both sender and
recipient of a message each have automatic responders - the
recipient’s responder sends mail to the sender’s responder, which
sends mail back to the recipient’s responder.
The primary purpose of the MAIL FROM address is to serve as the
destination for delivery status messages and other automatic
responses. Since in most cases it is not appropriate to respond to
an automatic response, and the responder is not interested in
delivery status messages, a MAIL FROM address of <> MAY be used for
this purpose. A MAIL FROM address which is specifically chosen for
the purpose of sending automatic responses, and which will not
automatically respond to any message sent to it, MAY be used instead
of <>.
The RCPT TO address will (of course) be the address of the intended
recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER
parameter of the RCPT command be specified if the SMTP server
supports the DSN option [N5.RFC3461].
4. Where to send automatic responses (and where not to send them)
In general, automatic responses SHOULD be sent to the Return-Path
field if generated after delivery. If the response is generated
prior to delivery, the response SHOULD be sent to the reverse-path
from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
envelope return address which serves as the destination for non-
delivery reports.
If the response is to be generated after delivery, and there is no
Return-Path field in the subject message, there is an implementation
or configuration error in the SMTP server that delivered the message
or gatewayed the message outside of SMTP. A Personal or Group
responder SHOULD NOT deliver a response to any address other than
that in the Return-Path field, even if the Return-Path field is
missing. It is better to fix the problem with the mail delivery
system than to rely on heuristics to guess the appropriate
destination of the response. Such heuristics have been known to
cause problems in the past.
A Service Responder MAY deliver the response to the address(es) from
the >From field, or to another address from the request payload,
provided this behavior is precisely defined in the specification for
that service. Services responders SHOULD NOT use the Reply-To field
for this purpose.
The Reply-To field SHOULD NOT be used as the destination for
automatic responses from Personal or Group Responders. In general,
this field is set by a human sender based on his/her anticipation of
how human recipients will respond to the specific content of that
message. For instance, a human sender may use Reply-To to request
that replies be sent to an entire mailing list. Even for replies
from humans, there are cases where it is not appropriate to respond
to the Reply-To address, especially if the sender has asked that
replies be sent to a group and/or mailing list. Since a Personal or
Group Responder operates on behalf of a human recipient, it is safer
to assume that any Reply-To field present in the message was set by a
human sender on the assumption that any reply would come from a human
who had some understanding of the roles of the sender and other
recipients. An automatic responder lacks the information necessary
to understand those roles. Sending automatic responses to Reply-To
addresses can thus result in a large number of people receiving a
useless or unwanted message; it can also contribute to mail loops.
Use of the From field as the destination for automatic responses has
some of the same problems as use of Reply-To. In particular, the
From field may list multiple addresses, while automatic responses
should only be sent to a single address. In general, the From and
Reply-To addresses are used in a variety of ways according to
differing circumstances, and for this reason Personal or Group
Responders cannot reliably assume that an address in the From or
Reply-To field is an appropriate destination for the response. For
these reasons the From field SHOULD NOT be used as a destination for
automatic responses.
Similarly, the Sender field SHOULD NOT be used as the destination for
automatic responses. This field is intended only to identify the
person or entity that sent the message, and is not required to
contain an address that is valid for replies.
The Return-Path address is really the only one from the message
header that can be expected, as a matter of protocol, to be suitable
for automatic responses that were not anticipated by the sender.
5. The Auto-Submitted header field
The purpose of the Auto-Submitted header field is to indicate that
the message was originated by an automatic process, or an automatic
responder, rather than by a human; and to facilitate automatic
filtering of messages from signal paths for which automatically
generated messages and automatic responses are not desirable.
5.1. Syntax
The syntax of Auto-Submitted is as follows, using the ABNF notation
of [N6.RFC2234]:
auto-submitted-field = "Auto-Submitted:" [CFWS]
auto-submitted [CFWS] CRLF
auto-submitted = ( "no" / "auto-generated" /
"auto-replied" / extension )
opt-parameter-list
extension = token
opt-parameter-list = *( [CFWS] ";" [CFWS] parameter )
The symbols "CFWS" and "CRLF" are defined in [N2.RFC2822]. The
symbols "token", and "parameter" are as defined in [N7.RFC2045] (as
amended by [N4.RFC2231]).
The maximum number of Auto-Submitted fields that may appear in a
message header is 1.
5.2. Semantics
The Auto-Submitted header field SHOULD NOT be supplied for messages
that were manually submitted by a human. (However, user agents that
allow senders to specify arbitrary fields SHOULD NOT prevent humans
from setting the Auto-Submitted field, because it is sometimes useful
for testing.)
The auto-generated keyword:
- SHOULD be used on messages generated by automatic (often periodic)
processes (such as UNIX "cron jobs") which are not direct
responses to other messages,
- MUST NOT be used on manually generated messages,
- MUST NOT be used on a message issued in direct response to another
message,
- MUST NOT be used to label Delivery Status Notifications (DSNs)
[I2.RFC3464], or Message Disposition Notifications (MDNs)
[I3.RFC3798], or other reports of message (non)receipt or
(non)delivery. Note: Some widely-deployed SMTP implementations
currently use "auto-generated" to label non-delivery reports.
These should be changed to use "auto-replied" instead.
The auto-replied keyword:
- SHOULD be used on messages sent in direct response to another
message by an automatic process,
- MUST NOT be used on manually-generated messages,
- MAY be used on Delivery Status Notifications (DSNs) and Message
Disposition Notifications (MDNs),
- MUST NOT be used on messages generated by automatic or periodic
processes, except for messages which are automatic responses to
other messages.
The "no" keyword MAY be used to explicitly indicate that a message
was originated by a human, if for some reason this is found to be
appropriate.
Extension keywords may be defined in the future, though it seems
unlikely. The syntax and semantics of such keywords must be
published as RFCs and approved using the IETF Consensus process
[N8.RFC2434]. Keywords beginning with "x-" are reserved for
experiments and use among consenting parties. Recipients of messages
containing an Auto-Submitted field with any keyword other than "no"
MAY assume that the message was not manually submitted by a human.
Optional parameters may also be defined by an IETF Consensus process.
The syntax of optional parameters is given here to allow for future
definition should they be needed. Implementations of Auto-Submitted
conforming to this specification MUST NOT fail to recognize an Auto-
Submitted field and keyword that contains syntactically valid
optional parameters, but such implementations MAY ignore those
parameters if they are present. Parameter names beginning with "x-"
are reserved for experiments and use among consenting parties.
The "comment" syntactical construct from [N2.RFC2822] can be used to
indicate a reason why this message was automatically submitted.
6. Security Considerations
Automatic responders introduce the potential for several kinds of
attack, including:
- Use of such responders to relay harmful or abusive content (worms,
viruses, spam, and spymail) for the purpose of wider distribution
of the content or masking the source of such content;
- Use of such responders to mount denial-of-service attacks by using
responders to relay messages to large numbers of addresses, or to
flood individual mailboxes with a large amount of unwanted
content, or both;
- Deliberate or accidental use of such responders to construct mail
loops or "sorcerer’s apprentice mode", thus taxing the resources
of the mail transport system;
- Use of such responders to determine whether recipient addresses
are valid, especially when such information is not otherwise
provided (e.g., SMTP RCPT or VRFY command responses) and is not
intended to be disclosed;
- Use of such responders to obtain personal information about
recipients, including information about recipients’ recent usage
of his mailbox or recent activity;
- In addition, the responder itself may be subject to attack by
sending it large numbers of requests.
This document attempts to reduce the vulnerability of responders to
such attack, in particular by
- Recommending that responders not relay significant content from
the subject message (thus minimizing the potential for use of
responders to launder or amplify attacker-chosen content)
- Recommending that responders clearly mark responses with the
"Auto-Submitted: auto-replied" header field to distinguish them
from messages originated by humans (in part, to minimize the
potential for loops and denial-of-service attacks),
- Recommending that Personal and Group Responders limit the number
of responses sent to any individual per period of time (also
limiting the potential damage caused by loops),
- Recommending that responders respond to at most one address per
incoming message (to minimize the potential for deliberate or
accidental denial-of-service via "multiplication" or sorcerer’s
apprentice mode),
- Recommending that responses from Personal and Group Responders
should be brief and in plain text format (to minimize the
potential for mail responders to be used as mechanisms for
transmitting harmful content and/or disguising the source of
harmful content).
However, because email addresses are easily forged, attacks are still
possible for any email responder which does not limit access and
require authentication before issuing a response. The above measures
attempt to limit the damage which can be done, but they cannot
entirely prevent attacks.
This section describes vulnerabilities inherent in automatically
responding to mail. Other vulnerabilities are associated with some
mail-based services which automatically respond to email messages,
but these are not caused by the fact that the server automatically
responds to incoming messages. In general, any network-based service
(including those accessed by email) needs to provide security that is
sufficient to prevent the service from being used as a means to
inappropriately or destructively access the resources that are
accessible by the service.
It has also been noted that Personal and Group Responders sometimes
inappropriately disclose recipients’ personal information. This
might happen automatically (as when a Group Responder automatically
supplies a recipient’s personal or mobile telephone number as
alternate contact information) or "manually". Automatically-
generated information SHOULD NOT include personal information about
the recipient which is not already known to, or easily available to,
the sender of the subject message. User interfaces which allow
recipients to supply response text SHOULD make it clear to the user
that this information will be made available not only to local
colleagues but also to the entire Internet, including potential
attackers.
7. Example: vacation program
This section illustrates how these recommendations might apply to a
hypothetical "vacation" program that had the purpose of responding to
a single recipient’s mail during periods in which that recipient was
busy or absent and unable to respond personally. This is intended as
illustration only and is not a normative part of this standard.
The vacation program is a Personal Responder.
The vacation program refuses to respond to any message which:
- appears to be spam (for instance, if it has been labelled as
advertising by the sender or as potential spam by some
intermediary),
- appears to contain a virus (for instance, if it contains an
executable attachment),
- contains an Auto-Submitted header field,
- has been sent a response within the previous 7 days,
- does not contain one of the recipient’s addresses in a To, CC,
Bcc, Resent-To, Resent-CC, or Resent-Bcc field,
- contains a Precedence field with a value of "list", "junk", or
"bulk",
- does not have a Return-Path address, or
- has a Return-Path address of <>, or a Return-Path address of a
form that is frequently used by non-delivery reports.
The format of the vacation response is as follows:
- The From header field is set to a name and email address specified
by the user on whose behalf the responses are being sent. (On
some systems it may be reasonable to have a default setting for
the From field of vacation responses that is based on the user’s
account name and the domain name of the system.)
- The Reply-To field is set only if explicitly configured by the
user on whose behalf the responses are being sent. For example, a
user might direct replies to a secretary or co-worker who has been
delegated to handle important matters during his absence.
- The To field contains the address of the recipient of the
response, as obtained from the Return-Path field of the subject
message.
- The Date field contains the date and time at which the response
was generated.
- The Subject field contains Auto: followed by a string chosen by
the user on whose behalf the responses are being sent. A default
setting of something like "away from my mail" might be
appropriate. If the Subject field contains non-ASCII characters
these are encoded per [N3.RFC2047].
- The In-Reply-To and References fields are generated from the
subject message per [N2.RFC2822].
- The Auto-Submitted field has the value "auto-replied".
- The message body contains some text specified by the user on whose
behalf the response is being sent. A brief summary of the subject
message is also included, consisting of From, To, Subject, Date,
and a few lines of message text from the subject message. No
attachments or non-text bodyparts are included in the response.
The SMTP MAIL FROM address of the message envelope is <>. The RCPT
TO address in the message envelope is the address of the user to whom
the response is being sent. NOTIFY=NEVER is also set in the RCPT TO
line if permitted by the SMTP server.
8. IANA Considerations
Section 5 of this document defines two new extension mechanisms - new
keywords for the Auto-Submitted header field, and new optional
parameters for the Auto-Submitted field. If at any point in the
future new keywords or parameters are approved (through an IETF
Consensus process) it may be appropriate for IANA to create a
registry of such keywords or parameters.
9. Acknowledgments
In the mid-1990s Jeroen Houttuin of TERENA authored a series of
internet-drafts on "Behavior of Mail Based Servers", and in
particular, one document on "Answering Servers". While these
documents were (to this author’s knowledge) never formally published,
they provided the first well-reasoned argument (known to this author)
as to the best way for such servers to interface with email systems
and protocols.
The idea for the Auto-Submitted field comes from the X.400/MHS mail
system [I7.X420]. [I8.RFC2156] defined an "Autosubmitted" field for
use when gatewaying between X.400 and Internet mail. Jacob Palme
wrote an internet-draft defining use of the "Auto-Submitted" field
for Internet mail, which made it through Last Call without
significant objections, but got stalled in an attempt to resolve
non-substantial objections. The definition of Auto-Submitted in this
document is derived (i.e., slightly simplified) from the one in that
document, with some text stolen outright.
Thanks are also due to those who contributed suggestions to this
document: Russ Allbery, Adam Costello, Ned Freed, Lawrence
Greenfield, Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera,
Dan Kohn, Bruce Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg,
Richard Rognlie, Markus Stumpf, Florian Weimer, and Dan Wing.
10. References
10.1. Normative References
[N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[N3.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[N4.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, November 1997.
[N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[N8.RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
10.2. Informative References
[I1.JARGON] "Sorcerer’s apprentice mode", originally from the
Jargon file once maintained at MIT-AI and SAIL; now
collected at various places on the net. See e.g.,
http://www.jargon.net/
[I2.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notifications", RFC 3798, May 2004.
[I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
February 1997.
[I5.RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-
Syntax for Core Mail List Commands and their Transport
through Message Header Fields", RFC 2369, July 1998.
[I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[I7.X420] CCITT Recommendation X.420 (1992 E). Information
technology - Message Handling Systems (MHS):
Interpersonal messaging system, 1992.
[I8.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
Author’s Address
Keith Moore
Innovative Computing Laboratory
University of Tennessee, Knoxville
1122 Volunteer Blvd, #203
Knoxville, TN 37996-3450
EMail: moore@cs.utk.edu
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights