If the sender is a human, and he/she is expecting
an automatically-generated reply,
the responding software cannot know what the originator -- human or
otherwise -- is expecting, except as indicated by the presence or absence
of a Reply-to field.
that's simply not true. if your robot performs a specific function
and expects a specific kind of input, it's reasonable for a robot
that receives well-formed input to assume that the sender is expecting
the robot to perform its particular function. (unfortunately robots
often get spammed these days which is why I said 'well-formed input')
Consider a message
intended for a mailing list where the sender specified the list address in
the reply-to field (which is a perfectly reasonable thing to do) - if a robot
answers the mail on behalf of a list recipient and sends the reply to the
entire list, this will be seen as disruptive.
it is frankly just as bad to have it go to the message originator. not as
bad in scale but as bad in inappropriateness.
no it's not. partially because the return-path should NEVER be a list.
in pretty much all cases of that type of situation, the fact that the
recipient is not explicitly mentioned in the To or CC field means that the
software should not send a reply at all.
true for a "out of the office memo" (though it's not specified anywhere),
but your assertion is not supportable in general.
And if both the sender and recipients are computer programs - i.e. if
this is the use of email within an application - it's probably best for
the sender to never use reply-to (and for the recipient to ignore it).
Reply-to overrides From. There is no reason not to use it.
Reply-to creates ambiguity and the possibility of replies going to different
places. There is no reason for anybody to use it unless the sender wants
to provide the recipient with a *choice* about where to reply. As for
robots, even assuming that robots need to be able to respond to one of
multiple destinations, it's probably better for the robot to define its own
mechanism with semantics appropriate to the applicatoin than to overload
reply-to.
The bottom line is that the specifications leave a lot of wiggle room
regarding use of Reply-To because we really haven't been able to find
a clear set of rules that works for all cases.
They do not leave as much wiggle room as folks often want to believe. The
protocol intent of Reply-To was and is simple and precise.
and naive.
Most of the problems with Reply-to are a) its semantics getting overloaded
by lack of another field for mailing list automata,
there's no need for a separate field for automata, return-path does fine.
and b) a tendency for
folk to forget that we are just talking about a protocol, albeit one that
often has a human as part of the protocol engine.
seems like the incorrect tendency is for certain humans to expect that humans
in general will rigidly follow subtle protocols.
Keith