[Top] [All Lists]

Re: vacation replies to From: or envelope from

2001-04-03 09:14:26
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

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

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

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