Subject: Re: vacation replies to From: or envelope from
From: Tim Showalter <[email-masked]>
To: "Dan Wing" <[email-masked]>
Cc: [email-masked]
Date: 03 Apr 2001 14:54:47 -0700
List-Id: <ietf-smtp.imc.org>

"Dan Wing" <[email-masked]> writes:

> > The problem is that nothing works in all cases. If not sending inappropriate
> > vacation notices is a top priority (and I think it should be), then a
> > combination of techniques is needed. And this is exactly what the
> > sieve vacation notice draft (draft-showalter-sieve-vacation-04.txt) does.
> > (It also requires that such notices be sent to the envelope from.)
> 
> The above I-D has expired, although I could find copies of it.
> 
> Tim, what is the status of draft-showalter-sieve-vacation?
> 
> <http://debian.ens-cachan.fr/ftp/mirror/RFC/internet-drafts/draft-showalter-si
> eve-vacation-04.txt.gz>

I want to check it over for errors, then submit and last call it.
I didn't intend to have it expire.

Tim

Date: Tue, 03 Apr 2001 13:38:18 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

Yes across the board but it doesn't change what I think about vacation
notices, which is the real issue.

For me, there is a value judgement associated with a vacation notice
(and my other suggestions) that is not present with MDNs as currently
defined.  The current definition is careful not to make value judgements
about messages, in particular, did the user think this message was
important.  It strictly addresses issues at the extreme edge of
delivery, which arguably are user agent/user issues.

A vacation notice is an indication that the message is important,
insofar as current usage is to tell you when I am going to get to the
message or if you think your message is important and can not wait
here's someone else to contact.  This is perhaps an extension of
"processed" but is certainly different than processed as defined.

The same is true of rejected and forwarded as I have suggested them.
Rejected is not deleted because with rejected I'm making a value
judgement and I want you to know it; I do not want your message.
Otherwise you're likely to find another way to reach me.

Similarly with forwarded.  It's more than just dispatched.  It's telling
you I want you to use the new address.

All of these are very definitely user actions and cover circumstances
beyond whether or not a message reached the message store.

Sieve is probably the answer; oh heck, it's the best answer I've seen
excepting some additional MDNs.

Jim

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, <[email-masked]>, "James M Galvin" <[email-masked]>
Subject: RE: vacation replies to From: or envelope from
Date: Tue, 3 Apr 2001 10:09:37 -0700
Importance: Normal
Sender: [email-masked]

> The problem is that nothing works in all cases. If not sending inappropriate
> vacation notices is a top priority (and I think it should be), then a
> combination of techniques is needed. And this is exactly what the
> sieve vacation notice draft (draft-showalter-sieve-vacation-04.txt) does.
> (It also requires that such notices be sent to the envelope from.)

The above I-D has expired, although I could find copies of it.

Tim, what is the status of draft-showalter-sieve-vacation?

<http://debian.ens-cachan.fr/ftp/mirror/RFC/internet-drafts/draft-showalter-si
eve-vacation-04.txt.gz>

-d

From: Keith Moore <[email-masked]>
To: James M Galvin <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: vacation replies to From: or envelope from 
Date: Tue, 03 Apr 2001 12:19:37 -0400
Sender: [email-masked]

>     I am mostly in agreement with the above.  But the standard for MDNs
>     also specifies that the notification must go to the return-path address
>     *if it is automatically generated* (which vacation notices are).
> 
> This may have been your intent but the documents do not say this.  

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]).  In this case, confirmation
   from the user SHOULD be obtained, if possible.  If obtaining consent
   is not possible (e.g., because the user is not online at the time),
   then an MDN SHOULD NOT be sent.

(okay, it's a "SHOULD", not a "must".  but the intent is clear.)

Keith

Date: Tue, 03 Apr 2001 12:18:12 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

    I am mostly in agreement with the above.  But the standard for MDNs
    also specifies that the notification must go to the return-path address
    *if it is automatically generated* (which vacation notices are).

This may have been your intent but the documents do not say this.  1894
is quite clear about sending the MDN to the envelope from but there is
no other restriction.  I would further argue that except for a few
ambiguous references to a user agent, 1894 and its siblings refer to MTA
activities.

    If we were to standardize a format for vacation notices, seems like
    we'd make them an extension of MDNs, and we'd want their behavior to
    be consistent with MDNs.

Consistent does not mean the same.  I stand firm on the architectural
principle that a vacation notice is a user agent feature
(notwithstanding certain implementation preferences).  The MTA is
responsible for routing and delivery to a message store.  It is not
responsible for the behavior of a user or specific user preferences with
respect to that delivery (again, notwithstanding certain implementation
preferences).

You and I may have to agree to disagree on this point.  We'll have to
wait until we create a "user agent MDN standard" to see which is in the
minority.

Jim

From: [email-masked]
Date: Tue, 03 Apr 2001 08:46:43 -0700 (PDT)
Subject: Re: vacation replies to From: or envelope from
To: James M Galvin <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

> While I accept your point of view as valid, let me say more about why I
> don't agree with it.

> The issue, as I see it, is being clear about when a message has been
> delivered and at what point in the infrastructure we are taking action.

> The standards that define how to use DNSs today all speak to the status
> of getting a message to its message store.  A message is considered
> delivered if it gets there and it is the MTA that is responsible for all
> the action.

> Vacation notices, in my opinion, are a user agent issue.  The fact that
> an MTA is executing the "vacation" program on behalf of a user or their
> agent does not change the fact that the "delivery has been completed"
> and the MTA responsibility has at least conceptually ended.  Once you
> cross that line the envelope information is not what's important, it is
> the message information that is important.

If this were the case then it would be OK to simply drop envelope information
as part of the delivery process, or at most place it in a field that's clearly
trace information only. But it isn't -- in particular, the envelope from is
made available via the return-path field.

> What we need are user agent DSNs to be defined, to make the distinction
> between MTA delivery status and user delivery status absolutely clear.

This has already been done. We call them MDNs, and they are defined in RFC
2298. I agree that user agents should generate MDNs and not DSNs. You will also
note that MDNs are supposed to be sent to the disposition-notification-to
field, which begins life as a copy of the envelope from, not the header from
field.

Unfortunately there's a loophole in RFC 2298: It allows MDNs to be sent when no
disposition-notification-to field is present but in this case doesn't say where
they should be sent to. However, given where disposition-notification-to comes
from using an envelope from in this case would seem like the logical thing to
do.

> Here's my short-list of suggestions for such statuses (there are others
> but this is a short-list):

>     rejected - could have been delivered but user doesn't want your
>     message; reason may or may not be stated

Careful here. You're talking about delivery, which is an MTA event. A devliery
failure requires a DSN.

I believe the event you are trying to describe is where the message is deleted
without being read or otherwise acted upon. This corresponds to the "deleted"
MDN type.

>     forwarded - user has chosen to redirect their email to some other
>     address and wants you to know

This corresponds to the "dispatched" MDN type.

>     unavailable - the generic of vacation; it means a message will not
>     be read before a certain date but does not speak to whether a
>     message will actually ever be read

There is presently no MDN type of this sort. We debated adding one at the
time RFC 2298 was written, but it was felt that dealing with the vacation
problem was a bit too much at the time.

> In each of these cases there would be no MTA DSN, because the final MTA
> completed its job.

Or alternately, there would be a "delivered" DSN.

> It is the user that is taking some action in these
> cases.  Thus, I think it is wrong to respond to the envelope from
> because that information is, in principle, unavailable to the user
> agent.

Actually, it isn't clear that the _user_ is taking action, rather that action
is being taken by the user or an agent of the user.

> For completeness, I agree as a practical matter that checking only the
> To: and Cc: header is insufficient, and not because mailing list
> behavior lacks standards.  Even with standards there would be lists that
> would put explicit email addresses in the message headers; the reason is
> for personalization.  Individuals will always have to account for these
> when configuring their "vacation notices", unless we could get a
> standard accepted that says that only one-way mailing lists may put
> explicit email addresses in the message headers.  There is one mailing
> list technology provider who would not like this.

The problem is that nothing works in all cases. If not sending inappropriate
vacation notices is a top priority (and I think it should be), then a
combination of techniques is needed. And this is exactly what the
sieve vacation notice draft (draft-showalter-sieve-vacation-04.txt) does.
(It also requires that such notices be sent to the envelope from.)

				Ned

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "James M Galvin" <[email-masked]>, "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: vacation replies to From: or envelope from 
Date: Tue, 03 Apr 2001 11:42:27 -0400
Sender: [email-masked]

> I disagree that a vacation autoresponder is a user agent function.  It is a
> function performed for the user, yes.
> 
> But the function should be performed by the user's MTA (or mail storage agent,
> whichever term you prefer).  If the vacation notice is sent by the user's MUA,
> and the user's MUA is on a PC, it is likely that the user's PC won't be turned
> on while the user is "on vacation".  It seems the function has to be done by
> the MTA.

whether this is a user agent function depends on whether you think of
the message store as part of the user agent or part of the mail delivery
system or a separate piece.  and what you think about this is probably 
influenced by the architecture of the mail systems with which you are 
most familiar.  if you deliver to an MS that has its own access protocols,
you might well think of it as part of an MTS; if you deliver mail to a 
file or directory that uses normal file-system access protocols and 
implement vacation via an on-delivery-hook (similar to .forward) then
you probably think of it as a UA function.

but for the purpose of this discussion I don't think it matters whether 
the message store is part of the UA or part of the MTS - in either case
you want vacation notices to go to the same place as other kinds of
notifications (DSNs and automatically-generated MDNs) 

Keith

From: "Dan Wing" <[email-masked]>
To: "James M Galvin" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: vacation replies to From: or envelope from
Date: Tue, 3 Apr 2001 08:26:47 -0700
Importance: Normal
Sender: [email-masked]

I disagree that a vacation autoresponder is a user agent function.  It is a
function performed for the user, yes.

But the function should be performed by the user's MTA (or mail storage agent,
whichever term you prefer).  If the vacation notice is sent by the user's MUA,
and the user's MUA is on a PC, it is likely that the user's PC won't be turned
on while the user is "on vacation".  It seems the function has to be done by
the MTA.

-d

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of James M Galvin
> Sent: Tuesday, April 03, 2001 8:03 AM
> To: Keith Moore
> Cc: [email-masked]
> Subject: Re: vacation replies to From: or envelope from
>
>
> While I accept your point of view as valid, let me say more about why I
> don't agree with it.
>
> The issue, as I see it, is being clear about when a message has been
> delivered and at what point in the infrastructure we are taking action.
>
> The standards that define how to use DNSs today all speak to the status
> of getting a message to its message store.  A message is considered
> delivered if it gets there and it is the MTA that is responsible for all
> the action.
>
> Vacation notices, in my opinion, are a user agent issue.  The fact that
> an MTA is executing the "vacation" program on behalf of a user or their
> agent does not change the fact that the "delivery has been completed"
> and the MTA responsibility has at least conceptually ended.  Once you
> cross that line the envelope information is not what's important, it is
> the message information that is important.
>
> What we need are user agent DSNs to be defined, to make the distinction
> between MTA delivery status and user delivery status absolutely clear.
> Here's my short-list of suggestions for such statuses (there are others
> but this is a short-list):
>
>     rejected - could have been delivered but user doesn't want your
>     message; reason may or may not be stated
>
>     forwarded - user has chosen to redirect their email to some other
>     address and wants you to know
>
>     unavailable - the generic of vacation; it means a message will not
>     be read before a certain date but does not speak to whether a
>     message will actually ever be read
>
> In each of these cases there would be no MTA DSN, because the final MTA
> completed its job.  It is the user that is taking some action in these
> cases.  Thus, I think it is wrong to respond to the envelope from
> because that information is, in principle, unavailable to the user
> agent.
>
> For completeness, I agree as a practical matter that checking only the
> To: and Cc: header is insufficient, and not because mailing list
> behavior lacks standards.  Even with standards there would be lists that
> would put explicit email addresses in the message headers; the reason is
> for personalization.  Individuals will always have to account for these
> when configuring their "vacation notices", unless we could get a
> standard accepted that says that only one-way mailing lists may put
> explicit email addresses in the message headers.  There is one mailing
> list technology provider who would not like this.
>
> Jim
>
>
>
>
>
> On Tue, 3 Apr 2001, Keith Moore wrote:
>
>     Date: Tue, 03 Apr 2001 09:54:49 -0400
>     From: Keith Moore <[email-masked]>
>     To: James M Galvin <[email-masked]>
>     Cc: Dan Wing <[email-masked]>, [email-masked]
>     Subject: Re: vacation replies to From: or envelope from
>
>     > Personally, I agree with the choice of responding to the message From:
>     > header as opposed to the envelope from.  The message From:
> header is the
>     > author of the content of the message and if that content is
> "urgent" in
>     > any way, I would want that person to know I am not being timely.
>
>     I am of the opposite opinion.  Vacation notices should go to the same
>     place as nondelivery reports and automatically-generated delivery
>     notifications - which is to say the envelope return address.
>     If the author of the message wants to get notifications about whether
>     and when a message will delivered or read, the standard mechanisms
>     for this all require that the author's address be in the envelope
>     return address. I see no reason why vacation notices should not follow
>     this well-established practice.
>
>     > In any case, I don't think the primary issue is where to respond but
>     > rather when to respond.  A response should only be created when the
>     > address of the recipient appears in either the message To: or Cc:
>     > header.
>
>     I agree that this is a useful heuristic, though I don't think it's
>     sufficient by itself.
>
>     > Of course, either set of rules means that certain mailing list softare
>     > habits are, shall we say, unorthodox.  I am often confounded by which
>     > set of rules is really the lesser of two evils, since at this point
>     > neither is a clear winner.
>
>     part of the problem is that very little about list behavior is
>     standardized, so we get a wide variation in behavior from one list
>     to another.  for instance, far too many lists fail to rewrite
>     return-path and gratuitously rewrite a half-dozen other headers.
>
>     in the past efforts to alleviate this problem have been hampered
>     because each author of list software truly believed that his way
>     was the One True Way.    but who knows, maybe the world is saner now.
>
>     Keith
>
>

From: Keith Moore <[email-masked]>
To: James M Galvin <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: vacation replies to From: or envelope from 
Date: Tue, 03 Apr 2001 11:17:19 -0400
Sender: [email-masked]

> While I accept your point of view as valid, let me say more about why I
> don't agree with it.
> 
> The issue, as I see it, is being clear about when a message has been
> delivered and at what point in the infrastructure we are taking action.
> 
> The standards that define how to use DNSs today all speak to the status
> of getting a message to its message store.  A message is considered
> delivered if it gets there and it is the MTA that is responsible for all
> the action.
> 
> Vacation notices, in my opinion, are a user agent issue.  The fact that
> an MTA is executing the "vacation" program on behalf of a user or their
> agent does not change the fact that the "delivery has been completed"
> and the MTA responsibility has at least conceptually ended.  Once you
> cross that line the envelope information is not what's important, it is
> the message information that is important.

I am mostly in agreement with the above.  But the standard for MDNs
also specifies that the notification must go to the return-path address
*if it is automatically generated* (which vacation notices are).

If we were to standardize a format for vacation notices, seems like
we'd make them an extension of MDNs, and we'd want their behavior to
be consistent with MDNs.
 
> What we need are user agent DSNs to be defined, to make the distinction
> between MTA delivery status and user delivery status absolutely clear.
> Here's my short-list of suggestions for such statuses (there are others
> but this is a short-list):
> 
>     rejected - could have been delivered but user doesn't want your
>     message; reason may or may not be stated
> 
>     forwarded - user has chosen to redirect their email to some other
>     address and wants you to know
> 
>     unavailable - the generic of vacation; it means a message will not
>     be read before a certain date but does not speak to whether a
>     message will actually ever be read

these could be new disposition-types if the existing ones were not
deemed to be sufficient. 

> In each of these cases there would be no MTA DSN, because the final MTA
> completed its job.  It is the user that is taking some action in these
> cases.  Thus, I think it is wrong to respond to the envelope from
> because that information is, in principle, unavailable to the user
> agent.

Actually, it's contained in the Return-Path field, and Return-Path
is required by the standards.

> For completeness, I agree as a practical matter that checking only the
> To: and Cc: header is insufficient, and not because mailing list
> behavior lacks standards.  Even with standards there would be lists that
> would put explicit email addresses in the message headers; the reason is
> for personalization.  Individuals will always have to account for these
> when configuring their "vacation notices", unless we could get a
> standard accepted that says that only one-way mailing lists may put
> explicit email addresses in the message headers.  

right.  that's certainly one of the reasons.

> There is one mailing
> list technology provider who would not like this.

there's always one :)

but in previous discussions about mailing list behavior, one thing
has been clear - even though we'd benefit if various things that we 
think of public mailing lists behaved more uniformly, it's not
reasonable to impose a lot of contraints on every kind of bulk mail.
there are always reasonable exceptions to those rules (even if 
the unreasonable ones far outnumber them)

Keith

Date: Tue, 03 Apr 2001 11:02:45 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

While I accept your point of view as valid, let me say more about why I
don't agree with it.

The issue, as I see it, is being clear about when a message has been
delivered and at what point in the infrastructure we are taking action.

The standards that define how to use DNSs today all speak to the status
of getting a message to its message store.  A message is considered
delivered if it gets there and it is the MTA that is responsible for all
the action.

Vacation notices, in my opinion, are a user agent issue.  The fact that
an MTA is executing the "vacation" program on behalf of a user or their
agent does not change the fact that the "delivery has been completed"
and the MTA responsibility has at least conceptually ended.  Once you
cross that line the envelope information is not what's important, it is
the message information that is important.

What we need are user agent DSNs to be defined, to make the distinction
between MTA delivery status and user delivery status absolutely clear.
Here's my short-list of suggestions for such statuses (there are others
but this is a short-list):

    rejected - could have been delivered but user doesn't want your
    message; reason may or may not be stated

    forwarded - user has chosen to redirect their email to some other
    address and wants you to know

    unavailable - the generic of vacation; it means a message will not
    be read before a certain date but does not speak to whether a
    message will actually ever be read

In each of these cases there would be no MTA DSN, because the final MTA
completed its job.  It is the user that is taking some action in these
cases.  Thus, I think it is wrong to respond to the envelope from
because that information is, in principle, unavailable to the user
agent.

For completeness, I agree as a practical matter that checking only the
To: and Cc: header is insufficient, and not because mailing list
behavior lacks standards.  Even with standards there would be lists that
would put explicit email addresses in the message headers; the reason is
for personalization.  Individuals will always have to account for these
when configuring their "vacation notices", unless we could get a
standard accepted that says that only one-way mailing lists may put
explicit email addresses in the message headers.  There is one mailing
list technology provider who would not like this.

Jim

On Tue, 3 Apr 2001, Keith Moore wrote:

    Date: Tue, 03 Apr 2001 09:54:49 -0400
    From: Keith Moore <[email-masked]>
    To: James M Galvin <[email-masked]>
    Cc: Dan Wing <[email-masked]>, [email-masked]
    Subject: Re: vacation replies to From: or envelope from
    
    > Personally, I agree with the choice of responding to the message From:
    > header as opposed to the envelope from.  The message From: header is the
    > author of the content of the message and if that content is "urgent" in
    > any way, I would want that person to know I am not being timely.
    
    I am of the opposite opinion.  Vacation notices should go to the same
    place as nondelivery reports and automatically-generated delivery 
    notifications - which is to say the envelope return address.
    If the author of the message wants to get notifications about whether
    and when a message will delivered or read, the standard mechanisms
    for this all require that the author's address be in the envelope 
    return address. I see no reason why vacation notices should not follow 
    this well-established practice.
    
    > In any case, I don't think the primary issue is where to respond but
    > rather when to respond.  A response should only be created when the
    > address of the recipient appears in either the message To: or Cc:
    > header.
    
    I agree that this is a useful heuristic, though I don't think it's
    sufficient by itself.
    
    > Of course, either set of rules means that certain mailing list softare
    > habits are, shall we say, unorthodox.  I am often confounded by which
    > set of rules is really the lesser of two evils, since at this point
    > neither is a clear winner.
    
    part of the problem is that very little about list behavior is 
    standardized, so we get a wide variation in behavior from one list 
    to another.  for instance, far too many lists fail to rewrite 
    return-path and gratuitously rewrite a half-dozen other headers.
    
    in the past efforts to alleviate this problem have been hampered 
    because each author of list software truly believed that his way 
    was the One True Way.    but who knows, maybe the world is saner now.
    
    Keith

Date: 	Tue, 3 Apr 2001 17:37:33 +0300
From: Matti Aarnio <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: vacation replies to From: or envelope from
Sender: [email-masked]

On Tue, Apr 03, 2001 at 09:54:49AM -0400, Keith Moore wrote:
> Propably  James M Galvin <[email-masked]>   wrote:
> > Personally, I agree with the choice of responding to the message From:
> > header as opposed to the envelope from.  The message From: header is the
> > author of the content of the message and if that content is "urgent" in
> > any way, I would want that person to know I am not being timely.
> 
> I am of the opposite opinion.  Vacation notices should go to the same
> place as nondelivery reports and automatically-generated delivery 
> notifications - which is to say the envelope return address.
> If the author of the message wants to get notifications about whether
> and when a message will delivered or read, the standard mechanisms
> for this all require that the author's address be in the envelope 
> return address. I see no reason why vacation notices should not follow 
> this well-established practice.

	Indeed.   It is a great nuisance to send something to
	a mailing-list and receive heaps of "autoresponding email"
	(or whatever it calls itself this week) that person XYZ
	is away now.

	With listmanager hat on, I would probably remove such
	recipients which bounce to list-owner address with
	vacation.  As a list-subscriber I definitely don't
	want kwazillion notifications that some people have
	vacation.  (And having had this situation, we *have*
	removed people who are complained about running that
	kind of M$ "vacation")

	For various reasons relating to corporate security
	I myself never run vacation, less "paranoid" people do...

> > In any case, I don't think the primary issue is where to respond but
> > rather when to respond.  A response should only be created when the
> > address of the recipient appears in either the message To: or Cc:
> > header.
> 
> I agree that this is a useful heuristic, though I don't think it's
> sufficient by itself.

	"vacation" responding when the message reaches one of five
	addresses I have, but not when To: or Cc: doesn't list
	any of them..  Yes, neat heuristic, and often ok.
	List traversing does not (usually) alter those two header
	types.  (Check also Resent-To: and Resent-Cc:)

	Adding also rate limiting, e.g. only one message per destination
	address per 24 hours, now that would be neat thing for most
	M$ environment vacation features -- UNIX has had that since
	day 2 (BSD + sendmail + vacation), so it is nothing new.

> > Of course, either set of rules means that certain mailing list softare
> > habits are, shall we say, unorthodox.  I am often confounded by which
> > set of rules is really the lesser of two evils, since at this point
> > neither is a clear winner.
> 
> part of the problem is that very little about list behavior is 
> standardized, so we get a wide variation in behavior from one list 
> to another.  for instance, far too many lists fail to rewrite 
> return-path and gratuitously rewrite a half-dozen other headers.
> 
> in the past efforts to alleviate this problem have been hampered 
> because each author of list software truly believed that his way 
> was the One True Way.    but who knows, maybe the world is saner now.

	And Keith is idealist  ;-)

	It would be nice if there could be some agreenment on
	how list systems should manage headers (and envelopes),
	but that is unlikely with existence of opposite schools
	of thought at

		"send individually tailored transfer envelope and
		visible headers to each recipient",
	vs.
		"minimize the number of sent messages by sending
		to all recipients at same domain(*) with multiple
		RCPT TO envelopes for the message"

	The first one tries to ensure that bounce message will
	get properly automatically processed -- with recipient
	recognition at reliable levels.  Simultaneously it will
	maximize network resource usage.

	The second one tries to minimize network resource usage
	(and is what RFC 821 / 1123 / DRUMS try to encourage.)

> Keith

-- 
/Matti Aarnio	<[email-masked]>

From: Keith Moore <[email-masked]>
To: James M Galvin <[email-masked]>
cc: Dan Wing <[email-masked]>, [email-masked]
Subject: Re: vacation replies to From: or envelope from 
Date: Tue, 03 Apr 2001 09:54:49 -0400
Sender: [email-masked]

> Personally, I agree with the choice of responding to the message From:
> header as opposed to the envelope from.  The message From: header is the
> author of the content of the message and if that content is "urgent" in
> any way, I would want that person to know I am not being timely.

I am of the opposite opinion.  Vacation notices should go to the same
place as nondelivery reports and automatically-generated delivery 
notifications - which is to say the envelope return address.
If the author of the message wants to get notifications about whether
and when a message will delivered or read, the standard mechanisms
for this all require that the author's address be in the envelope 
return address. I see no reason why vacation notices should not follow 
this well-established practice.

> In any case, I don't think the primary issue is where to respond but
> rather when to respond.  A response should only be created when the
> address of the recipient appears in either the message To: or Cc:
> header.

I agree that this is a useful heuristic, though I don't think it's
sufficient by itself.

> Of course, either set of rules means that certain mailing list softare
> habits are, shall we say, unorthodox.  I am often confounded by which
> set of rules is really the lesser of two evils, since at this point
> neither is a clear winner.

part of the problem is that very little about list behavior is 
standardized, so we get a wide variation in behavior from one list 
to another.  for instance, far too many lists fail to rewrite 
return-path and gratuitously rewrite a half-dozen other headers.

in the past efforts to alleviate this problem have been hampered 
because each author of list software truly believed that his way 
was the One True Way.    but who knows, maybe the world is saner now.

Keith

Date: Tue, 03 Apr 2001 09:06:00 -0400 (EDT)
From: James M Galvin <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
To: Dan Wing <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

There is no such citation of which I am aware.

Personally, I agree with the choice of responding to the message From:
header as opposed to the envelope from.  The message From: header is the
author of the content of the message and if that content is "urgent" in
any way, I would want that person to know I am not being timely.

In any case, I don't think the primary issue is where to respond but
rather when to respond.  A response should only be created when the
address of the recipient appears in either the message To: or Cc:
header.

Of course, either set of rules means that certain mailing list softare
habits are, shall we say, unorthodox.  I am often confounded by which
set of rules is really the lesser of two evils, since at this point
neither is a clear winner.

Jim

On Mon, 2 Apr 2001, Dan Wing wrote:

    Date: Mon, 02 Apr 2001 16:19:25 -0700
    From: Dan Wing <[email-masked]>
    To: [email-masked]
    Subject: vacation replies to From: or envelope from
    
    Our IT group here has recently installed a product which supports a
    vacation-like feature, but it replies to the From: field instead of the
    envelope from (MAIL FROM).
    
    Does anyone know of a cite for recommended behavior with autoreply
    vacation-like programs.  I checked several RFCs I expected to have such a
    cite, but couldn't find anything authoritative.
    
    Thanks.
    -Dan Wing

Date: Tue, 3 Apr 2001 10:57:56 WET DST
From: Johnny Eriksson <[email-masked]>
To: <[email-masked]>
Subject: Re: vacation replies to From: or envelope from
Sender: [email-masked]

"Dan Wing" <[email-masked]> wrote:

> Our IT group here has recently installed a product which supports a
> vacation-like feature, but it replies to the From: field instead of the
> envelope from (MAIL FROM).
> 
> Does anyone know of a cite for recommended behavior with autoreply
> vacation-like programs.  I checked several RFCs I expected to have such a
> cite, but couldn't find anything authoritative.

The recommended behavior is to repeatedly kick said IT group in the groin
until the install something that replys to the envelope from.

> Thanks.
> -Dan Wing

--Johnny

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Subject: vacation replies to From: or envelope from
Date: Mon, 2 Apr 2001 16:19:25 -0700
Importance: Normal
Sender: [email-masked]

Our IT group here has recently installed a product which supports a
vacation-like feature, but it replies to the From: field instead of the
envelope from (MAIL FROM).

Does anyone know of a cite for recommended behavior with autoreply
vacation-like programs.  I checked several RFCs I expected to have such a
cite, but couldn't find anything authoritative.

Thanks.
-Dan Wing