Subj : WWiVNews: Archive 18 To : All From : paulie420 Date : Sat Feb 13 2021 08:01 am ----wwiv9306.txt Ú¿Ú¿Ú¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿Ú¿ Ú¿ÚÄ¿ Ú¿ÚÄÄÄÄ¿Ú¿Ú¿Ú¿ÚÄÄÄÄ¿ ÉÍÍÍÍÍÍÍÍÍÍÍÍͳ³³³³³³³³³³³ÀÄ¿ÚÄÙ³³ ³³³ À¿³³³ÚÄÄÄÙ³³³³³³³ÚÄÄÄÙÍÍÍÍÍÍÍÍÍÍÍÍÍ» º Volume 4 ³³³³³³³³³³³³ ³³ ÀÅ¿ÚÅÙ³ ÀÙ³³ÀÄÄÄ¿³³³³³³³ÀÄÄÄ¿ June/July º º Issue 2 ³³³³³³³³³³³³ ³³ ³³³³ ³Ú¿ ³³ÚÄÄÄÙ³³³³³³ÀÄÄÄ¿³ 1993 º ÈÍÍÍÍÍÍÍÍÍÑÍÍͳÀÙÀÙ³³ÀÙÀÙ³ÚÄÙÀÄ¿ ÀÅÅÙ ³³À¿ ³³ÀÄÄÄ¿³ÀÙÀÙ³ÚÄÄÄÙ³ÍÍÍÑÍÍÍÍÍÍÍÍͼ ³ ÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ÀÙ ÀÙ ÀÄÙÀÄÄÄÄÙÀÄÄÄÄÙÀÄÄÄÄÙ ³ ³ The Electronic Forum for WWIVNet Sysops & Users! ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³This Issue's Features³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ Random Factors...................................Wayne Bell (1@1) ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ ³ WWIVNews Feature Topic: The UU Debate ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ Introduction to the UU Debate....................Omega Man (1@5282) ³ ³ ³ ³ Editorial Contributors...........................The Menace (1@4071) ³ ³ Redman (1@16950) ³ ³ Sleepy (1@3085) ³ ³ Snorkel (1@3459) ³ ³ ³ ³ Technical Contributors...........................Deltigar (1@1052) ³ ³ Snorkel (1@3459) ³ ³ Tolkien (1@3456) ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ Filo's Mod of the Month..........................Filo (1@2050) ³ ³ ³ ³ Type 0 Forum.....................................Omega Man (1@5282) ³ ³ ³ ³ WWIV-Compatible Networks List....................Red Dwarf (1@6264) ³ ³ ³ ³ TechnOTES........................................WWIVNews Staff ³ ³ ³ ³ Dateline: @#$*()#!...............................Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Random Factors ³ ³ Creative Commentary by Wayne Bell (1@1) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Quite a few things to discuss this issue, so let's get started: NET33 BUG: Yes, NET33 does have a bug where the 'BAD PW' SSM lops off the last digit of a node number. That's because i had strlen(s+1) instead of strlen(s)+1. This has been fixed for NET34, and the current one is still usable as an error flag If you see there's a bad PW, you can always look at NET.LOG and see which node is having connection problems. NET34: NET34 should have multiple nets in the same callout, although I haven't started coding that part of it yet. As usual, there have been a few minor bug fixes since net33. No major changes have been done yet, though. I (obviously) do not have a release date set yet. NEW DE1.EXE: As most of you saw in the last mail_to_all_sysops, I've sent out a new DE1.EXE. (If you haven't installed it, then you won't be reading this.)This was sent as a UU encoded .ZIP file. To use this, you need to UUDecode it, unZip it, then overwrite your current WWIVNet DE1.EXE with this. You should no longer use the old DE1.EXE (the one in NET*.ZIP). There have been those on some of the Sysop subs that have shown concern whether the UU'd file did in fact originate from @1, despite the source verification flags. If you're one of those who are still worried about this, take a look at the archive once you've decoded it. If PKZIP reports the CRC as 331fe474, then you have an authentic copy. If you are in more than one network, make sure you overwrite the correct DE1.EXE. Your DE1.EXE is probably in your WWIVNet data directory, or if not there, probably in your main WWIV directory. This new DE1.EXE utilizes compression (PKWare Data Compression Library) to reduce the size of net updates, and hopefully decrease network costs. This also means it is slower than the older version. An aside note to the AC's and GC's: Please make sure that new systems joining the network receive this new DE1.EXE. It's also suggested that you make it available for download by those sysops who are either unfamiliar or uncomfortable with the use of the UUDECODE procedures. WWIV v4.23: WWIV v4.23 is being worked on now. No, I do not have a preliminary date set for its release yet. I will let people know when a date is set, so please do not email me to ask. Unlike previous releases, though, v4.23 will have some significant portions of the new/upgraded code installed by other people. Tolkien (@3456) has installed a number of new features, augmented existing ones, and has made a lot of cosmetic changes. Jim Wire (@3950) is in the process of installing multi-instance (multi-line) code, and that should be being tested by the time this WWIVnews is released. v4.23 already has multi-languages supported (although most of the code for that was in v4.22 also, and not many non-English language .str files are available yet). Shakespear (2@2050) is currently working on a FidoNet implementation, which should work more elegantly than existing interfaces (which require "fake" fidonet node numbers (@6xx)). UU'D FILES & WWIVNet: As has been made clear in the mail-to-all-sysops before the one containing the DE1.EXE update, files should >NOT< be sent through WWIVNet, except if you have the permission of all intervening systems. This covers not only UUENCODEd files, but also PACKSCAN files, and any other method that may pop up. Yes, many times it may be convenient to use WWIVNet to send files to someone. However, by sending them through the net, you make other people pay for your convenience, which is not fair. If you have a need currently to send files to someone on a continuing basis, the best way is to set up your own mini- network, and then send files (uuencoded or via PACKSCAN) on your own network. That leaves the convenience for you, does not cost other people anything, and will not end up routing normal WWIVNet traffic between your systems (as would be the case if you simply added a WWIVNet connection between systems). I know some systems in the St. Louis area have set up their own separate network for this very purpose. Some people have complained to me about the no-file policy, saying things like "But I already pay $xx a month for dues to the server." Yes, but that is for just ONE server. messages of any type on the net tend to go through many intervening systems, not just the one server. Files also tend to be much larger than normal net traffic, and server dues are based upon normal traffic, not based upon the few people who want to send large files. In any case, in the relatively near future (no, no date yet), there will be an FREQ-type program available for WWIV systems, which will allow direct transfer of files between WWIV systems, not using any network. This will end up being (I believe) the most convenient method, and will limit the costs to those actually doing file transfers. Rules and policies regarding this matter will be covered in detail in the new WWIVNet policy docs that will accompany the release of NET33.ZIP. Any questions regarding the FREQ utility should be directed to the author, 2@2050. REGISTRATION & MULTI-LINE WWIV: Prior to this writing, I've received several E-Mails regarding the per-line registration deal. I would like to take a somewhat more mellow attitude about it right now, than what these people seem to think is the situation. Basically, explaining what the situation is, why changes are necessary, and what we're currently proposing, and why. This opposed to taking the attitude of "This is it, love it or leave it." Previously, the license agreement has not explicitly addressed the issue of running a multiple line WWIV, as until recently, it has only been possible to run it on one line (and even so, not many people have been going multi-line with it so far anyway). Since more and more people have become interested in running multi-lines, and since v4.23 will probably support multiple lines, obviously the license should be modified to explicitly address the multi-line issue. That much, everyone should agree with. The real issue, therefore, is in what way should multi-lines be handled (in the license)? A long time ago, someone (I'm sure) wanted to run two WWIV's. Not multi-line, but two separate BBS's. The question therefore came up, "Do I need one or two registrations?" If someone could run two BBS's with one registration, then it would also be possible for someone to say, "Yes, I run two BBS's - one at my house, and one at my friend John's house" as a way to try to get John's BBS to count as registered for "free." Also, other DOS-based licenses (eg, BC++) don't work that way - the license is for one copy on one computer. In any case, as I understand copyright law (and they just gave a big lecture at work on this), the standard license is for one copy on one computer. Anything beyond that has to be explicitly granted by the license agreement. So, obviously, if someone was running two BBS's, he needed two registrations. That "decision" also expanded when someone wanted to run two separate BBS's on the same computer (under DV, say). It therefore came to be "one registration per phone line." I'm almost certain I've posted that on at least one sysop's sub. Currently, that also applies to one person running a two-line BBS. Yes, I agree that's not perfectly fair, but it's all I could come up with. If I went with anything less restrictive than that, it would become possible for people to 'cheat' on it (although I don't think most people would intend to do that). "But," I hear people saying, "I can mod my BBS however I want, and I choose to mod it to handle multiple lines." Actually, that's not accurate. What people have done to handle multiple lines is modify the BBS so that multiple copies can be running simultaneously, not that one copy can handle multiple lines (that is, the difference between having one BBS.EXE running, and having more than one BBS.EXE running). So, even though it is one computer handling two phone lines, it is still two BBS.EXE's running at the same time. That's two copies. Thus the need for two registrations. Let me explain the difference there a bit more. Modifying your BBS to handle multiple phone lines would mean that you would have one BBS.EXE running on your machine, which would have the multi-tasking code built into it, and it would be the same BBS.EXE that was handling all users (on the same CPU). What people have done is to have the BBS.EXE's lock files, and gracefully allow multiple BBS.EXE's to access the same files almost concurrently. Unfortunately, since DOS machines can typically handle only one user at a time, DOS people have never encountered real multi-user licenses. In other environments (eg, UNIX, which is what I use at work), where multi-user machines are common, the typical licensing agreement is for a set number of concurrently running copies. For example, FrameMaker (a word-processor type program) has a "license server" program running on one machine in a network. Whenever a user (on that machine or on another) wants to run FrameMaker, their copy of FrameMaker gets a "license" from the license server. The server ensures that no more than the set number of licenses are active at a time. If you need to run more than that, then you pay more money for more licenses, and they send you a new keyfile or password to enable the greater number of licenses (the keyfile/password is based upon the machine name/serial-number/ ethernet-address, to ensure that you don't use the same key/pass on more than one machine). So, in response to all this, the WWIV license is being changed to be less restrictive. Instead of having to have a separate registration for each phone line, people will now be able to (legally) run a multi-line WWIV paying much less than $80 per line. Hopefully this clarifies matters a bit. UTILITY.WW4: Finally, Filo (1@2050) is in the process of compiling a comprehensive list of utilities for WWIV, to be included in the documentation package. If you wish to have your utility (or utilities, as the case may be) the following information should be submitted: FILENAME.EXT, Author's Name, ID, Description ^ ^ ^ ^ ^ : : : : :...Description MUST not be longer than : : : : 102 characters including spaces. : : : : If it is available only at a fee : : : : then include the fee in the : : : : description. : : : : : : : :....... Use PD, SW, or CM as ID to : : : indicate Public Domain, ShareWare : : : or commercial. : : : : : :.................. Self Explanatory : : : :.......................... Type of Compression used : :................................. Filename used as identification Submissions can be sent to the following addresses: WWIVNet: 1@830 WWIVLink: WWIVNet #1 at 830 @2050 IceNET: WWIVNet #1 at 830 @2050 That's all for now. See you next issue. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Introduction To The UU Debate ³ ³ by Omega Man (1@5282) ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Transmission of UU encoded files over WWIVNet has been a topic of debate for as long as the net has been in operation. The arguments for and against the use of UU encoding have periodically turned sysop subs across the net into heated flamefest arenas, producing lots of hurt feelings and very few real answers to the questions raised. The questions raised were simple ones with complex answers. Was the UU method actually more efficient than a file request network relying on direct hookups? Were UU'd files containing archives actually larger than the archives by themselves? Should text files be UU'd? Do servers and pass-through nodes have the right to scan network packets and purge UU'd files regardless of size or content? Does the WWIVNet as a whole have the responsibility to bear the costs involved in sending such large files, or does it have the right to take steps as a whole to prevent this perceived abuse of resources? Oddly enough, while it appeared the majority of WWIVNet was against UU'd file transmissions, many of those opposed also expressed their doubts against any sort of absolute rule against their use. At the same time, those in favor of few or no controls on UU transmission were also some of the more outspoken and persuasive members of WWIVNet, and what they lacked in acceptance among their peers they made up for with tenacity and aggressiveness. In an effort to help present all sides of this serious issue, WWIVNews placed a Call for Articles on UU encoding. There were quite a few submissions for editorials, as well as several reviews and technical articles regarding the various utilities designed to manage - and even eliminate - network packets containing UU'd files. However, as this issue was being compiled, WWIVNet 1@1 issued what can best be described as "The Last Word" on UU transmissions. As a result, several of those who submitted editorials on this topic requested that their submissions be dropped from publication. The reason cited was the same in all cases: Wayne had rendered the debate a moot issue, and the forthcoming release of a File Request netutil simply added the final nail to the coffin. Still, there were some views that were allowed to be expressed. The following editorials, technical papers, and product reviews are the remainder of the 30+ submissions on this topic. While the matter has arguably been settled, for future reference the WWIVNews staff came to the consensus to publish the remaining submissions, as presented below. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The Menace (WWIVNet 1@4071) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ As of late there has been a controversy concerning UUENCODED files being transferred across WWIVNet. A UUENCODED file (UUE) is coded with a special program called UUENCODE, a program common to the UNIX world. By UUE'ing a file, WWIVNet is capable of sending it across the network as a message. This encoding is done since WWIVNet and WWIV itself, does not have the capability of transferring files between nodes of the network. Upon receipt of this encoded file, you would use UUDECODE to transform it back to it's original usable/readable state. The issue seems to reside in the cost of the network connects. When these UUE files are transferred across the network, and distributed amongst the some 5000 BBS's in WWIVNet, each system must endure the extra cost and time, in addition to the normal cost associated with a normal network transfer. This issue may not seem like a concern to many, but there are those who abuse the freedom that WWIVNet offers. Occasionally sending a UUE file is not the issue, it is the constant transfer of packets containing large UUENCODED files created by rather lazy users. Most of these Sysops are accepting the increase in phone charges without a charge to the users. Most Sysops start a BBS because it is fun, and the idea behind WWIVNet was the free flow of information. These UUENCODED files in net packets, increase the cost of running a BBS and are tarnishing the charm of being "networked". In addition, some users and/or Sysops have been sending Non-Public Domain files (NPD) across the net in a UUE fashion. This exchange of illegal files is somewhat alarming to the Sysops who do not wish to associated with that part of BBS'ing community. The possibility of legal action being taken against a sysop on a network who has packets containing NPD software could be a major detraction to those that only wish to use the network as a message medium. A few users have compared WWIVNet to FidoNet, where files from other sites are allowed to be transferred and housed by your system. WWIVNet is a different medium all together. That feature was built into FidoNet by its creator, not much unlike the way it was left out by the creator of WWIV. Wayne wanted a message based BBS to exchange ideas and information, not files. My opinion, although it will probably anger many, is to come up with a simple across-the-board policy/standard. I think we should disallow ALL UUENCODED files from being transferred across WWIVNet. I feel that we can not compare apples to oranges anymore. We must decided together what the policy for the network is. In this decision, there should be fair consideration to all, no matter who they are or for what reasons they run their BBS. This approach seems fairest to everyone involved. I have heard talk of a feature in an upcoming release of WWIV, where you would be able to send a file directly to another node by aid of the BBS list. This way the cost would be incurred directly to the system who intends to send the file. This seems to be a wise solution, if it is possible to implement. The Sysop of the originating system could be notified about the file for transfer, and have final say as to whether he should let the file be transferred directly to the intended receiver node. Much like the NET VALIDATION option in the netted WWIV subs, this would help sysops to regulate the network into an orderly manner for all, yet maintain a high degree of fairness. Sysops would have a say in how their systems would be used.... ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Sleepy (1@3085) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ There has been more than enough discussion on the transfer of UU'd files across WWIVnet. It seems to me that some of the more obvious (not to mention Important) reasons against them have been completely ignored. That is what prompted me to offer my opinion for everyone to read. One more thought before I get to it, please remember that this is only my opinion, backed up with a few facts that are available to all WWIVnet SysOp's, the only thing I did was Read The Docs... Here is a partial quote from the WWIVNET.DOC Introduction, which *everyone* should have read. This quote maybe considered superfluous by a lot of you however, everything and everyone *Must* start somewhere. "WWIVnet is a voluntary association of bulletin boards using WWIV software, and participating in a network by calling one another to facilitate the transfer of electronic mail (e-mail) and message bases (subs)..." "Through this network, a user of any of the bulletin boards that are members may send e-mail to a user of any other board. A User may also post on a message base which may be read by the users of systems which subscribe to that message base;...Because this system of Communication read by others and because it has an effect on systems other than the one on which it originates, a spirit of cooperation must prevail. Out of this spirit grows a system of organization and regulation which are discussed in the pages that follow." After reading the above documentation there is only one intelligent interpretation: Data (be it messages or files) transferred on WWIVnet *MUST* be WWIVnet Message Subs posts or WWIVnet e-mail. IMHO if nothing else common sense should have turned a light on somewhere. Since we are all only human, and as such have responsibilities, some with families, but all with the same feelings that are too often hurt. We should be able to afford one another common courtesy. Common Courtesy is easily given and should be extended to everyone in the same manner and degree that we should all like to expect to receive. I don't run up your phone bill so don't you run up mine. We have all agreed to incur the costs necessary to transfer WWIVnet to and from our connects, some connects are fortunate enough to be local to one another. But there are some out there that must pay to transfer their packets. I don't mean to sound condescending, I honestly believe that all of us were taught manners by our parents. Everyone wants to be liked and wants to like everyone in return. However when Joe Blow on AbracadrabraNet will send anything and everything over his network, that does not mean that Wayne Bell allows the same. What matters is what is fair. Plain and simple, you don't use Sally's phone to do Sam's business nor can you expect others to incur charges for something that has nothing to do with what they are interested in. Would you pay for you neighbor's newspaper, say the daily East Palooka Extra? Oh that isn't the newspaper that you wanted to read? So sorry, but it is already here so what can you do??? It is impossible to run a board without expecting it to cost money. But the normal expenses are high enough without having to pay for another board's interest in a network that you have no interest in. And saying that sending "Mod" files is not fair because other files cannot be sent is completely unfair. The "Mod" files that are sent are for a Message base (which is in the Documentation as legit data) and the majority of SysOp's in WWIVnet do benefit from the Mods. I truly believe the whole UU'd discussion took place only because the file's being sent could be considered "unsolicited junkmail". I'm not calling anyone's Network Junk...I along with I'm sure 99% of the other WWIV SysOp's, don't begrudge success to anyone in any project they wish to pursue. We just don't want to foot the bill. Most of us have already agreed that we don't what unsolicited e-mail, so the same would (IMHO) be true of files that have nothing to do with WWIVnet. Although I do not believe that UU'd files should be completely banned, but once the guidelines are abused the abuse will continue. Most of the SysOp's that I know fairly well have no problems with WWIVnet files being UU'd and sent. If someone wants a file bad enough they should pay for it. Whether they are paying for a Commercial file or for the toll charges for a Shareware download. We should all care about each other's feelings, boards and pocket's. We are all in it for the same reason....FUN! We know just how hard we all have to work at keeping our boards running. Have a little respect for your fellow SysOp's and you'll get a lot in return. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Redman (1@16950) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ The practice of sending a UUE of your net package through another net is not a very good idea. This is not a practice that other nets should follow. To start with there was a reason for your starting your own network. And I am sure that one of the reasons was that you felt you had something better to offer. Therefore, having started your own net, it would only be proper that you do not send your net startup package, nor updates through another net. In my opinion you should either call that board or have the board that wants to join, call your board for the package. But to send a UUE of your net package for any reason is not right. I am sure that there is a reason for the UUE's. Otherwise the program would not have been made. But to use it for one network to send your net package over another network (Even if it is just one {this time}) is not right. You and I both know that it is not a 1 time thing. I am sure that many updates (startup) packages are being sent. I am the AC of DEADnet and I WILL NOT SEND the initial package or even an upgrade on someone else's network. Other networks were set up (more then likely) because WWIVnet did not quite suit your needs. Therefore you MUST be obligated to either a) pay for calling the board that wants to join your net, or b) have them call you. Seams BLACK AND WHITE. Reason being that I would not want another network to be sending their updates or start up packages through my net. Look at it this way, those that have set up nets did so with the understanding that their net would be used for their net, not for other networks. Would you like to set up a net and have other networks tieing up all of your members boards sending their network through yours? I do not think so! And to think that you can send it in UUE and then complain because it was deleted is moronic. It plainly states in the doc's that UUE's are allowed for the MOD sub ONLY. Reasoning behind this was so that those that program would be able to send ( small ) exe's and com's in a mod. Plus the big boys of WWIV 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! 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 . 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 log.Since this original program was written, Tolkien has expanded PACKSCAN's features until today, it is a full-featured NETWORK2 pre-processor for WWIV networks. Current features of PACKSCAN v2.31: þ Two versions for systems with different amounts of available memory. The standard version has a well written graphical screen which displays the progress of packet analysis. The memory-saving version gets rid of |07p|15AULIE|1142|07o |08......... --- Mystic BBS v1.12 A47 2021/01/26 (Raspberry Pi/32) * Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (11:1/230) .