========================================================================= Combined VirNet policy and echomail/netmail/nodelist/filenet policy V3.00betaB (12-Jun-94) ========================================================================= Note: This document is not in place yet! This is only a proposal for a new policy document. If this document is in place, these lines between "Note:" and "Contents ...." will then disappear. Changes between the last and current (this document) are not marked with a "#" at the beginning of each line, since there where too much changes to the last proposal. ;-) Changes: (11 Jul 93) - First release [... Lots of changes. For details, see previous documents] (12 Jun 94) - Midnight release Added technical guidelines Reworked the whole policy for easier understanding Contents of this document: -------------------------- 0. Preface. 1. Netmail, echomail and file export. 1.1 Bombing runs 2. Your own nodenumber. 2.1 Mailer-restrictions for akas. 3. Pvt Nodes and Points. 4. Use of nodenumbers. 4.1 The difference between coordinators and hosts and hubs in VirNet. 4.2 International Coordinator. 4.3 Zonehost. 4.4 Regionhost. 4.5 Nethost. 4.6 Nethub. 4.7 Nodes. 4.8 PVT-Nodes 5. VirNet nodelist = Routing list. 5.1 Who assigns nodenumbers. 5.2 Other information about nodenumbers. 5.3 Nodelist flags. 6. Listed Only nodes (nodelist flags). 7. AntiVirus helpnodes. 8. Gateways. 8.1 Gateway approval. 8.2 Gateways, what is forbidden? 9. Magic Filenames and available echos. 10. Hatching files. 11. VirNet node application. 12. Regular Polling. 13. Comercial and Hobby-Nodes. 14. Replacement and removal precedures. 15. Complaints 16. Regional policys. 17. Voting in VirNet. 18. Replacing this policy. 99. The editors of this document. 0. Preface. This policy document is written in an informal way in order to make it easy for anyone to understand what it is intended to say. This policy is covering some of the more important aspects of the net that applies to everyday use. What is VirNet all about? VirNet is a specialized network of BBSes that are interested in the subject virus/antivirus. The idea behind VirNet is to spread information about viruses and the programs that will help you get rid of viruses as fast as possible. VirNet was started in February 1991, By Mikael Larsson, Sweden. How does it work? VirNet makes use of the widespread Fido (tm) technology, therefore it is a 'FTN' (Fido Technology Network). To join it, your software has to support at least the technical matters described in the current revisions of the 'FTS' (FidoNet Technical Standard) documents as supplied by the 'FSC' (FidoNetStandards Commitee). Your software must be able to distribute files using a TICK-compatible fileprocessor. 1. Netmail, echomail and file export. This chapter handles only the use of the aka to route echomail or files within a part of virnet. The use of the aka in your Editor is described elsewhere in this document. Use the highest administrative AKA for echomail and file export you have. E.g: If you are a regionhost use 9:/0 instead of your nethost AKA. Netmail destined to another node and routed via your system is to be regarded as non-existant. That means that you are not allowed to forward the message, or the contents of the message in any way, to anyone. Treat it as you should always do with other peoples mail - don't read it. 1.1 Bombing runs A "bombing run" is when one node sends one netmail to all nodes in one network, or in one region, or entire VirNet. This practice generaly is strictly forbidden. This is only allowed for important informal reasons and routing tests. In these cases, the bombing-run should be as small as possible: Therefore the zonehost should ask the regionhosts to make a bombing run in his regions etc. 2. Your own nodenumber. This need not be used at all in echomail by a nethost/nethub. If you are a nethost/nethub and you set up your system so it will EXPORT with the correct adress (see chapter 1), then you are free to do so. Every phone-number listed in virnet must have it's own nodenumber! If the first line of your multiline-system is listed as nethost, this line must have it's own nodenumber despite of having the second line listed with a virnet-nodenumber. All technical and admin nodes, international coordinator, zonehost, regionHost, nethost and nethub are not considered as real nodenumbers. All upper listed hosts and coordinators must have a mere nodenumber with the same telephone-number and flags as listed in either the host or coordinator nodenumber. This percaution is nessesary just incase one of the upper hosts or coordinators resign, so that this person will not drop out of VirNet immediatly. Also, not all available software is able to process either the admin or coordinator nodenumbers. This insures that every host or coordinator can be reached in VirNet under his nodenumber. 2.1 Mailer-restrictions for akas. If you cannot list a aka in your setup due to limitations of your or the remote software, you have to do the following: Check, if your mailer can process file-requests to one of your akas _not_ listed in the mailer-setup. If the request fails, the nodenumber must not have the request-flag (X*). If the request is processed, you have to use the same flags as in previous entrys. A filerequest at the zonehost-, regionhost-, nethost-, hub-nodenumbers _must_ be possible. These numbers _must_ carry the request-flag. A further descrition of the nodelist-flags follows in an later chapter. 2.2 Use of your own nodenumber When writing echomails or netmails you should always use your not- administrative nodenumber. Only if you have to act in your administrative position, you should use your administrative nodenumber. This rule ensures, that you will get your netmail even if you resigned as hub, nethost, regionhost or zonehost. If you always use the highest administrative aka, netmails to your aka will be sent to the new 'owner' of the administrative nodenumber a long time after your resignment. 3. Pvt Nodes and Points. Points are not permitted in VirNet, but pvt nodes are. Therefore, if anyone requests membership, he should be given a nodenumber regardless of the reason for him not being a "full" node. There may be reasons, why someone requesting membership in virnet will not get a nodenumber. This is documented later. This means that if any of your own points wants to join - give them their own nodenumber. Regionhosts, Nethosts or nethubs cannot be pvt systems. Also - There should be no flags set in the nodelist for a private node. A private node is flagged as "Pvt" in the VirNet nodelist. 4. Use of nodenumbers. These are to be treated right. They are not to be used to extend your ego by having many AKA's. Also - the only Coordinator of VirNet is 9:9/1 - VirNet International Coordinator. If things do not work the way it should we might have to have Region Echo Coordinators as well, but this is not the case at this time. 4.1 The difference between coordinators and hosts and hubs in VirNet. The International Coordinator is the only position that can be voted on in VirNet, because it is his job to Coordinate and not to deal with technical matters inside VirNet. All other jobs in VirNet, such as zonehost, regionhost, nethost and nethub are technical jobs. These jobs will be assigned or replaced as decribed in paragraph 14 in this document. 4.2 International Coordinator. The international coordinator acts as a mediator and a coordinator of net and echomail. Any disputes between nodes in VirNet are processed by the international coordinator in cooperation with the zonehost. The international coordinator is the only true administrative node since he is not forced to carry any mail and files of VirNet. The international coordinator is not allowed to be the zonehost, regionhost or nethost, because of voting procedures decribed in paragraph 17. 4.3 Zonehost. There is ONE zonehost only, which is flagged as "Zone" in the VirNet nodelist. He can also be a regionhost and a nethost or nethub. 4.4 Regionhost. There is ONE regionhost in every country, which is flagged as "Region" in the VirNet nodelist. He can also be a nethost or nethub. 4.5 Nethost. There can be several nethosts in every region/country, which are flagged as "Host" in the VirNet nodelist. He can also be a hub. 4.6 Nethub. There can be several nethubs in every net, which are flagged as "Hub" in the VirNet Nodelist. 4.7 Nodes. One person might have one nodenumber for each of his systems - the only requirement is that there has to be a mailer on the system. Multiline BBS'es for instance can hold as many nodenumbers as there are lines. EVERY node - regardless of administrative numbers - must have it's own nodenumber. 4.8 Pvt-nodes. If you use a sysop-point to read/write write mails and/or to transmit files you can have a pvt-number even if you are a zonehost, regionhost, nethost, hub or node. Why? On many systems the sysop acts via a point-number from work, girlfried, boyfried etc. due to the fact, that every point asking for a membership virnet needs a pvt-nodenumber, an exclusion can't be made. 5. VirNet nodelist = Routing list. The VirNet Nodelist is list of all existing VirNet nodes, and at the same time it has to be used as a routing-list: Zonehost (Flag "Zone") |--------------------- | |--Regionhost (Flag "Region") |------------------------- | |--Nethost (Flag "Host") | |-------------------- | | | |--Node | |--Node | | |--Point (Flag "Pvt") | | | |--Nethub (Flag "Hub") | |------------------ | | | |-Node | |-Node | |-Point (Flag "Pvt") | |--Nethost (Flag "Host") |--Nethost (Flag "Host") - All regionhosts with the flag "Region" poll at the zonehost (9:9/0). - All nethosts with the flag 'Host' poll the first node listed before him in the virnet-nodelist carrying the flag 'Region'. - All nethubs with the flag 'Hub' poll the first node listed before him in the virnet-nodelist carrying the flag 'Host'. - All nodes poll the first node listed before him in the virnet-nodelist carrying the flag 'Hub' or the flag 'Host' depending on which comes first. - All pvt-nodes poll the first node listed before him in the virnet- nodelist not carrying the flag 'Pvt'. (e.g. Pvt-node 9:491/2011 would then poll at 9:491/2010) If a region or a network is planned after this suggestion, it is then no problem where to see, where information in VirNet can be accessed in the fastest way! Exceptions of this paragraph are only possible on a node-to-node base within the same hub-area. Echomail/File-links of virnet between to nodes in different hub-areas, nets or regions are not allowed! This means: A node can poll another node, if the routing of mails and files is faster than polling within the above structure. The allowance or disallowance is a decision of the regionhost, who may delegate this to the nethost, who may delegate this to the nethub. 5.1 Who assigns nodenumbers. A regionhost will only be assigned by the zonehost. His decision can depend on a vote in the specific country. Each country will be represented by exactly one regionhost. Nodenumbers are assigned by the regionhost, whome optionally might assign that responseability to the nethost, thus optionally might assign that responseability to a nethub inside it's network. When assigning nodenumbers to hubs and/or nodes, the nethost must use the virnet-nodelist as a routing-document. Within this document the nodenumber within a network must be ascending. Therefore it is not allowed to list up all hubs before the first or after the last node. The regionhost is responseable for the information that is listed in their regional VirNet nodelist segment files, and that the information listed there is always up to date. The level below can also be held responseable, if the regionhost allowed the nethost to assign nodenumbers inside his region. 5.2 Other information about nodenumbers. It is advised that the nodes are given a nodenumber that reflects to which nethub they belong. Say a sysop wants a new nodenumber and he wants to poll via nethub 3000, then he must be given a free number in the 3000 series of the specific net. This makes netmail routing a lot easier to set up for the nethosts. If one system quits VirNet, this nodenumber will be reserved for that node for a full year. This is not the case if a system switches to another nodenumber due to changing nets and so on. If somebody looses his virnet-nodenumber due to violations to this policy, there is no need to reserve this nodenumber. Every regionhost should send their regional VirNet nodelist segment to the zonehost on a weekly basis, the latest till wendnesday evening. The zonehost must compile a list of all regionhosts on every friday, and publish this then as Vir_diff.* to all members of VirNet. This virnet-nodelist must be available for file-request at the zonehost and will be distributed via a previously defined file-area. 5.3 Nodelist flags The current valid nodelist-flags that can be used in VirNet are always published in the most recent virnet nodelist. The modem-flags have to represent the modem-type the node has. Modem-specific flags can be left out for testing of modems only. The request-flag must be set according to the mailer-request-feature. If the X*-flag is missing, a request at this nodenumber is not possible. If you can't list all akas you have to set up for your (administrative) nodenumbers in virnet, you are allowed to leave out the X*-flag for your node-entry. The administrative levels must keep the X*-flag to allow adminstrative documents being frequested from a administrative aka. Before leaving out the X*-flag for your node-entry, you have to make a short test: Check, if your mailer can process file-requests to one of your akas _not_ listed in the mailer-setup. If the request fails, the nodenumber must not have the request-flag (X*). If the request is processed, you have to use the same flags as in previous entrys. Generaly, if a new nodelistflag is introduced to virnet, it must be assured, that all used software can cope with this new flag. If this is not the case, the old flags have to be used, paralell to the new introduced flag, until it is sure, that all software will support the new flags. If a node has ISDN, he had to use the rules being at the end of the virnet-nodelist. A further description of adding ISDN-nodes in virnet will not be in this policy, because then it will cause a policy-change if the way of representing ISDN-nodes in the nodelist will change. A administrative aka cannot be dedicated to a ISDN-line. 6. Listed Only nodes (nodelist flags). Actual valid nodelistflags are listed at the end of the VirNet Nodelist. Every sysop listed in the virnet-nodelist with a phone-number must grant every system free access for requesting or downloading files posted into VirNet. If you allow file-requests for listed nodes only, the access to files distributed via virnet in the BBS must be granted without any extra charges. In this case the flag 'LO' must be set. If there is no filerequest possible, the access to files distributed via virnet in the BBS must be granted without any extra charges. In this case the X*- and LO-flag must not be set. 7. AntiVirus helpnodes. Every regionhost and zonehost should incourage those, who are experts in anti-virus handling, who can help others who have problems with unknown viruses, ect. that these experts get a independant helpnode nodenumber in a region or zone segment. This makes it easier for those who have serious problems with infected material to contact the right person. Bear in mind, that the person who gets such a nodenumber should be well known, and should know what he is doing. A regionhost or zonehost should not assign this nodenumber to "anybody" ! Examples for such nodenumbers, see nodenumbers 9:49/10x inside VirNet Germany. 8. Gateways. Definition: A gateway is a system, that routes netmail/echomail or files in a different network, not compatible with VirNet standards, or to a system that isn't member of VirNet, but runs on software based to fidonet technology. A system that runs as multinetwork system, that means a system that runs on software, that is able to handle more then one network-format at the same time can also be called a gateway, when it makes VirNet to the othernet-systems available. 8.1 Gateway approval. The files and mail distributed via VirNet are not to be gated automatically to non-VirNet nodes without clearance from both the Zonehost and the International Coordinator. Gateways within a region to import messages or files from othernets to virnet must be approved by the regionhost, who has to inform the zonehost and the international coordinator. The regionhost or zonehost must give the gateway an Independant nodenumber. The Gateway has to accept the rules that are defined in this policy document, in supposition to recieving his gatway approval. Example for a gateway with a independant Nodenumber: The ZNetz-gateway in Germany, 9:49/50 A regionhost or zonehost can redraw a previously approved gateway due to technical reasons only. 8.2 Gateways, what is forbidden? -Installing gateways without contacting either the regionhost or zonehost, and routing information from VirNet into other networks. Even if there is only a test of one echo/file-area between two sysops for a gateway, the regionhost has to be informed. -Routing information other then information from VirNet, from other non VirNet networks, or information posted in echos other then the listed VirNet echos in the VirNet echolist that start with VIR_ . Not following these guidelines could result to the removal of the VirNet nodenumber without further notice. 9. Magic Filenames and available echos. Every zonehost, regionhost, nethost and nethub are required to have the following magic filerequestnames available on their systems. For nodes this is optional: VirNet ...: Information document about VirNet (e.g. ?:\VirNet\VIR_NODE\VIRINFO.ZIP) VIRNODES .: VirNet Nodelist (e.g. ?:\VirNet\vir_node\virnodes.*) Every zonehost, regionhost, nethost, nethub and node must have all VirNet echomail and fileechos available for distribution. 10. Hatching files. Files inside VirNet are only allowed to be hatched by the zonehost. If anybody has any good antivirus utility, that they want to get hatched inside VirNet, they must send the file to the zonehost, and contact him regarding the contents of these files. The only exception is, that the regionhost is allowed to hatch weekly region updatefiles inside his region, as well as for specific information material for that region alone. 11. VirNet node application. The current valid VirNet node application form is named VirNet.APP and is available at the zonehost and at all regionhosts. Except when a region has its own node applicationform for VirNet. This form has to be in english, and can also be in the language, that that region speaks. Regional VirNet node application forms have to be approved by the zonehost, before they can be used in a particular region. The name of a regional VirNet application-form would then be VIR-NODE. After reading and filling out this node application form, your request for a virnet nodenumber must be sent to the regionhost unless specified in the application formular. A nodenumber will be assigned only by Regionhost (or optionally nethost or nethub), if the data in the application formular is complete and correct. Virnet-Node-Applications should be processed within one week after it reached the administrator, who should process it. If the application is forwarded by the regionhost or nethost, the node should be informed about the delay. 12. Regular Polling. Every administrative system (regionhost, nethost, nethub) has to poll its uplink at least once a day. Every Node is required to poll either it's nethub or nethost at least three times a week. If a node knows in advance that it will not be able to poll according to the above, the node should notify the feed. If a system does not poll regulary he can be removed from virnet by the next level host above him (nethub, nethost, regionhost, or zonehost). 13. Commercial and Hobby-Nodes. No system listed in VirNet is allowed to sell information and files routed via virnet to any companies or profit making organisations. Every approved BBS user must have free access to all files distributed via VirNet, free of charge. Systems, that charge their users fees for access to VirNet files, or sell these for profit making have no right to be a member of VirNet. They must join the commercial region 99 of VirNet, and pay their fees for that. For more details, please ask either the zonehost or international coordinator. 14. Replacement and removal procedures. VirNet is a technical network, and is for this reason not democratic. Jobs, such as the zonehost, regionhost, nethost and nethub cannot be voted on. If the level before the higher level fails, the level above has the right to replace thet level below. The 'level above' can ask the nodes in the specific part of virnet, who is willing to do the to-be-replaced-job. If there is a election in the specific part of virnet according of the position, this vote is nothing more than a suggestion to the 'level above'. The result of this vote may be accepted or denied by adminstrator assigning this specific job. For the judement for replacement or removal, only technical reasons apply, e.g.: - Faulty installed software causing problems - System not online regulary - Files and messages dissapear - By request of the to-be-replaced/removed administrator/node - By violation of this policy The higher level, that replaces the level before him though has to follow some guidelines, so that passing the job to another system will work as smoth as possible: - The higher level has to find sombody else in the same hub/network/region who is willing to take over the job. This should happen as fast as possible, but a maximum of two weeks should do it. - The found candidates must have some technical experience in how to run a mailer, or how to connect oder disconnect downlinks. Hub/Nethost-level only: - If not found, the level above has the right to find sombody else outside the same Hub and network, who is willing to do the job. This should also happen as fast as possible, but a maximum of two weeks should do it. - If still no candidate is found by the level above, the level above has the right to close down that hub/network and tell the nodes of that hub/network to join other existing hubs/networks. Regionhost/Zonehost only: - If not found, the level above has the right to close down that region and remove it out of the VirNet-Nodelist. 15. Complaints Complaints must be technical. A complaint according to personal problems is not possible within virnet. Complaints can be written only by members of virnet. If a node has been removed from virnet by the higher-level host due to violations to this policy, this node has the right to submit a complaint to the higher-level host. The complaint must be submitted to a maximum of two weeks after removal out of the virnet nodelist. Complaints should be processed by the nethost, regionhost, zonehost or international coordinator within one week. 16. Regional policys. Are allowed, but may not interfere with this policy document. They have to be approved by the ZoneHost and International Coordinator. 17. Voting in VirNet. The only job that can get voted on in VirNet is the International coordinator. A majority vote of more then 50% of all nodes taking part in the ballot must be reached to vote a new International coordinator. The International coordinator will be voted every two years. If more then 20 percent of all VirNet nodes in at least three regions vote for replacing the IC, a voting is held before the actual time of office has ended. 18. Replacing this policy. Single paragraphs or the complete policy can be replaced using the following procedure: 1) Ideas, hints, comments and/or complete policy-paragraphs are posted in the echomail-conference vir_policy.int. In this area the nodes interested in a changed policy-paragraph discuss it. 2) If all effects and side-effects of the new or changed paragraph are discussed (after some weeks/months). 3) Additions and changes to this policy can only be made, when the majority of voting nodes accepted it. The voting procedure must be published in the echomail-areas VIR_SYSOP.INT and VIR_POLICY.INT and should be published in local sysop-conferences. The voting time cannot be shorter than one week. 4) If the vote ties up, the International Coordinator is entiteled to cast his personal vote to end the tie. To avoid endless votes about the same paragraph, it is not possible to vote within 3 months about the same paragraph again. If the policy has been changed, it must be made available to every node in virnet: (a) via filerequest at each *host (b) via the file-echo VIR_NODE (c) via the message-echo VIR_POLICY.int 99. The editors of this document. The first VirNet policy ever (vir-pol.053) was first written by Mikael Larsson (9:9/0) on 21-May-91. The second policy (echopol1.vir) from 03-Aug-92, referred as the second VirNet policy was written by Jonny Bergdahl (9:9/1) and Mikael Larsson (9:9/0) This policy (Vir_pol3bb.txt), which is based on both of the upper documents, and a lot of suggestions by the members of VirNet, was written in from 1993 to 1994 by Justin Mann (9:491/1000) and dirk astrath (9:492/1313) Special Thanks to: jonny bergdahl, Mikael Larsson, Thomas Schlangen, Rob Macare, Hinrich Donner, Robert Hoerner, Uwe Kepper, and those I forgot ... (sorry) ---------------------------> bite here again <--------------------------- Who is going to write the next policy document ;-) For additional changes to this document, please drop a note in VIR_POLICY.INT