INC NEWS - >>> ADMIN NOTE <<<

Wed Mar 28 17:22:02 EDT 2007

Randy - on a busy week i'll post 8 or 10 times to the Duke Park list. of 
those posts, maybe 1 a week or 1 every other week will be of interest to 
folks in other neighborhoods, and i think it would be a good thing to be 
able to post those without running into a spam filter.

given that the first filter is membership in the list, it's not like 
there's a whole universe of unknown spammers trying to deluge this list.

just my .02

barry ragin

RW Pickle wrote:
> If this is something the other list members would like, to get emails
> posted from across the City relative to other particular neighborhoods,
> then I believe I can change the settings to allow for additional email
> addresses.
>
> There seems to be only a couple (probably less than 4%) of members of the
> list who want this service. I suspect the others will see it as additional
> email that will burden their already bulging email boxes. Certainly
> anything posted to any other list can be posted to the INC list server. It
> just can not be broadcast across the City with one click. If an additional
> click by the sender is too much to ask to keep the conversations
> pertinant, then perhaps the membership would like to keep it like it is. I
> just administrate the list, I don't decide what is good or bad for those
> who get the emails.
>
> This is the only list I administrate where this is an issue. And since
> those few who want this ability are not members of the other lists, it
> would seem to be a personal preference rather than a general need. I'd
> suggest if it was a universal thought process, I'd see the same thing
> being requested across all lists and that is just not the case.
>
> I have never introduced the INC audience to online polling. But it's a
> good way to quickly get the pulse of what a membership thinks. In this
> case, it would be the list membership. Should that be something the
> membership would like to try, I'll see if I can fit it in. But just
> looking up the emails in the box today, I see a number of admin duties
> that require attention. This is part of the responsibility of doing this
> that the membership never get to see. It's like I said, the machine runs
> flawlessly if the humans follow the rules. It's the human factors that
> always create the additional work. And when it's the spammers, they have
> no mercy. Every bounced email they send comes back to the list server and
> it adds up in a hurry. Not just in work on the list server end, but as
> email to me notifying me of the problems that need attention. I could shut
> this feature off and never know, but that would neglect the needs the list
> server requires. I assume it would cease to function if it reached some
> capacity. But because it is maintained, that has never happened. I have on
> occasion (maybe even on this list), shut the server down for a period of
> time to be able to not allow the spam to bounce. No idea where it goes at
> that point since it is undeliverable. I just know after a couple of days
> of this action, it begins to taper off again.
>
> RWP
> List Administrator
>
>   
>> might i humbly suggest that the parameter of (1) additional email
>> address in step 2 below be changed to something a little higher, like (5)?
>>
>> Durham has a large and overlapping network of listservs on which to
>> disseminate information. Posting to INC, one or more PAC lists, and one
>> or more neighborhood lists at the same time is a pretty standard thing
>> to do, and to my knowledge, none of the other lists (including the ones
>> i moderate) will bounce a message as spam because it's been sent to 3 or
>> 4 other lists.
>>
>> Barry Ragin
>>
>> RW Pickle wrote:
>>     
>>> There seems to be some concern that there is something wrong with the
>>> list
>>> server. I will try to explain, in simple terms, what it is, what it
>>> does,
>>> and why anyone will experience problems as it relates to posting. It is
>>> a
>>> machine that has defined parameters. It doesn't look outside these and
>>> make judgement calls. It makes green (as in go) or red (as in stop)
>>> decisions. An all but .1% (and maybe less) of the reasons anyone would
>>> ever have a problem posting is relative to human error. the machine
>>> makes
>>> very few mistakes. So it's people problems and not list server problems
>>> that are the root of your concern. Perhaps understanding how the machine
>>> works will aid in solving the issues people seem to be facing.
>>>
>>> The List server does three things when it receives an emailed post from
>>> anyone. I'll use the character John Doe as my example. John is a member
>>> of
>>> the INC list for this example of how a list server works.
>>>
>>> First thing it does when it receives an emailed post is to see who it is
>>> from and check the senders name against the member list.  Because when
>>> you
>>> signed up for the list server, you had to enter an email address. This
>>> is
>>> how the list server recognizes you. If John registered as
>>> John.Doe at hotmail.com, that is the email address he must use when sending
>>> a
>>> post to the list server. If John Doe also has the email address of
>>> John.Doe at aol.com, and sends a post from this address, the list server
>>> doesn't recognize John because this is not the same address of the
>>> member,
>>> John Doe. It immediantly throws the email post from the aol address out.
>>> It helps that no two addresses are the same. Like your fingerprint, each
>>> one is different. John may get email regularly at both addresses, but
>>> the
>>> list server only knows that John is who he says he is when postings by
>>> his
>>> registered member email address; John.Doe at hotmail.com, arrive. John by
>>> any
>>> other email address or name is not John to the machine.
>>>
>>> The second thing the list server looks at, after recognizing that John
>>> is
>>> a member, is to see if there are a number of other email addresses that
>>> John has sent this post. Emails sent to a number of addresses are
>>> considered spam, because that is what spam is, broadcast email. Our list
>>> server likes it when it is the only address to which a post is sent. But
>>> it will allow a post with one additional email address. It does not
>>> allow
>>> Bcc (blind carbon copy) addresses at all. So if John sends a post to the
>>> lister server and one other email address, the post flies through
>>> uninterrupted. If John sends a post to several email addresses, even
>>> though John is a member, it sees it as spam and kicks it out. It won't
>>> allow John to spam the members.
>>>
>>> If it finds John is a member, and John has not sent the post to a bunch
>>> of
>>> other email addresses, it then looks at the size of the email post John
>>> has sent.  Our list server is set to accept a post up to 40KB (40
>>> kilobytes). As a measure of computer memory or storage, a kilobyte (KB)
>>> is
>>> approximately a thousand bytes (actually, 2 to the 10th power, or
>>> decimal
>>> 1,024 bytes). So 40KB would be a little more than 40,000 pieces of
>>> information in an emailed post; or roughly 4,000 words. That's why it's
>>> important to send messages to the list server in simple text. When sent
>>> in
>>> html format, the list server reads the html code and adds a byte for
>>> every
>>> piece of code it sees. If you know what html code looks like (just
>>> select
>>> View/Source from your browsers menu bar to see), then you realize that a
>>> little code adds a great deal of bytes to any message. I have the
>>> ability
>>> as administrator to change this to a greater or lesser number, allowing
>>> for larger or smaller posts. 40KB is generally large enough for just
>>> about
>>> any diatribe that comes through the service. Only rarely does it kick
>>> out
>>> a post due to size. And when it does, it typically is because it is sent
>>> in html format or is sent with multiple emails attached such as in a
>>> forwarded message. So size will throw the email post out as well.
>>>
>>> If the list server finds all of the three areas it checks as having no
>>> problems, it immediantly sends out Johns' email post to every member of
>>> the list. This all takes place in far less time than it has taken to
>>> read
>>> this far. But if there is a problem at any stage of the checking prior
>>> to
>>> sending out the post, the list server kicks out the emailed post and
>>> sends
>>> me an email telling me (the list administrator) that there is a post
>>> waiting for me on the list server that needs my attention. When I check
>>> my
>>> email, I'll find a message from the list server. Here's a copy of what
>>> it
>>> sends me:
>>>
>>> As list administrator, your authorization is requested for the
>>> following mailing list posting:
>>>
>>>     List:    INC-list at DurhamINC.org
>>>     From:    John Doe
>>>     Subject: Can You Believe It!
>>>     Reason:  Message has implicit destination
>>>
>>> At your convenience, visit:
>>>
>>>     http://lists.deltaforce.net/mailman/admindb/inc-list
>>>
>>> to approve or deny the request.
>>>
>>> In this particular message, the server tells me that Johns' emailed post
>>> was kicked out because it was seen as spam. "Implicit destination"
>>> refers
>>> to multiple addresses in the Cc field of the emailed post. It didn't
>>> check
>>> for size because it was kicked out at step 2 and did not get to step 3.
>>> So
>>> it may have been too large as well, the machine will never know until it
>>> is reposted by John. I have no ability to edit any emailed post, so I
>>> just
>>> can't fix the problem and send it on through. And since it doesn't know
>>> John Doe from David Harris, it treats everyone the same. That is why
>>> Davids' emailed post was rejected. It was a problem in step 1, 2, or 3.
>>> It's that simple. It wasn't a problem with the list server, it was human
>>> error that created the problem. The list server functioned just as it
>>> should.
>>>
>>> So when I have to go to the list server (done via online connections) to
>>> fix the problems that others create, I can do one of four things. I can
>>> hold it for dealing with it later, I can discard it, I can reject it in
>>> which case an email is sent back to the person sending the emailed post
>>> explaining the problem with it, or I can approve it after I have further
>>> examined the issue. This means I have to open every piece of problem
>>> email
>>> to determine the problem. I can't fix it, just do one of the 4 things
>>> listed above. Because of the sheer volume at times (because anyone can
>>> send the list server a post, even the same spammers that you get email
>>> from), I have taken the position to reject all problems and try to
>>> educate
>>> those who create the problem in the first place. My thoughts are that a
>>> better educated posting membership means less efforts as the
>>> administrator. After all, that's the way it should be, effortless. Some
>>> days, when we have a cross-posting event along with the regular spam,
>>> it's
>>> just nuts going to the list server so many times to fix the problems. If
>>> we get under a spam attack (like has happened in the past, where some
>>> spammer is using our posting email address as the return email on their
>>> spam mail), it means as many as 2,000 messages get held for me to look
>>> at
>>> and resolve and 2,000 emails I get from the server telling me about the
>>> problems. Just think about getting 2,000 emails a day for a week. It'll
>>> drive you nuts dealing with it. But it seems that education about
>>> problem
>>> posting issues is useful although it only seems to work for a while and
>>> then it's the same people who create the problem over again. I educate,
>>> the problem goes away; it reoccurs again and I educate again. It's a
>>> cycle...
>>>
>>> About the only time I will approve a held posting is when it relates to
>>> size. If that is the reason for being held, and the size is just a
>>> little
>>> bit over, I will send it on through. Otherwise, when someone isn't a
>>> member, or when posts are sent with implicit destinations, I have taken
>>> the position to reject them all, regardless of the sender. You have to
>>> draw the line somewhere and create boundaries in which to operate and
>>> maintain a list server. that is why there is an administrator. He has to
>>> administrate.
>>>
>>> So it's not the list server that is the issue, it's the problems the
>>> members (and non-members) create that cause the problems. The machine
>>> just
>>> does what it is supposed to do, serve messages to the list members. I
>>> think that most of the list is happy to not be getting a bunch of spam.
>>> Enough of it comes via general email already.
>>>
>>> I hope this helps those who seem to think the problem is in the list
>>> server. Human error is the culprit and I haven't figured out a way to
>>> fix
>>> that yet. It seems like education is the best way to resolve the human
>>> issues. I have seen those who would regularly make mistakes, learn. And
>>> in
>>> learning, they made both of our lives easier and thier posting
>>> experience
>>> more enjoyable. That's what it's all about.
>>>
>>> RWP
>>> List Administrator
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> INC-list mailing list
>>> INC-list at rtpnet.org
>>> http://lists.deltaforce.net/mailman/listinfo/inc-list
>>>
>>>
>>>       
>> _______________________________________________
>> INC-list mailing list
>> INC-list at rtpnet.org
>> http://lists.deltaforce.net/mailman/listinfo/inc-list
>>
>>     
>
>
> ====================================================================
> This e-mail, and any attachments to it, contains PRIVILEGED AND
> CONFIDENTIAL information intended only for the use of the addressee(s) or
> entity named on the e-mail. If you are not the intended recipient of this
> e-mail, or the employee or agent responsible for delivering it to the
> intended recipient, you are hereby notified that any reading,
> dissemination or copying of this e-mail in error is strictly prohibited.
> If you have received this electronic  transmission in error, please notify
> me by telephone (919-489-0576) or by electronic  mail to the sender of
> this email, RW  Pickle (pickle at patriot.net) immediately.
> =====================================================================
>
>   