At 09:10 AM 6/3/2002 -0400, Keith Moore wrote:
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
oh. you mean 'expect' the same way that an smtp server, listening on port
25 'expects' smtp protocol conformance and the way a server receiving IP
datagrams with a TCP protocol id 'expects' conformance with TCP.
Yes. When the application-level mail receiving code is participating in a
formal application level protocol, it should 'expect' that the other side
is conforming to that application-level protocol. The response-addressing
rules will be whatever is specified for that application protocol.
Absent such formal, application-level value-added enhancement to the
protocol environment, the question is what should an automaton that is a
participant in the unmodifed RFC 2822 protocol environment.
there's a separate question about whether it's a good idea for such a
formal protocol to allow use of reply-to. IMHO it is generally a bad idea.
It should honor the reply-to field. It needs to have a very good reason
not to. That is what an IETF "SHOULD" means.
having the responses be issued by a robot who is not in a position to
make an intelligent decision about whether to override the reply-to
default is a very good reason for the robot to ignore reply-to.
The reply-to field specifies an email-level protocol behavior for the
generation of user-agent level replies that are not handling-related.
blind faith in the ability of a rigid protocol engine to do the right
thing doesn't solve real problems - especially when experience indicates
that the rigid protocol often does the wrong thing.
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.
I did not say that sending such an automated response to return-path was
good. I said that it was just as bad. the effect is just as bad.
having the response go to the return-path field is safer - has less
potential to cause harm. this is not "just as bad", it's better.
comment was not about protocol formalities, but the real-world impact that
such rogue responses cause to real users, no matter what address they are
sent to. My own belief is that such automata behaviors are the same as spam.
surely there's a difference between this "spam" going to the sender of a
message, who might actually be able to use the information in the response,
and having the "spam" going to other parties who had nothing to do with
the request and have no idea why they're being issued the response?
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
Reply-to causes confusion only for the 2 reasons I cited in my previous
note. The intent and specification of reply-to was and is pretty
clear. And, yes, I know that you are not the only one who thinks otherwise.
the intent may have been clear. it turns out that it doesn't work well.
There is no reason for anybody to use it unless the sender wants
to provide the recipient with a *choice* about where to reply.
The same as a protocol participant has a 'choice' about conforming to the
protocol. Reply-to is not added because the sender wishes to create choice
but wishes to direct a respondent to send to a specific -- and possibly
different -- address.
in the case of a human respondent, it MUST be a choice. the original sender
cannot reasonably expect the respondent to reply only in the way he/she
saw fit. there are too many exceptional cases. now you could insist
that user agents force the respondent to compose a separate message, but
that's a pretty silly impediment for the sake of protocol purity.
humans simply don't follow rigid protocols - at least, not if they want
to work effectively. interpersonal messaging systems need to reflect
that reality and not impose arbitrary constraints on how humans communicate.
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
Having random protocol participants define their own, random behaviors is
no, it's sanity. having each protocol layered on top of mail overload
the semantics of the underlying mail protocol by using reply-to in subtly
different ways is anarchy.
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.
I said *mailing list* automata. Mailing lists are notably different
communication domains than regular, person email and hence the need for a
'followup' header, or some such.
I agree that mailing lists are sometimes different, but in the case you
cite, the mailing list isn't doing the replying. At most it is adding
another hint to the message for the recipient/respondent to sort out.
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.
But it is not so incorrect to expect rigid behavior from automata and other
software that are coded to follow protocol specifications.
no, it's just incorrect to specify those automata in such a way that they
expect or force humans to behave rigidly.