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