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