Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Bounced message from Colin Mick <ckm@xxxxxxxxxxxxx>

Hi Colin,

In response to a number of complaints I received about the volume of 'subscribe'
and 'unsubscribe' messages sent mistakenly to the reflector (instead of
majordomo@xxxxxxxxxxxxxxxxxx as they should be) I turned on the reflector
configuration option 'administrivia'. This option means that the reflector will
divert any e-mails it thinks are administrative requests, such as messages that
appear to be 'subscribe' or 'unsubscribe' requests, to the list owner rather
than to the reflector. The only problem is the algorithm it uses to determine if
a message is an administrative message. Words this algorithm makes 'taboo'
include the word 'subscribe' or 'unsubscribe' anywhere within the first 10
lines. Also 'taboo' is a new line within the first 10 lines starting with the
word 'get' followed by one word followed by a carrage return as this could
indicate an administrative 'get' request. It was this that caught you out, you
happened to have a new line start with the word 'get' followed by one word (in
your case it was 'get worse.<CR>') within the first 10 lines.

Now I have had the reflector with this option turned on for a few weeks now and
it certainly has worked well with several 'subscribe' and 'unsubscribe' requests
diverted to me. I was even remarking to somebody yesterday in an e-mail how well
this option was working with lots of correctly intercepted 'subscribe' messages
and not as single false positive. Well, I spoke too soon didn't I.

What I am gong to do now is work with the IEEE office and see if I can get the
list of 'taboo' words changed to just 'subscribe' and 'unsubscribe' as I believe
any other type of administrative type of request being incorrectly sent to the
reflector is rare. The only question is can we have this configuration just for
this 802.3ae reflector or would the change impact all reflectors. Now
unfortunately this one is a balance between 'subscribe' or 'unsubscribe'
messages getting to the reflector against some pain in getting things set up
just right. I will keep you all posted on this one.

     David Law

Colin Mick <ckm@xxxxxxxxxxxxx> on 09/02/2000 23:09:44

Sent by:  Colin Mick <ckm@xxxxxxxxxxxxx>

To:   David Law/GB/3Com@3Com, stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject:  Re: Bounced message from Colin Mick <ckm@xxxxxxxxxxxxx>

SO why did this bounce?

At 10:03 PM 2/9/00 +0000, David Law wrote:

>Please reply to Colin Mick <ckm@xxxxxxxxxxxxx>
>owner-stds-802-3-hssg@xxxxxxxx on 09/02/2000 18:35:51
>Sent by:  owner-stds-802-3-hssg@xxxxxxxx
>To:   owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
>cc:    (David Law/GB/3Com)
>Subject:  BOUNCE stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> >From owner-stds-802-3-hssg@xxxxxxxx  Wed Feb  9 13:35:51 2000
>Received: from  by (8.9.3/8.9.3) with ESMTP
>id NAA12019; Wed, 9 Feb 2000 13:35:50 -0500 (EST)
>Received: from ( [])
>      by (8.9.3/8.9.3) with ESMTP id NAA15038
>      for <stds-802-3-hssg@xxxxxxxx>; Wed, 9 Feb 2000 13:35:49 -0500 (EST)
>Received: from Tiger ([]) by
>           (InterMail vK. 201-232-116 license
>           with ESMTP id <20000209183615.WYIW9448.smtp1a@Tiger>
>           for <stds-802-3-hssg@xxxxxxxx>; Wed, 9 Feb 2000 10:36:15 -0800
>Message-Id: <>
>X-Sender: ckm@xxxxxxxxxxxxxxxxxx
>X-Mailer: QUALCOMM Windows Eudora Pro Version
>Date: Wed, 09 Feb 2000 10:34:45 -0800
>To: stds-802-3-hssg@xxxxxxxx
>From: Colin Mick <ckm@xxxxxxxxxxxxx>
>Subject: reflector et al
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>I agree with both Howard and Brian than an open reflector is essential.
>The sheer magnitude of content presented on this reflector is a major
>problem to new members and, probably, to many of us who are observing but
>not actively participating in the discussion. The problem is only going to
>get worse.
>It would be extremely helpful to all but the rabidly enthusiastic (and
>eclectic, given the range of proposals I've seen) if some one or some group
>spent some time preparing and maintaining an organized summary/history of
>events. Simpler projects have made do--sort of--with archives (e.g., the
>two inches of paper we distributed for Fast Ethernet and the email archives
>we started during the gigabit project) but this one is too complex and has
>too many options and far too much content already.
>It would behoove the task force to create an organized archive/history
>now--both as an aid to folks who will be joining this conference in the
>future and as an aid to other 802 and sponsor ballot folks who will have to
>vote on this project at some time in the future.
>Then again, there is always that chance that the group may go down a blind
>alley and have to back up and consider other options. In such a case a
>detailed map of your journey might prove invaluable.