< draft-moore-auto-email-response-04.txt   draft-moore-auto-email-response-05.txt >
Internet-Draft K. Moore Internet-Draft K. Moore
Expires: 1 April 2004 University of Tennessee Expires: 29 July 2004 University of Tennessee
1 October 2003 29 January 2004
Recommendations for Automatic Responses to Electronic Mail Recommendations for Automatic Responses to Electronic Mail
draft-moore-auto-email-response-04 draft-moore-auto-email-response-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions of This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026. Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is not currently associated with any working group. This document is not associated with any working group. Comments on
Comments on this internet-draft should be sent to the mailing list this document should be sent to the mailing list <ietf-822@imc.org>, or
<ietf-822@imc.org>, or to the author. Such comments should cite the to the author. Such comments should cite the Internet-Draft identifier
Internet-Draft identifier draft-moore-auto-email-response-04 so others draft-moore-auto-email-response-05 so others can be sure you are
can be sure you are commenting on the same version they read. commenting on the same version they read.
Abstract Abstract
This memo makes recommendations for software that automatically responds This memo makes recommendations for software that automatically responds
to incoming electronic mail messages, including "out of the office" or to incoming electronic mail messages, including "out of the office" or
"vacation" response generators, mail filtering software, email-based "vacation" response generators, mail filtering software, email-based
information services, and other automatic responders. The purpose of information services, and other automatic responders. The purpose of
these recommendations is to discourage undesirable behavior which is these recommendations is to discourage undesirable behavior which is
caused or aggravated by such software, to encourage uniform behavior caused or aggravated by such software, to encourage uniform behavior
(where appropriate) among automatic mail responders, and to clear up (where appropriate) among automatic mail responders, and to clear up
skipping to change at page 2, line 29 skipping to change at page 2, line 29
inappropriate addresses, and occasional incidences of mail loops or inappropriate addresses, and occasional incidences of mail loops or
"sorcerer's apprentice" mode. This memo recommends behavior for "sorcerer's apprentice" mode. This memo recommends behavior for
programs that automatically respond to electronic mail in order to programs that automatically respond to electronic mail in order to
reduce the number of problems caused by such programs. reduce the number of problems caused by such programs.
(Note: the term "sorcerer's apprentice mode" is defined as a bug in a (Note: the term "sorcerer's apprentice mode" is defined as a bug in a
protocol where, under some circumstances, the receipt of a message protocol where, under some circumstances, the receipt of a message
causes multiple messages to be sent, each of which, when received, causes multiple messages to be sent, each of which, when received,
triggers the same bug.) (From [I1.JARGON]) 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 electornic 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 1.1 Types of automatic responses
There are several different types of automatic responses. At least two There are several different types of automatic responses. At least two
types of automatic responses have been defined in IETF standards - types of automatic responses have been defined in IETF standards -
Delivery Status Notifications [I2.RFC3464] which are intended to report Delivery Status Notifications [I2.RFC3464] which are intended to report
the status of a message delivery by the message transport system, and the status of a message delivery by the message transport system, and
Message Disposition Notifications [I3.RFC2298] which are intended to Message Disposition Notifications [I3.RFC2298] which are intended to
report of the disposition of a message after it reaches a recipient's report of the disposition of a message after it reaches a recipient's
mailbox. These responses are defined elsewhere and are generally not mailbox. These responses are defined elsewhere and are generally not
within the purview of this document, except that this document within the purview of this document, except that this document
skipping to change at page 3, line 34 skipping to change at page 3, line 39
Recognizing the wide variety of response types in use, these Recognizing the wide variety of response types in use, these
recommendations distinguish between several classes of automatic recommendations distinguish between several classes of automatic
responders according to the party or service on whose behalf the responders according to the party or service on whose behalf the
responder acts: responder acts:
- "Service Responders" exist to provide access to some service via - "Service Responders" exist to provide access to some service via
email requests and responses. These are permanently associated email requests and responses. These are permanently associated
with one or more email addresses, and when sending to such an with one or more email addresses, and when sending to such an
address the sender presumably expects an automatic response. An address the sender presumably expects an automatic response. An
email-based file retrieval service is an example of a Service email-based file retrieval service is an example of a Service
Responder. A calendar service that allowed appointment requests to Responder. A calendar service that allows appointment requests to
be made via email, and which responded to such requests, would be be made via email, and which responds to such requests, would be
another example of a Service Responder. another example of a Service Responder.
- "Personal Responders" exist to make automatic responses on behalf - "Personal Responders" exist to make automatic responses on behalf
of a single recipient address, in addition to, or in lieu of, that of a single recipient address, in addition to, or in lieu of, that
recipient reading the message. These responders operate according recipient reading the message. These responders operate according
to criteria specified on a per-recipient basis. The UNIX to criteria specified on a per-recipient basis. The UNIX
"vacation" program is an example of a Personal Responder. A "vacation" program is an example of a Personal Responder. A
responder that accepts mail sent to a single address, attempts to responder that accepts mail sent to a single address, attempts to
analyze and classify the contents, and then issues a response which analyze and classify the contents, and then issues a response which
is dependent on that classification, is also a Personal Responder. is dependent on that classification, is also a Personal Responder.
skipping to change at page 4, line 42 skipping to change at page 4, line 49
Unless specified otherwise, the term "recipient" refers to the email Unless specified otherwise, the term "recipient" refers to the email
addresses to which a subject message was delivered (rather than, for addresses to which a subject message was delivered (rather than, for
instance, the address to which the response was sent). A "recipient" instance, the address to which the response was sent). A "recipient"
address might be permanently associated with a responder, or it might be address might be permanently associated with a responder, or it might be
the address of a human being whose mail is, under some conditions, the address of a human being whose mail is, under some conditions,
answered by a responder. answered by a responder.
2. When (not) to send automatic responses 2. When (not) to send automatic responses
An automatic responder MUST NOT send a response for every message An automatic responder MUST NOT blindly send a response for every
received. In practice there are always reasons to refuse to respond to message received. In practice there are always reasons to refuse to
some kinds of received messages, e.g. for loop prevention, to avoid respond to some kinds of received messages, e.g. for loop prevention, to
responding to "spam", to avoid being used as a means to launder or avoid responding to "spam" or viruses, to avoid being used as a means to
amplify abusive messages, to avoid inappropriately revealing personal launder or amplify abusive messages, to avoid inappropriately revealing
information about the recipient (e.g. to avoid an automatic indication personal information about the recipient (e.g. to avoid an automatic
that a recipient has not read his mail recently), and to thwart denial- indication that a recipient has not read his mail recently), and to
of-service attacks against the responder. The criteria for deciding thwart denial-of-service attacks against the responder. The criteria
whether to respond will differ from one responder to another, according for deciding whether to respond will differ from one responder to
to the responder's purpose. In general, care should be taken to avoid another, according to the responder's purpose. In general, care should
sending useless or redundant responses, and to avoid contributing to be taken to avoid sending useless or redundant responses, and to avoid
mail loops or facilitating denial-of-service attacks. contributing to mail loops or facilitating denial-of-service attacks.
Here are some broad guidelines: Here are some broad guidelines:
- Automatic responses SHOULD NOT be issued in response to any message - Automatic responses SHOULD NOT be issued in response to any message
which contains an Auto-Submitted header field (see below), where which contains an Auto-Submitted header field (see below), where
that field has any value other than "no". that field has any value other than "no".
- Personal and Group responses that are intended to notify the sender - 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 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) message (e.g. "away from my mail" or "too busy" notifications)
skipping to change at page 7, line 47 skipping to change at page 8, line 6
The following behavior is thus recommended: The following behavior is thus recommended:
- For responses sent by Service Responders, the From field SHOULD - For responses sent by Service Responders, the From field SHOULD
contain an address which can be used to reach the (human) contain an address which can be used to reach the (human)
maintainer of that service. The human-readable portion of the From maintainer of that service. The human-readable portion of the From
field (the display-name preceding the address) SHOULD contain a field (the display-name preceding the address) SHOULD contain a
name or description of the service to identify the service to name or description of the service to identify the service to
humans. humans.
- For responses sent by Personal Responders, the From field SHOULD - For responses sent by Personal Responders, the From field SHOULD
contain the name of the recipient and an address chosen by the contain the name of the recipient of the subject message (i.e. the
recipient to be recognizable to correspondents. Often this will be user on whose behalf the response is being sent) and an address
the same address that was used to send the subject message to that chosen by the recipient of the subject message to be recognizable
recipient. 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 In the case of a recipient having multiple mail addresses forwarded
to the same mailbox (and responder), a Personal Responder MAY use to the same mailbox (and responder), a Personal Responder MAY use
heuristics to guess, based on the information available in various heuristics to guess, based on the information available in various
message header fields, which of several addresses for that message header fields, which of several addresses for that
recipient the sender is likely to have used, and use that address 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 in the From field of the response. However it MUST be possible for
a recipient on whose behalf the responder is acting to explicitly a recipient on whose behalf the responder is acting to explicitly
specify the human-readable name and address to be used in the From specify the human-readable name and address to be used in the From
header fields of responses. header fields of responses.
skipping to change at page 12, line 23 skipping to change at page 12, line 28
4. Where to send automatic responses (and where not to send them) 4. Where to send automatic responses (and where not to send them)
In general, automatic responses SHOULD be sent to the Return-Path field In general, automatic responses SHOULD be sent to the Return-Path field
if generated after delivery. If the response is generated prior to if generated after delivery. If the response is generated prior to
delivery, the response SHOULD be sent to the reverse-path from the SMTP 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 MAIL FROM command, or (in a non-SMTP system) to the envelope return
address which serves as the destination for nondelivery reports. address which serves as the destination for nondelivery reports.
If the response is to be generated after delivery, and there is no If the response is to be generated after delivery, and there is no
Return-Path field in the subject message, there is an implementation Return-Path field in the subject message, there is an implementation or
error in the SMTP server that delivered the message, or that SMTP server configuration error in the SMTP server that delivered the message or
is improperly configured. A Personal or Group responder SHOULD NOT gatewayed the message outside of SMTP. A Personal or Group responder
deliver a response to any address other than that in the Return-Path SHOULD NOT deliver a response to any address other than that in the
field, even if the Return-Path field is missing. It is better to fix Return-Path field, even if the Return-Path field is missing. It is
the problem with the mail delivery system than to rely on heuristics to better to fix the problem with the mail delivery system than to rely on
guess the appropriate destination of the response. Such heuristics have heuristics to guess the appropriate destination of the response. Such
been known to cause problems in the past. heuristics have been known to cause problems in the past.
A Service Responder MAY deliver the response to the address(es) from the A Service Responder MAY deliver the response to the address(es) from the
>From field, or to another address from the request payload, provided >From field, or to another address from the request payload, provided
this behavior is precisely defined in the specification for that this behavior is precisely defined in the specification for that
service. Services responders SHOULD NOT use the Reply-To field for this service. Services responders SHOULD NOT use the Reply-To field for this
purpose. purpose.
The Reply-To field SHOULD NOT be used as the destination for automatic The Reply-To field SHOULD NOT be used as the destination for automatic
responses from Personal or Group Responders. In general, this field is responses from Personal or Group Responders. In general, this field is
set by a human sender based on his/her anticipation of how human set by a human sender based on his/her anticipation of how human
skipping to change at page 14, line 28 skipping to change at page 14, line 40
The auto-generated keyword: The auto-generated keyword:
- SHOULD be used on messages generated by automatic (often periodic) - SHOULD be used on messages generated by automatic (often periodic)
processes (such as UNIX "cron jobs") which are not direct responses processes (such as UNIX "cron jobs") which are not direct responses
to other messages, to other messages,
- MUST NOT be used on manually generated messages, - MUST NOT be used on manually generated messages,
- MUST NOT be used on a message issued in direct response to another - MUST NOT be used on a message issued in direct response to another
message. message,
- MUST NOT be used to label Delivery Status Notifications (DSNs)
[I2.RFC3464], or Message Disposition Notifications (MDNs)
[I3.RFC2298], or other reports of message (non)receipt or
(non)delivery. Note: Some widely-deployed SMTP implementations
currently use "auto-generated" to label nondelivery reports. These
should be changed to use "auto-replied" instead.
The auto-replied keyword: The auto-replied keyword:
- SHOULD be used on messages sent in direct response to another - SHOULD be used on messages sent in direct response to another
message, message by an automatic process,
- MUST NOT be used on manually-generated messages, - 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 - MUST NOT be used on messages generated by automatic or periodic
processes, except for messages which are automatic responses to processes, except for messages which are automatic responses to
other messages. other messages.
The "no" keyword MAY be used to explicitly indicate that a message was 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 originated by a human, if for some reason this is found to be
appropriate. appropriate.
Extension keywords may be defined in the future, though it seems Extension keywords may be defined in the future, though it seems
unlikely. The syntax and semantics of such keywords must be published unlikely. The syntax and semantics of such keywords must be published
skipping to change at page 17, line 5 skipping to change at page 17, line 27
happen automatically (as when a Group Responder automatically supplies a happen automatically (as when a Group Responder automatically supplies a
recipient's personal or mobile telephone number as alternate contact recipient's personal or mobile telephone number as alternate contact
information) or "manually". Automatically-generated information SHOULD information) or "manually". Automatically-generated information SHOULD
NOT include personal information about the recipient which is not NOT include personal information about the recipient which is not
already known to, or easily available to, the sender of the subject already known to, or easily available to, the sender of the subject
message. User interfaces which allow recipients to supply response text message. User interfaces which allow recipients to supply response text
SHOULD make it clear to the user that this information will be made 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, available not only to local colleagues but also to the entire Internet,
including potential attackers. including potential attackers.
7. IANA Considerations 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 nondelivery 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 Section 5 of this document defines two new extension mechanisms - new
keywords for the Auto-Submitted header field, and new optional keywords for the Auto-Submitted header field, and new optional
parameters for the Auto-Submitted field. If at any point in the future parameters for the Auto-Submitted field. If at any point in the future
new keywords or parameters are approved (through an IETF Consensus new keywords or parameters are approved (through an IETF Consensus
process) it may be appropriate for IANA to create a registry of such process) it may be appropriate for IANA to create a registry of such
keywords or parameters. keywords or parameters.
8. Acknowledgments 9. Acknowledgments
In the mid-1990s Jeroen Houttuin of TERENA authored a series of In the mid-1990s Jeroen Houttuin of TERENA authored a series of
internet-drafts on "Behavior of Mail Based Servers", and in particular, internet-drafts on "Behavior of Mail Based Servers", and in particular,
one document on "Answering Servers" [I7.BOMBS]. While these documents one document on "Answering Servers" [I7.BOMBS]. While these documents
were (to this author's knowledge) never formally published, they were (to this author's knowledge) never formally published, they
provided the first well-reasoned argument (known to this author) as to provided the first well-reasoned argument (known to this author) as to
the best way for such servers to interface with email systems and the best way for such servers to interface with email systems and
protocols. protocols.
The idea for the Auto-Submitted field comes from the X.400/MHS mail The idea for the Auto-Submitted field comes from the X.400/MHS mail
skipping to change at page 17, line 36 skipping to change at page 19, line 36
when gatewaying between X.400 and Internet mail. Jacob Palme wrote an when gatewaying between X.400 and Internet mail. Jacob Palme wrote an
internet-draft [I10.AUTOSUB] defining use of the "Auto-Submitted" field internet-draft [I10.AUTOSUB] defining use of the "Auto-Submitted" field
for Internet mail, which made it through Last Call without significant for Internet mail, which made it through Last Call without significant
objections, but got stalled in an attempt to resolve non-substantial objections, but got stalled in an attempt to resolve non-substantial
objections. The definition of Auto-Submitted in this document is objections. The definition of Auto-Submitted in this document is
derived (i.e. slightly simplified) from the one in that document, with derived (i.e. slightly simplified) from the one in that document, with
some text stolen outright. some text stolen outright.
Thanks are also due to those who contributed suggestions to this Thanks are also due to those who contributed suggestions to this
document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield, document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield,
Arnt Gulbrandsen, Eric Hall, Tony Hansen, Dan Kohn, Bruce Lilly, der Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera, Dan Kohn, Bruce
Mouse, Lyndon Nerenberg, Florian Weimer, and Dan Wing. Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg, Richard Rognlie,
Markus Stumpf, Florian Weimer, and Dan Wing.
9. Author's Address 10. Author's Address
Keith Moore Keith Moore
Innovative Computing Laboratory Innovative Computing Laboratory
University of Tennessee, Knoxville University of Tennessee, Knoxville
1122 Volunteer Blvd, #203 1122 Volunteer Blvd, #203
Knoxville, TN 37996-3450 Knoxville, TN 37996-3450
moore@cs.utk.edu moore@cs.utk.edu
10. Normative References 11. Normative References
[N1.RFC2119] [N1.RFC2119]
Bradner, S. Key words for use in RFCs to Indicate Requirement Bradner, S. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[N2.RFC2822] [N2.RFC2822]
Resnick, P. (ed.) Internet Message Format. RFC 2822, April 2001. Resnick, P. (ed.) Internet Message Format. RFC 2822, April 2001.
[N3.RFC2047] [N3.RFC2047]
Moore, K. MIME (Multipurpose Internet Mail Extensions) Part Moore, K. MIME (Multipurpose Internet Mail Extensions) Part
skipping to change at page 18, line 40 skipping to change at page 20, line 40
[N7.RFC2045] [N7.RFC2045]
Freed, N. Borenstein, N. Multipurpose Internet Mail Extensions Freed, N. Borenstein, N. Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies. RFC 2045, (MIME) Part One: Format of Internet Message Bodies. RFC 2045,
November 1996. November 1996.
[N8.RFC2434] [N8.RFC2434]
Narten, T., Alvestrand, H. Guidelines for Writing an IANA Narten, T., Alvestrand, H. Guidelines for Writing an IANA
Considerations Section in RFCs. RFC 2434, October 1998. Considerations Section in RFCs. RFC 2434, October 1998.
11. Informative References 12. Informative References
[I1.JARGON] [I1.JARGON]
"Sorcerer's apprentice mode", originally from the Jargon file "Sorcerer's apprentice mode", originally from the Jargon file
once maintained at MIT-AI and SAIL; now collected at various once maintained at MIT-AI and SAIL; now collected at various
places on the net. See e.g. http://www.jargon.net/ places on the net. See e.g. http://www.jargon.net/
[I2.RFC3464] [I2.RFC3464]
Moore, K. Vaudreuil, G. An Extensible Message Format for Moore, K. Vaudreuil, G. An Extensible Message Format for
Delivery Status Notifications. RFC 3464, January 2003. Delivery Status Notifications. RFC 3464, January 2003.
skipping to change at page 19, line 42 skipping to change at page 21, line 42
[I9.RFC2156] [I9.RFC2156]
Kille, S. MIXER (Mime Internet X.400 Enhanced Relay): Mapping Kille, S. MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME. RFC 2156, January 1998. between X.400 and RFC 822/MIME. RFC 2156, January 1998.
[I10.AUTOSUB] [I10.AUTOSUB]
Palme, J. "The Auto-Submitted and Expires Headers in E-mail". Palme, J. "The Auto-Submitted and Expires Headers in E-mail".
Expired Internet-Draft "draft-ietf-mailext-new-fields-15.txt", Expired Internet-Draft "draft-ietf-mailext-new-fields-15.txt",
February 1999. (reference included only for attribution) February 1999. (reference included only for attribution)
12. Copyright Notice 13. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
skipping to change at page 20, line 20 skipping to change at page 22, line 20
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
13. Changes since version -03 (not intended for inclusion in the RFC) 14. Changes since version -04 (not intended for inclusion in the RFC)
- format of references changed. see note to RFC Editor below
- status paragraph following abstract marked as not being intended
for publication as an RFC
- section 1.1 - personal group responders now operate "in addition
to, or in lieu of" a recipient response. (was "in advance of, or in
lieu of")
- section 2 - it's now okay to send personal or group responses to a
recipient named in a resent-{to,cc,bcc} field.
- section 2 - responder now MUST NOT send a response to a null - Stated that this document is limited in scope to email messages,
address (was SHOULD NOT) not instant messaging, SMS, Usenet, etc.
- section 5.1 - missing definitions of CFWS and CRLF productions - Added text regarding applicability of Auto-Submitted to DSNs and
referenced from RFC 2822. MDNs.
- copyright notice added, even though author thinks the first - Added section illustrating applicability to a hypothetical
sentence after "status of this memo" should be sufficient for an I- "vacation" program.
D.
- reference to X.420 supplied (thanks Ned) - Other minor wording changes and grammar fixes.
14. Notes to RFC Editor (not intended for inclusion in the RFC) 15. Notes to RFC Editor (not intended for inclusion in the RFC)
- The format used for references in this document is a compromise - The format used for references in this document is a compromise
between the desire to (a) have informative and normative references between the desire to (a) have informative and normative references
in separate sections (b) have reference tags be meaningful to those in separate sections (b) have reference tags be meaningful to those
who know the documents (e.g. RFC822), and (c) have references who know the documents (e.g. RFC822), and (c) have references
appear in the order they were referenced. Unfortunately, the appear in the order they were referenced. Unfortunately, the
result is ugly. Feel free to change the format of reference tags result is ugly. Feel free to change the format of reference tags
as you see fit. as you see fit.
- If you see the text ">From" appearing at the beginning of a line in - If you see the text ">From" appearing at the beginning of a line in
the document; this is due to a glitch in somebody's mail system. the document; this is due to a glitch in somebody's mail system.
Please change it to "From". Thanks. Please change it to "From". Thanks.
- The internet-draft of this document has been produced in PostScript - The internet-draft of this document has been produced in PostScript
and PDF versions in addition to the plain text version. This was and PDF versions in addition to the plain text version. This was
done as an experiment. The author does not claim that these done as an experiment. The author does not claim that these
versions offer any improvement in readability over the plain text versions offer any improvement in readability over the plain text
version. In fact the author believes that (due to the formatting version. In fact the author believes that (due to the formatting
conventions used, paper size, etc) the text version is more conventions used, paper size, etc) the text version is more
readable than the alternatives. readable than the alternatives.
- To reduce the potential for transcription errors, nroff source code
for this document is available at
http://www.cs.utk.edu/~moore/nroff/draft-moore-auto-email-response-05.ms
 End of changes. 26 change blocks. 
66 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/