Some people like to have acknowledgements of successful delivery, and some
people do not.  Others like to hear about the problems and still others do
not.  We each have our own preferences, and it is nice that LISTSERV is
able to do what we want to a great extent.
 
Many of the messages received, however, are not generated by LISTSERV but
are generated by the various mail transport programs around the various
networks.  The most annoying of these messages are the ones that indicate
that the problem is the fault of the receiving user or of the receiving
system itself.  Another category is the user who is no longer there.
 
One message I have received from many places informs me that the DEVICE
NAME is invalid.  My practice when receiving such mail is to forward it
right back to the postmaster of that node, asking them to correct the
device name that was invalid.
 
For all kinds of mail rejection notices, there are various destinations that
are the proper places for each to go.
 
1.  Notices about users no longer being on the system should go to the owner
    of the list, who can delete them.  These should NEVER go to contributors.
 
2.  Notices about a disk or mail-file quota being full should go to a person
    designated AT THAT NODE ONLY and not to ANY destination on the network.
    That is a problem only correctable there, so it should stay there.
 
3.  Notices about a system related delivery failure should always go to the
    systems programmer responsible for the node where the failure occured.
 
4.  Messages about invalid headers should always go back to the source of
    those invalid headers, the best that can be determined.  Of course
    LISTSERV helps by filtering off non-RFC822.  Still, many mail transport
    programs cannot accept certain formations, such as quoted strings
    continued across multiple lines.
 
We should look at the problem of getting the mail programs around the world
to deliver their rejection notices to the proper destination where it is most
applicable for the message it contains.  LISTSERV is for the most problem,
just an innocent participant in the network.  Little bugs exist, but more of
what I get cannot be easily fixed by LISTSERV, although they perhaps can be
compensated for by hacking on LISTSERV; a practice I want to discourage.