Florian Weimer | 2 Jun 22:34 2002
Picon

Choosing recipient of automatic replies


Suppose a mail-based service needs to send an automatic reply to an
incoming mail message.  Mail is received sent over a protocol which
contains an envelope sender (such as SMTP).

Should the service use the envelope or the header address to choose
the recipient for the automatic reply?

Keith Moore | 2 Jun 23:21 2002
Picon

Re: Choosing recipient of automatic replies


> Suppose a mail-based service needs to send an automatic reply to an
> incoming mail message.  Mail is received sent over a protocol which
> contains an envelope sender (such as SMTP).
> 
> Should the service use the envelope or the header address to choose
> the recipient for the automatic reply?

it's a bit of an open-ended question, but in general I recommend 
that automatic responses use the envelope return address (or 
return-path header address which should be the same).  that way, 
all responses get sent to the same place, regardless of whether 
they are normal replies, nondelivery reports, delivery reports, 
or whatever. 

Keith

Dave Crocker | 3 Jun 05:52 2002

Re: Choosing recipient of automatic replies


At 10:34 PM 6/2/2002 +0200, Florian Weimer wrote:
>Suppose a mail-based service needs to send an automatic reply to an
>incoming mail message.  Mail is received sent over a protocol which
>contains an envelope sender (such as SMTP).
>
>Should the service use the envelope or the header address to choose
>the recipient for the automatic reply?

The important distinction is between a reply by the transport service, 
about transmission, versus a reply by an email-based application, about an 
activity of the application.

If the reply is about email transport, then the envelope address should be 
used, per RFC 2821.  If the reply is about the application-level service 
that is simply using email as an underlying service, then the reply should 
use the rules in RFC 2822:

>3.6.2. Originator fields
...
>The originator fields also provide the information required when replying 
>to a message. When the "Reply-To:" field is present, it indicates the 
>mailbox(es) to which the author of the message suggests that replies be 
>sent. In the absence of the "Reply-To:" field, replies SHOULD by default 
>be sent to the mailbox(es) specified in the "From:" field unless otherwise 
>specified by the person composing the reply.

and

>3.6.3. Destination address fields
(Continue reading)

Keith Moore | 3 Jun 07:52 2002
Picon

Re: Choosing recipient of automatic replies


> >Should the service use the envelope or the header address to choose
> >the recipient for the automatic reply?
> 
> The important distinction is between a reply by the transport service,
> about transmission, versus a reply by an email-based application, about an
> activity of the application.

Certainly a reply by the mail transport service should always go to the
return-path / MAIL FROM address - that much, at least, is not controversial.

However it's not at all clear that a reply that is not from the transport
service should go to the reply-to address(es) even if the field is present.
For example, automatically generated message disposition notifications aren't 
generated by the mail transport system - they're generated by the recipient's 
user agent - but they are still supposed to go to the return-path address.  

   from RFC 2298:

   MDNs SHOULD NOT be sent automatically if the address in the
   Disposition-Notification-To header differs from the address in the
   Return-Path header (see RFC 822 [2]).  

As to whether Reply-to should be used for other kinds of automatic replies,
the answer can be subtle.  If the sender is a human, and he/she is expecting
an automatically-generated reply, then it might be reasonable to assume
that if the human set a reply-to field then he/she intended the reply to
go to that address rather than the From address.  On the other hand, if the
sender is not expecting an automatically generated reply, but is expecting
a reply from a human (as in a "out of the office" response) then sending 
(Continue reading)

Dave Crocker | 3 Jun 14:38 2002

Re: Choosing recipient of automatic replies


At 01:52 AM 6/3/2002 -0400, Keith Moore wrote:
>For example, automatically generated message disposition notifications aren't
>generated by the mail transport system - they're generated by the recipient's

right.  meant to cover all "transport-related" communications.

my main intent was to distinguish application-level replies from 
"handling-related" replies.

>   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.

>On the other hand, if the
>sender is not expecting an automatically generated reply, but is expecting
>a reply from a human (as in a "out of the office" response) then sending
>to the return-path address usually makes more sense.

no.

>    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.

(Continue reading)

Keith Moore | 3 Jun 15:10 2002
Picon

Re: Choosing recipient of automatic replies


> >   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),
(Continue reading)

Barry Leiba | 3 Jun 15:55 2002
Picon

Re: Choosing recipient of automatic replies


The fact that mailing lists are a difficult problem is a matter of bad
choices throughout the history of e-mail.  In the beginning, one couldn't
guess, but once it became clear, we should have put mailing-list-specific
fields in to solve the problem.  We didn't.  A pity.

But let's look at how this stuff might be used (and *is* used, in some
non-standard systems, at least) in a business environment.  Here's a
common situation: an admin assistant sends a note on behalf of a principal,
submitting the message from a shared group ID.  The message asks for some
response to be sent to the principal's tech assistant.  Something like this:

> Return-Path: <Group-ID <at> company.com>
> Sender: <Joe-Admin-Asst <at> company.com>
> From: <Susan-Manager <at> company.com>
> Reply-To: <Nancy-Tech-Asst <at> company.com>
> To: ...
> Subject: Information needed
> 
> All,
> I urgently need any information you have about the Banana project.  Please
> collect that you have and send it to Nancy ASAP.  Thanks.
> 
> Susan Goombah
> Manager, Fruit Projects
> company.com, Inc.

Now, the decision about where to send various types of replies can be a
complicated one, and very much depends upon the semantics.  Very rarely
sure *any* reply to this go to Susan.  It's her signature on the message,
(Continue reading)

Keith Moore | 3 Jun 18:43 2002
Picon

Re: Choosing recipient of automatic replies


> The fact that mailing lists are a difficult problem is a matter of bad
> choices throughout the history of e-mail.  In the beginning, one couldn't
> guess, but once it became clear, we should have put mailing-list-specific
> fields in to solve the problem.  We didn't.  A pity.

well, we did put them in eventually.  it just took awhile.
even now I'm not sure that list-specific fields solve those problems,
but I do like list-specific fields better than having lists rewrite 
originator-supplied fields.

> The problem is that all of this isn't clear, and that some of it
> depends upon a human thinking about what the reply is and to whom it
> should really be sent.  And many/most humans can't be bothered, with
> the result that replies often wind up going to *everyone* the MUA will
> allow them to be sent to.

interesting that in the days of paper memos, people could be bothered 
to think about such things.  

part of the problem is probably (as you said) that the subtle 
differences between return-path, from, reply-to, and sender 
aren't clear to most email users - and there is a lot of 
misunderstanding out there.   (and if the protocol developers can't
agree on when to use each field, how can we expect users supposed to 
behave uniformly?)  still, if the protocol folks can come to agreement
there is some potential that improved user interfaces might help 
this problem.

another part of the problem is probably that email has made it so 
(Continue reading)

Barry Leiba | 3 Jun 19:28 2002
Picon

Re: Choosing recipient of automatic replies


> another part of the problem is probably that email has made it so
> easy to send messages that we now have to deal with too many messages
> - which is a clue as to why people "can't be bothered" to think about
> where to send replies anymore.  offhand, I don't see how to fix this

Yes, exactly.  A couple of years ago, we did an IBM Academy study on 
e-mail, and as part of it we talked with some executive secretaries. 
One question we asked was, "What's the biggest problem you have, or 
your principal has, with e-mail?", and the answer was "It's abused." 
When we pressed for explanations, we found that the complaint was 
twofold:

1. Because it's so easy to send it, people send it... and the principal 
is *flooded* with things that s/he never had to deal with before. 
People used to say to themselves, "The VP is too important for us to 
bother with this," when "bothering" meant calling on the telephone or 
sending a paper memo.  Now they say, "We'd better send this to the VP, 
just to cover all the bases."

2. One thing many of us like about e-mail is that it's asynchronous. 
One thing that executives (or, at least, their secretaries) hate about 
it is that it's asynchronous.  In the old days, if you called the exec, 
and the exec was on the phone, well... you had to try again later.  Or 
you had to talk with Cerberus (uh, the secretary).  Either way, it was 
self-limiting.  Now... you send e-mail and go on your way.  So the busy 
exec has that much more to deal with.

The result of the combination of these things is that most exec sec'ies 
sort their principals' mail, a sort of triage, and the exec never 
(Continue reading)

Lawrence Greenfield | 3 Jun 19:58 2002
Picon

Re: Choosing recipient of automatic replies


   Date: Mon, 03 Jun 2002 07:38:43 -0500
   From: Dave Crocker <dcrocker <at> brandenburg.com>
[...]
   >On the other hand, if the
   >sender is not expecting an automatically generated reply, but is expecting
   >a reply from a human (as in a "out of the office" response) then sending
   >to the return-path address usually makes more sense.

   no.

The Sieve vacation draft (now expired) explicitly mandates that the
vacation response messages be sent to the envelope from address
("Return-path").  In practice, we haven't had any complaints about
this behavior.

We do receive complaints about the check for the recipient's address
in the To/Cc header lines.

Larry


Gmane