Discussion of RFC 2822 ()

Dave Crocker | 3 Jun 2002 05:52

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)

headers

Florian Weimer | 4 Jun 2002 22:18

Re: Choosing recipient of automatic replies

Dave Crocker <dcrocker <at> brandenburg.com> writes:

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

What about a mailing list?  The application itself is a transport.

headers

Dave Crocker | 3 Jun 2002 14:38

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)

headers

Charles Lindsey | 4 Jun 2002 20:34

Re: Choosing recipient of automatic replies


In <5.1.0.14.2.20020603072431.03368b80 <at> jay.songbird.com> Dave Crocker
<dcrocker <at> brandenburg.com> writes:

>At 01:52 AM 6/3/2002 -0400, Keith Moore wrote:

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

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

But what about the case where the list-bot wants to refuse the message, or
"your message has been passed to the moderator of the list"? Clearly,
Reply-To is disastrous in this case. From is actually the best choice,
though Reutrn-Path _might_ just do instead.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

(Continue reading)

headers

Keith Moore | 5 Jun 2002 04:56

Re: Choosing recipient of automatic replies


> But what about the case where the list-bot wants to refuse the message, or
> "your message has been passed to the moderator of the list"? Clearly,
> Reply-To is disastrous in this case. From is actually the best choice,
> though Reutrn-Path _might_ just do instead.

>From is no better than reply-to here.  Either one can be a potentially
large group of people.  (more likely with reply-to, but still possible
with from)

Keith

headers

Barry Leiba | 3 Jun 2002 15:55

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)

headers

Dave Crocker | 4 Jun 2002 01:12

Replying to a mailing list

At 12:43 PM 6/3/2002 -0400, Keith Moore wrote:
>but I do like list-specific fields better than having lists rewrite
>originator-supplied fields.

every now and again, Keith and I agree on something.  This is one of them.

(but of course, it did not last for even one entire message...)

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

the human factors issues are a tad different.  paper did not automatically 
fill out the reply fields...

Getting the defaults "right" is a dilemma and, therefore, requires choosing 
the kind of error that is least undesireable.

>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

The intent was that users should only need to know about From/Reply-to, 
with Sender serving as a kind of accountability fall back.  Return-path 
(and Sender) are intended for the mail handling system, not really for the 
recipient user.

(Continue reading)

headers

Keith Moore | 4 Jun 2002 18:23

Re: Replying to a mailing list


> >but I do like list-specific fields better than having lists rewrite
> >originator-supplied fields.
> 
> every now and again, Keith and I agree on something.  This is one of them.
> 
> 
> (but of course, it did not last for even one entire message...)

:)

> >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.
> 
> the human factors issues are a tad different.  

absolutely.

> paper did not automatically fill out the reply fields...

and thus, paper never filled out the reply field incorrectly :)

> Getting the defaults "right" is a dilemma and, therefore, requires choosing
> the kind of error that is least undesireable.

I think of it as a user interface issue.  sometimes user interfaces that

(Continue reading)

headers

Keith Moore | 3 Jun 2002 18:43

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)

headers

Eric A. Hall | 3 Jun 2002 20:46

Re: Choosing recipient of automatic replies

Keith Moore wrote:

> even now I'm not sure that list-specific fields solve those problems,

> part of the problem is probably (as you said) that the subtle
> differences between return-path, from, reply-to, and sender

IMO, the whole construct is wrong. While the headers were appropriate for
the time and place of their design, the modern usage has gone to another
place which is not particularly well suited to the design. For example,
>From vs Sender is a good model if From doesn't have connectivity, but in
the modern age, From is just another way for spammers to lie.

I've been thinking about this in terms of a revised format/protocol, and
am of the opinion that a better usage for the current Internet mail model
is to use a Sender and Signatories model. This solves a lot of problems,
but as with all of the other radical departures, it pretty much depends on
overhauling the infrastructure.

In the Sender and Signatories model, the Sender is the Original Sender, as
identified in the envelope. These must match, and Sender must always be
provided. If there is only one party associated with the message, then
only the Sender needs to be provided. If something like a mailing list
redistributes the message, it becomes the Signatory, but the Sender header
field remains (and must still match the Original Sender envelope). If a
secretary is sending mail on behalf of the PHB, the PHB is the Signatory,
and the secretary is the Sender. Default replies go to the Signatory,
Reply-to-All goes to the Signatory+Sender+CC.

(Continue reading)

headers

Keith Moore | 3 Jun 2002 21:18

Re: Choosing recipient of automatic replies


Keith Moore wrote:

> > even now I'm not sure that list-specific fields solve those problems,
> 
> > part of the problem is probably (as you said) that the subtle
> > differences between return-path, from, reply-to, and sender
> 
> IMO, the whole construct is wrong. While the headers were appropriate for
> the time and place of their design, the modern usage has gone to another
> place which is not particularly well suited to the design. For example,
> From vs Sender is a good model if From doesn't have connectivity, but in
> the modern age, From is just another way for spammers to lie.

>From vs. Sender is as valid as it ever was.  My boss is constantly
asking other people (his secretaries and other employees) to send
out messages on his behalf.  That's exactly the case for which the
>From vs. Sender distinction was intended - the problem is just that 
that this isn't widely understood.

> I know this is OT, but I wanted to make the argument that the canonical
> problem is that the legacy model is not reflective of modern usages. 

well, neither is the model you've proposed.  

Keith

headers

Eric A. Hall | 3 Jun 2002 21:24

Re: Choosing recipient of automatic replies


Keith Moore wrote:

> From vs. Sender is as valid as it ever was.  My boss is constantly
> asking other people (his secretaries and other employees) to send
> out messages on his behalf.

>From and Sender is only one way to solve that particular problem.
Authenticated sender permissions is another. Letting any fool send mail as
your boss is about the dumbest imaginable method, given the current
climate. It was certainly a reasonable design choice at its inception but
things change, eh.

> > I know this is OT, but I wanted to make the argument that the canonical
> > problem is that the legacy model is not reflective of modern usages.
> 
> well, neither is the model you've proposed.

:/

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Keith Moore | 3 Jun 2002 21:37

Re: Choosing recipient of automatic replies


> > From vs. Sender is as valid as it ever was.  My boss is constantly
> > asking other people (his secretaries and other employees) to send
> > out messages on his behalf.
> 
> >From and Sender is only one way to solve that particular problem.
> Authenticated sender permissions is another. Letting any fool send mail as
> your boss is about the dumbest imaginable method, given the current
> climate. It was certainly a reasonable design choice at its inception but
> things change, eh.

okay, but what you've specified is not semantically equivalent to
>From vs. Sender - nor does it seem to reflect reality as well.  
(at least not in my part of the world - though I expect that 
practice varies quite widely from one culture to another)

authentication is a separate issue. it is as easy to authenticate From 
and/or Sender as it would be to authenticate your Sender and Signatories. 

e.g. 

From: Jack Dongarra <dongarra <at> cs.utk.edu>
From-authorization: {a formatted statement indicating that 
  "<moore <at> cs.utk.edu> is allowed to send messages on my behalf"
  and including certain conditions, like date and/or subject,
  that is signed using dongarra <at> cs.utk.edu's private key}
Sender: Keith Moore <moore <at> cs.utk.edu>
Content-type: multipart/signed

{message signed with moore <at> cs.utk.edu's signature}

(Continue reading)

headers

Barry Leiba | 3 Jun 2002 19:28

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)

headers

Dave Crocker | 4 Jun 2002 01:18

Sieve

At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
>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.

I suspect you haven't been sampling adequately.  Most of the people I know 
are quite irritated with getting such notices, unless they have explicitly 
cited the recipient in To or CC.

At any rate, such a specification should be done as an extension to 2822, 
rather than as a part of sieve.  The issue goes beyond split-UA interactions.

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

Complaints from whom?  The people who get vacation notices when they send 
to a mailing list?

d/

----------
Dave Crocker  <mailto:dcrocker <at> brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

headers

Lawrence Greenfield | 4 Jun 2002 03:25

Re: Sieve

   Date: Mon, 03 Jun 2002 18:18:42 -0500
   From: Dave Crocker <dcrocker <at> brandenburg.com>
[...]
   At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
   >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.

   I suspect you haven't been sampling adequately.  Most of the people I know 
   are quite irritated with getting such notices, unless they have explicitly 
   cited the recipient in To or CC.

I'm sorry, let me rephrase: "In practice, we haven't had any
complaints about vacation responses going to the envelope from address
and not the reply-to address."

Vacation messages to the envelope from address are easier to reason
about.  I suspect they're much less likely to cause mail loops.

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

   Complaints from whom?  The people who get vacation notices when they send 
   to a mailing list?

Complaints from the people who set the vacation messages and want
their messages to go to everybody who sends them mail directly or
indirectly.  I hate vacation messages from mailing lists, and I agree

(Continue reading)

headers

Dan Wing | 4 Jun 2002 17:44

RE: Sieve


>    At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
>    >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.
>
>    I suspect you haven't been sampling adequately.  Most of the people I know
>    are quite irritated with getting such notices, unless they have explicitly
>    cited the recipient in To or CC.
>
> I'm sorry, let me rephrase: "In practice, we haven't had any
> complaints about vacation responses going to the envelope from address
> and not the reply-to address."
>
> Vacation messages to the envelope from address are easier to reason
> about.  I suspect they're much less likely to cause mail loops.
>
>    >We do receive complaints about the check for the recipient's address
>    >in the To/Cc header lines.
>
>    Complaints from whom?  The people who get vacation notices when they send
>    to a mailing list?
>
> Complaints from the people who set the vacation messages and want
> their messages to go to everybody who sends them mail directly or
> indirectly.  I hate vacation messages from mailing lists, and I agree
> with the To/Cc test for responses.  But not everyone agrees with us.
> Luckily I don't sell my software and don't have to be responsive to
> customer complaints.

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 19:22

Re: Sieve

Dan Wing wrote:

> A mailing list would rewrite the envelope-from address.  So vacation
> notices sent to envelope-from wouldn't be seen by the person posting
> to the mailing list, nor would the vacation notice appear as a
> 'post' on the mailing list itself.

Even if the reverse-path has been rewritten to reference an appropriate
mailbox, the owner of the mailing list is likely to be uninterested in the
sender's vacation plans. After enough of these, the owner may even
manually pause or remove the sender from the list, resulting in the same
effect.

If the reverse-path has been misconfigured to reference an inappropriate
mailbox (eg, list-request <at> domain) then this might even happen
automatically. This is *designed* to happen automatically with mailing
lists that use VERP and similar proposals:

 |                                         The VERP extension implements
 | a way of automatically identifying undeliverable mail recipients,
 | even when non-delivery reports originate from mail systems that do
 | not implement delivery status notifications

Even outside the list world, there are scenarios where sending to the
reverse-path is inappropriate. EG, when the Sender/From construct is
actually used, the notification is returned to the Sender instead of the
>From parties.

I might be using a terminal or kiosk with a reverse-path referencing the

(Continue reading)

headers

Florian Weimer | 4 Jun 2002 21:29

Re: Sieve

"Eric A. Hall" <ehall <at> ehsco.com> writes:

> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request <at> domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:
>
>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications

VERP is basically dead for practical purposes.

At work, we run a small read-only mailing list which mainly targets
German IT workers.  Apparently, many larger institutions gateway mail
from RFC 821/822 format to some X.400 derivate or proprietary mail
implementations, and these gateways throw away the distinction between
envelope address and header address.

As a result, even delivery failure notifications are regularly sent to
the address in the From: header, not just the regular stream of
out-of-office notifications during school vacations.

> Even outside the list world, there are scenarios where sending to the
> reverse-path is inappropriate. EG, when the Sender/From construct is
> actually used, the notification is returned to the Sender instead of the
> From parties.

(Continue reading)

headers

Russ Allbery | 5 Jun 2002 07:21

Re: Sieve

Florian Weimer <fw <at> deneb.enyo.de> writes:

> VERP is basically dead for practical purposes.

Do you mean in the sense of being absolutely reliable, or in the sense of
being widely used?

If you mean the latter, you're wrong.  I read the bounce logs of
Stanford's mail servers regularly.  :)

> At work, we run a small read-only mailing list which mainly targets
> German IT workers.  Apparently, many larger institutions gateway mail
> from RFC 821/822 format to some X.400 derivate or proprietary mail
> implementations, and these gateways throw away the distinction between
> envelope address and header address.

> As a result, even delivery failure notifications are regularly sent to
> the address in the From: header, not just the regular stream of
> out-of-office notifications during school vacations.

There is always some mail system out there that's sufficiently perverse
that it will break anything that you try to do, but that's not a reason
not to do something.

The basic idea of VERP is fundamentally sound and solves one of the major
problems in mailing list management, namely correlating a DSN with a list
member when all of the forwarding information for how the message got
there has been systematically destroyed by bad mail systems.

(Continue reading)

headers

Moore, Tom J | 4 Jun 2002 22:07

RE: Sieve


And just maybe Microsoft will read it.  

Tom

-----Original Message-----
From: Dan Wing [mailto:dwing <at> Cisco.COM]
Sent: Tuesday, June 04, 2002 3:59 PM
To: Eric A. Hall
Cc: Keith Moore; Lawrence Greenfield; Dave Crocker; Florian Weimer;
ietf-822 <at> imc.org
Subject: RE: Sieve

> > Keith is arguing that the decisions and permutations are too hard, and
> > the Return-Path should be used.
> 
> That would certainly be a reasonable position. It would seem that every
> other argument has some kind of failing exception.

If we have consensus on this, it'd be nice to do an I-D on it.  How to
do Vacation correctly comes up about once a year.

-d

headers

Keith Moore | 4 Jun 2002 20:13

Re: Sieve


> Even if the reverse-path has been rewritten to reference an appropriate
> mailbox, the owner of the mailing list is likely to be uninterested in the
> sender's vacation plans. After enough of these, the owner may even
> manually pause or remove the sender from the list, resulting in the same
> effect.
> 
> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request <at> domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:

VERP isn't well-designed then. a recipient-unique envelope return address 
is useful, but it's unwise to expect that every message sent to that 
address is a nondelivery report - there is absolutely nothing in the mail 
specifications that says that only nondelivery reports should go to that 
address.

>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications
> 
> Even outside the list world, there are scenarios where sending to the
> reverse-path is inappropriate. EG, when the Sender/From construct is
> actually used, the notification is returned to the Sender instead of the
> From parties.

That's a bug in RFC 822.  Nondelivery reports should always go to the 
Return-path/MAIL FROM address, NEVER to the Sender address.  The

(Continue reading)

headers

Florian Weimer | 4 Jun 2002 21:56

Re: Sieve

Keith Moore <moore <at> cs.utk.edu> writes:

> VERP isn't well-designed then. a recipient-unique envelope return address 
> is useful, but it's unwise to expect that every message sent to that 
> address is a nondelivery report - there is absolutely nothing in the mail 
> specifications that says that only nondelivery reports should go to that 
> address.

It's a fact that most user agents don't know much (if anything) about
envelope addresses, and I can't think of one which offers a "reply to
envelope address" command.  Gateways from RFC 821 to other protocols
(essentially, a UNIX delivery agent is such a gateway) tend to throw
away envelope (To) addresses and keep header addresses only.

If the mailing list is for announcements only, you can add a Reply-To
header to divert messages from real people (and unfortunately, some
out-of-office notifications) to a suitable account, and the remaining
mail to the envelope from should come from an automated service.
Actually, you don't care which one--if your mailing list is so large
that you can't afford dealing with bouncing addresses manually, a lost
subscriber doesn't matter at all. 

> That's precisely the reason that the MAIL FROM address is exposed in the 
> message header as return-path - so the address can be used for automatic 
> responses that are generated after the message leaves the transport/delivery 
> system.

Ah, this is new in RFC 2821.  Nice, however it doesn't seem to be
implemented widely.

(Continue reading)

headers

ned+ietf-822 | 4 Jun 2002 22:12

Re: Sieve


> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the transport/delivery
> > system.

> Ah, this is new in RFC 2821.

Actually, a slightly weaker form of this requirement is present in RFC 1123.
Section 5.2.8 says, in part:

         When the receiver-SMTP makes "final delivery" of a message,
         then it MUST pass the MAIL FROM: address from the SMTP envelope
         with the message, for use if an error notification message must
         be sent later ...

and then:

         IMPLEMENTATION:
              The MAIL FROM: information may be passed as a parameter or
              in a Return-Path: line inserted at the beginning of the
              message.

RFC 2821 makes it explicit that this has to be done with a return-path field;
an improvement IMO.

> Nice, however it doesn't seem to be implemented widely.

Hmm. My impression has been the exact opposite. Specifically, I know that PMDF
and iMS (MTAs I've worked on) add such a field, and I believe sendmail, qmail,

(Continue reading)

headers

Florian Weimer | 4 Jun 2002 22:53

Re: Sieve


ned.freed <at> mrochek.com writes:

[Return-path with proper semantics]

>> Nice, however it doesn't seem to be implemented widely.
>
> Hmm. My impression has been the exact opposite.

Maybe it's implemented widely, but not universally.

> Specifically, I know that PMDF and iMS (MTAs I've worked on) add
> such a field,and I believe sendmail, qmail, MMDF, PP, exim, and even
> Exchange do so as well.

In Exim, it's a config item which is not enabled by default.

headers

Dan Wing | 4 Jun 2002 22:59

RE: Sieve


> > Specifically, I know that PMDF and iMS (MTAs I've worked on) add
> > such a field,and I believe sendmail, qmail, MMDF, PP, exim, and even
> > Exchange do so as well.
> 
> In Exim, it's a config item which is not enabled by default.

That implementation decision hinders proper operation of RFC2298-
compatible UAs.

-d

headers

Keith Moore | 4 Jun 2002 22:02

Re: Sieve


> Gateways from RFC 821 to other protocols
> (essentially, a UNIX delivery agent is such a gateway) tend to throw
> away envelope (To) addresses and keep header addresses only.

the envelope addresses of other recipients are typically unavailable
to such gateways anyway.  SMTP doesn't communicate the envelope address
of each recipient to each MTA - the only envelope addresses sent to
an MTA are those for which *that MTA* is responsible for delivery.

> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the transport/delivery
> > system.
> 
> Ah, this is new in RFC 2821.  Nice, however it doesn't seem to be
> implemented widely.

no, it's in RFC 821 also.  however it's true that many MTAs don't 
implement it correctly.

Keth

headers

Eric A. Hall | 4 Jun 2002 20:28

Re: Sieve

Keith Moore wrote:

> > Even outside the list world, there are scenarios where sending to the
> > reverse-path is inappropriate. EG, when the Sender/From construct is
> > actually used, the notification is returned to the Sender instead of
> > the From parties.
> 
> That's a bug in RFC 822.  Nondelivery reports should always go to the
> Return-path/MAIL FROM address, NEVER to the Sender address.  The
> contents of the Sender field aren't even required to be a legal address.

The reverse-path is almost always the same mailbox address as the message
sender (as specified in Sender, when it is actually present). In that
regard, the reverse-path will point to the Sender rather than From.

> > These examples are all really beside the ultimate point, however:
> > out-of-office notifications are an application of the messaging network
> > and not in-band management messages, so they really should use the
> > headers rather than the envelope.
> 
> That's precisely the reason that the MAIL FROM address is exposed in the
> message header as return-path - so the address can be used for automatic
> responses that are generated after the message leaves the
> transport/delivery  system.

We're not disagreeing here. Management messages should use the envelope,
and the reverse-path is provided to the application through Return-Path
header field. Meanwhile, application messages (replies, content filters,
and yes out-of-office notifications) should use the application headers,

(Continue reading)

headers

Keith Moore | 4 Jun 2002 20:47

Re: Sieve


> > > Even outside the list world, there are scenarios where sending to the
> > > reverse-path is inappropriate. EG, when the Sender/From construct is
> > > actually used, the notification is returned to the Sender instead of
> > > the From parties.
> > 
> > That's a bug in RFC 822.  Nondelivery reports should always go to the
> > Return-path/MAIL FROM address, NEVER to the Sender address.  The
> > contents of the Sender field aren't even required to be a legal address.
> 
> The reverse-path is almost always the same mailbox address as the message
> sender (as specified in Sender, when it is actually present). In that
> regard, the reverse-path will point to the Sender rather than From.

correct.  but you get this address from the Return-Path field, not the
Sender field.

> > > These examples are all really beside the ultimate point, however:
> > > out-of-office notifications are an application of the messaging network
> > > and not in-band management messages, so they really should use the
> > > headers rather than the envelope.
> > 
> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the
> > transport/delivery  system.
> 
> We're not disagreeing here. Management messages should use the envelope,
> and the reverse-path is provided to the application through Return-Path
> header field. Meanwhile, application messages (replies, content filters,

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 21:06

Re: Sieve

Keith Moore wrote:

> no, "management" vs. "application" messages is not where the line should
> be drawn.  Return-Path is provided so that applications can use it when
> it's appropriate.  Most automatic responses should go to Return-Path.

What if there are multiple addresses in From: and Sender: was just the
messenger, or what if From: is a group address? The application acks fall
apart if basic features of the messaging network are used but the
application sends its ack to the node instead of the application

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Keith Moore | 4 Jun 2002 21:11

Re: Sieve


> > no, "management" vs. "application" messages is not where the line should
> > be drawn.  Return-Path is provided so that applications can use it when
> > it's appropriate.  Most automatic responses should go to Return-Path.
> 
> What if there are multiple addresses in From: and Sender: was just the
> messenger, or what if From: is a group address? 

that's part of why sending the response to the return-path address is
better - it's more likely to reach someone who can actually make use
of the response.

> The application acks fall
> apart if basic features of the messaging network are used but the
> application sends its ack to the node instead of the application

if the sending application is putting anything in the MAIL FROM
field other than an address which will reach the sending 
application, the sending application is broken.

Keith

headers

Eric A. Hall | 4 Jun 2002 21:23

Re: Sieve

Keith Moore wrote:

> that's part of why sending the response to the return-path address is
> better - it's more likely to reach someone who can actually make use
> of the response.

But they are not always the most useful target.

Consider an original message which has a From: PHB and CC: HR, and where
the recipient is the only address listed in To:. It is reasonable for an
out-of-office notification to go to the From: and CC: parties, since this
message is specifically intended for the recipient (given the other people
in the distribution, it would be a damn good idea to send it to all of
them). It is not entirely logical to send the message to the secretary
mailbox in the reverse-path. The secretary doesn't care.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Keith Moore | 4 Jun 2002 21:35

Re: Sieve


> > that's part of why sending the response to the return-path address is
> > better - it's more likely to reach someone who can actually make use
> > of the response.
> 
> But they are not always the most useful target.
> 
> Consider an original message which has a From: PHB and CC: HR, and where
> the recipient is the only address listed in To:. It is reasonable for an
> out-of-office notification to go to the From: and CC: parties, since this
> message is specifically intended for the recipient 

No, it's not reasonable for an autoresponder to make such assumptions, 
because the autoresponder has no idea about the purpose of the message
or the roles of those whose addresses are in the From or CC lines.  
(heck, even I can't guess what PHB means)

The only thing the autoresponder knows is that the return-path address
should be set up to receive automatic replies.

It's the responsibility of the sender to ensure that MAIL FROM is set
to an address which is useful for this purpose.

> (given the other people
> in the distribution, it would be a damn good idea to send it to all of
> them). It is not entirely logical to send the message to the secretary
> mailbox in the reverse-path. The secretary doesn't care.

perhaps unfortunately (but probably not), we don't have a separate address
for every discrete purpose, so we don't have one for out-of-office responses.

(Continue reading)

headers

Dan Wing | 4 Jun 2002 21:26

RE: Sieve


> > that's part of why sending the response to the return-path address is
> > better - it's more likely to reach someone who can actually make use
> > of the response.
> 
> But they are not always the most useful target.
> 
> Consider an original message which has a From: PHB and CC: HR, and where
> the recipient is the only address listed in To:. It is reasonable for an
> out-of-office notification to go to the From: and CC: parties, since this
> message is specifically intended for the recipient (given the other people
> in the distribution, it would be a damn good idea to send it to all of
> them). It is not entirely logical to send the message to the secretary
> mailbox in the reverse-path. The secretary doesn't care.

It's never appropriate to send vacation notices to the entire list
of mailboxes in the To/CC.

Imagine the case of exactly this thread, where several people are
on the To/CC line, and the ietf-822 <at> ietf.org mailing list is also
on the To/CC line.  If a vacation program did a reply-all, the
vacation notice would go to the ietf-822 mailing list.

-d

headers

Florian Weimer | 4 Jun 2002 21:39

Re: Sieve

"Dan Wing" <dwing <at> cisco.com> writes:

> Imagine the case of exactly this thread, where several people are
> on the To/CC line, and the ietf-822 <at> ietf.org mailing list is also
> on the To/CC line.  If a vacation program did a reply-all, the
> vacation notice would go to the ietf-822 mailing list.

Virus scanners do this (some even in their default configurations, it
seems), and it's really annoying.  Autoreplies sent to Cc: or To:
fields is never a good idea because the software cannot know the
semantics of the addresses.

headers

Dan Wing | 4 Jun 2002 21:43

RE: Sieve


> > Imagine the case of exactly this thread, where several people are
> > on the To/CC line, and the ietf-822 <at> ietf.org mailing list is also
> > on the To/CC line.  If a vacation program did a reply-all, the
> > vacation notice would go to the ietf-822 mailing list.
> 
> Virus scanners do this (some even in their default configurations, it
> seems), and it's really annoying. 

Yeah, I have seen this behavior on the main IETF list a time or two.

> Autoreplies sent to Cc: or To:
> fields is never a good idea because the software cannot know the
> semantics of the addresses.

-d

headers

Eric A. Hall | 4 Jun 2002 21:32

Re: Sieve

Dan Wing wrote:

> It's never appropriate to send vacation notices to the entire list
> of mailboxes in the To/CC.

I am only postulating for specific scenarios, eg new threads (no "Re:").
Also, the message you sent to me had two To: recipients.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Dan Wing | 4 Jun 2002 21:41

RE: Sieve


> > It's never appropriate to send vacation notices to the entire list
> > of mailboxes in the To/CC.
>
> I am only postulating for specific scenarios, eg new threads (no "Re:").

Well, let's postulate that I send mail to the author of RFC2822 (Peter
Resnick) and CC ietf-822 <at> imc.org, asking for clarification on a section
of RFC2822.  This wouldn't have a "Re:".

It would be like:

  return-path: <dwing <at> cisco.com>
  to: presnick <at> qualcomm.com
  cc: ietf-822 <at> imc.org
  from: dwing <at> cisco.com

And if Pete has a vacation program that does a reply-all, I think
there would be significant outcry on the mailing list.

> Also, the message you sent to me had two To: recipients.

I don't understand the distinction you're making regarding multiple recipients
in To:.

-d

headers

Lawrence Greenfield | 4 Jun 2002 20:52

Re: Sieve

   From: Keith Moore <moore <at> cs.utk.edu>
   Date: Tue, 04 Jun 2002 14:47:59 -0400
[...]
   > We're not disagreeing here. Management messages should use the envelope,
   > and the reverse-path is provided to the application through Return-Path
   > header field. Meanwhile, application messages (replies, content filters,
   > and yes out-of-office notifications) should use the application headers,
   > (ala From/Reply-To).

   no, "management" vs. "application" messages is not where the line should 
   be drawn.  Return-Path is provided so that applications can use it when
   it's appropriate.  Most automatic responses should go to Return-Path.

I believe Dave was agreeing with Eric here that "out-of-office"
notifications should use the From/Reply-to.  I don't think I
understand Dave's reasoning, so I'd kinda another explanation to get
it through my head.

I (and my implementation) agree with Keith and Dan that using the
return-path is preferable.

Larry

headers

Dan Wing | 4 Jun 2002 19:57

RE: Sieve


> > A mailing list would rewrite the envelope-from address.  So vacation
> > notices sent to envelope-from wouldn't be seen by the person posting
> > to the mailing list, nor would the vacation notice appear as a
> > 'post' on the mailing list itself.
> 
> Even if the reverse-path has been rewritten to reference an appropriate
> mailbox, the owner of the mailing list is likely to be uninterested in the
> sender's vacation plans. After enough of these, the owner may even
> manually pause or remove the sender from the list, resulting in the same
> effect.

Yep, which is why I stated below the best bet is only send vacation
when recipient is on to/CC, and send vacation to the envelope-from.

> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request <at> domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:
> 
>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications

Simplistic implementations of auto-unsubscribe will likewise have
issues with unable-to-send-for-8-hours informational messages, such
as are common with many sendmail configurations.  I expect that any
auto-unsubscribe system will have to deal with those informational
messages (which are sent to the envelope-from).

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 20:30

Re: Sieve

Dan Wing wrote:

> Simplistic implementations of auto-unsubscribe will likewise have
> issues with unable-to-send-for-8-hours informational messages, such
> as are common with many sendmail configurations.  I expect that any
> auto-unsubscribe system will have to deal with those informational
> messages (which are sent to the envelope-from).

To be clear, I'm not endorsing VERP. Having said that, the idea is to
catch notifications which are not DSNs. Status: Delayed can be trapped
easily. I would ass-u-me that implementors also look for WARNING: and
other magic strings appropriately. At that point the question would be
about the ~thresholds for any kind of auto-unsub action that might take
place.

By the same token, if you annoy the list owner, where is their threshold?

> Sender/From is classically described for use with a secretary and an
> executive:  the secretary would be Sender, the executive would be From.
> In that case, I argue the executive isn't interested in NDNs (or
> vacation notices) and thus the return-path should be the sender.
> This causes NDNs to be sent to the secretary.  Likewise, if
> vacation notices are sent to the return-path (as vacation works
> on Unix), the vacation notices are sent to the secretary (Sender).
> 
> I believe you're arguing that the executive should see the NDNs and
> should see the vacation messages for a Sender/From message?

I would argue that Sender: secretary should receive the delivery failure

(Continue reading)

headers

Keith Moore | 4 Jun 2002 21:28

Re: Sieve

> Dan Wing wrote:
> 
> > Simplistic implementations of auto-unsubscribe will likewise have
> > issues with unable-to-send-for-8-hours informational messages, such
> > as are common with many sendmail configurations.  I expect that any
> > auto-unsubscribe system will have to deal with those informational
> > messages (which are sent to the envelope-from).
> 
> To be clear, I'm not endorsing VERP. Having said that, the idea is to
> catch notifications which are not DSNs. Status: Delayed can be trapped
> easily. I would ass-u-me that implementors also look for WARNING: and
> other magic strings appropriately. At that point the question would be
> about the ~thresholds for any kind of auto-unsub action that might take
> place.

If you parse the message enough to be sure that it is a nondelivery report 
(whether a DSN or not) and treat it as such, I have no problem with that.
But it's foolish to treat unrecognized messages as if they were nondelivery 
reports.

> I would argue that Sender: secretary should receive the delivery failure
> notification but From: PHB should receive the out-of-office notification.

You're assuming too much.  Just because a message is sent by someone's
authority does NOT mean that they want to receive any kind of automatic
notifications.  It would be perfectly reasonable for a CEO to send out
a message of the form:

From: CEO

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 21:42

Re: Sieve

Keith Moore wrote:

> You're assuming too much.  Just because a message is sent by someone's
> authority does NOT mean that they want to receive any kind of automatic
> notifications.  It would be perfectly reasonable for a CEO to send out
> a message of the form:
> 
> From: CEO
> Reply-to: customer-relations
> Sender: secretary
> Return-Path: bounce-address  (set on delivery from MAIL FROM)
> To: customers:;

Why should the secretary get them? Why shouldn't the customer-relations
get them? You are essentially arguing that the messaging applications
should not communicate on the off-chance that the boss might get annoyed
one day.

What if my boss sends a message to the staff on *my* behalf. What then?

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Keith Moore | 4 Jun 2002 21:58

Re: Sieve


> > You're assuming too much.  Just because a message is sent by someone's
> > authority does NOT mean that they want to receive any kind of automatic
> > notifications.  It would be perfectly reasonable for a CEO to send out
> > a message of the form:
> > 
> > From: CEO
> > Reply-to: customer-relations
> > Sender: secretary
> > Return-Path: bounce-address  (set on delivery from MAIL FROM)
> > To: customers:;
> 
> Why should the secretary get them? 

why should the secretary get *what*?  NOTHING should get sent to the
address in the Sender field.  the only purpose of that field is to 
identify who actually caused the message to be sent; it's not intended
to be used for responses.

> You are essentially arguing that the messaging applications
> should not communicate on the off-chance that the boss might get annoyed
> one day.

no, I'm arguing that messaging applications that issue automatic responses
should not make unwarranted assumptions about the roles of those whose
addresses appear in any field other than the return-path field.

> What if my boss sends a message to the staff on *my* behalf. What then?

if person A sends a message on person B's behalf, whether that is

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 22:07

Re: Sieve

Keith Moore wrote:

> > > Return-Path: bounce-address  (set on delivery from MAIL FROM)

> why should the secretary get *what*?

Sorry, I missed the header.

Of course using the null reverse-path is an option for anybody, so I'm not
sure what this argument proves, other than it would be nice for messaging
systems to implement a feature that none of them currently offer.

> if in sending such a message person A fails to recognize that
> MAIL FROM should be set up as appropriate to receive any automatic
> responses that might result from that message, person A has
> failed to use the mail protocol correctly.

It would be a lovely feature for other reasons as well. EG, perhaps my ISP
enforces draconian AUTH<->reverse-path matching, and being able to use a
different reverse-path than the From: header would be a viable and fully
legitimate (still traceable) solution to that problem.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Keith Moore | 4 Jun 2002 22:26

Re: Sieve


> EG, perhaps my ISP
> enforces draconian AUTH<->reverse-path matching, and being able to use a
> different reverse-path than the From: header would be a viable and fully
> legitimate (still traceable) solution to that problem.

the solution here is to get another ISP.
the mail protocol can't be expected to fix ISP brain-damage.

Keith

headers

Dan Wing | 4 Jun 2002 21:45

RE: Sieve


> Keith Moore wrote:
> 
> > You're assuming too much.  Just because a message is sent by someone's
> > authority does NOT mean that they want to receive any kind of automatic
> > notifications.  It would be perfectly reasonable for a CEO to send out
> > a message of the form:
> > 
> > From: CEO
> > Reply-to: customer-relations
> > Sender: secretary
> > Return-Path: bounce-address  (set on delivery from MAIL FROM)
> > To: customers:;
> 
> Why should the secretary get them? Why shouldn't the customer-relations
> get them? You are essentially arguing that the messaging applications
> should not communicate on the off-chance that the boss might get annoyed
> one day.

Keith is arguing that the decisions and permutations are too hard, and
the Return-Path should be used.

> What if my boss sends a message to the staff on *my* behalf. What then?

NDNs and vacation notices go to Return-Path, which is set appropriately
based on whoever wants to receive NDNs, vacation notices, and delay
warnings.

-d

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 21:52

Re: Sieve

Dan Wing wrote:

> Keith is arguing that the decisions and permutations are too hard, and
> the Return-Path should be used.

That would certainly be a reasonable position. It would seem that every
other argument has some kind of failing exception.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Dan Wing | 4 Jun 2002 21:59

RE: Sieve


> > Keith is arguing that the decisions and permutations are too hard, and
> > the Return-Path should be used.
> 
> That would certainly be a reasonable position. It would seem that every
> other argument has some kind of failing exception.

If we have consensus on this, it'd be nice to do an I-D on it.  How to
do Vacation correctly comes up about once a year.

-d

headers

Keith Moore | 4 Jun 2002 22:25

I-D on automatic responses


> If we have consensus on this, it'd be nice to do an I-D on it.  How to
> do Vacation correctly comes up about once a year.

Okay, how about an I-D on automatic responses to email?  

offhand, seems like it should discuss the following:

I. Introduction
  - discuss the need to specify recommendations for behavior 
    of automatic responses - e.g.
    avoid sending useless/unwanted responses 
    avoid sending responses to the "wrong place"
    avoid mail loops and sorcerer's apprentice syndrome   

II. Types of automatic responses
  - distinguish between automatic responses and DSNs and MDNs
    (which are covered elsewhere)

  - distinguish between mail robots whose response is anticipated
    by the sender (sender sends to that address knowing that it will
    automatically respond), vs. mail robots that respond on behalf
    of a human recipient:

  - mention a few different kinds of automatic responses -
    - mail robots that accept requests from humans and send back responses
      (e.g. subscribe to a list, retrieve a file, 
       convert this fortran program to c)
    - out-of-office notices (that don't reply to every message)
    - use of email to communicate between two applications

(Continue reading)

headers

Florian Weimer | 4 Jun 2002 23:12

Re: I-D on automatic responses


Keith Moore <moore <at> cs.utk.edu> writes:

> III. Format of automatic responses
>     - envelope return address (avoid loops!)
>     - headers (to, from, subject, auto-submitted)
>     - content (should probably limit size, content to limit
>       DoS attack potential - e.g. should not allow sender to
>       use the responder as a relay for viruses)

     - plain text, English version included, involved addresses have
       to be in Internet syntax

Have a look at

http://www.exim.org/pipermail/exim-users/Week-of-Mon-20020603/039366.html

to see why this is required, or post to BUGTRAQ. :-/

headers

Florian Weimer | 4 Jun 2002 22:51

Re: I-D on automatic responses


Keith Moore <moore <at> cs.utk.edu> writes:

>   - mention a few different kinds of automatic responses -

       - assignment of a tracking number or a similar identifier

> III. Format of automatic responses
>     - envelope return address (avoid loops!)
>     - headers (to, from, subject, auto-submitted)
>     - content (should probably limit size, content to limit
>       DoS attack potential - e.g. should not allow sender to
>       use the responder as a relay for viruses)

      - proper MIME encapsulation (?)

> VI. security considerations
> 	- DoS attack through mail loops
> 	- DoS attack through large #s of requests
> 	- DoS attack by using responder to flood large #s of mailboxes
> 	- attack by using responder to relay harmful/abusive content
> 	- requests by unauthorized parties

        - privacy risks of out-of-office notifications (coworker names
          make social engineering easier)

headers

Russ Allbery | 5 Jun 2002 06:30

Re: I-D on automatic responses

Florian Weimer <fw <at> deneb.enyo.de> writes:
> Keith Moore <moore <at> cs.utk.edu> writes:

>>     - content (should probably limit size, content to limit
>>       DoS attack potential - e.g. should not allow sender to
>>       use the responder as a relay for viruses)

A somewhat dubious but effective way of getting around the problem of
being used as a relay for viruses is to include the original message in
the body of the reply in plain text rather than as a MIME-formatted
inclusion.  That defangs most of the active content in most mailers.
That's what I'm doing right now.

>       - proper MIME encapsulation (?)

What in particular would you encapsulate?  Just the original message if
you're including it for reference, or other things as well?

Bear in mind that MIME encapsulation can make it harder for the user to
actually see that portion of the message.  We still regularly get
complaints about our bounce messages, which I switched a while back to a
format that strictly conforms with the DSN standard, because the original
message shows up as an attachment that the user's mail client can't deal
with.

(I've also encountered a bizarre problem apparently in Eudora where the
mail client for some reason doesn't properly delete the DSN message off of
the server when using POP, thus making the user think that they're
receiving the message over and over again when we only sent it once and

(Continue reading)

headers

Eric A. Hall | 5 Jun 2002 07:14

Re: I-D on automatic responses

Russ Allbery wrote:

> >       - proper MIME encapsulation (?)
> 
> What in particular would you encapsulate?  Just the original message if
> you're including it for reference, or other things as well?

I would think that all autogenerated messages should be sent as
multipart/report, if for no other reason than to let messaging systems
reuse existing code. Secondarily, reusing multipart/report yields itself
to letting people filter them out (eg, list owners can universally reject
them from the posting queue). Furthermore, if we are going to define
fundamental behavior for all apps to use, a little consistency in the
reporting service will go a long way to getting it right. Keith and I are
arguing about this and he can explain his position, but that's mine.

If a multipart/report were used, any subsequent message/<app>-notification
entities should at a minimum contain the Original-Recipient body field
(sourced from ORCPT, if available). List admins can use this to figure out
who they need to cutoff, if nothing else.

> Bear in mind that MIME encapsulation can make it harder for the user to
> actually see that portion of the message.

Which portion? Everything the average user should need to know ought to be
clearly explained in the text/plain leader.

> We still regularly get
> complaints about our bounce messages, which I switched a while back to a

(Continue reading)

headers

Russ Allbery | 5 Jun 2002 07:56

Re: I-D on automatic responses

Eric A Hall <ehall <at> ehsco.com> writes:

> I would think that all autogenerated messages should be sent as
> multipart/report, if for no other reason than to let messaging systems
> reuse existing code.

Er, what if the text/plain portion is the entire content?
multipart/report assumes that you're reporting something that implies some
meaningful content to at least the second portion of the message.

Clearly, message/delivery-status isn't always applicable as the second
part.  (Consider, for example, an auto-generated response that gives the
user a tracking number for their problem.  A message/delivery-status part
wouldn't provide any useful information.)

Furthermore, as mentioned in my message, handling of multipart/report in
popular clients is rather far from ideal; the only portion of the message
that you can be assured of them being able to read is the initial part.

> If a multipart/report were used, any subsequent
> message/<app>-notification entities should at a minimum contain the
> Original-Recipient body field (sourced from ORCPT, if available). List
> admins can use this to figure out who they need to cutoff, if nothing
> else.

Well, no, they can't.  For the hard cases where the list owner can't
already tell that, you already don't have enough information to include a
meaningful Original-Recipient.  If the user forwarded their yahoo.com
e-mail address to your server, you have no idea what their original mail

(Continue reading)

headers

Eric A. Hall | 5 Jun 2002 15:53

Re: I-D on automatic responses


Russ Allbery wrote:

> message/delivery-status isn't always applicable as the second part.

No, but a message/generic-notification can be.

> > Which portion? Everything the average user should need to know ought to
> > be clearly explained in the text/plain leader.
> 
> If everything that's important is in the text/plain section, why on earth
> should one send anything other than that?

Because humans aren't the only ones that get them.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Russ Allbery | 5 Jun 2002 23:42

Re: I-D on automatic responses


Eric A Hall <ehall <at> ehsco.com> writes:
> Russ Allbery wrote:

>> message/delivery-status isn't always applicable as the second part.

> No, but a message/generic-notification can be.

Can you give me some idea of what additional content you think would be
useful to include in all autogenerated replies?

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

headers

Eric A. Hall | 6 Jun 2002 01:58

Re: I-D on automatic responses

Russ Allbery wrote:
> 
> Eric A Hall <ehall <at> ehsco.com> writes:
> > Russ Allbery wrote:
> 
> >> message/delivery-status isn't always applicable as the second part.
> 
> > No, but a message/generic-notification can be.
> 
> Can you give me some idea of what additional content you think would be
> useful to include in all autogenerated replies?

Original-Recipient, at least. (I know you said that you think VERP is
required for this, but the common usage is already there, and at least
some systems conform to it).

Original-Message-ID would also be particularly useful if the generic
notifications were used for things like virus notifications.

I would also expect that specific applications would want to tailor their
own, as we already have with DSNs and MDNs. Vacation and virus
notifications would be obvious candidates.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Florian Weimer | 17 Jun 2002 11:50

Re: I-D on automatic responses


"Eric A. Hall" <ehall <at> ehsco.com> writes:

>> Can you give me some idea of what additional content you think would be
>> useful to include in all autogenerated replies?
>
> Original-Recipient, at least. (I know you said that you think VERP is
> required for this, but the common usage is already there, and at least
> some systems conform to it).
>
> Original-Message-ID would also be particularly useful if the generic
> notifications were used for things like virus notifications.

And the Received: headers of the triggering message, to enable abuse
tracking.

headers

Russ Allbery | 6 Jun 2002 02:58

Re: I-D on automatic responses

Eric A Hall <ehall <at> ehsco.com> writes:

> Original-Recipient, at least. (I know you said that you think VERP is
> required for this, but the common usage is already there, and at least
> some systems conform to it).

I've never understood the use of this field.  Could you explain more about
how you think this would be helpful to include?

> Original-Message-ID would also be particularly useful if the generic
> notifications were used for things like virus notifications.

Virus notifications are a class of autoresponse that I think should be
full-blown multipart/report; I agree with you there.

I'm thinking more in terms of a typical use for an autoreply (at least in
my experience), something like "thank you for your message, we're really
busy, we'll write back to you in 2147" or "here's a ticket tracking number
for your message; no one here will have any idea what you're talking about
if you refer to it in your later e-mail, but they make great sock
warmers."

> I would also expect that specific applications would want to tailor
> their own, as we already have with DSNs and MDNs. Vacation and virus
> notifications would be obvious candidates.

I agree on virus notifications, at least, yes.  I can see an argument for
vacation messages maybe if we can convince MUA authors to actually do
something reasonable with structured content, but so far it seems like

(Continue reading)

headers

Eric A. Hall | 4 Jun 2002 22:35

Re: I-D on automatic responses


Keith Moore wrote:

> anything else?

Unless I missed them:

  no autoreplies to owner-* or *-request

  maintain db of respondents, recommended minimum of once per week

One other optional thing is message/vacation-notification media-type for
use with multipart/report. Apart from the normal body fields
(Original-Recipient especially), I also wanted to provide a Return-Date
header which could optionally be used by MUAs to flag an entry in the
address book ("is away until mm/dd") or by mailing lists to suspend
delivery automagically.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

Russ Allbery | 5 Jun 2002 06:25

Re: I-D on automatic responses

Eric A Hall <ehall <at> ehsco.com> writes:

> Unless I missed them:

>   no autoreplies to owner-* or *-request

>   maintain db of respondents, recommended minimum of once per week

Which type of autoreplies?

For example, my mail system currently sends some autoreplies which are
essentially bounces, but which aren't formatted as bounces because bounces
confuse the user.  There are role addresses that we've retired in favor of
a ticket tracking system, and the user is told to instead submit their
problem to that system.

I believe that those autoreplies should be sent in response to every
message sent to them, not just once a week.  (Whether or not they should
go to owner-* or *-request is an iffier question.)

I'm following this discussion with interest as currently they're going to
From/Reply-To because that's been more reliable in actually reaching the
sender, but I'm pretty much convinced they should actually go to envelope
sender.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

(Continue reading)

headers

Keith Moore | 5 Jun 2002 14:43

Re: I-D on automatic responses


> I believe that those autoreplies should be sent in response to every
> message sent to them, not just once a week.  

I certainly don't believe that the "once a week" idea should apply to
all autoreplies, just to notices of the form "this recipient is
temporarily unavailable".

headers

Florian Weimer | 4 Jun 2002 22:47

Re: I-D on automatic responses


"Eric A. Hall" <ehall <at> ehsco.com> writes:

>   maintain db of respondents, recommended minimum of once per week

ITYM "at most one message per week" (we want to establish an upper
bound on the notification rate, not a lower bound)

headers

Keith Moore | 4 Jun 2002 22:37

Re: I-D on automatic responses


>  I also wanted to provide a Return-Date
> header which could optionally be used by MUAs to flag an entry in the
> address book ("is away until mm/dd") or by mailing lists to suspend
> delivery automagically.

the last bit seems dubious - just because I won't respond to mail
for some period of time doesn't mean I don't want it to be sent to me.

headers

Eric A. Hall | 4 Jun 2002 22:42

Re: I-D on automatic responses


Keith Moore wrote:
> 
> >  I also wanted to provide a Return-Date
> > header which could optionally be used by MUAs to flag an entry in the
> > address book ("is away until mm/dd") or by mailing lists to suspend
> > delivery automagically.
> 
> the last bit seems dubious - just because I won't respond to mail
> for some period of time doesn't mean I don't want it to be sent to me.

If you don't implement the other features, this one provides a reasonable
escape hatch to the list owner. After 3 or 4 oof/notification messages in
a single day, flag the account.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

headers

ned+ietf-822 | 4 Jun 2002 22:09

RE: Sieve


> > > Keith is arguing that the decisions and permutations are too hard, and
> > > the Return-Path should be used.
> >
> > That would certainly be a reasonable position. It would seem that every
> > other argument has some kind of failing exception.

> If we have consensus on this, it'd be nice to do an I-D on it.  How to
> do Vacation correctly comes up about once a year.

We had a vacation draft for sieve that covered this but it expired. I'll see
if I can't get the author to resurrect it.

				Ned

headers

Florian Weimer | 4 Jun 2002 22:06

Re: Sieve

"Dan Wing" <dwing <at> cisco.com> writes:

> If we have consensus on this, it'd be nice to do an I-D on it.  How
> to do Vacation correctly comes up about once a year.

Yes, and the industry doesn't get it right. 

Such reference material could encourage customers to complain to their
vendors more loudly.

headers

Dave Crocker | 3 Jun 2002 18:31

Re: Choosing recipient of automatic replies

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

(Continue reading)

headers

Keith Moore | 3 Jun 2002 21:30

Re: Choosing recipient of automatic replies


> 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

(Continue reading)

headers

Lawrence Greenfield | 3 Jun 2002 19:58

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

headers

Keith Moore | 3 Jun 2002 15:10

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)

headers

Keith Moore | 3 Jun 2002 07:52

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)