"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)]
|
