Very nice job, Keith.
In section 1, after ""sorcerer's apprentice" syndrome" I would add these
sentences:
(sorcerer's apprentice mode: n. [from Goethe's "Der Zauberlehrling" via
Paul Dukas's "L'apprenti sorcier" the film "Fantasia"] 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.)
And provide a non-normative reference to
<http://www.jargon.net/jargonfile/s/sorcerersapprenticemode.html>
In section 2.1.4, you have:
NOTE: Just as the prefix "Re:" (presumably an abbreviation of the
English word "reply") is sometimes translated to other languages by mail
readers, or otherwise interpreted by mail readers as indication that the
message is a reply, so the prefix "Auto-Re:" may also be translated or
used as a generic indication that the message is an automatic response.
However the "Auto-Re:" indication is intended only as an aid to humans
in processing the message. The validity of "Auto-Re:" SHOULD NOT be
assumed by mail processing software.
I would instead recommend:
NOTE: The string "Re: " (from the Latin "res", in the matter of) in the
Subject is often translated by mail readers to the user's native
languages before display. It is important to note that the phrases "Re:
" and "Auto-Re: " are both protocol elements, and so SHOULD always be
sent on the wire in their native English form, not as a translation. If
this were not the case, n languages would require n*(n-1) equivalence
mappings, with (n-1) mappings on each MUA. By treating the prefixes as
protocol elements, only n equivalence mappings are needed, and each MUA
need only be able to translate from the English phrases to that user's
language.
I don't really see what you're getting at in the final sentence of your
original text, since every aspect of RFC 2822 mail is so eminently
forgeable.
In section 5, I think you need to specify that any use of an extension
token should be interpreted as the message being automatically
generated, and so an automatic response MUST NOT be sent to it. I.e.,
if the Auto-Submitted: field is present AND it does not contain "no",
then the message was automatically generated.
Section 3 then changes from:
- Automatic responses SHOULD NOT be issued in response to any message
which contains an Auto-Submitted header field with a value of
"auto-replied" or "auto-generated".
To:
- Automatic responses SHOULD NOT be issued in response to any message
which contains an Auto-Submitted header field and in which that
field
has any value other than "no".
In Section 7, s/paramters/parameters
- dan
--
Dan Kohn <mailto:dan(_at_)dankohn(_dot_)com>
<http://www.dankohn.com/> <tel:+1-650-327-2600>
Essays announced on <mailto:dankohn-subscribe(_at_)yahoogroups(_dot_)com>
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Wednesday, June 05, 2002 17:04
To: ietf-822(_at_)imc(_dot_)org
Cc: moore(_at_)cs(_dot_)utk(_dot_)edu
Subject: I-D Recommendations for Automatic Responses to Electronic Mail
I have just sent the document to internet-drafts. It should be in the
repositories in a day or two. In the meantime, you can download it from
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.txt
or in alternate versions for the ASCII-impaired:
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.ps
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.pdf
Keith