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?
> 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
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)
> >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)
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)
> > 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)
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)
> 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)
> 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)
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
RSS Feed1 | |
|---|---|
2 | |
7 | |
3 | |
15 | |
21 | |
12 | |
2 | |
1 | |
1 | |
4 | |
27 | |
2 | |
9 | |
2 | |
21 | |
7 | |
1 | |
1 | |
2 | |
8 | |
37 | |
10 | |
154 | |
1 | |
7 | |
4 | |
16 | |
17 | |
129 | |
26 | |
25 | |
16 | |
4 | |
21 | |
25 | |
50 | |
15 | |
3 | |
4 | |
2 | |
3 | |
2 | |
10 | |
4 | |
8 | |
13 | |
1 | |
2 | |
6 | |
6 | |
7 | |
49 | |
74 | |
123 | |
12 | |
99 | |
104 | |
85 | |
122 | |
118 | |
289 | |
329 | |
273 | |
62 | |
1 | |
16 | |
20 | |
13 | |
80 | |
201 | |
33 | |
40 | |
177 | |
56 | |
32 | |
2 | |
36 | |
16 | |
6 | |
61 | |
280 | |
427 | |
58 | |
56 | |
83 | |
26 | |
95 | |
11 | |
176 | |
235 | |
126 | |
69 | |
240 | |
24 | |
23 | |
31 | |
43 | |
48 | |
10 | |
1 | |
25 | |
114 | |
12 | |
3 | |
19 | |
41 | |
16 | |
15 | |
17 | |
8 | |
2 | |
8 | |
14 | |
15 | |
6 | |
137 | |
2 | |
16 | |
11 | |
22 | |
2 | |
11 | |
13 | |
93 | |
88 | |
50 | |
8 | |
29 | |
50 | |
65 | |
81 | |
3 | |
4 | |
4 | |
82 | |
39 | |
6 | |
75 | |
82 | |
12 | |
2 | |
1 | |
3 | |
1 | |
1 | |
3 | |
6 | |
33 | |
14 | |
8 | |
10 | |
2 | |
11 | |
29 | |
6 | |
21 | |
47 | |
14 | |
1 | |
17 | |
55 | |
46 | |
83 | |
36 | |
23 | |
109 | |
138 | |
187 | |
208 | |
210 | |
100 | |
55 | |
45 | |
23 | |
57 | |
2 | |
18 | |
10 | |
34 | |
52 | |
159 | |
112 | |
141 | |
86 | |
16 | |
104 | |
78 | |
126 | |
324 | |
205 | |
165 | |
96 | |
17 | |
16 | |
13 | |
34 | |
55 | |
57 | |
30 | |
94 | |
201 | |
212 | |
103 | |
186 | |
150 | |
384 | |
293 | |
98 | |
88 | |
136 | |
111 | |
209 |
