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.
It should honor the reply-to field. It needs to have a very good reason
not to. That is what an IETF "SHOULD" means.
The reply-to field specifies an email-level protocol behavior for the
generation of user-agent level replies that are not handling-related.
> 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. My
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.
> 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.
Except the empirics of experience.
Out-of-office/vacation notices are but one example. Another would be the
filtering agents that notify you of selective handling by the recipient,
depending upon whether they know you. And so on.
> >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.
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. It is the same construct FTP third-party server
specification and HTTP redirects.
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
anarchy. Protocols specify a discipline. It's not very helpful to
well-behaved open systems operation, if a participant behaves any ol' way
it chooses, because there is no way to predict that behavior, and hence
there will be no interoperability.
> 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.
> 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.
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.850.1850