Recommendations for Automatic Responses to Electronic Mail
RFC 3834

AD review comments:

(0) This document is long enough (19 pages) to need a table of contents.

(1) The intended status paragraph that appears after the abstract should
    be marked as needing to be removed prior to publication.

(2) In the definitions of personal and group responders you state that
    these things operate in advance or in lieu of an actual recipient
    response. While typical implementations send such responses on or
    around the time of delivery and hence in advance of any possible
    recipient response, it isn't clear to me that such responses necessarily
    have to occur in advance. And the async nature of email certainly
    means the responses can be recieved later. I therefore suggest changing
    the wording to "in addition to or in lieu of".

    This sort of picayune stuff would be of no importance were it not
    for the tendency of some to put documents like this under a microscope
    and use such wording to claim their broken crap is somehow exempt. While
    I have no problem pushing back on such claims it is somewhat more
    convenient to avoid loopholes whenever possible.

(3) The condition that personal and group responses SHOULD NOT be sent
    unless the recipient's address is explicitly included in a To, Cc, or
    Bcc field fails to take Resent- field variants into account. I think
    it is appropriate for the presence of a recipient address in a
    Resent- field to authorize a reply. The scenario I have in mind here
    is that of someone who resends a critical message rather than handling
    it themselves, but does so to someone who is on vacation. In such a
    case getting a vacation notice is a Good Thing.

(4) You have a "SHOULD NOT generate any response for which the
    destination of that response would be a null address". I think this
    needs to be a MUST NOT -- under what exceptional circumstances would
    a response to a null address possibly be appropriate?

(5) A ">From" crept into the third paragraph of section 4. It should be
    "From", of course. Or perhaps this is an artefact of Internet-Drafts
    processing? If so, the Secretariat should be notified. You might also
    want to consider indenting things a bit to avoid such problems.

(6) The CFWS and CRLF ABNF productions are used but not defined. A sentence
    referring to 2822 is probably in order.

(7) The mandatory copyright and IPR boilerplate isn't present in this
    document and needs to be added.

(8) The RFC Editor has recently indicated that references of the form
    [RFCnnnn] are preferred over [n] and, I suspect, [Nn]/[In]. I don't
    know if this rises to the level of a required change, but I thought I'd
    mention it.

(9) The auto-submitted IPM extension was added in the 1992 CCITT version of
    the X.420 specifications (There are both ISO/IEC and CCITT (now ITU-T)
    versons of X.400 and there are some differences between the two.) The
    correct citation would be something like:

    CCITT Recommendation X.420 (1992 E): Information technology -
    Message Handling Systems (MHS): Interpersonal messaging system,
    1992.