I have a few comments regarding this draft.
While I agree with a lot of the statements regarding mailing
lists and bulk mail, I disagree with the following:
"4. Suggested Practices
Wherever possible, OoO replies SHOULD NOT be used. If they have to be
used, their use should be tightly controlled:
1. OoO replies SHOULD only be used internal to any organization.
Any mailbox available for contact with external parties SHOULD be
a role-based mailbox to which several employees have access.
Outgoing replies SHOULD have a From: header from that role
mailbox, not from the person replying. This serves the purposes
of
* being always available to the external party
* keeping sensitive information in-house.
Role-based mailboxes SHALL NOT generate OoO replies ever."
This is fine for organizations where anyone within a certain group can
handle a particular external request. This does, however, not work in
most circumstances that I have seen. The reason being that often one
person is handling a particular project or customer, and there is too
much context necessary to satisfactorily transfer the handling of that
contact on a very temporary basis, which makes it uneconomical.
This recommendation is too restrictive and doesn't consider such cases
that in my experience are very common. It might be a good idea to explore
typical cases where OoO notifications are being used, and give tailored
recommendations for these cases individually, since I believe there is
no one-size-fits-all.
"2. OoO replies MUST NOT include job information of the addressee."
Again, in the cases described above, you would want to respond in an
official capacity, in which case many companies require to include a
specific company signature containing all sorts of business information,
including the job title and contact information.
It is perfectly OK to include such information when responding to
customer requests or emails from project partners. It is, however,
not desirable in most cases for bulk mail and automated senders,
which are addressed separately in this recommendations.
"4. OoO systems MUST remember which originators were already notified
and MUST NOT resend another OoO reply during a configurable
timeframe. This timeframe SHOULD vary between one week and one
month."
This should be applicable for any unique combination of <From: address,
To: address, OoO incident> (and possibly some other values).
I am specifically referring to the possibility that someone might be OoO
on Monday, and then again from Wednesday to Friday. If the incident was
defined as Monday plus Wednesday to Friday, and the sender was notified
of this whole set, then only one notification is sufficient. If the OoO
period 'Wednesday to Friday' was not known when the OoO notification was
set up for Monday, and thus this information was not conveyed in the
notifications sent out for that Monday incident, then a separate
notification should be sent for the second incident, regardless of the
fact that the sender already got a notification within a week (or month).
/jr