INC NEWS - >>> ADMIN NOTE <<<

Wed Mar 28 08:13:46 EDT 2007

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
>
>   