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. :)