On Wed, 10 Feb 1993 15:36:33 -0700 Gene V Glass said:
(text deleted...)
> It seems to be raining Error messages on me, now in the third year of
> our existence. I spend lots of time just deleteing the darned things.
(text deleted...)
> In short, what do you people do? Do you religiously sit there
> and do everybody's UNSUBBing for them?
I try to do something with every new delivery error I receive. And
while I've been flamed for the method I'm about to describe, I'm quite
happy with it, and have never received a complaint from a list member.
Some people feel that acting on one delivery error is "ogre-ish" but if
your list is very active I'd recommend doing so. Especially if you try
to contact the people involved explaining what you've done in addition
to suspending or deleting their subscription.
When I see a delivery error I look through it to decide if it's a
permanent error or something transient/temporary. If the error is
definitive and permanent, then I remove the person from the list. So,
errors like "no such user FOO on node XYZ" get foo@xyz removed from
the list immediately. Since it's possible (if highly unlikely) that
the mail software on XYZ is so broken that account FOO does exist, I
also prepend a form letter to an edited copy of the mail delivery
notice and send it to the user. This form letter contains instructions
for re-subscribing and also explains that they have been removed due
to my having received a mail delivery error from their system. If it
gets through, then the user knows what happened and can handle the
situation as they like. They can re-subscribe and/or complain to the
people responsible for their mail system.
For transient problems, like users that have exceeded their disk quota,
I send a form letter to the address that bounced the mail (in case the
problem has been resolved), and set the mailing list subscription to
NOMAIL. The form letter explains what has happened and details the
steps the user can take to restore his/her mailing list service.
If the error reported is ambiguous, uninformative, or undecipherable
then I handle it differently. I usually send mail to the postmaster
at the system that reported the delivery error with a CC'd copy to the
address that supposedly couldn't be reached. That form letter (which
is prepended to an edited copy of the delivery error, as in the other
cases), explains that the user's mailing list subscription has had
the NOMAIL option set, requests help in identifying the problem and
tells the user how to set the MAIL/DIGEST/INDEX flag to get their mail
flowing again. This informs the people that maintain the mail system
that there is a problem (which may be the first that they hear about
it). And if the letter gets through to the recipient, then the list
list member finds out what has happened and also is told how to put
things back to normal. So the note attempts to alert the postmaster
and also serves as a connectivity test to the address. One interesting
thing I found from experience is that it's better to send the note
explaining what's happened before setting the NOMAIL flag. That way,
if the user does get the mail, they see the explanation before the
note from LISTSERV about the NOMAIL flag being set. :)
Now, that's all well and good but you still have to figure out what
entry on the mailing list is causing the bounce. I've found that with
a bit of practice, and a copy of the mailing list handy, you can find
the culprit 99% if the time. For those cases where it's not clear
what the bouncing address is from the delivery error, I'd suggest
getting a copy of the list with the command, GET list-name ( NOLOCK
and searching for e-mail address(es) in the LIST file that match the
header-soup in the delivery error. Now there *will* be cases where
it's absolutely impossible to determine what address on the mailing
list is causing the error, but those are rare in my experience. If
that does happen, the most productive thing you can do it ask the
postmaster of the system that bounced the mail for help. I don't
have a form letter for that one :) since it only happens a couple
of time a year. And by the way, if you "GET" the list you'll see
all the concealed subscribers too. Just don't forget the "(NOLOCK"
option or people won't be able to issue commands to sub/unsub or
otherwise change the mailing list.
>GENE V GLASS ATGVG at ASUACAD.BITNET
>College of Education ATGVG at ASUACVAX.BITNET
>Arizona State University Internet Address:[log in to unmask]
>Tempe, AZ 85287-2411
>602-965-2692
-jj
PS - It still can take a lot of time to deal with busy mailing lists,
especially ones with unreliable mail connectivity or lots of short-term
accounts on the list. Also, Monday mornings can be hell too, since we
all know that if a large mail gateway is going to bust, it will do so
on Friday evening. :)
|