"Duane D. Weaver" <[log in to unmask]> writes: > > When I receive mail stating that the userid is invalid or an unknown > user, I usually just delete the subscriber from the list. If the rejection > mail is due to an unknown host, I usually delete the rejection mail, and > wait to see if the same error occurs in a couple of days. Then I delete > the subscriber from the list. > > On a recent occasion, I deleted a group of users from the same site, > due to being inavlid userids. I later learned that the error message > was a in error as the rejection mail was caused by a fluke in their system. > > So what do you do? > Comments? Discussion? Well Since I have previously complained about behavior such as Duane's here on this list, I guess that I am obligated to offer some reflections. About 6 months ago after making a complaint I was challenged by Diane Kovacs ([log in to unmask]), owner of GOVDOC-L to see how "life really is" by taking over the ERRORS generated for GOVDOC-L. This list is rather large with 700-800 subscribers. Many subscribers are not directly on BITNET machines, but are rather gatewayed to other mail systems within their institutions. The list is moderated and runs 5-10 messages per day. I agreed to handle the error messages and did so until last week or so, when it seemed that the "experiment" had lasted long enough. Here are some thoughts about that experience: The messages that LISTSERV sends to ERRORS-TO are of several types: 1) messages intended for the list. The only case where I have seen this happen is when some brain damaged mailer software included all of the headers from some received mail into a submission to the list. 2) messages indicating that the user/id is invalid 3) messages indicating that the user is unable to receive mail currently. Usually this is due to some quota being placed on the amount of mail that can be waiting for a user at a particular time. 4) messages indicating that the host is invalid 5) other mail problems usually from the system which is host of the the LISTSERV. Now my first premise is that except for cases 1 & 5 which are relatively rare, the other cases can be simply routed to the bit bucket with little harm other than the fact that more messages continue to be generated. How serious the problem of routing the messages of classes 2-4 to the bit bucket probably is highly dependent on the tools available to the owner. I life on a Unix based system which has a reasonable MUA (elm), good response time, and my connection is either via telenet from a PC on my desk or via a high speed modem from a pc at my home. This means that just using my normal setup, I can easily deal with the error messages very quickly. Even when there are several hundred messages, it still only takes me 5 minutes to scan each one, determine that it is not a case 1 or 5, and discard it. I have lived on a heavily loaded CMS system and when you can go get a cup of coffee in the time it takes you to go from one message to the next you obviously need other tools to scan the error messages. It would be nice to have some tools to help you recognize how long error messages have been coming. I always waited until several working days had expired before doing anything about a particular subscriber. I had to rely on my memory for doing this, although I did save all error messages and could go back and review if I wanted to spend the time. When I decided to do something about an address, I would simply foward the error message to the postmaster at the site if it was a problem with a particular user id, or to the zone contact if it was an unknown host problem and I could not find a better address in the error message (using whois to find the technical contact). My experince about whether it was appropriate to remove a subscriber from a list or if it was a system problem differed considerably depending on the characteristics of the host. If it was a VM or VMS system directly on bitnet, in almost all cases, it was the appropriate action. On the other hand, if it was an internet site or gatewayed to a PC lan or other mail system then frequently it was not the correct thing to do. I think that this has to do with the difference between the system programmers for VM & VMS systems and system administrators for the other systems. While most Bitnet sites have been established for many years and have worked out good procedures for making certain that their systems kee handling mail correctly. System administrators for other systems are frequently single persons rather than being part of a group. The system administrators for other systems frequently are the only person with the responsibility, are less well trained, less experienced, may be doing it in addition to other responsibilities, and are working with software which is less well tested. In addition, many of these systems fuction without an operator to notice a malfunctioning system. In summary then, I think that frequently we do not have the tools available to do a good job of dealing with the error messages which a big, active list generates. Whether we expend effort to be gentle to users or summarily delete them from a list probably depends on how much effort we are willing to spend to be of service to the subscribers of a list. -phil -- J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 [log in to unmask] - Internet (314) 362-3617 [362-2694(FAX)] -- J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 [log in to unmask] - Internet (314) 362-3617 [362-2694(FAX)]