Volume 5, Number 29 18 July 1988 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango FidoNews is published weekly by the International FidoNet Association as its official newsletter. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. Copyright 1988 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 Proposal for (yet) another new net ....................... 1 Toward a Virus Free FidoNet .............................. 15 XlaxNode Version 2.10 Release Notice ..................... 17 2. NOTICES .................................................. 18 The Interrupt Stack ...................................... 18 FidoCon/Delta ticket giveaway ends soon! ................. 18 Latest Software Versions ................................. 18 FidoNews 5-29 Page 1 18 Jul 1988 ================================================================= ARTICLES ================================================================= Jack Decker 154/8 PROPOSAL FOR (YET) ANOTHER NEW NET Within the last few months, I've seen a few new nets form as "alternatives" to Fidonet. The problem with many of these, in my view, is that they are almost "special interest" nets... for example, Alternet is the "burnouts" net with a medieval motiff (some say "Dungeons and Dragons"). The "Good Egg Net" is for those who want a return to the simpler days of Fidonet, and has a "National Egg Commissioner" and various titles like that. Personally, the thought of joining a net and having to refer to those higher in the organization as the Duke or Duchess of such-and-such, or Egg Inspector so-and-so, does not really appeal to me. These games are fine for those who enjoy them (and this is not a slam against those who do), but it's just not my cup of tea. I'd guess I prefer a net that's run on a slightly more businesslike basis. At the same time, I see many problems in Fidonet that come about because the workings of Fidonet are often based on assumptions that are not totally valid, and policies that were formulated back in the days before echomail even existed. For that reason, I'd like to propose a new net to be called "LCRNET". LCR Stands for "LEAST COST ROUTING" and describes the most basic guiding principle behind this new net... namely, the primary purpose of this net will be to enable sysops to move netmail and echomail as inexpensively as possible. To this end, any tradition or policy that interferes with the concept of Least Cost Routing will be disposed of post haste. In the next few paragraphs, I'd like to outline just a few specifics of this proposal. I want to find out if anyone else is interested in such a net, and if so, solicit ideas for the best way to implement it. HOW DOES LCRNET DIFFER FROM FIDONET? LCRNET will make some major breaks with time-honored Fidonet conventions, but where possible we want to retain enough compatibility with Fidonet that we can still pass netmail and echoes back and forth. Unfortunately, unless someone can come up with a better idea, the only way that I can see to accomplish this is to follow the precedent set by the other "alternative" nets that have gone before, and assign LCRNET a separate "zone" number. The reason for doing this is that echomail can then be passed through "zonegates" which will have the capability to produce echomail packets in a format acceptable to Fidonet nodes, should any "conversion" be required. FidoNews 5-29 Page 2 18 Jul 1988 NO REGIONS Regions are a political division within Fidonet. They are not used by any echomail or netmail processor for mail routing. It appears that in Fidonet regional divisions have actually worked against Least Cost Routing. The reason for this is that some regional coordinators see their regions as sort of their own little fiefdoms, and regard regional boundaries as sacred. But for many sysops, the least expensive source for echomail may well be on the other side of the artificially-created regional boundary. Thus, I feel that regional divisions have proven to be counter-productive to the efficient operation of the net, and propose that the whole concept of Regions be done away with. ZONES TO BE GATEWAYS TO OTHER NETS Zones, even though on a higher level than nets, are still basically artificial geographic divisions. I feel that "zonegates" can be more useful as gateways to other nets (Fidonet, Alternet, FamilyNet, Eggnet, etc.). However, this is not cast in stone, and if anyone can provide compelling reasons for duplicating Fidonet's zone usage in LCRNET, we can certain consider that aspect of mail addressing. Please note that the country in which a net is located can be determined from the net number if the numbering plan described in the next paragraph if adopted. NET NUMBERS TO BE FOUR DIGIT NUMBERS I have two reasons for this. One is that by using four digit numbers for nets, it will make it much easier to interface LCRNET with Fidonet, which generally uses three-digit zone numbers. The other reason is that we can specify that the first digits of the net number will duplicate the telephone country code for the net where the country is located, thus giving us some opportunity for deterining where a node is geographically located should this become desirable. For example: Net 1xxx = United States & Canada.... 1000 possible net numbers Net 61xx = Australia.... 100 possible net numbers Net 507x = Panama.... 10 possible net numbers Net numbers ending in "99" (for countries with one digit country codes) or "9" (for countries with two or three digit country codes) will be reserved for point nets. These numbers will never appear in the nodelist and thus can be reused for different point nets at various locations throughout a country. They are simply left unassigned as a convenience so that any sysop can create a point net and assign a net number with the assurance that this number will never be used by any "real" net. NO GEOGRAPHIC RESTRICTIONS ON NETS Normally, a net will encompass the local calling area of a city, plus some outlying nodes that may or may not be able to call into the city with a local call. But in LCRNET, the sysop of FidoNews 5-29 Page 3 18 Jul 1988 any given node may join any net he chooses to, providing the net host is willing to allow him in. Joining a net at some distance away because it is a low-cost or no-cost call to that location is specifically permitted, and even encouraged. By the same token, there will be no prohibition against having more than one net covering the same geographic area. LCRNET is not a geographically-driven net... cost is the driving factor. Nodes can even join nets in other countries if they wish (in which case they will use the net number of their net host). This is to avoid restricting a node that may have access to a special calling service (for example, a foreign exchange line to a distant city) from joining a net in that distant city, but it is also designed to avoid the situation where a net host can become overbearing on the nodes under him. There are no monopolies in LCRNET, any node is free to join any net that will take him in. Net hosts in LCRNET should be willing to take in nodes outside their local geographic area so long as it does not increase their costs and so long as the node has a reasonably good reason for wanting to join. A "personality conflict" with the local net host *may* be considered good reason for him to join another net, however, net hosts are not required to take in nodes that have proven themselves to be "twits" in other nets. SOFTWARE BREAKS WITH FIDONET Certain assumptions that were considered valid in Fidonet are specifically NOT valid in LCRNET. These include: Invalid assumption #1: File attaches are never forwarded. In LCRNET, a good sysop will try to provide a way to forward file attaches (netmail messages with files attached) so long as they do not increase his costs. In other words, file attaches need not be forwarded if the sysop is paying a per-minute toll charge to send netmail, but local file attaches (and those that can be sent via PC Pursuit and similar services) SHOULD be forwarded to the destination node. This may in some cases require the use of software that is not yet available, so this goal may not be attained immediately. Please note that just because the capability to forward file attaches is present does not mean it should be used. Anyone planning to forward a very large file, or to forward files on a regular basis, should probably obtain permission first from the sysops of the systems through which such files will pass. Invalid assumption #2: ARCA and ARCE are the "standard" ARCing and deARCing programs. ARCA and some versions of ARCE do NOT support "squashing" which is the most efficient method of packing many netmail archives. Therefore, in LCRNET the "standard" programs will be PKARC and PKXARC. Some sysops may not be able to use PKARC during the FidoNews 5-29 Page 4 18 Jul 1988 mail packing process so they may continue to use ARCA as an interim measure, but they should at least try to use PKXARC to unARC files. Many mail tossers now allow the option of using PKXARC to unpack files, and conversion programs (e.g. ARC2PK) are available for use with other systems (such as Opus 1.03b). Programs that are totally incapable of at least unARCing "squashed" archives shall be considered non-standard in LCRNET. Invaild assumption #3: Netmail (or matrix mail, as it is sometimes called) is always sent direct, or from net host to net host. In LCRNET, it is considered desirable to send messages at the lowest possible cost. Therefore, within the United States all Net Hosts that are not themselves PC Pursuitable shall make arrangements to "home" their mail traffic to a node in a PC Pursuitable city (net hosts in other countries, particularly those in Canada, may optionally elect to do this as well). When this is done, the PC Pursuitable node to which netmail traffic for this net can be routed should be listed under an AI: flag in the nodelist comment field (see NODELIST FLAGS). Since LCRNET attempts to route netmail messages over "no cost" routes, or at very least along with regular echomail packets, the use of software that allows "return receipts" to be generated shall be considered a desirable feature. One other break with Fidonet is that the use of "tiny" SEEN-BY lines and tight control over network topologies will be encouraged. Sending duplicate messages around the net shall be considered an EXTREMELY undesirable action. Therefore, all nodes carrying echomail shall, whenever possible, use software that supports the ^APATH: line (e.g. ConfMail) so that the source of duplicate messages can be easily determined. In addition, NO NODE SHALL RECEIVE THE SAME ECHO FROM TWO DIFFERENT FEEDS, unless he specifically informs BOTH feeds of what he is doing and they BOTH authorize it, and steps are taken to avoid the introduction of DUPE messages into the net. POLITICAL BREAKS WITH FIDONET I would like to leave politics out of LCRNET as much as possible. This is one reason I advocate eliminating Regions, as these simply create small fiefdoms that tend to give certain individuals too much power. In addition, I advocate the following breaks with Fidonet: CONFERENCE MODERATORS TO BE SUPREME OVER THEIR CONFERENCES In LCRNET, a conference moderator has more authority and more responsibility than in Fidonet. In LCRNET, the moderator shall try to keep an accurate topology map of his conference, and to know at all times where a given node is receiving the conference from, and who he is sending it to. The only exception to this is that if one node is feeding the conference to other nodes in a given net, the conference moderator need not be informed of those who add and drop the conference within the net. FidoNews 5-29 Page 5 18 Jul 1988 Any LCRNET node receiving a conference shall provide a comple list of the nodes he is receiving the conference from, or that he is sending the conference to, at the request of the moderator. The conference moderator may, for good cause, rename a conference (to avoid name confusion with another conference, or to facilitate merging the conference with another of the same name) and/or direct that links to a particular node be cut. Valid reasons for cutting nodes to a link could include any of the following: 1) Messages originate from that node that contain foul language. Those who believe in total freedom of speech and the right to say anything, anywhere, at any time will NOT be happy in LCRNET and are encouraged NOT to join. The intent is that LCRNET will be more like Alternet than Fidonet in this regard. Profanity and foul language shall normally be considered bad behaviour in LCRNET unless a conference moderator specifically allows them in a given conference. HOWEVER, no LCRNET node shall under any circumstances be required to carry or pass along an echo in which profanity or foul language are allowed. 2) Messages originate from a node that contain personal attacks on others. It is one thing to disagree with someone else's viewpoints, quite another to attack their intelligence or background, etc. As with foul language, personal attacks shall normally be considered bad behaviour in LCRNET, and no LCRNET node shall under any circumstances be required to carry or pass along an echo in which they are tolerated. 3) Messages originate from a node that consistently violate the stated rules of an echo. Also, a conference moderator is not required to put up with users that consistently "test the limits" of the moderator's patience by trying to see how close they can come to breaking a rule without actually breaking it (for example, using "veiled" profainty in which the meaning is fairly obvious, or "near" personal attacks). 4) Messages originate from a node that contain illegal information (stolen credit card numbers, etc.), that are patently obscene, or that contain remarks designed to stir up hatred or advocate violence between people of different races, religions, etc. These types of messages are specifically NOT ALLOWED in LCRNET. Note that in regard to illegal information, a message must actually CONTAIN illegal information to violate this rule. For example, a message that states "I think everyone ought to use stolen credit cards" would not violate THIS rule, though it might violate a posted rule of the conference in question. But a message that CONTAINED stolen credit card numbers WOULD violate this rule. 5) In the case of religious or political echoes that are intended as "meeting places" for people of like mind, links may be cut to nodes that constantly allow messages that agitate against these beliefs. For example, if a conference were set up FidoNews 5-29 Page 6 18 Jul 1988 for the express purpose of discussing how best to implement the Strategic Defense Initiative, a node that consistantly allows messages to be posted discouraging the whole concept, advocating a nuclear freeze, etc. could be cut from the conference. The test here shall be whether the conference is set up primarily for people of like mind to share thoughts and ideas, or whether the conference is considered "open to unbelievers". However, even in the latter case, a node may be cut for specific repeated violations of conference rules. 6) Links may be cut to a node if the Sysop of that node refuses the legitimate request of the conference moderator to provide a list of nodes that he is receiving the conference from and sending the conference to. The conference moderator must have this information available in order to track down the source of duplicate messages, or messages that consistently violate the rules of LCRNET or of the echo itself. However, conference moderators shall not pass out this information to others if the Sysop requests that such information be kept confidential, unless such disclosure is necessary to prove that a rule violation has occurred when cutting links to that node. ECHOES CARRIED ON LCRNET DO NOT AUTOMATICALLY BECOME "PUBLIC DOMAIN" The one and only purpose of this statement is to assure conference moderators that they are allowed to pull their conferences OFF of LCRNET should they feel the absolute need to do so. We hope that the greater authority afforded to moderators on LCRNET would never make this necessary, but a moderator does have the right to do this if he or she feels it necessary. LCRNET echoes may NOT be carried by nodes belonging to any other net (Star or backbone nodes in particular) unless they agree to this condition. ECHOMAIL HUBS MAY NOT CUT ECHO FEEDS FOR POLITICAL REASONS In Fidonet the situation has sometimes come up where a node will cut all echomail feeds to another node because of some disagreement between the two sysops. Thus, control over echomail feeds becomes a form of "blackmail" over another sysop. This sort of thing is considered EXTREMELY bad behaviour in LCRNET. Generally speaking, no LCRNET node is required to bring any given conference into an area, but when it does bring in a conference and offers it to other nodes, it must offer it on a non-discriminatory basis. The only valid reasons for refusing to send a conference to a node are as follows: 1) The conference moderator has directed that links to this node for a particular conference be cut, as specified above. 2) Providing the conference would cause the node to incur additional costs. Obviously, this is not valid if the conference can be sent via a flat-rate medium such as PC FidoNews 5-29 Page 7 18 Jul 1988 Pursuit, or if the receiving node offers to poll for the echoes. 3) Technical limitations... for example, a node is running Opus software and is already sending a given echo to ten other nodes (the maximum allowed in Opus). But if the node receiving the request for a feed is the ONLY no-cost source for that echo available to that node, some sort of arrangement should be made to try and accommodate that node. 4) Technical problems at the receiving node... for example, no one is required to provide feeds to a node that constantly generates "dupe" messages. Please keep in mind that the primary motivation of LCRNET is to reduce costs for all involved. Therefore, if you are the only no-cost source of an echo to a given node, and you refuse to provide the echo to that node, you should have a VERY good reason for the refusal. PASSING ON COSTS Nodes that wish to become Echomail hubs for a given area should be prepared to absorb the expenses incurred in that operation. This is not to imply that two or more nodes cannot share costs incurred in bringing echoes into an area, but this should be considered the exception rather than the rule. If a node is using a flat-rate service such as PC Pursuit to bring echoes into a given area and wishes to split the monthly cost with other nodes, it shall be divided equally among all nodes receiving the echoes. For example, if one node is receiving echoes and distributing them to four other nodes, this means that five nodes are benefiting from the echoes, so each node should pay one-fifth of the monthly charge ($5 in the case of PC Pursuit at $25 per month). Costs should not be assessed on number of echoes received since this discourages nodes from carrying new echoes. Again, however, this type of cost sharing should be considered the exception rather than the norm (primarily since the person holding the flat-rate account can use it for non-BBS related activites, and thus derives greater benefit from it). Cost sharing of non-flat-rate services (e.g. regular long distance charges) is officially discouraged because it almost invariably leads to arguments and hard feelings over whether everyone is paying their "fair share". NET HOSTS GOVERN AT THE PLEASURE OF THE NET SYSOPS Despite the cries for a "democracy" in Fidonet, I don't feel that net hosts should be subject to the necessity of "campaigning" and running a "popularity contest" periodically. Many sysops have stated they simply would not take a position under such circumstances. However, nothing in the LCRNET rules will PREVENT the formation of democratically-governed nets, where the Net Host is elected by the sysops in the net, but in such cases the rules for such elections shall be decided by the FidoNews 5-29 Page 8 18 Jul 1988 net itself. Please keep in mind, however, that nothing in LCRNET rules prevents the formation of two different nets that cover the same geographical area. There are no monopolies in LCRNET! Thus if a number of sysops feel that they cannot function under the current net host, and he or she cannot be persuaded to resign, those sysops are perfectly free to start another net. However, things should not be allowed to deteriorate to the point where this is necessary if at all possible. LCRNET should be a net of cooperation, not competition. Net hosts who feel the need to dictate many rules or policies for their own net (in addition to those in this document) might be happier in another net. Above the Net level, there are no intermediates until you reach the national/international level. I am open to suggestions for the type of organization we should have there. However, any positions at those levels will be unpaid, volunteer positions. LCRNET will not hold conventions in fancy hotels, nor squander money. There will be no "dues" to be in LCRNET, or any organization connected with LCRNET. There will be no "poll tax" to vote on any issue facing LCRNET. We do reserve the right to ask for voluntary contributions should that become necessary, but the word VOLUNTARY is emphasized... no coercion or pressure shall be put on anyone to "contribute", and no disparaging remarks shall be made about anyone because they did not contribute. In any vote held in LCRNET, the principle of "one person, one vote" shall be strictly adhered to. That means that each sysop listed in the LCRNET nodelist gets one vote, regardless of the number of systems he may sysop. THE NODELIST The LCRNET nodelist will NOT be used as a political tool. NO ONE shall be dropped from the LCRNET nodelist unless their node goes offline or is consistantly unreachable during the Fidonet Zone Mail Hour (which LCRNET nodes will be expected to observe until or unless we adopt a different mail hour). A node shall NOT be dropped from the nodelist because of a personality conflict with someone else, however they may be dropped for consistant and pervasive violations of the rules in this document. What this means is that unless somebody is such a blatent and obvious jerk that almost everybody in the net hates his guts, he will not be dropped from the nodelist. Net hosts should be aware that anyone dropped from their net is perfectly free to apply to be included in another net. Conversely, however, since nets are not strictly geographically based, there will be no "independent" nodes in LCRNET. A node that might be "independent" in another net should try to join a net in a major city (in the United States it would be preferable to join one based in a PC Pursuitable city). This also gives us some control over "twit" sysops because if a sysop gains a really bad reputation, chances are that no net host will take FidoNews 5-29 Page 9 18 Jul 1988 him into his or her net (for very long, anyway). Of course, the "twit" sysop can always start his own net, but a net by definition consists of MORE THAN ONE node (controlled by more than one sysop). Once again, if a net host takes an action that will cost someone else money (for example, dropping someone from a local net, thus forcing them to call long distance to pick up mail from another net) they should have a VERY good reason for doing so. NODELIST FLAGS We intend to expand the number of valid nodelist flags from those allowed in Fidonet, and are open to suggestions. However, LCRNET will allow a specific new flag, as follows: AI:net[/node][,net[/node],net[/node]...] The net/node(s) listed are alternate nodes to which inbound mail can be sent. These are nodes which either the sysop or his net host polls regularly. LCRNET net hosts located in the United States but not in a PC Pursuit inbound area will be expected to use this flag to indicate at least the PC Pursuitable node on which they "home" for netmail traffic. If only a single number is listed after the AI: designator, it will be taken as a net number and netmail can be directed to the net host of that net (net/0). For example: AI:1234 is equivalent to AI:1234/0 Let's take a typical situation. Node 1777/80 and his net host, 1777/0 are in a non-PC Pursuitable city and in addition, 1777/0 is not a PC Pursuit user. However, he regularly picks up echoes from 1876/0, who IS a PC Pursuit user and who regularly calls 1323/5 in a PC Pursuitable city to pick up echoes. Here's how the AI: field might read for each of these nodes: 1777/80 - AI:1876,1323/5 - In this case, 1777/80 can receive netmail sent to 1777/0 (his normal inbound host, which is assumed), 1876/0, 1323/5, or 1323/0 (the net host for 1323/5). 1777/0 - Same as for 1777/80, since he can receive from the same nodes. 1876/0 - AI:1323/5 - In this case, 1876/0 would list the PC Pursuitable node that he polls regularly. Mail for him could be sent to 1323/5 or 1323/0 (the net host for 1323/0). 1323/5 would not be required to use an AI: in the nodelist, since he's in a PC Pursuitable city. Now let's see how the actual routing of incoming netmail would be handled. Let's assume a "worst case" situation, where a piece of netmail intended for 1777/80 is sent to 1323/0. 1323/0 would have a statement in its routing control file FidoNews 5-29 Page 10 18 Jul 1988 similar to this: ArcCM 1323/5 1876/ALL 1777/ALL This would route the mail for net 1777 to 1323/5. 1323/5 would have a statement in its routing control file like this: ArcHold 1876/0 1876/ALL 1777/ALL This would route the mail for net 1777 to 1876/0. 1876/0 would have a statement like this: ArcHold 1777/0 1777/ALL This would send the mail for net 1777 to the Net 1777 host, where it would finally get set to 1777/80. Note that in this case, the mail could pass through several systems before reaching its destination. This is why all net hosts at least are encouraged to "home" directly on PC Pursuitable cities whenever this can be done without incurring additional expense. In Fidonet, speed of mail delivery is considered of primary importance, regardless of the expense. In LCRNET, cost is the driving factor. This is one major difference between the two nets. Of course, there is nothing to prevent an LCRNET sysop from directly crashing messages to another system without routing them, so really important messages can always be sent immediately, albeit at higher cost. MODEM TYPE FLAGS The use of the following modem type flags will be specifically allowed in the nodelist comment field: HAY Hayes V series HST USRobotics HST MAX Microcom AX/9624c PEP Telebit Trailblazer MNP MNP error correction protocol available Further suggestions are welcome. CONTINUOUS MAIL In LCRNET, the ability to send and receive continuous mail shall be considered the norm (except where hours of operation are given). Software that does NOT have this ability shall be so indicated by the special nodelist flag NC (for Non-Continuous). As an interim measure, the CM: flag may be used by all systems that can receive mail continuously (24 hours a day) in order to be compatible with existing nodelist processors. It is hoped that new software can be written for use with LCRNET that will recognize and properly process the new nodelist flags. STATEMENT ON "POINTS" AND THEIR PURPOSE FidoNews 5-29 Page 11 18 Jul 1988 In LCRNET, a "point" is a regular BBS user who calls into a BBS using software that will pick up the echoes he wishes to read, and allows him to read and reply to those echoes offline. The main difference in LCRNET Is that here it is quite acceptable for the BBS operator to make the outgoing call to the "point" on a prearranged schedule, if by doing so a lower cost to the user can be achieved. The BBS operator may recover any long distance costs incurred in doing this from the "point" user. BBS operators are never "points". If a BBS operator is unable or unwilling to observe the Zone Mail Hour but would otherwise qualify to be in the nodelist, he or she should be listed as a private, unlisted node. No one who is running compatible software shall be denied listing in the LCRNET nodelist just because they are running a private node that is not available to the general public. INTERCONNECTIONS WITH OTHER NETS The main purpose of LCRNET is to encourage communications at the lowest possible cost. Therefore, interconnections with other nets shall be encouraged. However, wherever possible these shall take place through "gateway" systems wherever echomail is involved (except for local or private conferences circulated to a very small or tightly controlled group of nodes). There are two reasons for this: One is to prevent "dupe" messages from flowing from one system into another. If all messages between the two nets pass through a single "gateway" system, then the dupe killer at that system should prevent any duplicate messages from entering the other net. The other reason is that should the quality of the conference begin to deteriorate on the other net to the point where messages coming from that net consistantly violate LCRNET rules, or are mostly irrelevant to the topic of discussion, the link can be easily cut (although this is something that would NOT be done suddenly and without warning). It is realized that in the initial stages of setting up LCRNET, most sysops will continue to get echo conferences through the same Fidonet feeds that they always have. In keeping with the spirit of LCRNET, no sysop will be forced to drop any independent feed of an echo that he is getting from Fidonet or any other net. He MAY be asked, however, not to feed this echo to other LCRNET nodes, particularly where by doing so "dupe" messages are being created. As always, cost will be the motivating factor in deciding how echoes are distributed. MESSAGE CONTENT (FLAMES, ETC.) Most of the restrictions on message content have already been covered. However, there are certain people who can't seem to hold a discussion without resorting to FLAMES, personal attacks, and so on. We would prefer these people NOT attemt to join LCRNET, because we want to have a friendly, happy and sharing FidoNews 5-29 Page 12 18 Jul 1988 net. If you are the type of Sysop who has been embarrassed to let your family read the echomail areas on your BBS because of some of the childish attitudes displayed there, you will probably be welcome in LCRNET. Because nets are not geographically restricted, and there are no regional coordinators of any kind, much of the necessity for FLAMES should be eliminated. If you have a problem with the Net host, join another net, or form your own. If you have a problem with the national leadership, tough toenails... there are other nets around. In LCRNET we want to give everyone choices so that if you find an individual particular abrasive, you can simply ignore him (which will probably infuriate him more than flaming at him anyway... such individuals usually crave attention, even if it's negative). There are no monopolies in LCRNET. Most of the power in LCRNET will rest with the net hosts. It's sort of like choosing a hamburger joint for lunch... if you find the people are consistantly rude in one, you find another. If the other happens to be ten blocks farther away and charges 10 cents more per burger, then you have to decide which is more objectionable to you. What you don't do is stand outside of one or the other and yell and scream and stomp and call the manager names... that will get you nowhere fast... about as far as FLAMES in LCRNET will get you. We want LCRNET to be a nice, discussion oriented net, where common courtesy and politeness are expected and practiced. PRIVATE MESSAGES The official position of LCRNET will be that LCRNET does *NOT* support the transmission of "private" or "confidential" mail. Mail may be intercepted at any point along its path and read by persons other than the intended recipient. LCRNET should not be used to transmit messages of a private or confidential nature. TECHNOLOGICAL ADVANCES We would like for LCRNET to be the network of choice for innovators... those who don't feel constrained by the established norms in software and hardware, for example. Of course, if you are designing software for use in the net, you should attempt to make it as compatible as possible with existing software... after all, it wouldn't do to design a program to toss echomail packets that no other program can read! But it's also okay to make a new program that's "downward compatible" with existing programs. We'd also like to encourage the use of means of communications other than standard telephone lines, especially those means that can lower the cost of communications. We're waiting for the day that all the echomail hubs can stick up a $100 Ku-band satellite dish and simutaneously receive the "4 A.M. National Echomail Feed" every morning. In the meantime, experiments with such items as radio modems, microwave or infrared transmission, FidoNews 5-29 Page 13 18 Jul 1988 direct tie-ins to packet networks, moon bounce, or anything else folks might want to try are encouraged in LCRNET. You will not find a "Technical Standards Committee" here telling you that "you can't do that because it will obsolete the piece of software I wrote three years ago." Again, this does not imply that you should be TRYING to "break" existing software, but we certainly are open to whatever you may be doing... particularly if it will wind up saving money for sysops. WANT TO JOIN US? If you think you'd be interested in being part of LCRNET, please send Netmail to Jack Decker at 154/8. Send flames to NUL. I know some of you detest the formation of new nets, and frankly, I couldn't care less. Fidonet long ago stopped being responsive to the needs of the "average sysop", and recently seems to have become a haven for petty self-appointed demagogues. We want to provide an alternative to that sort of nonsense. If enough interest is expressed, we will form this net and issue a nodelist. If you'd like to be a net host in this net, please so indicate and also indicate your choice for a net number (remember that it must be a four digit number that begins with your country's telephone country code). Constructive suggestions and criticisms (other than "don't do this"... if there's enough interest we will, if there's not, we won't) will be welcome and will be considered! And if anyone with writing skills would care to polish this document into a basic LCRNET policy document, it would be very much appreciated. Your input is welcomed. If you feel that we should go ahead with this, then at this point I especially need input on what sort of national leadership we should have. My own preference is for a rather loose, informal organization at the top that would perhaps only be responsible for getting out the nodelist and mediating any disputes in regard to LCRNET rules, but I'm certainly very open to other suggestions! We have started an echo called LCRNET (naturally) which is hubbed off of Fidonet node 154/7 (a PC Pursuitable node) for further discussion. This echo is is just starting and if you are interested in seeing this proposal inplemented and would like to be part of such an echo, please send netmail. One other point... I can almost bet that once this proposal hits the wires, somebody's going to accuse me of trying to start my own little fiefdom. Well, I'm not going to spend a lot of time debating with such people, I will just simply say that it isn't true, but you can believe it if you want to. You can also believe the earth is flat if you want to. However, I do *not* see myself in a leadership position in LCRNET... there are many others who have much better organizational talents that could probably do a much better job of running such an organization (to whatever extent that it needs anyone to "run" it at all). I have been around Fidonet long enough to realize that there's no FidoNews 5-29 Page 14 18 Jul 1988 way I'm going to make this proposal without getting a few personal attacks, but I would much rather see the debate center on the actual proposal itself. And if anyone in Fidonet or any other net would care to "borrow" any ideas from this document, by all means please feel free to do so. If all this document accomplishes is to give someone in another net some ideas for their net, then it will have served a useful purpose. ----------------------------------------------------------------- FidoNews 5-29 Page 15 18 Jul 1988 Toward a Virus Fee FidoNet by Bob Hartman 1:132/101.1 In the interest of helping people make sure that the programs which they use are free from viruses, I have made the following list. This list is the output from PKARC version 3.6 on various archives that I KNOW are virus free. I know this because I was the person that created the archives, and compiled the original programs within them. The command used to create the list was: PKARC V archive > output I then edited the output to fit into FidoNews by deleting some of the information which is unimporant (like the method of archiving). If you do the same command, and compare to the output below, be wary of any program which does not match the numbers below EXACTLY! I would even appreciate being warned of any such mismatches. A file containing this article, including any updates will always be requestable from 1:132/101 under the magic filename "NO_VIRUS.CRC". Searching Archive: BEXE_150.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- BINKLEY.CFG 7747 3860 51% 05-05-88 22:13:16 33D6 BOB.WHY 13886 6821 51% 05-07-88 17:19:22 F71D BT.EXE 107421 79965 26% 05-07-88 04:07:00 8D69 BTCTL.EXE 14339 11476 20% 05-07-88 04:07:16 AB35 BT_REF.DOC 81466 32829 60% 05-06-88 18:19:36 90A2 BT_USER.DOC 81628 34219 59% 05-06-88 18:33:14 30E8 RELEASE.DOC 5787 2712 54% 05-06-88 18:36:20 82BB VINCE.WHY 9828 4869 51% 05-07-88 16:36:06 74A5 ---- ------ ------ ----- 0008 322102 176751 46% Searching Archive: CAL_110.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- CALENDAR.C 12189 5733 53% 05-09-88 14:24:46 48B4 CALENDAR.CFG 519 344 34% 05-09-88 14:19:34 9C82 CALENDAR.DOC 850 612 28% 05-09-88 14:27:28 2B47 CALENDAR.EXE 17115 13592 21% 05-09-88 14:25:04 6CB2 ---- ------ ------ ----- 0004 30673 20281 34% Searching Archive: CONFMAIL.ARC Filename Length Size Ratio Date Time CRC FidoNews 5-29 Page 16 18 Jul 1988 -------- ------ ------ ----- ---- ---- --- CONFMAIL.DOC 88989 34754 61% 12-12-87 14:19:50 255D CONFMAIL.EXE 80569 57433 29% 12-31-87 15:20:52 0D2D READ.ME 1009 688 32% 12-12-87 14:26:02 8708 ---- ------ ------ ----- 0003 170567 92875 46% Searching Archive: PLST_110.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- PARSELST.CFG 5921 2843 52% 05-09-88 15:24:08 02D5 PARSELST.DOC 35772 13316 63% 05-15-88 16:40:56 9831 PARSELST.EXE 49437 37428 25% 05-16-88 03:04:38 377E READ.ME 1231 681 45% 05-10-88 23:05:26 142F ---- ------ ------ ----- 0004 92361 54268 42% Searching Archive: REMAPPER.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- REMAPPER.DOC 7161 3485 52% 11-23-87 13:17:14 F07D REMAPPER.EXE 21741 17245 21% 12-12-87 14:35:04 8D46 ---- ------ ------ ----- 0002 28902 20730 29% Searching Archive: RENUM40.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- RENUM.DOC 3302 1779 47% 03-23-88 03:07:46 0CDA RENUM.EXE 17917 14405 20% 03-23-88 03:08:26 DF4D RENUM.NEW 1184 671 44% 03-23-88 03:14:02 3AED ---- ------ ------ ----- 0003 22403 16855 25% Searching Archive: REPLYLNK.ARC Filename Length Size Ratio Date Time CRC -------- ------ ------ ----- ---- ---- --- REPLYLNK.DOC 2344 1350 43% 03-23-88 03:41:24 0F78 REPLYLNK.EXE 19181 15210 21% 03-23-88 03:41:58 1FEF ---- ------ ------ ----- 0002 21525 16560 24% ----------------------------------------------------------------- FidoNews 5-29 Page 17 18 Jul 1988 Scott Samet 1:135/990 XlaxNode Version 2.10 XlaxNode Version 2.10 is now available for general release. XlaxNode is a high performance replacement for a number of popular nodelist utilities. The raw nodelist is compiled directly to Opus 1.0x, Opus 1.1x, Binkley, QuickBBS and/or Seadog format in a single step. No intermediate files or programs are needed. All sorts are internal. Xlax_210.Arc (151K) is available for file request from the following nodes. Unless otherwise noted, they are 2400 baud and accept file requests from one hour after NMH to one hour before NMH. All are Pursuitable via D/FLMIA. 135/4 135/8 HST-9600 Baud 135/10 135/11 Requests honored 0700-0100 EDT; HST-9600 Baud 135/27 1200 only 135/35 1200 only 135/41 XlaxNode emulates almost all of the functions of XlatList, OpusNode, NLComp, PCPFix, PCPExch, PCPExch2, QNode and ParseLst. XlaxNode also adds features not found in any of these programs. Processing is typically two to five times faster than these programs. Users of previous versions will find a number of improvements. Version 2.10 is smaller and, for many options, faster. A number of bugs have been fixed. QuickBBS and Binkley NodeList.Ext support has been added. One NodeList.Idx file can be shared by all three data files. Any or all of the output files can be created in a single pass. The nodelists can be tailored, selecting the zones and nets desired. Output can range from a single net to the entire nodelist. Support for multi-zone nodelists has been enhanced. The Opus 1.1x message and call cost fields are supported. PC Pursuit processing can be enabled or disabled for individual output files. 2400 baud script support has been improved. The companion program, XlaxDiff, included in the archive, applies the weekly NodeDiff update file. The license permits a thirty day trial period, after which a $10 per node fee is required. ----------------------------------------------------------------- FidoNews 5-29 Page 18 18 Jul 1988 ================================================================= NOTICES ================================================================= The Interrupt Stack 25 Aug 1988 Start of the Fifth International FidoNet Conference, to be held at the Drawbridge Inn in Cincinnati, OH. Contact Tim Sullivan at 108/62 for more information. This is FidoNet's big annual get-together, and is your chance to meet all the people you've been talking with all this time. We're hoping to see you there! 24 Aug 1989 Voyager 2 passes Neptune. 5 Oct 1989 20th Anniversary of "Monty Python's Flying Circus" If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- -> -> -> FidoCon/Delta ticket giveaway ends soon! <- <- <- One free round-trip ticket from Delta Airlines to anywhere Delta flies in the continental U.S. is about to be given away! You can have a chance to win this ticket by registering for FidoCon'88 in Cincinnati before the July 15th deadline! Your chance to fly Delta free depends upon you! Just complete the registration form found in FidoNews, from your Net host or on 1/88. If you mail your registration it should be postmarked no later than July 15th. If you NetMail your registration it should arrive at 1/88 no later than July 15th. The winner will be announced at FidoCon. See you there! ----------======---------- ----------------------------------------------------------------- Latest Software Versions BBS Systems Node List Other & Mailers Version Utilities Version Utilities Version FidoNews 5-29 Page 19 18 Jul 1988 Dutchie 2.90* EditNL 4.00* ARC 5.22* Fido 12h MakeNL 2.12* ARCmail 1.1 Opus 1.03b Prune 1.40 ConfMail 3.31 SEAdog 4.10 XlatList 2.86 EchoMail 1.31 TBBS 2.0M XlaxNode 2.10* MGM 1.1 BinkleyTerm 1.50 XlaxDiff 2.10* QuickBBS 2.01 ParseList 1.10 * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 5-29 Page 20 18 Jul 1988 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Ken Kaplan 100/22 Chairman of the Board Don Daniels 107/210 President Mark Grennan 147/1 Vice President Dave Dodell 114/15 Vice President - Technical Coordinator David Garrett 103/501 Secretary Leonard Mednick 345/1 Treasurer IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Steve Jordan 102/2871 Don Daniels 107/210 11 Bill Allbritten 11/301 Hal DuPrie 101/106 12 Leonard Mednick 345/1 Mark Grennan 147/1 13 Rick Siegel 107/27 Brad Hicks 100/523 14 Ken Kaplan 100/22 Ted Polczyinski 154/5 15 Jim Cannell 128/13 Kurt Reisler 109/74 16 Vince Perriello 141/491 Robert Rudolph 261/628 17 Rob Barker 138/34 Greg Small 148/122 18 Christopher Baker 135/14 Bob Swift 140/24 19 Vernon Six 19/0 Larry Wall 15/18 2 Henk Wevers 2:500/1 Gee Wong 107/312 ----------------------------------------------------------------- FidoNews 5-29 Page 21 18 Jul 1988 Rob Barker 138/34 Chairman, Elections and Nominations Committee RULES AND PROCEDURES The next two pages are your Official ballot for the Election of the IFNA Board of Directors. The following are the few rules which must prevail in this election: 1. You must send a legible copy of this ballot to the address listed on the ballot or cast your vote in person at the conference prior to the closing of the election Polls. It must be signed and bear your current net/node number. 2. You may vote for any person in your Division for the position of Divisional Director. This vote is to be cast in the LEFT column of the ballot. 3. You may vote for any six people for the position of Director at Large. These votes are to be cast in the RIGHT column of the ballot. 4. Voting will continue until the end of the Conference registration on the 25th of August, 1988. Ballots which are mailed must reach the address listed below prior to Wednesday, 24 August 1988. The results will be read during the opening of business meeting on the first day of the conference. 5. Write-in votes will be accepted and are requested during this election. IFNA Board Of Directors Ballot Candidate Net/Node Divisional At-Large Vote Vote ------------------ --------- ---------- -------- DIVISION 2: Henk Weavers 500/1 (1) DIVISION 10: Jim Bacon 103/507 _____ _____ Courtney Harris 102/732 _____ _____ Steve Jordan 102/2871 _____ _____ DIVISION 12: Bill Bolton 711/403 _____ _____ Leonard Mednick 345/1 _____ _____ FidoNews 5-29 Page 22 18 Jul 1988 DIVISION 14: Glen Jackson 100/517 _____ _____ Ken Kaplan 100/22 _____ _____ DIVISION 16: Vince Perriello 141/491 (1) DIVISION 18: Chris Baker 18/14 (1) ADDITIONAL AT-LARGE Steve Bonine 115/777 _____ Don Daniels 107/210 _____ Dave Melnik 107/233 _____ Robert Rudolph 261/628 _____ Greg Small 148/122 _____ ________________ _________ _____ ________________ _________ _____ ________________ _________ _____ (1) This candidate has been elected to the office of Divisional Director with no further voting procedure necessary as per By Law #11. "The Nominations and Elections Committee shall delete the name of any nominee who mayt be ineligible for election and the name of any who may withdraw by written communications. The remaining names shall be listed on a ballot, in alphabetical order. IF THERE BE BUT ONE ELIGIBLE NOMINEE, THE NOMINATIONS AND ELECTION COMMITTEE SHALL DECLARE HIM ELECTED WITHOUT BALLOTING BY THE MEMBERSHIP. (Emphasis added. -rb) If there be more than one eligible nominee, then at least 45 days prior to the Annual Meeting the Secretary shall send by mail to every voting member, and publish in FidoNews, a ballot listing the candidates for director. The ballot shall contain a copy of the current voting rules." Name ______________________________ Net/Node ___________ Signature______________________________ Date ___________ Please complete this and mail it to: Rob Barker IFNA Elections Committee 7406 - 27th Street West Suite #7, Plaza West Tacoma, Wa 98466 or bring it with you when you come to the conference in August. FidoNews 5-29 Page 23 18 Jul 1988 Thank You Rob Barker Elections and Nominations Committee ----------------------------------------------------------------- FidoNews 5-29 Page 24 18 Jul 1988 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (tm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays the annual membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. Name __________________________________ Date ___________________ Address _________________________________________________________ City ____________________________________________________________ State ________________________________ Zip _____________________ Country _________________________________________________________ Home Phone (Voice) ______________________________________________ Work Phone (Voice) ______________________________________________ Is this a new application? _________ a renewal? ________________ Are you a Sysop? _________ If so, for how long? ________________ Your BBS Info: (Non-Sysops enter info for your most-called BBS) Zone:Net/Node Number ____________________________________________ BBS Name ________________________________________________________ BBS Phone Number ________________________________________________ Your Special Interests __________________________________________ _________________________________________________________________ _________________________________________________________________ In what areas would you be willing to help in FidoNet? __________ _________________________________________________________________ _________________________________________________________________ Are there any special resources that you could provide? _________ _________________________________________________________________ Regular Membership $25 Lifetime Membership $250 Send this form and a check or money order in US Funds to: International FidoNet Association c/o Leonard Mednick, CPA 700 Bishop Street, #1014 Honolulu, HI 96813 USA IFNA is a general not-for-profit organization. Articles of Association and By-Laws were adopted by the membership in January 1987. The IFNA Echomail Conference has been established on FidoNet to assist the Board of Directors. We welcome your input on this Conference. ----------------------------------------------------------------- FidoNews 5-29 Page 25 18 Jul 1988 INTERNATIONAL FIDONET ASSOCIATION ORDER FORM Publications The IFNA publications can be obtained by downloading from Fido 1:1/10 or other FidoNet compatible systems, or by purchasing them directly from IFNA. We ask that all our IFNA Committee Chairmen provide us with the latest versions of each publication, but we can make no written guarantees. Hardcopy prices as of October 1, 1986 IFNA Fido BBS listing $15.00 _____ IFNA Administrative Policy DOCs $10.00 _____ IFNA FidoNet Standards Committee DOCs $10.00 _____ SUBTOTAL _____ IFNA Member ONLY Special Offers System Enhancement Associates SEAdog $60.00 _____ SEAdog price as of March 1, 1987 ONLY 1 copy SEAdog per IFNA Member Fido Software's Fido/FidoNet $100.00 _____ Fido/FidoNet price as of November 1, 1987 ONLY 1 copy Fido/FidoNet per IFNA Member International orders include $10.00 for surface shipping or $20.00 for air shipping _____ SUBTOTAL _____ HI. Residents add 4.0 % Sales tax _____ TOTAL _____ SEND CHECK OR MONEY ORDER IN US FUNDS: International FidoNet Association c/o Leonard Mednick, MBA, CPA 700 Bishop Street, #1014 Honolulu, HI. 96813-4112 USA Name________________________________ Zone:Net/Node____:____/____ Company_____________________________ Address_____________________________ City____________________ State____________ Zip_____ Voice Phone_________________________ Signature___________________________ -----------------------------------------------------------------