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-re
sponse-00.txt
Great document, Keith.
I noticed inconsistent terms used to describe the message which
elicited the automatic response -- some places it was "subject
message" or "message resulting in the response". This is somewhat
confusing with all of the messages flying around. It would be
good to pick a term, define it, and use it throughout the doc.
Capitalization, which you used elsewhere to assist in understanding,
would be useful for this term.
The Abstract, which is all that most folks read on the I-D
announcements, should probably include the word 'vacation'.
In 1.1, in the item describing the spam-prevention system which
requires the sender to demonstrate signs of intelligent life,
the wording is complex and could perhaps be reduced to something
like:
Responders designed to filter spam by quarantining a message,
requesting the sender to perform some (supposedly non-
automatable) action, after which the message is removed from
quarantine and relayed to the original recipient.
In 1.1, the description of Group Responders should include an
example of a service address (support(_at_)example(_dot_)com), which you
mentioned in some email threads but isn't described directly
here in the I-D itself. The virus scanner is one example,
but the autoresponder for service addresses is a better (and
more common) example.
I think the order of section 2, 3, and 4 could be improved.
Currently, the order is "what to send", "when to send",
and "where to send". A more natural order seems to be
"when to send", "what to send", and "where to send".
Section 2.1.0 says SHOULD for the entire section, but section
2.1.1 contains a MUST. I'm not sure the interpretation of
this conflict is clear.
The I-D contains the text:
The human-readable portion of the From address (the
phrase before the address) SHOULD contain an indication
of the function performed by the Group Responder and
on whose behalf it operates (e.g. "Example Agency
virus filter")
Instead of "the phrase before the address", you should cite the ABNF
in RFC2822 ("phrase").
Section 2.2 mentions multipart/alternative for multi-language
response, but also says multiple charsets?
Section 2.2 says:
Response messages SHOULD NOT include significant
content from the subject message. In particular
responses SHOULD NOT contain non-text/plain
attachments from the subject message.
This requires further discussion in the I-D. For example,
if the subject message contains only text/html, what's the
autoresponder supposed to do (I would advise not including
any portion of the message).
By the way, I have noticed some autoresponders don't decode
RFC2047-encoded subject lines correctly when they include
the Subject of the "subject message" in the body of the
response. It might be good to point out RFC2047-encoded
Subjects as a case that needs to be properly handled by
autoresponders.
In 2.2.1, the I-D says:
An MDN SHOULD NOT be issued as an automatic
response unless the subject message contains
a Disposition-Notification-To field.
This isn't a new requirement, but rather a repeat of an
existing RFC2298 requirement. Your I-D should say
something like:
As required by [2], an MDN SHOULD NOT ...
Section 3 says:
An automatic responder MUST NOT send a response
for every message received.
This requirement will break all mailing list software
(majordomo, LISTSERV, etc.), as they're supposed to
send a response for every message received. I think
you really want to restrict this MUST to personal
responders, or otherwise soften this MUST if you did
intend it to cover majordomo-/LISTSERV-like responders.
In section 3, the I-D says:
... for the recipient is explicitly included in
the To, CC, or Bcc field of the subject message.
change to:
... for the recipient is explicitly included in
the To, CC, or Bcc field (where present) of the
subject message.
In the same section, the I-D says:
Responders SHOULD NOT generate responses for
any null address.
I know you mean where MAIL FROM is "<>", but the I-D
should be clearer.
Later, it says:
Responders SHOULD check the destination
address for validity before generating the
response, to avoid cluttering up the local
mail queues with messages that cannot be
delivered or are unlikely to be useful.
I don't quite think this responsibility falls directly
on the responder, but rather on the local mail system
to validate RCPT TO addresses for syntactic validity
before accepting the message from an application such
as mail or an autoresponder.
I'm not sure how the autoresponder can decide if
a message is "unlikely to be useful" by examining
the rcpt to address (beyond the examination of
MAILER-DAEMON, owner-*, *-request, etc.).
In section 4, the I-D says:
If the Return-Path field is not present
in the subject message, there is bug
in the SMTP server that delivered the
message, or that SMTP server is
improperly configured.
Note that autoresponders which are implemented in the
transport (as opposed to at the UA layer) won't see
the Return-Path. The text needs to be exapanded in
scope to include transport-based autoresponders which
legitimately won't see Return-Path, but will see the
same thing in another field (perhaps via an internal
datastructure which contains the same text as Return-
Path _would_ contain).
In section 4, where you're describing Reply-To, it's
unclear in the I-D how
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.
could occur. It's obvious to me where the person
accidentally (or on purpose) puts a mailing list name
in the Reply-To, but it may not be obvious to the
readers of the I-D how a "large number of people" could
receive the autoresponders message. As pointed out on
the mailing list, many group responders currently use
Reply-To because in many UAs, From isn't rewritable
(and MAIL FROM is even more unlikely to be rewritable),
and users might have legitimate reasons to specify
a different Reply-To, and users like that group
autoresponders use that specific Reply-To. I know
back in days that BITNET hosts had filestores, I
liked the ability to use Reply-To to direct file
requests to another mailbox for example.
In section 4, the paragraph on From doesn't directly
say SHOULD NOT.
Section 5 defines new protocol elements, and as such
should be a separate standards-track document.
Section 5.2 says:
Such a field MAY be supplied for a manually
sent message that is intended to test the
response of other mail system components to
the presence of an Auto-Submitted field in a
message.
During debugging and testing, there are lots of things that
users, developers, postmasters, and system administrators
will do, some of which purposefully violate MUSTs. I think
you can safely strike the sentence above.
At the end of section 5.2, it says:
The "comment" syntactical construct can be used to
indicate a reason why this message was auto-submitted.
The ABNF from RFC2822 should be cited.
In security considerations, perhaps we should strongly advise
autoresponders to include sufficient information to allow
tracing the source of attacks, such as the headers of the
message which triggered the autoresponse? Perhaps this by
itself is a reason to standardize a multipart for
autoresponders. The inclusion In-Reply-To in the response
is good, but only if in conjunction the autoresponder
retains headers. Or perhaps "retain headers for auditing"
should be a recommendation in the security considerations
section?
Is your I-D intended to be a BCP document?
-d