ned <ned+ietf-822(_at_)mrochek(_dot_)com> writes:
One type of responder that's missing from your first list is the "change
of address" agent that reports that a given recipient address has
changed and senders should update their address lists.
That one's kind of interesting in that there's an opportunity to provide
data in a way that can be acted on automatically.
An interesting wrinkle that comes up in the case of setting the from
address for a service responder is the desire to conduct a sort of
"dialogue" with such an agent. For example, a mailing list maintenance
service may send requests for confirmations that the original sender
then replies to. I don't believe this case changes your general
recommendation that the from address in this case should be one
associated with the service maintainer. However, you may want to mention
this case, and point out the potential for mail loops that exists when
the responder does put its own address in the from field.
A good example here is a mail message sent to confirm a subscription that
includes information about how to unsubscribe (by replying to that
message). This is common for mailing list managers.
Would all cases in which no response to the auto-generated message is
desired or will be read essentially be classified as DSNs (bounce
messages, in essence)? The examples that occur to me are basically bounce
messages, such as an autoreply put on an old address that is no longer in
service, giving new contact information that isn't via e-mail.
It's been one of my long-running gripes with the DSN standard that the
from address should be a deliverable e-mail address. It's a good idea in
theory; in practice, that address gets so much complete junk from people
who didn't read the bounce or have no real understanding of mail at all
that it never gets read and it may as well go to /dev/null. I made the
choice of violating the DSN standard in only that respect with bounces
generated by @stanford.edu, instead sending the mail out from an address
that silently discards all responses, saying that explicitly in the
bounce, and giving alternate contact information in the event of an
emergency in the bounce.
Before I did that, we got tons of mail every day from people just
forwarding the bounce back to its From address, as if that would somehow
magically make their mail go through.
Section 3 (when to send an automatic response) doesn't seem to deal with
the case of a service responder. It isn't entirely clear to me that your
blanket "In practice there are always reasons to refuse to respond to
requests" necessarily applies to service responders.
You may also want to include a note about Precedence: bulk and Precedence:
junk; in practice, they're even better than checks for things like
*-request in avoiding sending mail back in response to mailing list
traffic. (Auto-Submitted doesn't serve quite the same purpose.)
Saying that service responders shouldn't use Reply-To is a definite
departure from current best practice as I understand it for mailing list
management daemons. I don't think that's a good recommendation, and I
also don't agree with your description of what Reply-To is for; that's
not, in practice, what I see it used for. I see it much more frequently
used to work around a mail system that fixes the From header at a
particular value, in which case using Reply-To is the right thing to do.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>