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
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
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.
On Tue, 3 Apr 2001, Keith Moore wrote:
Date: Tue, 03 Apr 2001 09:54:49 -0400
From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: James M Galvin <galvin(_at_)acm(_dot_)org>
Cc: Dan Wing <dwing(_at_)Cisco(_dot_)COM>, ietf-smtp(_at_)imc(_dot_)org
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:
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.