John Leslie wrote:
I claim this data supports my contention that folks don't _use_
the NDNs that they get.
I don't agree. I do agree that almost nobody uses or understands
the content of the NDNs they get.
Users apparently don't, despite considerable efforts to make the content more
comprehensible. (One of the product areas we are often to enhance is the
ability to return both DSNs and MDNs in an "appropriate" language. We routinely
see requests for additional language support - if memory serves Gallegan was a
recent one - as well as for improved ways to select the right language to use
out of the many we have available.)
However, I would guess that anywhere
from 2% to 10% of people use the *fact* that they received an NDN to take
further action. We deal with many unsophisticated users, and although they
have no clue what an NDN means, the receipt of one prompts them to contact
their helpdesk person or the intended recipient (if they can figure out
that much...)
And the helpdesk can ask to see the NDN, especially if it is one generated by
the user's own system. Given the vagarities of NDN formats in use it is too
much to expect even trained helpdesk personnel to decode arbitrary ones, but
teaching them what to look for in their local ones seems reasonable.
I don't deal directly with frontline support groups, but when frontline can't
figure it out and backline folks look and think it may indicate a problem with
the local mail system and contact the vendor, we frequently ask for, and often
are able to get, the entire NDN at issue in short order.
Getting back to the question, "properly report" involves, at the
minimum, logging the incident so that it's _possible_ to reconstruct
what happened. I'd like to suggest forwarding those log entries to
the client you received the message from, but I suspect that exceeds
our charter.
I think it should read something like this:
In either case, a formal handoff of responsibility for
the message occurs: the protocol requires that a server
MUST accept responsibility for either delivering a
message or properly reporting the failure to do so.
A proper failure report SHOULD consist of a notification sent
to the Return-Path of the original message. Where this is not
possible (because of a blank Return-Path) or not desirable
(because the Return-Path is untrusted for local policy
reasons), the server MUST record enough information for a
human operator to reconstruct the nature of the delivery
failure, the original Return-Path and the addresses of the
original recipients.
I fear, though, that may exceed the charter as you say.
I like this text as well but I'll defer to the powers-that-be to first
determine if it is in scope.
Ned