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.