At 10:30 AM 5/8/2001 -0400, James M Galvin wrote:
>On Mon, 7 May 2001, Nick Simicich wrote:
> We may have to disagree on this one. The way I read the standard, MDNs
> first have to be requested with a Disposition-notification-to header.
> Vacation notices are sent unsolicited, and as such, do not have a
> disposition-notification-to style target, and thus the genesis of this
> discussion, "where do we send the vacation notices"?
>Interesting point. Now that you mention it, I can see how the spec
>could be read to mean that MDNs are only generated upon request, given
>the opening sentence in Section 2. Of course, that fits with all the
>keywords currently defined.
Actually, my belief was based on my reading that standard and finding no
indication that any MDN could be sent to any address that was not in a
"Disposition-notification-to" header. There was, as you mentioned below,
the indication that certain mismatches could stop the notifications from
being sent automatically. But there seemed to be no provision for applying
the standard to any non-requested MDN.
The standard basically says, "There is this header, and this is how you
respond when this header does exist".
>Personally, I've never been stuck on that point. In addition, the
>specification is intended to be extensible and any conversations I've
>had about vacation notices always revolved around MDNs, so I don't think
>that's a requirement one should expect to survive forever.
I agree that the standard is intended to be extensible, the standard says
so clearly. However, it was my opinion that the extensibility was to such
things as extra keywords, ignoring keywords for which you have no
provisioning so that you could use an older version of an MDN responder
with a disposition-notification-to header with new keywords, and the
description of X- keywords within the header and the scheme for insuring
that X- keywords did not clash and the provision for registering and
describing new keywords.
The use of MDNs when no MDN was requested is, in my opinion, a departure
from the standard rather than an extension of the standard. In fact, it
violates the standard, because the Disposition-notification-to header is
used to control whether the MDN is generated, and the way that MDN loops
are prevented is to state that an MDN can never have a
Disposition-notification-to header, so that an MDN is never generated in
response to an MDN. Generating an MDN when no MDN was requested breaks
this loop control method in a way that is orthogonal to and incompatible
with the original loop control method.
Now, if you want to say that the right thing to do with vacation is to only
respond when there is a Disposition-notification-to: header with the
sub-keyword "absense-report-to:" I'd say, Hurray, a blight on the net ends!
and support you completely. In that case, MDN is clearly on point, and I
wish this had been the case since day 1 of RFC 822. But it is unlikely
that people will accept that the important news that they are out of the
office should only be reported to those who say that they want to know
that, and therefore they will continue to tell, all and sundry,
willy-nilly, that they are out of town and that it is the right day to
break into their house. :-) Therefore, either a new standard or a standard
that describes how to generate unsolicited reports seems on point.
I'm going to strongly disagree that this particular standard could be
logically extended in the direction of unsolicited reports.
> Now, I don't *really* think that DSN or MDN applies to vacation notices.
> But Vacation notices are closer to DSN than to MDN since they may be sent
> unsolicited, and I think that, in the absense of other guidance, they
> should be sent to the transport envelope address and not the from or
> reply-to address.
>It is worth noting that DSNs are for MTAs and MDNs are for UAs. Since
>vacation notices are generated by UAs on behalf of users, I think we'll
>find that the email technical community considers them closer to MDNs,
>not DSNs, irrespective of your solicited versus unsolicited distinction.
I'm going to have to disagree here again. Quoting from 1894 again,
regarding the purposes of DSN:
94>The DSNs defined in this memo are expected to serve several purposes:
94>(a) Inform human beings of the status of message delivery processing,
94>as well as the reasons for any delivery problems or outright failures,
94>in a manner which is largely independent of human language;
Now, they go on to talk about allowing MTAs to track messages and mailing
lists to track messages, but the first mentioned purpose is to report
failures to human beings. However, I'm going to go out on a limb here and
say that a "vacation" notice is clearly a notice to a human being of
"delayed delivery" (another quote from 1894). Thus, vacation does seem to
fit loosely into DSN and not at all into MDN. The main reason that
vacation does not fit into DSN is because DSN seems to be intended for use
by MTAs rather than MUAs, but in those cases (Lotus Notes, for example)
where the DSN is generated by the MTA on user instruction rather than the
MUA, I think that the DSN could apply.
> Now if you think that DSN applies to vacation notices, I will bring this
> quote from 1894 up: ...
>As far as DSNs requiring the use of the MAIL FROM address in the SMTP
>transaction, so do MDNs, currently. That's what's in the Return-Path:
>header. More specifically, the MDN should not be automatically
>generated unless the address requesting the notification matches the
>Return-Path:; the generation should be confirmed with a user.
And which does serve to amplify the first point I was trying to make, that
the envelope address, however preserved to the MUA, is the preferred
address for any sort of automated notification, whereas other header
addresses should be used when manual responses are generated.
Why is this applicable to list managers? My logic is that if you are not
parsing your responses to your envelope address but are assuming that they
are all failure notifications, you are doing the wrong thing. That said, I
do the wrong thing - if I get a response I can't parse, I switch the list
into VERP mode and remove people (or switch them to digest) on the second
bounce. But this is probably reasonable, and an unfortunate fact of life.
We will fight for bovine freedom, And hold our large heads high.
We will run free, with the buffalo or die! Cows with Guns.
- Dana Lyons, Cows With Guns
Nick Simicich mailto:njs @
http://scifi.squawk.com/njs.html -- Stop by and Light Up The World!