ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/HATCH/WWIVNEWS.ZIP/9308_2.NWS

Text File | 1993-08-04 | 28KB | 501 lines

have set a size limit for UUE's as well. I would venture to say that this was
to help prevent huge phone bills for the LD connections. This purpose was for
the benefit of most network users.

So now you are thinking, "Why only allow UUE's for the MOD sub". Well even
I can figure this out. The mods are a benefit to all that use them. And I
would venture to say that the majority of netted boards have mods installed.
But I would also bet you that most boards do not carry your net. Thus allowing
UUE's in the MOD sub only is understandable. Besides this one little example,
the proper use of UUE's is in the doc's and that makes it a rule.

So to summarize this all up in a nut shell. UUE's are only allowed in the
MOD sub. You as a network sysop, have the right to use UUE's only as stated in
the doc's and not as a way to send your net (upgrades and or startup)
packages. It is not right, nor is it allowed to use UUE for any other purpose.

It is also well known that Net33 will have detailed rules concerning the
use of UUE's.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
─────────────────────────────────────────────────────────────────────────────
"Could someone please send me the Latest copy of McAfee's Clean and Scan? Mine
is old and I don't want to take any chances."

How often have you seen requests like that on Network subs? How often have you
been a "good buddy" and responded to such requests? I know I have!  Most of
us have good local connects, so all it costs us is a couple of minutes to
UUEncode or Packscan the file and stick it on the net. It's great to be on the
receiving end too, as it saves an LD call. The file you requested just appears
on your board in a couple of days. Often you may get several copies since
WWIVnet is a friendly place where a spirit of helpfulness and cooperation
prevail (most of the time).

There is just one small thing we have overlooked while we were being so
helpful. Just how did those utilities get from your system to the person who
wanted them. Well, it may have looked something like this:

           SENDER --> 1040 --> 1050 --> 1120 --> 3314 --> RECEIVER
Ok, you are local to 1040, so that is a free call. 1040, 1050, 1120, and
3314 are Long Distance calls to each other so THEY EACH have to PAY the phone
company in order to move the utilities. Since the receiving system is local to
3314, he doesn't incur any expense. I think at this point you can see the
problem. The mail servers and hubs are stuck PAYING to move YOUR FILES.

When they agreed to allow other systems to connect to them, and to act as a
net mail server, they understood they would be handling MESSAGE traffic. Even
though the average message is less than 1k, the bills add up fast. Servers
routinely pay the phone company over $100 per month just to move MESSAGES.
Remember those utilities you sent out?  After UUEncoding they probably
exceeded 300k. It doesn't take many people sending this type of stuff to add
$25 to $50 a month to a servers bill. It is their right and responsibility to
try and limit the non message traffic. It is their LD bill at stake. Without
these Servers there would be NO WWIVnet!

Now, it seems that some of these helpful, cooperative sysops became nasty and
abusive, when advised that WWIVnet was for MESSAGES, not FILE transfers. It
was explained that this practice is against network guidelines, and incurs
extra costs for the systems handling the mail. They were asked nicely not to
send their files over the net, and these requests were met with comments like:
"It's my right, This is a public network, You can't stop me, I'll just find
another way, etc"

At this point, Tolkien went to work on a utility to detect UUEncoded messages
and several other types of encoding that could be carrying "files". NetProbe
was born. This program was not cheap, nor was it easy to get. Tolkien put in
place a number of safeguards to insure it would never fall into irresponsible
hands. Despite the cost, a number of the Mail Server systems and Hubs shelled
out the cash in hopes they could control this abuse of the net.

UUEing is the most popular way of sending "programs" over the net. The easiest
way to curb this was to target the vehicle (UUEncoding & Packscan). Since
UUEing is a valuable way of moving mods and other small files containing small
EXEs and OBJs, it was decided to ONLY stop the LARGE and MULTIPLE ones, as
they would be the most likely to contain "programs". NetProbe does NOT delete
these messages, it simply flags them by moving them into a separate file. At
that point, the large ones are either passed or deleted at the Server Sysops'
option. If they are deleted, the system(s) involved will get at least ONE
warning. Further attempts will be deleted, and if it continues, the GC/NC will
be notified.

The size limit is a figure that the NetProbe Servers could collectively agree
on. Some favored NO UUEs at all, while others didn't mind singles up to the
32k net limit. Small-(less than 10k)-SINGLE-UUEs still flow freely! Also, a
few subs (like ModNet) that benefit the greater portion of the net were
exempted from the scan. Unfortunately, as with any filter, you sometimes catch
things you don't want, but for the most part, the program is working VERY
well.


I compiled some stats on the volume of UUE type files flowing through here
(6211) for the last couple of months.

     Feb  : 3.5 meg  (including several copyrighted major programs)
     Mar  : 2 meg
     Apr  : .8 meg (and none had to be stopped !)

Last month the only UUEs were those going to & from ModNet (only 147k) and
those going to & from systems who have a common connect here. The phone bill
is lower, and the sysop is smiling.

I'm afraid that if the current attitude held by many sysops that "I can send
what I want at someone else's expense" continues, Wayne will pull the plug
completely and prohibit the use of UUE, Packscan, etc completely over the
net! How many of you that are complaining know what would happen if 1040
(Filo), 1042, 1050, 1051, 1111, 1112, etc, decided that this was costing too
much and shut down their servers.......? It's truly sad that so many Sysops
have so LITTLE RESPECT for the people that pay the LD bills so WWIVnet,
IceNET, etc, can exist!

<concerned, sad sigh>

Of course, there are lots of questions to be answered about this situation.

Question: I can Zip a 10k text file and then UUEncode it and it ends up
smaller than the original (about 8k). Wouldn't that be a better way of sending
mods and large text files?

Answer: No. Network compression or your modem's internal compression (MNP5
or V.42bis) will compress that 10k text file down to about 5k. The
Zipped/UUEncoded version will not compress down much more than it already is.
In fact even though it appears smaller on your hard disk, the Zipped/UUEd
version will have about 20% to 30% more bytes to transmit.

Question: I have a large mod I want to post on ModNet. It is larger than the
32k network message limit. If I zip it, and UUE it, then it will fit. It this
ok?

Answer: No, for two reasons. First, if you split it into two text files
and send them normally, it will take less LD time to transmit them (saving
everyone money). Second, most people want to look at a mod before they decide
if they want it. If it's UUEd, they can't do that. The ONLY reason to UUE a
mod is if you have to include a small EXE or OBJ with it. If so, you should
post a message ahead of it describing exactly what it is.

Question: Can I be sure any UUEs (under 10k) that I send will get through?

Answer: That depends on the Server. The NetProbe systems have agreed on a
"defacto standard" for what to pass. Some servers are more (or less) tolerant
than others. Even though NetProbe only flags large UUEs and PACKSCANs, it
generates a report of ALL of them that pass through the node. If a sysop
observes
you are sending many small UUE's, he may suspect you are trying to put one
over on him by breaking files up into tiny packets. In that case he would
probably put a stop to it.

Question: How many warnings will I get?
Answer: A busy Sever Sysop may not have the time to examine and make
individual decisions on UUE containing messages that have been flagged. He may
just kill them, send you one warning and be done with it. Others may prefer
not to keep a list of who has had warnings and who hasn't, so you may get more
than one warning from them.


Question: Why are you stopping UUEs? They aren't the enemy, it's the EXEs
in them that are the problem.

Answer: If there had been an easy way to only stop UUEs carrying EXEs, and
not mods or OBJs, that would have been much better, but under the
circumstances, we just have to put up with a little inconvenience in order to
keep the net healthy.   The intent is to put an end to using WWIVnet to
transfer "programs"!  It's just too bad that some legitimate uses for UUEing
have been caught in the sieve.

Question: I thought one of the beauties of WWIVnet was that it didn't have
a lot of rules. I was one of the first systems in the net. All these rules
didn't exist then and everything worked fine. Don't you think you have gone a
little overboard?

Answer: Ah... the good old days. Possibly, the fact that computers were
more expensive, not everyone had one, and the net was smaller contributed to
a strong sense of cooperation and respect. At that point, if someone said "
You can connect here, but please keep the traffic low" all the connects would
try their best to do so. Now when one of the servers ask for a little
cooperation or respect, all they get is " You can't do that, It's my right,
etc".

Question: Who gave these "Servers" the right to "censor" my mail? I think
their power has gone to their heads.

Answer: Don't you think they have the 'right' and 'responsibility' to do
their best to keep network traffic flowing?  Along with the obvious cost
factor, they have to maintain enough hard disk space. It takes up to 3 times
the packet size to process an incoming packet. If WWIV allowed file transfers,
many servers would go down due to the increased cost. Those that didn't would
have to get larger hard disks and faster systems. Since at this time, file
transfers aren't allowed, why should these Sysops have to foot the cost for
those who would abuse the system. It is their RESPONSIBILITY to filter out
file transfers so we can maintain the excellent mail service we now enjoy. If
and when file transfers are permitted on the net, I suspect we will see the
demise of the free connects.

Question: One 10 UUE doesn't cost a high speed system more than a couple
of pennies. Why all the fuss?

Answer: You are correct. The cost of a single small UUE is insignificant,
and that is why they still pass freely. Review the stats I posted earlier in
this article where I showed the reduction in UUE type files over the last few
months. The Program is working. For a system like 1021, his savings were on
the order of $40 per month (don't quote me on that figure). That's nearly $500
per year. Enough for a nice new hard disk, or summer camp for the kids, etc...
Question: All the discussion on banning UUEs has probably cost as much as
will ever be saved by doing so. Why didn't someone explain what was happening
before NetProbe went into use?

Answer: I think for the most part, all this bickering is the fault of the
NetProbe systems themselves. We failed to completely and fully explain what
was happening initially. I guess that was my job. I told Tolkien I would
handle getting a "Press Release" out, and I let it slide. Things escalated
from there. I sincerely hope this article helps clear things up.


─────────────────────────────────────────────────────────────────────────────
Deltigar (1@1052)
─────────────────────────────────────────────────────────────────────────────

FILEnet is a network dedicated to making file transfers as easy as possible
while at the same time making some transfers unnecessary. The former is made
possible with the latest in File Transfer software designed specifically for
FILEnet. The latter is a byproduct of being able to request lists of files
from other FILEnet systems.

The concept I have put into play is one of a Server/End Node only network.
This allows the individual sysop to choose what traffic flows through their
system.  On the application form, you are asked several questions concerning
what type of connection you want. All Servers connect to each other, and all
End Nodes connect to at least one server. This keeps the maximum number of
hops to 3. This is mainly to keep the total cost of transfers as low as
possible. Unfortunately, it is one of the lesser understood aspects of
FILEnet. I often get an application from someone who doesn't understand why he
is not just connected to another FILEnet node simply because he is local.
Granted, a connect will be established because they ARE local, but unless the
other node is a Server, the new node will ALSO have to connect to a server.

I would like to ask potential new members to please NOT request a connect to
an End Node as your primary connect. If that individual wishes to pick up
your traffic, they will have to become a server to keep the maximum hop down
to 3. If this individual had wanted to do so in the first place, they would
already be a server.

Server connections are "Call In Only" or "Shared". Call In Only connections
are for End Nodes who are paying for all of their incoming and outgoing
traffic.  Shared means that both the Server and the End Node pick up the tab.
In FILEnet, the importance of the Server cannot be stressed enough.

End Nodes are those nodes whose traffic is theirs, and theirs alone. They may
limit the files leaving simply by editing the configuration files. In their
default state, no files re allowed to be transferred off the new system. Only
by adding the directory numbers to DIRLIST.FTS in the FILEnet directory can
files be made available to FILEnet. Limiting the incoming files is simply a
matter of restraint. If you don't use either FTSREQ or the User File Request
Door, you will not receive files from FILEnet (Except normal net updates).

The Software we use in FILEnet has been specially developed by myself and
Private Idaho. It is intended to be the standard FILEnet software. However,
it is still quite acceptable to use PackScan, WWFNET, or any other method of
sending whole files through the net. You simply need to keep in mind that the
other systems you are dealing with also need to be running that software. If
they do not, then the standard system is still there.

For more information on the development of the new software, and improvements
that are being made, FILEnet Software Development is autorequestable on all
major networks, and a few minor ones. Check your favorite network's subs list
for the subtype nearest you.

[Deltigar's NOTE: Subtypes are WWIVnet 11052, IceNET 11084, WWIVLink 11184,
TARDISNet 11052, FILEnet 101 and TLCnet 155.]

The ONLY transfer method that is expressly banned, is UUE traffic. This is
not because we don't want files sent, it is simply because everything else is
so much more cost effective. UUE files are bigger than the zip files they
contain, so why not just send the zip file?! The standard FILEnet software is
EASIER to use than UUEncoding anyway. With the ability to post on certain
FDL's, UUEncoded subs have become obsolete.

There are two classes of file transfers on FILEnet: FDL and FTS.

FDL - File Distribution List. This system allows a sysop to subscribe to an
FDL (with FDLREQ.EXE) or host one (with FDL.EXE). The concept is somewhat
like a one way message base. The host posts a file, such as a new release, or
updated utility, and it is automatically sent out to the subscribing nodes. On
certain FDL's posts are allowed, making the entire system behave like a
networked directory. This, IMHO, can UUEnd the UUDebate for good.

FTS - File Transfer System. This system allows a sysop to send a single file
to a single node (with FTSEND.EXE), or to request one to be sent (with
FTSREQ.EXE). A listing of all files available on a system may also be
requested (also with FTSREQ.EXE). The system receiving the request has
complete control over which files are made available for request (with
DIRLIST.FTS) and my block out any systems they do not wish to grant access to
(with BADNODES.FTS).

One thing we would like to work for is to make FILEnet the network that other
networks use to transfer files, since files are generally of a nature that
all sysops want, and are not usually network specific.  A good example is the
HS/Link File Distribution List. Once a sysop has subscribed to this list
he/she is assured of receiving the latest version of HS/Link very shortly
after it is released.

Another goal is to get software developers hooked into FILEnet.  This will
greatly decrease the time between when a product is released, and when it
becomes widespread. Already we have Diamond, who recently made a splash with
MO, a new message base optimizer and Private Idaho, who is probably best
known for his GoSnarf utility.

In order to join FILEnet, there has historically been a very strict ritual
involved -- one must ASK to join. You must also be a REGISTERED WWIV sysop.
That simple. The reason behind requiring registration is quite simple. There
are plenty of other networks out there for new WWIV sysops to cut their teeth
on. FILEnet is not network you would want to make mistakes on. A single
misunderstanding could land you a BIG phone bill. You also should be very
familiar with the WWIV software, and if you are that familiar with it, then
your registration trial period has probably already passed <SMILE>.

The VBBS Problem - Since our software reads many of the configuration and
data files on a WWIV system, and due to our lack of VBBS software developers,
we have yet to design an interface for VBBS systems. It is my sincere hope
that sometime in the near future a VBBS programmer will subscribe to FILEnet
Software Development (Offered on all major networks) and help us open FILEnet
to REGISTERED VBBS sysops as well.


─────────────────────────────────────────────────────────────────────────────
                          The FILEnet Application
─────────────────────────────────────────────────────────────────────────────

The EASIEST way to give the information needed is to simply extract the line
for your system from the applicable BBSLIST file in your primary WWIV-Based
network. Insert it below, or fill out the top paragraph.

You will be notified as to what your FILEnet Node number will be as soon as
this form is received. You will also be notified as to which server you will
be connected to. If you have a FILEnet server in your area, please indicate
which one it is.

 Node     Phone Number  Rate   Reg#   Compat BBS Name
@0000    *000-000-0000 #00000 [00000]  !$?  "Your BBS Name Goes Here"

@  Major Net/Node Number:
*  Complete Phone Number:
#  Highest Modem Speed  :
[] WWIV Registration Num:
!$ Modem Compatibility  :
"" System Name          :

Do you want to be an End Node or a Server?

── End Nodes Only ──────────────────────────────────────────────
What type of Connection do you want?
-Call In Only (YOU pay for all YOUR traffic)
-Shared (You SHARE cost with a Server)
────────────────────────────────────────────────────────────────

── Servers Only ────────────────────────────────────────────────
Free Drive Space:
Your VOICE Phone:
Your REAL Name  :
Your AGE        :

What type of connections are you willing to have?
-Call In Only (THEY pay for all THEIR traffic)
-Shared (You share cost with the other node)
 (NOTE: Server-Server connections will be SHARED)
────────────────────────────────────────────────────────────────

Edit and send this form to FILEnet, TARDISNet or WWIVnet 1@1052,
IceNET 1@1084 or WWIVLink 1@1184.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
and Tolkien (1@3456)
─────────────────────────────────────────────────────────────────────────────

During the last few months of 1992, the WWIVnet sysops in the 314 area code
(of which the authors are two), who pay to support the operation of the
St. Louis WWIVnet Server, were informed by the server's sysop, The Sandman
(1@1021), that it appeared that we had a problem.

The Sandman had been running the server's day-to-day operation for over 2
years, and had been observing that as WWIVnet doubled in size, the flow of
WWIVnet packets was increasing exponentially, growing at about 4 times the
rate of WWIVnet expansion. He found this disturbing, especially since much of
the message traffic during that time was routed to other connections via
PCPursuit, which operates at only 2400 bps. Additionally, our server was
gradually being weaned off of PCPursuit and onto standard AT&T phone line, so
that it could take advantage of the US Robotics HST Dual Standard 16,800 bps
modem that our group had purchased. The Sandman was concerned that if this
rate of message traffic increases continued, we would soon not be able to
afford the cost of long distance bills, and that this might force us to shut
down our server.

The Sandman brought his concerns to the server group, and we began to discuss
what could be contributing to this seemingly unwarranted increase in WWIVnet
message traffic. After several days of discussion, what began to emerge was a
feeling that much of this increase in WWIVnet message traffic was the result
of binary-encoded files being sent back and forth over the network. Most of
us were only aware of one (1) form of encoding that would allow a file to be
transmitted as binary data between connecting systems, and that was UUENCODE.
We then discussed how we might be able to not only test this theory, but also
do something about it if it turned out that we were correct.

Since WWIVnet packets are compressed using algorithms from the PKWare
Compression Library, our group decided that it would be necessary to purchase
a copy of this library, so as to be able to decompress the incoming packets
for analysis. It was decided very early that this program would have to
function as NETWORK1. It would be written so as decompress the incoming
packet (if it was compressed) to do its analysis, and then call the "real",
but renamed NETWORK1. The job of writing the program was given to Tolkien,
1@3456, who has a good working knowledge of WWIV data structures.

Tolkien, and others, felt that it would not be ethical to simply delete UUE
packets out of hand, so it was proposed that UUE packets under a certain
agreed upon size would be allowed to pass without being stopped. He and others
also felt that any packet that exceeded that maximum size should simply be
removed from the outgoing packet, and placed in a file, called CHECK.NET,
which could then be viewed, with LNET, by the server's sysop. Also, to be
fair, NETPROBE, as it was soon named, would also be able to sense, and be able
to filter PACKSCAN packets. Tolkien had created PACKSCAN, initially to simply
scan the incoming decompressed LOCAL.NET files and write a synopsis of the
contents to the sysop's log. However, PACKSCAN soon evolved into a utility
which was capable of breaking large files into 32K chunks for transmission
between BBS's. Therefore, with this potential for abuse, PACKSCAN and other
binary data packets sub packets were also added to the list of things for
which
NETPROBE would scan.

With the PkWare Compression Library in hand, Tolkien began to write the
program. Realizing the potential for abuse if NETPROBE was distributed to all
sysops in WWIVnet, it was decided that it would only be made available to
sysops who ran WWIVnet mail servers, for a nominal fee to recover the cost of
our purchase of the PKWare Compression Library. It was also decided, very
early in the development of NETPROBE, that, to prevent some sysops from simply
giving away copies of NETPROBE to their friends, some type of registration
code would be needed before NETPROBE could work. Without this code, NETPROBE
would not be able to function at all. Finally, a NETPROBE "application" was
drafted, and mail to all WWIVnet server sysops. This "application" was
designed to to limit the number of copies of NETPROBE which would be
distributed, and to inform the sysops of the need to use this program
ethically.

It quickly became apparent that the responsibility for deciding who could get
a copy of NETPROBE should not rest in the hands of any one person, since
NETPROBE was written for the good of the entire network. Lance Halle, 1@6211,
graciously volunteered to draft an objective set of qualifications that must
be met by anyone wishing a copy. These qualifications are:

       1) The sysop must be running a server.

       2) The sysop must have run a WWIVnet system for 18 consecutive
          months, 6 months as a server.

       3) The sysop must receive approval from three other server
          sysops running NETPROBE.


NETPROBE is actually quite a simple utility. It decompresses compressed
network packets, and analyzes all packets coming to or through the system it
is running on. It works in a multi-network environment, comes with a network
decompressor, a utility to send command line netmail, and a program to
generate
the daily logs (that can be then sent in netmail to any net address using the
included command line netmailer as part of the external event).

Subpackets are analyzed to determine what they are (message, file, SSM, etc).
Files are logged, along with some information about them (who sent them, who
they was going to, maintype, minortype, etc). If the file is not from a system
that the NETPROBE system has given the "okay" to for sending files through
him/her and if the subpacket is larger than a specified size (default is 10k,
which still leaves room for small utilities and data subpackets) then the file
is shunted into the CHECK.NET file for later personal review by the NETPROBE
sysop. NETPROBE does not itself EVER delete anything. It will delay only.
Actual deletion requires human control.

The creators and sponsors of NETPROBE sincerely hope that it will soon no
longer be needed. NETPROBE is not the ideal solution. The ideal solution
would be for people who wish to transmit files over WWIVnet to get permission
from all the intervening systems instead of covertly trying to have others,
especially net servers, pay the cost for such files, which are usually for the
benefit of just one or two people. However, it appears that a number of
people continue to think about no one but themselves. So for now, NETPROBE is
the only real solution to this growing problem. A point-to-point network FREQ
utility will (hopefully) alleviate the problem, but that remains to be seen.
If such a FREQ program isn't used because people would rather try to make
others pay for their file transfers, then NETPROBE may still be needed years
into the future.


─────────────────────────────────────────────────────────────────────────────
Snorkel (1@3459)
─────────────────────────────────────────────────────────────────────────────

This utility, written by Tolkien 1@3456 WWIVnet, has evolved into the finest
NET packet analyzer for WWIV or any compatible network.After almost 2 years
of revisions and improvements, PACKSCAN version 2.31 has now become more than
just a WWIV packet scanner.

In 1991, at my urging, Tolkien undertook the task of writing a program which
would scan all incoming NET mail packets for WWIV, and log them to the sysop