[Top] [All Lists]

Re: Choosing recipient of automatic replies

2002-06-03 11:57:19

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.

  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

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  <>
tel +1.408.246.8253;  fax +1.408.850.1850

<Prev in Thread] Current Thread [Next in Thread>