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.
indeed. provided, of course, you can authenticate it.
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)?
no, not at all. DSNs report on the delivery status of a message,
and are originated by the email system. this is a completely different
thing than a response from the recipient of the subject message that
might even be based on the content of that message. If you get a
failure DSN you should not get any response from the recipient
(or his responder); if you get a success DSN then you might still get
such a response. so I think trying to shoehorn such responses into
DSN format would be a really poor fit.
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.
even that isn't necessarily a DSN if it's issued by the recipient.
(e.g. if I change addresses and leave a vacation program running
at the old address that says "please use this new address instead"
then strictly speaking, that really shouldn't be a DSN)
It's been one of my long-running gripes with the DSN standard that the
from address should be a deliverable e-mail address.
I suppose the alternative is to provide no feedback path in case the
DSN was issued in error? I'm not sure this is better than the current
situation. Personally I don't see many human-originated replies
to DSNs; I do see occasional replies/responses to DSNs from broken
mail robots, and *lots* of bounced DSNs resulting from spam that was
sent to my mail system, forwarded to another address, bounced, and
couldn't be returned to the original return address because it wasn't valid.
I'm tempted to put in code that insists that all mail forwarded
to another system have a return address that appears to be capable
of receiving bounced mail - on seeing a RCPT to a forwarded address,
it will send HELO/MAIL FROM:<>/RCPT TO:<return-path> back to the MX
for the return-path address. If that gives me a 5xx response, then
the response to RCPT on the incoming message will also be 5xx -
invalid return address.
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.)
Precedence is so over-loaded and its use is so varied that I hesitate
to recommend it for anything. Maybe I'll make that a MAY...
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.
I see Reply-to used for that purpose also. But I think it's sheer
insanity to recommend that Reply-To be diluted from its distinct purpose
because some UAs failed to implement another feature of the mail protocol.
Rather than try to make Reply-To be a replacement for From when the
sender wants replies to go back to him or her, at, why not just make From
settable? It's clear from 822 that From is supposed to be settable, how
else could sender specify multiple From addresses, the boss's address, etc...?
And for various reasons, when the alternate From address really does
identify the message author, making From settable is a lot more reliable
than setting reply-to.
Keith