Crawly Crypt Collection 2

home *** CD-ROM | disk | FTP | other *** search

/ Crawly Crypt Collection 2 / crawlyvol2.bin / apps / bbs / nest_kit / nestpoly / nestpoly.024

Wrap

Text File | 1995-03-06 | 41KB | 885 lines

__ ¯¯//\ //| // ////// ////// ////// // /\ // | // // // //™ // \/\ // 9|0 // //// ////// // \\ * / // | // // // // \\ / _ // | // // // // \\/__ // |// ////// ////// // Policy for NeST (Network ST) - The Free Network! (Issue 24 : 06/03/1995) ============================================================================= Changes made within this issue of the policy document: - '>' in the left margin indicates a small change within the document. - 's' in the left margin indicates a spelling, or gramatical correction. ============================================================================= INDEX of the NeST Policy Document. ================================== [01.00] - Introduction to the Policy Document. [02.00] - Legal and Decent Operation. [03.00] - EchoMail. [03.01] - Compulsory NeST Echos. [03.02] - Echo's compulsory to all 'Hub', 'Host', or 'Region' Coordinators: [03.03] - Regional NeST Echos. [03.04] - Echo Moderator. [03.05] - General Echo Rules. [03.06] - Echo Naming. [03.07] - Backboned Echo's. [03.08] - New Echo's. [04.00] - File Echos. [04.01] - File Echo Naming. [05.00] - Mail Flow and Routing. [05.01] - NeST Routing Heirachy. [05.02] - Echo Gatewaying. [05.03] - Changes to EchoMail Distribution. [06.00] - NeST File Echo's. [07.00] - The NeSTDiff & NeSTList. [07.01] - Issuing of the NeSTList and other Documents. [07.02] - Updating of the NeSTList/Diff. > [07.03] - NeST Document Distribution. [08.00] - Membership of the N.I.A. and of the NeST Network. [09.00] - Administration. [09.01] - On Matters of Setting Policy. [09.02] - Voting Within NeST. [09.03] - Rules for Resolving Differences Within NeST. [09.04] - Changing Nets or Leaving NeST. [09.05] - Network Fees and Charges. [10.00] - Network Security. [10.01] - Session Mailing. [10.02] - Encrypted Mail (PGP, etc). [10.03] - Interfering with NeST Mail. [11.00] - Life the Universe and Other Odd Bits. [11.01] - Holidays. [11.02] - Extended time off line. [11.03] - Helpfulness. [12.00] - NeST and the United Kingdom Data Protection Act of 1984. [13.00] - The processing of new NeST Members. ============================================================================= [01.00] - Introduction to the Policy Document. An [*] in the left margin of the document indicates any changes made to the text of the policy. Please note that the following are copyright trademarks of Daron Brewood, and all rights are reserved, along with the NeST logo shown at the top of this document: 'NeST' 'Network ST' 'N.I.A.' 'NeST International Association.' 'NeST Logo as coded in GFA Basic.' 'NeST Logo as within the NEST_IMG.xxx file.' NeST members may freely use the 'NeST' name, N.I.A. initials, or NeST logo in welcome screens, BBS adverts, etc. In the event of the NeST Zone Coordinator leaving NeST, the members of the network may still use the network names as detailed above, as long as it is accepted that Daron Brewood originated the name. In this case the ZC will select a replacement ZC, or will organise appropriate elections to elect a new ZC, and ensure a trouble-free change-over. If this happens a network address should be kept free within the NeSTLiST structure for the old ZC('s) in case they ever wish to contact the network again. This policy document was issued when NeST was first created, and therefore may not be changed without the consent of the network, and/or, the NeST Zone Coordinator (ZC). The ZC reserves the right to over-ride any changes implemented by the network, or issues of this policy if they are found to be in error. It is the policy of the NeST Network to promote the responsible use of computers, and computer based communications within all sections of the community, on a worldwide basis. This policy document will be issued on an irregular basis to all systems within NeST, via the 90_NEST file echo, which *all* systems in NeST must take to ensure they have the latest policy document in their posession. Any new policy revisions which are produced and issued come into effect as soon as they reach your systems. It is your responsibility to read new updates and ensure that you comply with any changes made to network policy. [02.00] - Legal and Decent Operation. Systems within the NeST Network may *not*: a) Carry any material which would be considered offensive to the majority of BBS users. b) Carry any material breaking the laws of the country in which the bulletin board is operated from. c) In anyway encourage the use of unauthorised software. d) In anyway encourage unauthorised access to computer systems. e) Transmit any information concerning NeST's policies, activities, Echos, FileEchos, procedures, regulations, or forthcoming plans, to any other network if the intent is to damage the NeST network, either directly or indirectly. f) Due to recent publications in the media it should be explicitly stated that NeST does not allow the transmission of any material deemed to be pornographic in nature, via any routes in the country(ies) concerned. If any Node is found to be breaking these rules, it will be expelled from NeST on a permanent basis. [03.00] - EchoMail. Note the information detailed herein is a brief outline and resume of the echomail structure. See the other NeST documents for more data. Point systems that are part of the NeST network may access those echos marked with a 'P' for 'Points Allowed'. Systems found to be leaking information from these Echos to other networks will be removed from NeST on a permanent basis. Network Group prefix designations: N.ADM.* = Administration Echo's (Nodes Only). P N.FALCON.* = Atari Falcon Specific Echo's. P N.MISC.* = Miscellaneous Non-Computer Related Echo's. P N.NET.* = Network Information / Announcements, etc. P N.ST.* = Atari ST/TT Related Echo's. P N.SUP.* = Echo's dedicated to Software Support. N.SUP.BETA.* = 'Closed' or 'Restricted Access' Echo's for Beta testers. N.UK.* = Country-specific echomail areas. These may be N.GER.* = distributed to other contries, but only if allowed by N.GR.* = the sysops of the originating country. N.SCA.* = These are native language echo's, and the use of N.ITA.* = English is not compulsory. For further details, please refer to the NeST documents concerning echos. However, note that the following message echos *MUST* be kept confidential, and are only to be accessed by full NeST systems, i.e. Systems appearing in the NeSTList. (See 3.01 & 3.02). [03.01] - Compulsory NeST Echos. NeST Echo Message Area Title --------------- ------------------ N.ADM.NEST NeST World Sysop & Administraion Echo. This echo shall be used to discuss administrational topics within the network, and for conversation by all NeST Sysop's worldwide. This echo shall be moderated by the NeST Zone Coordinator. [03.02] - Echo's compulsary to all 'Hub', 'Host', or 'Region' Coordinators: NeST Echo Message Area Title --------------- ------------------ N.ADM.ECHO NeST 'Message Echo' Administration Echo. For discussions concerning all aspects of Message Echo's within NeST including; New echos, removing echo's, moderation, echo gating, echo rules, and echo policy decisions. This echo shall be moderated by the NeST World Echo Coordinator. N.NET.CHANGES NeST Changes Echo. To be used for announcing official network structural changes, that affect the net as a whole. For notification of Region, Host, and Hub NeSTList changes. This echo shall be moderated by the NeST Zone Coordinator. N.NET.NOTICE NeST Official Notices Echo. This echo shall be used to make official announcements concerning NeST. Topics include; NeST Sysop meetings, both official and unofficial, BBS meets, etc. This echo shall be moderated by the NeST Zone Coordinator. N.NET.NOTICE.FILES This echo shall be used to announce new files hatched out into the NeST file echo's, which pass through 90:90/0.0@nest.ftn. N.NET.SEE NeST Space Empire Elite Discussions. This echo must be taken by all nodes in the NeSTList who run Space Empire Elite within the NeST World Space Empire League. This echo shall be moderated by the NeST SEE Coordinator. N.UK.ADM NeST UK SysOp's. This echo may only be accessed by sysop's, or points, within the UK. This echo shall be moderated by the Regional Coordinator of Region 1. [03.03] - Regional NeST Echos. Regional Coordinators may maintain message Echos especially for use within their own region, however the WEC must be informed of the details, so that they can be shown in the master Echolist. If a Regional NeST SysOp's Echo is created for use within a specific region, it must use the correct echo naming structure for nodes within that country. If no country suffix has been defined a new code will be created after due discussion with the World Echo Moderator. [03.04] - Echo Moderator. The Echo Moderator of an echo is the person who has proposed the creation of the echo, and set's the rules, or policy, for that echo. Some echo's which are especially busy may have joint moderators, or co-moderators. The moderator of the echo must provide a set of guidelines, or 'rules' for that echo. These rules must be copied to the World Echo Coordinator each time they are re-issued. The moderator has the right to change the rules at any time, without prior notice to any party. Notification of any such changes will be made in the conference that the change applies to. This notification must be made by posting a copy of the rules in the echo concerned. Echo rules should be published by the Echo Moderator each month to ensure all users of that echo know what it is for, and how to behave within it. It would be appreciated if Echo Moderator's give details such as whether handles are permitted within their echo's. Any rules issued by the Echo Moderator *must* not contravene NeST regulations or policy. It would be appreciated if Echo Moderators could use the pseydonym feature, now found in many mail tossers (e.g. JetMail), to append {EM} to their name. (e.g. Jane Doe{EM}) This allows the moderator of the echo to be easilly identified when reading mail. It is the Echo Moderator's job to moderate their echo. If you have any complaints about messages in an echo, please inform the respective Echo Moderator via *netmail*. [03.05] - General Echo Rules. Echo's should be kept on topic where ever possible. All messages in backboned echo's *must* be in the English language, unless otherwise agreed with the ZC. Regional echo's may be in the native language of the Region at the moderators/RC's descretion. Profane language is not allowed in any echo. [03.06] - Echo Naming. Echo names are the property of the Echo Moderator, and it is their right to use whatever name they wish, as long as it is clear and does not contravene NeST policy. However it is expected that echo moderators follow the following guidelines: - The echo should start with the characters 'N.', and follow the official NeST rules concerning Echo names. - If the so-called 'high ascii' characters are to be used within the text of a message they must be used in a sensible manner, to produce a graphical image, or to emphasize important text within the message. Characters may not be used if they cause any problems with mail transportation in any way. [03.07] - Backboned Echo's. An echo which is to be 'back-boned' must be taken by all NeST 90:*/0 nodes within the NeSTList. [03.08] - New Echo's. New echo's must be proposed and voted on using the official NeST echo voting form, ECO_VOTE.???. The proposer of the new echo should use the form to announce the prospective echo. Votes for, or against the echo should be collected by the proposee via netmail, and regular postings made in the N.ADM.ECHO echo concerning the status of the vote. If an echo acrues the necessary number of votes within the time period listed in the ECO_VOTE form the echo shall be backboned within the network. Closed access echo's, used for beta testing, or product support may be installed without a public vote, as long as permission has been given by the ZC and the WEC. [04.00] - File Echos. The following file Echos are compulsory within NeST and all systems must link into them: NeST File Echo File Area used to distribute: --------- ----------------------------- 90_NEST NeST Files (NeSTFile, NeSTEcho, NeST_BBS,etc). 90_NLIST NeST Complete NeSTList Distribution. * 90_DIFF NeST NeSTDiff files. ** 90_SEE NeST SEE programs & utilities. *** 90_FFF NeST Falcon FacTT File Support. >**** 90_SYSOP NeST Sysop's Pictures. * = This file echo is only strictly compulsory for NeST Host systems which have the ability to create a full NeSTList for further distribution. ** = Space Empire Elite. Compulsary for any nodes taking the N.NET.SEE message echo. *** = Compulsary for any nodes taking the N.FALCON.FACTT_FILE echo. > **** = The only non-compulsary NeST Echo. [04.01] - File Echo Naming. - The file echo should have a maximum of 8 characters in its name. - The file echo should start with the characters '90_'. - Use of characters such as; !"£$% &*()-+¯= should be avoided. [05.00] - Mail Flow and Routing. NeST being an international network, its hierarchy must be such to favour the quickest, most effective and cheaper way to distribute the mail bundles and networked files. To this end special mail routings may be arranged with the RC, or ZC. This can mean that unlikely routes may be used, _if_approved_, such as international mail going via: RC country A -> HC country B -> RC country B Such routes should be approved by the relevant RC and/or the ZC. [05.01] - NeST Routing Heirachy. The routing strucure, wherever and whenever possible, should follow the following schematic: ZC | RC <--------------------------------> RC | | HC <--------------> HC HC <---------> HC | | | | Hub <---> Hub Hub <---> Hub Hub <---> Hub Hub | | | | | | | --- --- --- --- --- --- --- | | | | | | | | | | | | | | Node Node Node Node Node Node Node Node Node Node Node Node Node Node ......... ......... ......... ......... ......... ......... ......... | | +-------+------ Points linking into Nodes. This means that bundles from each Node in a given Hub should be routed to the superior hierarchichal level (i.e. Hub Coordinator), and again, from each Hub in a given net directly to the Host, to be distributed to the other Hubs in the net if they are addressed within such net, or to other Hosts via the net gateway (or Host) if addressed to other nets or Regions. Note that Point systems are not considered within this hierachy, as they are equal to single users. However, NeST encourages Point systems to become Private Nodes, whenever they are active enough to give a valid contribution to the Network and to the N.I.A. [05.02] - Echo Gatewaying. Gating of message echo's must be agreed beforehand with all applicable authorites of the networks concerned, both those in the network heirachy and the echo moderators concerned. Any echo's which are gated must be listed in the NeST Echo List by the WEC. > If a new echo gateway is being prosposed then it should be discussed > in full in the N.ADM.ECHO message echo, to ensure all interested > parties know about the proposal and can discuss the effects of it's > creation. Special gateways can bypass this ruling in certain cases, > but such gateways must be agreed with the ZC and WEC before > implementation. [05.03] - Changes to EchoMail Distribution. The main aim of the NeST mail system is effectiveness, coupled with the lowest possible cost to the sysops involved. To this end local and international routes may be adjusted to improve operation. Such changes, however MUST not be implemented without due consultation with the relevant NeST RC's. The RC's may forbid such a link, if it is found not suitable for the Network's purposes. Changes in the distribution structure must be notified to all NeST members in the N.NET.CHANGES Echo. [06.00] - NeST File Echo's. NeST does not have it's own full blown official world wide file echo system, as it was deemed that such was not needed as other file echo systems were/are already in operation. > The only file distribution system that has the permission to use NeST > mailing routes is the FANFiles (Zone 95) file echo system operated by > Laurence McDonald. If any NeST sysop wishes to use NeST routes for any other file distribution system (that will involve more than one country) the ZC > and relevant RC(s) must be contacted to formalise the route. [07.00] - The NeSTDiff & NeSTList. The NeSTList and NeSTDiff's will be used to contain the structure of the NeST network, and will carry address's of all full members of the network. > The NeSTList/NeSTDiff files are also to be considered an electronic > mailing list in accordance with the definitaions laid down in the > United Kingdom Data Protection Act or 1994. [07.01] - Issuing of the NeSTList and other documents. Copies of the NeSTList/NeSTDiff files containing details of active, Down, or new Nodes will be sent out weekly by the NeST Coordinator via the MakeDiff program. Copies for NeST Nodes will be sent out in the following file echo's with the relevant .TIC or .FLE file, for distribution throughout the NeST Network: NestLists via 90_NLIST NestDiffs via 90_DIFF > The other NeST documents (as defined in 7.03) will be issued out in > the 90_NEST file echo. [07.02] - Updating of the NeSTList/Diff. The master NeSTList and NeSTDiff files maintained and issued by the NeST Zone Coordinator (ZC), at 90:90/0@nest.ftn will be updated automatically by use of the MakeDiff program (copyright David > Thomas BSc). The NeSTList and NeSTDiff files, once updated, will be prepared and > sent out in the above mentioned File Echos every Friday morning by the ZC. They will be transmitted in LHarc -lh5- format, where the file extender will be .Lxx, where the L stands for Lharc, and the 'xx' is the last two digits of the Julian issue date. Coordinators C's should install MakeDiff, or comparable software on non- Atari computers, and use it to send update files to the next > highest C in the network. If this is not possible then a manually > created ASCII list should be submitted. Manually created NeSTList segments are permitted and should be sent > to the relevant heirachial node using file attach messages, this is > done to ensure that the receiving node knows that an ASCII file has > been received (without a valid CRC) that will have to be processed > manually. Nodes that are submitting/receiving such manual segments > must install mailer session passwords to ensure that the data can not > be tampered with, thereby ensuring network security. [07.03] NeST Document Distribution. Each Regional Coordinator, Host, Hub or Node must collect the current > NeSTList/Diff when available, and pass it on through the NeST > distribution system. Coordinators, Hosts and Hubs must keep each NeSTList/diff on hold either until all sub-systems have collected it, or for a minimum of 4 weeks, also all Hosts must keep an updated NeSTList file requestable for Nodes to collect if their NeSTList get's corrupted. This file should be available for freq'ing using the magic name of 'NESTLIST', with the latest Diff file being available as 'NESTDIFF'. The NeSTList is the only means that a Node, Hub or Host can make contact to anyone else, they MUST be file Requestable from a Host or ZC or Hub within 24 hours of receipt. Failure to do this is considered to be an annoyance to others, and he or she will be considered for removal from the NeSTList if this practice is found to be continuous. > The following magic names should be used within NeST to ensure that > NeST the official NeST (as detailed below) documents can be file > requested from all 90:*/0 systems. > > Filename. Magic Name. Official Document Name. > > NESTLIST.xxx NESTLIST Latest NeSTList issued by the ZC. > NESTDIFF.xxx NESTDIFF Latest NeSTDiff issued by the ZC. > NESTPOLY.xxx NESTPOLY Latest NeST Policy issued by the ZC. > NESTEPLY.xxx NESTEPLY Latest NeST Echo Policy issued by the WEC. > NESTSTRC.xxx NESTSTRC Latest NeST Structure issued by the ZC. > NEST_INF.xxx NEST-INF Latest NeST Information issued by the ZC. > NESTECHO.xxx NESTECHO Latest NeST Echo Listing issued by the > WEC. > NEST_APP.xxx NEST-APP Latest NeST Application Form issued by > the ZC. > NESTSOFT.xxx NESTSOFT Latest NeST Software List issued by the > NeST Software Coordinator. > NEST_SEE.xxx NEST-SEE Latest NeST Space Empire Application > Form issued by the NeST SEE Coordinator. > SEE_SYST.xxx SEE-SYST Latest NeST S.E.E. Gaming Systems as > issued by the NeST SEE Coordinator. > ECO_VOTE.xxx NEST-EV Latest NeST Echo Voting Forms issued by > the WEC. > NESTLOGO.xxx NESTLOGO Latest NeST Logo (in GFA) issued by the > ZC. > NEST_KIT.ARC NEST-KIT Latest NeST Information Pack issued by > the ZC. > > Note with the issuance of this policy Document the NESTFILE.* file is > considered obsolete and should be deleted from all systems. [08.00] - Membership of the N.I.A. and of the NeST Network. Membership is open to any SysOp who agrees to these rules and guidelines. A new NeST member should be 'processed' into the NeST structure as defined by the regulations in section [13.00]. If after due discussion between the Administrators it is decided that a member has acted in a way liable to be detrimental to the Network, the member will be asked to modify their behaviour. If this is not done that member may be expelled from the NeST Network. [09.00] - Administration. The Association and the Network shall be administered by the NeST Zone Coordinator and a number of Assistant Coordinators. The Assistant Coordinators shall be appointed by the Zone Coordinator, who may ask any member of the Network to become an Assistant Coordinator following discussion between the current Coordinators, if required. Region Coordinators shall be appointed by the ZC, while HCs and Hubs shall be appointed by their respective RCs. [09.01] - On Matters of Setting Policy. All decisions will be made by the Zone Coordinator following discussions with the Assistant Coordinators, and other members of the Network as appropriate. Local decisions are to be made by Hub coordinators for each Hub, Host Coordinators for each Host, Region Coordinators for each Region. In case a member has anything to say against a decision taken by its hierachical superior, he may complain at the following step, i.e, a Node may complain over a Hub's decision with its Host, a Hub with the RC, and so on. [09.02] - Voting Within NeST. It must be remembered that the ZC is the originator of this network, and therefore can not be forced to resign from the network by any voting method. If the ZC decides to leave the network he shall appoint a new ZC as his successor after due discussion with the Assistant Coordinators. Voting for replacement NeSTList Coordinators (RC/HC/Hub) shall be carried out by members of that segment of the NeSTList, and the decision shall be validated by the next highest Coordinator in the NeSTList. [09.03] - Rules for Resolving Differences Within NeST. Where possible, polite, precise information regarding all problems should be passed to the next highest member in the NeST hierarchy from Hub to HC, or from RC to ZC. Where possible, the next highest member in the NeST hierarchy should try and resolve the problem. If the problem is between two SysOps, the Host should try and get both SysOps to send NetMail ONLY to each another and a copy to the Host, to be forwarded if the problem cannot be resolved by the Host and the sysop's themselves. If the problem is between two Hubs, then the Hubs should also try to resolve their differences making sure that copies of NetMails are sent to the HC. If the problem cannot be resolved by the Hubs and their HC, then the problem should be forwarded to the RC along with the relevant NetMail conversations. If the problem is between two HC's (God forbid!), then again, the problem should be resolved through Netmails between themselves, with copies again going to the RC. If the problem is between two RCs, then again, the problem should be explained and attempts to resolve the relevant RCs problems should be through NetMail with copies going to the ZC. If the problem cannot be resolved by the two RCs, then the ZC will have to step in to resolve the problem. The private NetMail between two parties having relationship problems should contain: i) Detailed coverage of the grievance/problem. ii) Details of attempts at resolving the problem by suggesting amicable solutions. iii) The NetMails must NOT contain abuse of any kind, or foul language. It will be the responsibility of the next member in the hierarchy to make sure that these three steps are being carried out appropriately. Of course, if one of the two parties involved sends a NetMail to the other without a copy going to the next member in the hierarchy chain, then it's responsibility of the receiving party to forward this NetMail to the next member in the hierarchy. One possibility of checking NetMails is to get the two parties to number the messages. These private NetMails should be kept for a period of thirty days. If, during this time, the problem flares up again, then, these NetMails, along with a short report, should be forwarded to the ZC, else, they should be deleted on the 31st. day, and the problem will be officially considered resolved on this day ONLY. [09.04] - Changing Nets or Leaving NeST. If you wish to move to another net (e.g. if you are moving to another area, or if there is a personality clash), please discuss it with your current Host before approaching another, so that they can help with any problems you may have. If you still want to move nets, tell your Host that you are leaving their net and tell the Host of the net you want to join that you wish to do so. This helps to keep everyone talking to each other, and is good manners. If you have not spoken to your current Host, then your new Host should refuse to have you in his net till you do so. If, on the other hand you wish to leave the NeST network completely, please tell your Host at least a week before hand, so that he can stop calling you or holding messages for you. There is nothing more annoying than polling a non-existent board, or causing duplicate messages to go around because you are being polled by two systems. [09.05] - Network Fees and Charges. There shall be no fees or other charges for membership of the N.I.A. or in the Network. If a service is offered to NeST members, a contribution may be required, to cover the cost of the service. The use of any such service shall not, however, be a condition for membership of the Network nor of a local net within the Network. [10.00] - Network Security. Sysops within NeST should make every effort to maintain a secure system, that is to ensure no unauthorised mail systems or users can access the system. It is responsibility for each individual sysop to maintain their own system, and to resolve any problems as soon as they are located. [10.01] - Session Mailing. Each node linked into NeST should take care to install session mailing passwords for their FTN mailers. This is to ensure that no unauthorised systems, or hackers, can interfere with mail flow. Such session passwords should be installed as soon as a mail link has proved to be operational. [10.02] - Encrypted Mail (PGP, etc). Encryption systems such as PGP (Pretty Good Privacy) may be used within NeST. Systems which permit Encrypted Mail on/through their system *MUST* have the ',PGP', or ',UPGP' flags shown in their entry in the NeSTList. The following rules are also applicable when using Encrypted mail: -Routes used must be between PGP nodes (as flagged in the NeSTList), or by direct crashmail between systems. -Encrypted messages may not be sent as echomail under any circumstances. -PGP signatures may be used within NetMail only, they are prohibited within EchoMail. -Sysops who do not wish to carry Encrypted Mail on, or through, their system may take any action deemed necesary to stop a repeatition, and may include deletion of the message(s), or the 'bouncing' of the mail back to the originating system. If mail is deleted a netmail should be sent to the offending system letting them know that the mail was deleted. If offenders continue to transmit messages then the relevant HC, RC, or the ZC should be informed. Any system within NeST that is found to be using Encrypted Mail for illegal activities of any nature will be reported to the legal authorities in their country of origin. In this case it should be made clear that NeST disapproves of such activities taking place and is not to be held responsible for that individuals actions. The system(s) concerned will immediately be expelled from NeST in the case of proven illegal operation. [10.03] - UUencoded files (and other methods of sending files via NeST message). It should be noted that NeST does not permit UUencoded (or similar messages to be transmitted within NeST. This includes both routed netmail and echomail as useage in this case would cause additional costs to those carrying the files. The only time UUencoding, or similar, may be used are currently as follows: (a) If the transfer is by direct mail to another system at the senders expense, or if the receiver pays for the transfer and knows about it in advance (thereby accepting the cost of the transfer freely). (b) A small UUencoded message may be posted in a NeST message echo if the moderator is approached and gives his/her permission for the file to be posted. The request to post should be made within the echo itself so that members of the said echo will have a chance to agree/disagree on whether the posting is needful to them, this may also help the moderator to decide whether to allow the post. [10.04] - Interfering with NeST Mail. If is an offense within NeST to interfere with echomail, or netmail, in any way excepting certain situations that are covered within this document (see PGP). Any system found interfering with mail in any way will be subject to NeST disciplinery procedures, and may be expelled from NeST. [11.00] - Life the Universe and Other Odd Bits. Lets remember this is a hobby and, although we take it seriously, a little humour and light relief occasionally never hurt anyone. It is our wish that we be pleasant to each other at all times. At times this may not be possible, but we would like to promote light heartedness and harmony in this great realm of ours. Threats and blackmail are not permitted within the NeST Network. Any single member, or group of members, found to be attempting these actions against any other members of the network, or the network itself will be dealt with accordingly. Action taken _may_ be: a) Written warning from the ZC. b) Second written warning from the ZC. c) Expulsion from the NeST Network. It is requested that each member board carries information on their systems about the NeST Network. If a Sysop not in the Network expresses interest in NeST, they should be given details of how to join, or be given details concerning contacting the relevant Host Coordinator. [11.01] - Holidays. If you are going on holiday please let your Host know, so that if, while you are away your system crashes, he/s will know that you have not deserted us, and will keep any mail on hold for you till you return. Even if your system does not crash while you are away, it would be nice to inform your Host of your return. Notice of such holidays may be made in the N.ADM.NOTICE echo, if thought to effect the operation of the network in a major way. [11.02] - Extended time off line. If, for any reason, your system goes down, say the computer needs repair or maintenance and it may be a while before you can get back online, please let your Host know, so that he can hold mail for you until you are back up and running again. Systems that this applies to will be marked as 'Down', or 'Hold' in the NeSTList. [11.03] - Helpfulness. Please be patient and, where ever you can, render help to those that are not as familier with the network as yourself. [12.00] - NeST and the United Kingdom Data Protection Act of 1984. As far as NeST is concerned the NeSTList, NeSTDiff, NeSTEcho, NeSTFile, NeSTPoly, and NeST_Inf files along with any electronic messages, programs, and files distributed through the network, are to be considered as part of a 'Mailing List' system. It is agreed that the NeSTList contains the minimum personal data needed to make sure that the other information files, programs, and electronic messages get distributed to those members whose data is contained within the NeSTList. Due to the above, Network ST (NeST), is exempt from registry under Exemption 6: Mailing Lists, Part A.7, of the Act. [13.00] - The processing of new NeST members. The SysOp of the bulletin board who is introducing the prostective new member to Network ST (NeST) must provide that user with the relevant network documents needed to understand the legal, and operational restrictions, rules and regulations utilised within the NeST network. As a minimum the applicant should be provided with the following NeST documents; NESTPOLY.xxx, NESTLIST.xxx, ECHOPOLY.xxx, NESTSTRC.xxx, NEST_APP.xxx, and NEST_INF.xxx. All documents must be the latest issue held at that station. An applicant is defined as anyone who wishes to access NeST either as a point system or as a private node. This is to ensure that any new member (with access to echomail and email within the network) understands the operation and useage of NeST. The applicant must read the NESTPOLY.xxx and ECHOPOLY.xxx files as a minimum, and then complete the NEST_APP.xxx application form if they wish to become a member of NeST. The application should then be either 'file-attached' or emailed to the node they wish to establish the NeST mail link with. Applicant's may also obtain information on NeST from within the NeST starter kit (NEST_KIT.ARC) which is distributed within NeST to all member bulletin boards each month. On receiving the completed application form the sponsoring SysOp should mail it to the next highest *C in the network (Hub, Host, RC, or ZC) for processing. This 'bouncing upwards' of mail will continue until the receiving *C has the authority and ability to make a change to the relevant NeST Nodelist Segment. The *C should then use data from the application form to compile a new nodelist entry into the nodelist segment under their control. The new nodelist segment should then be transferred through the network (either through manual updates, or by use of programs such as MakeDiff/MakeNL) and travel 'up' the NeST structure until they reach the ZC at 90:90/0.0@nest.ftn. The ZC will then compile the updated segments into the master NeSTList (and NeSTDiff) which originate from 90:90/0.0@nest.ftn on a weekly basis. (C)1995 Daron M. Brewood [NeST Zone Coordinator]