[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Listserv issue ... something isn't right!
Klaus, This issues deserves serious attention. The method being used, clearly isn't working. I fully support a viable solution. lms Klaus-Dieter Naujok wrote: > On Mon, 31 Jul 2000 14:48:52 -0400, Lisa M. Shreve wrote: > > <SNIP> > > >Please take a moment to review this issue. I don't see this as a > >serious technical problem, to set up a simple database, keep count of > >the number of bounces, and when the number reaches some quantity of > >days, remove the person. ebXML cannot afford to remove participants so > >casually from our listserv's. As an organization, we have been around > >for almost a year now, listserv and website problems are reaching the > >point of being inexcusible. > > Lisa, > > I fully agree with you. I raised this issue in an earlier > message: > > Date: Tue, 18 Jul 2000 13:59:26 -0500 > From: Klaus-Dieter Naujok <email@example.com> > Subject: Fwd: NOTICE OF REMOVAL FROM eLISTS > To: ebxml-stc <firstname.lastname@example.org> > > The response from Karl was that it takes 2 out of 3 messages being > not delivered to trigger removal. > > Since I got no support at that time for the issue raised, I did > not continue with my objections. However, in support of Lisa's > valid concerns let me restate the problem with automatic removals. > > It does not work. > > Example, Karl did send out a announcement to all 9 public lists. > That day, hotmail.com had a problem for an hours, but because of > some hotmail users were on more than 3 lists the 9 delivery errors > caused them to be removed. If those messages had been send in a > more timely dispersed way, it would not have triggered a removal. > I could give more examples, such as ibm.com being down a few month > ago, had we had auto removal than, Bob would have been removed > without knowing it, but I am sure you got the point by now. > > My suggestion to deal with errors is still the same, based not > only on my experience, but those of other list administrator: > > 1. Collect all error messages in a single mail box or error list. > > 2. Sort the messages by error type. > > 3. Review the errors to determine is it really a bad address or a > temporally problem with the delivery, such as a gate way down, > mail box full, time out, etc. > > 4. If the error is truly a bad user idea or domain name, remove > the address. > > 5. Most organizations that have lists know the contact for a > particular member and using that information use other channels to > determine what the real problem is. I suggest we do something > similar in that we enquire via a special list (StC members as > members) if someone knows the user tied to the address to resolve > the issue. > > If you agree with the general idea of my suggestions please let me > know. I don't have to asked those that disagree to do so, since > they will. Hope we can agree to a way forward to ensure that our > members receive the mail they are expecting. > > Regards, > > Klaus > > -- > Klaus-Dieter Naujok NextERA Interactive > Antioch, CA USA +1.925.759.1670 > > PGP Finger: 6A4B 1683 CD99 E7BE F855 CC2F 4569 6BD8 76BD 1117
Powered by eList eXpress LLC