Re: Listserv issue ... something isn't right!

["Lisa M. Shreve" <lms@wwnet.com>]

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 <knaujok@pacbell.net>
> Subject: Fwd: NOTICE OF REMOVAL FROM eLISTS
> To: ebxml-stc <ebxml-stc@lists.ebxml.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