Welcome to AtariNet in the Triangle Area! by *** ** Erik Williams, Triangle Area Tarheels Host ** *** SunFox Productions, Ltd. *** ** Raleigh, North Carolina ** *** AtariNet 51:102/0.0, 51:102/1.0 SunFox's Realm ==> 919-859-9469! LAST REVISION: January 12th, 1993 A little about us... Thank you for showing interest in AtariNet, one of the world's fastest growing Atari-support networks! AtariNet was conceived and implemented by Bill Scull and Jim Goedhart (and as Bill tells it, copious amounts of beer were involved) a little less than a year ago. In that time, we've grown to over 75 nodes covering the United States and we have several nodes in Canada, England, Germany, Australia, and New Zealand. AtariNet is a truly global network! AtariNet is based in Longwood, Florida, with Bill Scull as our Zone Coordinator at 51:1/0. He is assisted by our Zone Echo Coordinator Terry May over at 51:2/0 and our AtariNet File Distribution System Coordinator Bill Jones at 51:203/0. AtariNet utilises the latest in FIDONET technology, the standard in network communications. This means that not only Atari systems can participate in our activities but anyone who can run the standard FIDO software. We have over 20 echoes available covering a wide range of Atari-specific topics including Desktop Publishing, FIDONET and BinkleyTerm, and so forth. One thing you will notice about AtariNet is that we are one of the friendliest networks around...all of us have left whatever politics we may have had at the door and have come together to share Atari information among one another. There is only one stringent requirement for the new sysop: your software must be "domain-aware" as your system must have a Zone 51 address in order to get a feed. This preserves our identity as a separate network from FIDONET and is a requirement that comes from the Zone Coordinator (and that I heartily agree with) and will not be changed. Like FIDONET, we have a policy document that I have appended to the end of this welcome guide and all nodes are expected to follow the provisions of the policy (don't worry, it's common sense stuff very similar to POLICY4.TXT from FIDONET). This document is meant to acquaint you with procedures to make your introduction to Atarinet as smooth as possible (I wish I had one of these when I started out...I had to figure out the ropes pretty much by myself with a good amount of help from our Zone Coordinator and his "care package" of FIDO programmes and configurations). This is not an exhaustive guide to the operation of your node within AtariNet...if you have any suggestions for new material that will make life easier for the new sysop, please let me know and I'll include it (with credits). Once again, welcome to AtariNet...we hope you will enjoy your stay with us. A little about me... I got hooked by the "sysop bug" about ten months ago and jumped into AtariNet and FIDONET. I didn't have a lot of time to devote to the BBS and it wasn't until the end of July that I had a dedicated BBS machine...an Atari Mega4STE with a 50-meg hard disk. Before the Mega4STE, I was hit or miss at best...the BBS was on my personal machine (a TT030). I've been playing around with this ever since I migrated the BBS to the BBS machine and SunFox's Realm looks a lot better than it did when I first started. I graduated from the University of Central Florida (Orlando) with a B.Sc in Computer Science on December 12th and had moved to Raleigh, North Carolina by the next day. I had made an agreement with Bill Scull (ZC) to become the Triangle Area Host for AtariNet and originator for ST_UTIL, an AFDS file echo. I'm also a "hat-trick" moderator for AtariNet...I moderate A_DTP (my specialty), A_4SALE, and A_COMMERCIAL_ADS. Since setting up shop here in Raleigh, I have made many changes to the look and feel of the BBS. I've also developed two programmes that are used to make life a whole lot better here: Maxi*Kill (which kills unwanted or old files) and Maxi*Mover which moves AFDS files into the download directories automatically. Eventually, there will be new BBS software in place...probably the one from the author of FidoDoor. Also, I'll be looking into getting a Dual Standard to service all high speed callers. First things first... The first thing that is required for you to participate in AtariNet is a nodelist entry...in this case, that will be assigned by me once I have received the information pertaining to your system. The important part is that you send me this via netmail which assures me that you have a FIDONET capable system on your end. Use an address like 51:102/9999.0 or something until I have assigned you a permanent node number when you send this first piece of netmail. This information includes: 1. BBS Name 2. BBS Phone Number 3. BBS Sysop Name (real name, please!) 4. BBS Modem Type (HST, V.32bis, etc.) 5. BBS Modem Compressions supported (MNP, v.42bis, etc.) 6. BBS Maximum Speed 7. BBS Hours of Operation (either 24 hours or not) 8. Does your BBS allow human callers or is it a mail-only node? The above will comprise your nodelist entry...once I have added it in here, I'll use a special nodelist here to send you mail and send mail back up the network to Bill (so you don't have to wait two weeks like you do in FIDONET). Other members of AtariNet will have to wait until the regular distribution of the nodelist in order to contact you, but at least you will have the mail coming in your direction to iron out any bugs you may have. Depending on when you are added to the nodelist, it may take a week before your entry is added to the master nodelist by Bill. Nodelists are issued every Sunday from 51:1/0 and I will send them on to you when I get them. 9. Your personal password for a mail connection...limited to eight ASCII characters. I will also use this password as your password for AREAFIX and the AtariNet File Distribution System file echoes for simplicity. I'd also appreciate a voice phone number and hours that I may contact you in case there are problems (I'm expecting a few until I get the bugs ironed out on my end...I'm rather new at this!). I'm quite willing to work with new systems to get problems ironed out as quickly as possible...I'll be here during the week and home in Fayetteville during the weekends until further notice. Also, I'll probably be in Fayetteville on Tuesday night as well. Now I'm in the nodelist, what do I do? The first thing you are going to want to do is add a few echoes to your board to make sure that the mail is flowing smoothly to and from your system. The following is a list of echoes available as of this date...as a host I am required to carry a full feed at all times so anything in the echolist is available from me. ========================================================================== = ||| AtariNet Backbone EchoList ||| = = / | \ Compiled by Terry May @ 51:2/0.0 / | \ = ========================================================================== *** Effective June 7, 1993 *** +------------------------------------------------------------------------+ | A.ADM.ECHO AtariNet Echo Discussion | +------------------------------------------------------------------------+ Moderator: Terry May @ 51:2/0.0 Handles: No Discussion of AtariNet echoes and echo policy. Includes discussion and voting of proposed new echoes, as well as removal of old echoes no longer being actively used. Also, AtariNet echo policy proposals and changes. Rules of a specific echo are NOT on topic. ATARINET SYSOPS ONLY! (Required echo for all AtariNet hosts/hubs.) +------------------------------------------------------------------------+ | A.ADM.FDS AtariNet FDS Announcements | +------------------------------------------------------------------------+ Moderator: Bill Jones @ 51:203/0.0 Handles: N/A Announcements of all files distributed through the AtariNet File Distribution System. This is a READ-ONLY echo -- no posting allowed! +------------------------------------------------------------------------+ | A.ADM.HOST AtariNet Hosts | +------------------------------------------------------------------------+ Moderator: Bill Scull @ 51:1/0.0 Handles: No Discussion of all matters relating specifically to AtariNet hosts, such as the recruiting and signing of new members, routing, etc. ATARINET HOSTS ONLY! (Required echo for all AtariNet Hosts.) +------------------------------------------------------------------------+ | A.ADM.SYSOP AtariNet SysOps | +------------------------------------------------------------------------+ Moderator: Bill Scull @ 51:1/0.0 Handles: No Discussion of all matters relating to AtariNet SysOps, that aren't already covered in another AtariNet echo. This echo is for official AtariNet business, and any other topics specific to AtariNet SysOps. ATARINET SYSOPS ONLY! (Required echo for all AtariNet SysOps.) +------------------------------------------------------------------------+ | A.ADM.TEST AtariNet Test Echo | +------------------------------------------------------------------------+ Moderator: Bill Scull @ 51:1/0.0 Handles: No Test echo for AtariNet sysops. This echo should be used for AtariNet sysops testing their software and setup. Test messages should be avoided in all other AtariNet echoes. ATARINET SYSOPS ONLY! (Required echo for all AtariNet hosts/hubs.) +------------------------------------------------------------------------+ | A.4SALE.COMMERCIAL Commercial Advertisements | +------------------------------------------------------------------------+ Moderator: Erik Williams @ 51:102/0.0 Handles: No The companion echo to A_4SALE, A_COMMERCIAL_ADS is limited to commercial advertisements only. From time to time, I'll be posting press releases available from GEnie or other sources that may be of interest to the readers of A_COMMERCIAL_ADS. Discussions of experiences with commercial vendors is also on-topic as far as I'm concerned. Please keep the personal advertisements to A_4SALE! +------------------------------------------------------------------------+ | A.4SALE.PERSONAL Personal Items For Sale | +------------------------------------------------------------------------+ Moderator: Erik Williams @ 51:102/0.0 Handles: No The AtariNet marketplace! If you have items of a personal nature (not necessarily computer or Atari-related items) that you wish to offer for sale, then this is the place for you! Commercial advertisements are off-topic in A_4SALE...there is another echo devoted to them! +------------------------------------------------------------------------+ | A.ATARI Atari General Discussion | +------------------------------------------------------------------------+ Moderator: Nick Hard @ 51:2/4.0 Handles: No Area may be used for General discussion of the Atari computer. You will be encouraged to find the appropriate subject in another area if it does exist. +------------------------------------------------------------------------+ | A.ATARI.DTP Atari Desktop Publishing | +------------------------------------------------------------------------+ Moderator: Erik Williams @ 51:102/0.0 Handles: No Discussion and support of the field of desktop publishing. *FRIENDLY* discussions of *ANY* DTP platform and software as well as related topics of scanning, colour separations, design tips, and tips and tricks of using a desktop publisher are welcome in A_DTP. +------------------------------------------------------------------------+ | A.ATARI.EXPLORER Atari Explorer Magazine | +------------------------------------------------------------------------+ Moderator: Ron Kovacs @ 51:1/13.0 Handles: Yes Discussion of articles from Atari Explorer and Atari Explorer Online magazines. +------------------------------------------------------------------------+ | A.ATARI.FALCON Atari Falcon Computers | +------------------------------------------------------------------------+ Moderator: Daron Brewood @ 51:500/0.0 Handles: Yes Discussion of the Atari Falcon computers. +------------------------------------------------------------------------+ | A.ATARI.GRAPHICS Atari Graphics Hardware/Software | +------------------------------------------------------------------------+ Moderator: Terry May @ 51:2/0.0 Handles: Yes Discussion of Atari graphics hardware and software, including, but not limited to, paint programs, graphics utilities, digitizers, expansion cards, pictures, graphics demos, etc. +------------------------------------------------------------------------+ | A.ATARI.SOUND Atari Sound Hardware/Software | +------------------------------------------------------------------------+ Moderator: Terry May @ 51:2/0.0 Handles: Yes Discussion of Atari sound hardware and software, including, but not limited to, MIDI hardware and software, sound utilities, sound and music players, sound and music data files, digitizers, demos, etc. +------------------------------------------------------------------------+ | A.ATARI.TECH Atari Technical Discussions | +------------------------------------------------------------------------+ Moderator: Wes Newell @ 51:202/0.0 Handles: No For the discussion of Hardware/Software of a technical nature. +------------------------------------------------------------------------+ | A.BBS Atari BBS Programs & BBS Ads | +------------------------------------------------------------------------+ Moderator: Terry May @ 51:2/0.0 Handles: Yes Discussion and support of all Atari BBS programs not already convered in another specific AtariNet echo. Friendly discussion of the pros and cons of various BBS programs are also welcomed, as are BBS ads (limited to one per week per BBS). +------------------------------------------------------------------------+ | A.BBS.DOORS Atari BBS Doors (Externals) | +------------------------------------------------------------------------+ Moderator: David Blanchard @ 51:1/6.0 Handles: No Discussion of all BBS doors (external programs) not already covered in another specific AtariNet echo. +------------------------------------------------------------------------+ | A.BBS.NETWORKING Atari Fido-Style Networking | +------------------------------------------------------------------------+ Moderator: Daron Brewood @ 51:500/0.0 Handles: Yes Discussion of all aspects of Fido-style networking, except those topics already covered by a more specific AtariNet echo. Gated with N.ST.FIDO (NeST). +------------------------------------------------------------------------+ | A.MISC General Discussion | +------------------------------------------------------------------------+ Moderator: Nick Hard @ 51:2/4.0 Handles: Yes General Chit Chat area, not related to computers. Talk about whatever subject you wish here, but be NICE! This is the area where you may find the time to unwind. +------------------------------------------------------------------------+ | A.MISC.FILEFIND AtariNet File-Finder | +------------------------------------------------------------------------+ Moderator: Brian Watters @ 51:3/3.0 Handles: No This echo is used for searching files using Mark Matts' File-Finder program. Any BBSes using File-Finder will show any matches to all requested filespecs. This is NOT an echo for chit-chat; it's ONLY for making requests to File-Finder. Only AtariNet SysOps may have WRITE access to this echo! +------------------------------------------------------------------------+ | A.PROG Atari Programming | +------------------------------------------------------------------------+ Moderator: Don Liscombe @ 51:5/0.0 Handles: Yes Discussion of programming for Atari computers. +------------------------------------------------------------------------+ | A.PROG.C Atari C Programming | +------------------------------------------------------------------------+ Moderator: Don Liscombe @ 51:5/0.0 Handles: Yes Discussion of C programming for Atari computers. +------------------------------------------------------------------------+ | A.PROG.GFA Atari GFA Programming | +------------------------------------------------------------------------+ Moderator: Don Liscombe @ 51:5/0.0 Handles: Yes Discussion of GFA programming for Atari computers. +------------------------------------------------------------------------+ | A.SUP.AUTOMAGIC AutoMagic Support | +------------------------------------------------------------------------+ Moderator: David J. Thomas (NeST) Handles: No Support for AutoMagic software, including AutoFile-ST and MakeDiff. Gated with N.SUP.AUTOMAGIC (NeST). +------------------------------------------------------------------------+ | A.SUP.BINKLEY BinkleyTerm-ST Support | +------------------------------------------------------------------------+ Moderator: Joerg Spilker @ 51:601/102.0 Handles: No Support for the BinkleyTerm-ST front-end mailer and terminal program. Gated with BINKLEY.ST (FidoNet) and N.SUP.BINKLEY (NeST). +------------------------------------------------------------------------+ | A.SUP.FIDODOOR FIDOdoor Support | +------------------------------------------------------------------------+ Moderator: Bryan Hall @ 51:3/6.0 Handles: No Support for the FIDOdoor message reader/editor. Gated with FIDODOOR (FidoNet). +------------------------------------------------------------------------+ | A.SUP.JETMAIL JetMail Support | +------------------------------------------------------------------------+ Moderator: Daniel Roesen @ 51:601/111.0 Handles: No Support for the JetMail mail processor and maintenance system. Mainly to discuss desired features, at this time, as all help with JetMail is currently restricted to the FidoNet JETMAIL_BETA echo. Gated with N.SUP.JETMAIL (NeST). +------------------------------------------------------------------------+ | A.SUP.MAXI MaxiMiser/MaxiDoor/PhidoQWK Support | +------------------------------------------------------------------------+ Moderator: Shawn Smith @ 51:5/4.0 Handles: No Support for the MaxiMiser, MaxiDoor and PhidoQWK .QWK utilities. Gated with FNET conference. In order to get any of these echoes, you'll need to use the AreaFix utility on my system. The following is a description of how to use AreaFix written by the authors of JetMail (my mail tosser). How to use Jetmail AreaFix This programm makes it possible for you to connect and disconnect echomail areas from this Jetmail system. You don't need to install the program yourself. All you need to do is use it. One thing is neccesary, a password, you probably have allready set this up,if not contact me first, there is no way you can use AreaFix without apassword! apart from the password, you also need to know the name of my AreaFix, "areafix" or "areamgr" will do. How to (dis)connect areas: ========================== Write a NETMAIL message to Areafix (or Areamgr) to one of the following addresses: For AtariNet: 51:102/0 or 51:102/1 For PerotNet: 17:1/0 or 17:1/1 For FidoNet: 1:151/167 On the subjectline you put the password you set up with this system (use same caps!). After the password, you could also specify some of the following flags: -q (%QUERY) : Send list of connected echomail areas. -l (%LIST) : Send list of connected/available echomail areas. -r (%RESCAN) : Rescan the requested areas. -h (%HELP) : Send this helpfile. Instead of putting the flags into the subjectline, you can also write the equivalents in the braces into the message text. Note that %RESCAN works likea switch in this case. The first %RESCAN enables rescanning of the following areas and the next %RESCAN disables rescanning. To connect an area you put the names of the echomailareas you want to connect in the message text, (only 1 name on each line). To disconnect an area put a - in front of the areaname in the messagetext. Example: ========================================================================= Msg #59 / 1 - 60 Time: 11 Dec 91 14:25:56 From: Carsten Brockmann on 51:102/1701 To : Areamgr on 51:102/1 Subj: password -l ------------------------------------------------------------------------- %HELP ATARI.GER %RESCAN ST_FIDO.GER %RESCAN JETMAIL_BETA -PENPAL -MSDOS.GER ========================================================================= This message connects you to ATARI.GER, ST_FIDO.GER and JETMAIL_BETA while at the same time disconnects you from PENPAL and MSDOS.GER. It rescans ST_FIDO.GER, sends you a list of connected and available areas and this helptext. The available areas on this system are divided into groups. Maybe you're not allowed to connect to some groups, because they are X-rated or only accessable under other network addresses. It is possible to (dis)connect all areas (or some specific groups) which are available with the commands %-ALL [groups] %+ALL [groups] (or %ALL [groups]) You can partly disable/enable areas with the commands %PASSIVE [groups] %ACTIVE [groups] If no groups are specified all groups are set to passive. This works also for groups which are normally only available under some other network- address. The areas set to passive are not disconnected but no mail is passed to you with the exception of personal mail in the areas. ===================================== Changing Parts of your Linkdefinition ===================================== You can also change some parts of your current linkdefinition with the following commands: %NOTIFY ON/OFF %COMPRESSION [LHAMail|LZHMail|ZIPMail|ARCmail|ARJMail|ZOOmail|None] If you have any problems using Areafix, please contact the system administrator on this system. Now that you have echoes... One of the echoes that you will probably want to use first will be A.ADM.TEST to send test messages through the network. This is the approved echo for testing your connections to the network and if you have A.ADM.TEST working, then the rest of the echoes will be a snap. There is also a local test echo called A.NET102.TEST which you may use for your pleasure (if you feel a bit self-conscious about putting out tests in the international echo!). Once you have connected A.ADM.TEST using AreaConsultant, send a message through using 51:102/0 as your hub for host-routed mail. Then do a manual poll to send it along to me. I'll respond to it through the echo when I see the message and that should make it back to you when you poll me the next time. A.ADM.TEST is also a good place to test out that new tagline that you've been dying to put out on the network, or test that super new mail tosser... :) We should be able to iron out any problems very quickly using A.ADM.TEST and then you are ready to grab any echo you wish. Sysop-only echoes should only be accessed by the sysop(s) of your system...any other echoes are for free distribution to anyone who wishes to read them. If you have a troublesome user, you may wish to restrict their write access to an echo...the decision is up to you as sysop of your node. AtariNet File Distribution System... The AtariNet File Distribution System (AFDS) is similar to the file echoes available through FIDONET and is based on the TICK-standard for sending files from node to node. This is a relatively new facet to AtariNet and I have a complete feed for AFDS files that I can pass on to your node should you desire it. You do not have to have a TICK-compatible programme on your end to get these files (as I will send them to you if you wish them regardless of whether you have TICK or not), but TICK will make your life a lot easier as you can have the new files automagically CRC-verified and moved to directories of your choice. If you do not have TICK (or compatible programme), then don't worry...all you have to do is kill the TIC files from your inbound directory and move the files as you wish. AFDS is Bill Jones' baby and he is at 51:203/0. Here are the available file echoes for your enjoyment... AtariNet File Distribution System The following file areas are either currently on the AtariNet FileBone, or are awaiting approval. If you'd like to receive one of these areas, please contact your host. Hosts are not required to carry all areas, however all areas will be available from 51:203/0. Current File Echoes: FileEcho Description Origination at =========================================================================== A_NODES AtariNet node administration Bill Scull, 51:1/0 ABBSUTIL BBS-Related Utilities Bill Jones, 51:203/0 ABBSGAME BBS-Related Games (Doors) (open) ABBSOTHR BBS-Related other software (open) AFDOOR FidoDoor Updates (includes ST-QWK) Bryan Hall, 51:3/6 AUTILS ST Utilities Erik Williams, 51:102/2 AGAMES ST Games Rich Tietjens, 51:2/10 ANETWORK FidoNet-Related Software Bill Jones, 51:203/0 AZNET Z*Net On-line magazine Ron Kovacs, 51:1/13 AOTHER Other ST Software (open) AGRAPHIC Graphics and related programs Terry May, 51:2/0 ASOUND Sounds, samples and related programs Terry May, 51:2/0 APROG Sources and programming info Bryan Hall, 51:3/6 =========================================================================== Any questions or comments should be directed to me at 51:203/0. Bill Jones, AFDS Coordinator I am the originator for AUTILS (this list is a bit old as I just got the job!), so you'll be able to get anything from that echo directly from me here in Raleigh should you wish to have them. Other file echoes take a while to finally filter down to Net 102, so please be patient! A.ADM.FDS is a message echo devoted to telling people about the files that are hatched into the AFDS and is available from me. Administratrivia... Every Sunday, a new nodelist will be sent to me and then I will forward it on to you using AutoFile...a TICK-style utility. If you can handle TIC files, then you can have your TICK utility stick the files wherever you want them to reside. Otherwise, you can kill the TIC files that I will send along with the file I'm hatching to your node. From time to time, I might also send you an update to this Net 102 policy document if anything significant changes (like AtariNet POLICY). The latest version will always be available from me for FREQ using the magick name NET102. Changes to the echo distribution list or file echo distribution lists will always be available in A.ADM.ECHO...it is an echo that is strongly recommended for your information on changes to the network echo structure (both message and file echoes). I'm thinking of doing a newsletter for Net 102 here in Raleigh just to give you an idea of what is going on over here in terms of changes to the BBS and general network policy/procedures, neat stuff available for your use, and so forth. This would be a two-way newsletter...if you have news of interest to the AtariNet community here in Raleigh, I'd be happy to include it in a newsletter. If I do this, it will probably be started in February or March. Who knows, this may mutate into a newsletter project for the entire network... :) AtariNet Policy - Draft July 04, 1992 This is a draft of a proposed policy for AtariNet. 1 OVERVIEW -------------- This document establishes the policy for sysops who are members of the AtariNet organization of electronic bulletin board systems. 1.1 LANGUAGE The official language of AtariNet is English. All documents must exist in English. Translation into other languages is encouraged. 1.2 INTRODUCTION AtariNet is an amateur electronic mail system and is not a common carrier or a value-added service network and is a public network only in as much as the independent, constituent nodes may individually provide public access to the network on their system. In order to provide compatibility with the majority of existing networks, AtariNet has been structured on 'FidoNet Technology' and, as such, makes large use of associated managerial and structural procedures whereby MultiNet operation and decentralized management provide the structure and control. This document describes the procedures which have been adopted to manage the network. 1.3 GEOGRAPHY There is no "true" need to assign nodes within the United States to a Host in their own state as in-state long distance calling is more expensive than out of state calling. This may also be true in other countries and this document will be updated accordingly. 1.4 NODELISTS The nodelist is a file updated weekly which contains the addresses of all recognized AtariNet nodes. This file is regularly made available by the Zone Co-ordinator on a weekly basis. To be included in the nodelist, a system must meet the requirements defined by this document. The full list as published by the International Co-ordinator is regarded as the official AtariNet nodelist, and is used in circumstances as determination of eligibility for voting. All parts that make up the full nodelist are available on each Zone Co-ordinator's and each Regional Co-ordinator's system. 2 ORGANISATION ----------------- AtariNet systems are grouped on several levels, and administration is de-centralized to correspond with these groupings. This overview provides a summary of the structure and the duties of the Co-ordinator positions. 2.1 INDIVIDUAL SYSTEMS AND SYSTEM OPERATORS The smallest subdivision of AtariNet is the individual system, corresponding to a single entry in the nodelist. The system operator (SysOp) formulates a policy for running the board and dealing with users. The sysop must mesh with the rest of the AtariNet system to send and receive mail. 2.1.1 THE BASICS As the sysop of an individual node, you can generally do as you please, as long as you observe mail events, are not excessively annoying to other nodes in AtariNet, and do not promote or participate in the distribution of pirated copyrighted software or other illegal behaviour via AtariNet. 2.1.2 TRAFFIC ENTERING AtariNet VIA A NODE A sysop listed in the nodelist entry is responsible for all traffic entering AtariNet via that system. This includes (but is not limited to) traffic entered by users, points, and any other networks for which the system might act as a gateway. If a sysop allows "outside" messages to enter AtariNet via the system, the gateway system must be clearly identified by a AtariNet node number as the point of origin of that message, and it must act as a gateway in the reverse direction. Should such traffic result in a violation of Policy, the sysop must rectify the situation. 2.1.2.1 USERS The sysop is responsible for the actions of any user when they affect the rest of AtariNet. Any traffic entering AtariNet via a given node, if not from the sysop, is considered to be from a user and is the responsibility of the sysop. 2.1.2.2 POINTS A point is a AtariNet-compatible system that is not in the nodelist, but communicates with AtariNet through a node referred to as a bossnode. A point is generally regarded in the same manner as a user, and the bossnode is responsible for mail from the point. (See section 2.1.2) Points are addressed by using the bossnode's nodelist address; for example, a point system with a bossnode of 114/15 might be known as 114/15.12. Mail destined for the point is sent to the bossnode, which then routes it to the point. 2.1.3 ROUTING MAIL You are not required to route traffic if you have not agreed to do so. You are not obligated to route traffic for all if you route it for any, unless you hold a Co-ordinator position. Routing traffic through a node not obligated to perform routing without the permission of that node may be annoying behavior. This includes unsolicited echomail. If you do not forward a message when you previously agreed to perform such routing, the message must be returned to the sysop of the node at which it entered AtariNet with an explanation of why it was not forwarded. (It is not necessary to return messages which are addressed to a node which is not in the current nodelist.) Intentionally stopping an in-transit message without following this procedure constitutes annoying behavior. In the case of a failure to forward traffic due to a technical problem, it does not become annoying unless it persists after being pointed out to the sysop. 2.1.3.1 ALTERATION OF ROUTED MAIL You may not modify, other than as required for routing or other technical purposes, any message, netmail or echomail, passing through the system from one AtariNet node to another. If you are offended by the content of a message, the procedure described in section 2.1.3 must be used. 2.1.4 USE OF CURRENT NODELIST Network mail systems generally operate unattended, and place calls at odd hours of the night. If a system tries to call an incorrect or out-of-date number, it could cause some person's phone to ring in the middle of the night, much to their annoyance and to those of civil authorities. For this reason, a sysop who sends mail is obligated to obtain and use the most recent edition of the nodelist as is practical. 2.1.5 NODE UNAVAILABILITY If your node will be down for an extended period (more than a day or two), inform your Co-ordinator as soon as possible. It is not your Co-ordinator's responsibility to chase you down for a status report, and if your system stops accepting mail it will be removed from the nodelist. If you will be leaving your system unattended for an extended period of time (such as while you are on vacation), you should notify your Co-ordinator. Systems have a tendency to "crash" now and then, so you will probably want your Co-ordinator to know that it is a temporary condition if it happens while you are away. 2.1.6 EXCOMMUNICATION A system which has been dropped from the network is said to be excommunicated (i.e. denied communication). If you find that you have been excommunicated without warning, your Co-ordinator was unable to contact you. You should rectify the problem and contact your Co-ordinator. It is considered annoying behavior to assist a system which was excommuni- cated in circumventing that removal from the nodelist. For example, if you decide to provide an echomail feed to your friend who has been excommuni- cated, it is likely that your listing will also be removed. 2.1.7 FORMING A NETWORK If there are several nodes in your area, but no network, a new network can be formed. This has advantages to both you and to the rest of AtariNet. You receive better availability of nodelists and everyone else can take advantage of host-routing netmail to the new network. The first step is to contact the other sysops in your area. You must decide which nodes will comprise the network, and which of those nodes you would like to be the Network Co-ordinator. Then consult your Regional Co-ordinator. You must send the following information: 1) The region number(s), or network number(s) if a network is splitting up, that are affected by the formation of your network. The Regional Co-ordinator will inform the Zone Co-ordinator and the Co-ordinators of any affected networks that a new network is in formation. 2) A copy of the proposed network's nodelist segment. This file should be attached to the message of application for a network number, and should use the proper nodelist format in use on AtariNet. Please elect a name that relates to your grouping. Granting a network number is not automatic. Even if the request is granted, the network might not be structured exactly as you request. Your Regional Co-ordinator will review your application and inform you of the decision. Once the request is granted, everyone in the new net must change their node numbers accordingly. The old numbers will be left intact for approximately one week. 2.2 NETWORKS AND NETWORK CO-ORDINATORS A network is a collection of nodes Uaually in a geographic area and usually defined by an area of convenient telephone calling. Networks Co-ordinate their mail activity to decrease cost. The Network Co-ordinator is appointed by the Regional Co-ordinator. 2.2.1 RESPONSIBILITIES A Network Co-ordinator has the following responsibilities: 1) To receive incoming mail for nodes in the network, and arrange delivery to its recipients. 2) To assign node numbers to nodes in the network. 3) To maintain the nodelist for the network, and to send a copy of it to the Regional Co-ordinator whenever it changes. 4) To make available to nodes in the network new nodelist files and new revisions of Network Policy Documents as they are received, and to periodically check to ensure that nodes use up to date nodelists. 2.2.2 ROUTING INBOUND MAIL It is your responsibility as Network Co-ordinator to Co-ordinate the receipt and forwarding of host-routed inbound netmail for nodes in your network. The best way to accomplish this is left to your discretion. If a node in your network is receiving large volumes of mail you can request that the sysop contact the systems which are sending this mail and request that they not host-route it. If the problem persists, you can request your Regional Co-ordinator to assign the node a number as an independent and drop the system from your network. You are not required to forward encrypted, commercial, or illegal mail. However, you must follow the procedures described in section 2.1.3 if you do not forward the mail. 2.2.3 ASSIGNING NODE NUMBERS It is your responsibility to assign node numbers to new nodes in your network. You may also change the numbers of existing nodes in your network, though you should check with your member nodes before doing so. You may assign any numbers you wish, so long as each node has a unique number within your network.You may not assign a node number to a node in an area covered by an existing network. Further, if you have nodes in an area covered by a network in formation, those nodes must be transferred to the new network. You must not assign a node number to any system until you have received a formal request from that system by AtariNet mail. This will ensure that the system is minimally operational. It is also recommended, though not required, that you call a board which is applying for a node number before assigning it a node number. You should use network mail to inform a new sysop of the node number, as this helps to ensure that the system is capable of receiving network mail. If a node in your network is acting in a sufficiently annoying manner, then you can take whatever action you deem fit, according to the circumstances of the case. 2.2.4 MAINTAINING THE NODELIST You should implement name changes, phone number changes, and so forth in your segment of the nodelist as soon as possible after the information is received from the affected node. You should also on occasion send a message to every node in your network to ensure that they are operational. If a node turns out to be offline with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the line should be removed from the nodelist). You should assemble a master nodelist for your network every week and send it to your Regional Co-ordinator by the day designated. It is important that you forward this by the day specified by the Regional Co-ordinator so as not to cause a further week's delay in adding a node to the master nodelist. 2.2.5 MAKING AVAILABLE POLICIES AND NODELISTS As a Network Co-ordinator you should obtain a new issue of the nodelist every week from your Regional Co-ordinator. You must make this available to all nodes in the network. You should also obtain the most recent versions of the Policy documents that bind the members of your network, and make those available to the nodes in your network. Policies are released at sporadic intervals, so you should also inform the nodes in your network when such events occur, and ensure the nodes are generally familiar with the changes. 2.2.6 NETWORK ROUTING HUBS Network Routing Hubs may be appointed by the Network Co-ordinator, in order to assist in the management of a large network but should be avoided if at all possible so as not to cause uneccessary delays in mail routing. The exact duties and procedures are a matter for the Network Co-ordinator and the hubs to arrange, and will not be discussed here, except that a Network Co-ordinator cannot delegate responsibility to mediate disputes. 2.3 REGIONS AND REGIONAL CO-ORDINATORS A region is a well-defined geographic area containing nodes which may or may not be combined into networks. A typical region will contain many nodes in networks, and a few independent nodes which are not a part of any network. Regional Co-ordinators are appointed by the Zone Co-ordinator. 2.3.1 RESPONSIBILITIES A Regional Co-ordinator has the following responsibilities: 1) To receive incoming mail for networks in the region, and arrange delivery to its recipients. 2) To assign node numbers to independent nodes in the region. 3) To encourage independent nodes in the region to join existing net- works, or to form new networks. 4) To assign network numbers to networks in the region and define their boundaries. 5) To compile a nodelist of all of the networks and independents in the region, and to send a copy of it to the Zone Co-ordinator whenever it changes. 6) To ensure the smooth operation of networks within the region. 6) To make new nodelist files and Policies available to the Network Co-ordinators in the region as soon as is practical. 2.3.2 ASSIGNING NODE NUMBERS It is your responsibility to assign node numbers to independant nodes in your region. (Section 2.2.3 is applicable) If you receive a node number request from outside your region, you must forward it to the most local Co-ordinator for the requestor as you can determine. If you receive a node number request from a new node that is in an area covered by an existing network, then you must forward the request to the Co-ordinator of that network instead of assigning a number yourself. If a network forms in an area for which you have independent nodes, those nodes will be transferred to the local network as soon as is practical. 2.3.3 ENCOURAGING THE FORMATION AND GROWTH OF NETWORKS One of your main duties as a Regional Co-ordinator is to promote the growth of networks in your region. You should avoid having independent nodes in your region which are within the coverage area of a network. There are, however, certain cases where a node should not be a member of a network, such as a system with a large amount of inbound netmail; see section 2.2.2. If several independent nodes in your region are in a local area you should encourage them to form a network, and if necessary you may require them to form a network. Refer to section 2.1.7. Note that this is not intended to encourage the formation of trivial networks. Obviously, one node does not make a network. The exact number of nodes required for an effective network must be judged according to the circumstances of the situation, and is left to your discretion. 2.3.4 ASSIGNING NETWORK NUMBERS It is your responsibility to assign network numbers to new networks forming within your region. You are assigned a pool of network numbers to use for this purpose by your Zone Co-ordinator. 2.3.5 MAINTAINING THE NODELIST As a Regional Co-ordinator, you have a dual role in maintaining the nodelist for your region. First, you must maintain the list of independent nodes in your region. You should attempt to implement name changes, phone number changes, and so forth in this nodelist as soon as possible. You should also on occasion send a message to every independent node in your region to ensure that they are operational. If a node turns out to be offline with no prior warning, you can either mark the node down or remove it from the nodelist. (Nodes are to be marked DOWN for a maximum of two weeks, after which the entry should be removed from the nodelist.) Second, you must receive the nodelists from the Network Co-ordinators within your region. You will need to maintain a set of nodelists for each network within your region, since you cannot count on getting an update from each Network Co-ordinator every week. You should assemble a master nodelist for your region every week and send it to your Zone Co-ordinator by the day and time designated. 2.3.6 OVERSEEING NETWORK OPERATIONS You are responsible for appointing Network Co-ordinators for the nets in your region. If the outgoing Network Co-ordinator suggests a successor, you are not obligated to accept that individual, although you normally will. Similarly, you are not obligated to accept the individual selected by the members of the network in an election, although you normally will. It is your responsibility as Regional Co-ordinator to ensure that the networks within your region are operating in an acceptable manner. This does not mean that you are required to operate those networks; that is the responsibility of the Network Co-ordinators. It means that you are responsible for assuring that the Network Co-ordinators within your region are acting responsibly. If you find that a Network Co-ordinator within your region is not properly performing the duties outlined in Section 2.2, you should take whatever action you deem necessary to correct the situation. If a network grows so large that it cannot reasonably accommodate traffic flow , the Regional Co-ordinator can direct the creation on one or more new networks from that network. These new networks, although they may be within a single local-calling area, must still conform to a geographical basis for determining membership. It is your obligation as Regional Co-ordinator to maintain direct and reasonably frequent contact with the networks in your region. The exact method of accomplishing this is left to your discretion. 2.3.7 MAKING AVAILABLE NODELISTS AND POLICIES As a Regional Co-ordinator, it is your responsibility to obtain the latest nodelist and network policies as they are published, and to make them available to all Network Co-ordinators within your region as soon as is after you receive them. The method of distribution is left to your discretion. 2.4 Zone CO-ORDINATOR The Zone Co-ordinator is the "first among equals" Region Co-ordinator, and Co-ordinates the joint production of the master nodelist by the Region Co-ordinators. 2.4.1 RESPONSIBILITIES The Zone Co-ordinator has the primary task of co-ordinating the creation of the master nodelist by managing the distribution between the Zones of the Zone nodelists and for the co-ordination and distribution of Network Policies to the Region Co-ordinators. The Zone Co-ordinator is responsible for definition of new region and for negotiation of agreements for communication with other networks. ("Other network" in this context means other networks with which AtariNet communicates as peer-to-peer, not "network" in the sense of the AtariNet organizational level.) In cases not specifically covered by this document, the Zone Co-ordinator may issue specific interpretations or extensions to this policy. The Region Co-ordinator structure may reverse such rulings by a majority vote. 2.5 CHECKS AND BALANCES These levels act to distribute the administration and control of AtariNet to the lowest possible level, while still allowing for Co-ordinated action over the entire mail system. Administration is made possible by operating in a top-down manner. That is, a person at any given level is responsible to the level above, and responsible for the level below. If a person at any level above sysop is unable to properly perform their duties, the person at the next level may replace them. For example, if a Regional Co-ordinator fails to perform, the Zone Co-ordinator can replace him. To provide for checks and balances at the highest level of AtariNet, there are two exceptions to this top-down organization. Region Co-ordinators and the the Zone Co-ordinator are selected by a majority vote of the Co-ordinators at the level below. Similarly, decisions made by the Zone Co-ordinator can be reversed by the Region Co-ordinators and decisions made by a Region Co-ordinator can be reversed by the Network Co-ordinators. Decisions made by other Co-ordinators are not subject to reversal by a vote of the lower level, but instead are subject to the appeal process described in section 3.4. 3. SETTLEMENT OF DISPUTES ------------------------- The first step in any dispute between sysops is for the sysops to attempt to communicate directly, at least by netmail, preferably by voice. Any complaint made that has skipped this most basic communication step will be rejected. Filing a formal complaint is not an action which should be taken lightly. Investigation and response to complaints requires time which Co-ordinators would prefer to spend doing more constructive activities. Persons who persist in filing trivial policy complaints may find themselves on the wrong side of an excessively-annoying complaint. Complaints must be accompanied with verifiable evidence, generally copies of messages; a simple word-of- mouth complaint will be dismissed out of hand. Failure to follow the procedures herein described (in particular, by skipping a Co-ordinator, or involving a Co-ordinator not in the appeal chain) is in and of itself annoying behavior. 3.1 PROBLEMS WITH ANOTHER SYSOP If you are having problems with another sysop, you should first try to work it out via netmail or voice conversation with the other sysop. If this fails to resolve the problem, you should complain to your Network Co-ordinator and the other sysop's Network Co-ordinator. If one or both of you is not in a network, then complain to the appropriate Regional Co-ordinator. Should this fail to provide satisfaction, you have the right to follow the appeal process described in section 3.4. 3.2 PROBLEMS WITH YOUR NETWORK CO-ORDINATOR If you are having problems with your Network Co-ordinator and feel that you are not being treated properly, you are entitled to a review of your situa- tion. As with all disputes, the first step is to communicate directly to attempt to resolve the problem. The next step is to contact your Regional Co-ordinator. If your case has merit, there are several possible courses of action, including a change of Network Co-ordinators or even the disbanding of your network. If you have been excommunicated by your Network Co-ordinator, that judgement may be reversed, at which point you will be reinstated into your net. If you fail to obtain relief from your Regional Co-ordinator, you have the right to follow the appeal process described in section 3.4. 3.3 PROBLEMS WITH OTHER CO-ORDINATORS Complaints concerning annoying behavior on the part of any Co-ordinator are treated as in section 3.4 and should be filed with the next level of Co-ordinator. For example, if you feel that your Regional Co-ordinator is guilty of annoying behavior (as opposed to a failure to perform duties as a Co-ordinator) you should file your complaint with the Zone Co-ordinator. Complaints concerning the performance of a Co-ordinator in carrying out the duties mandated by policy are accepted only from the level immediately below. For example, complaints concerning the performance of Regional Co-ordinators would be accepted from Network Co-ordinators and independents in that region. Such complaints should be addressed to the Zone Co-ordinator after an appro- priate attempt to work them out by direct communications. 3.4 APPEAL PROCESS A decision made by a Co-ordinator may be appealed to the next level. Appeals must be made within two weeks of the decision which is being appealed. All appeals must follow the chain of command; if levels are skipped the appeal will be dismissed out of hand. An appeal will not result in a full investigation, but will be based upon the documentation supplied by the parties at the lower level. For example, an appeal of a Network Co-ordinator's decision will be decided by the Regional Co-ordinator based upon information provided by the Co-ordinator and the Sysop involved; the Regional Co-ordinator is not expected to make an independent attempt to gather information. The appeal structure is as follows: Network Co-ordinator decisions may be appealed to the appropriate Regional Co-ordinator. Regional Co-ordinator decisions may be appealed to the appropriate Zone Co-ordinator. At this point, the Zone Co-ordinator will make a decision and communicate it to the Regional Co-ordinators in that zone. This decision may be reversed by a majority vote of the Regional Co-ordinators. If your problem is with the Zone Co-ordinator per se, that is, the Zone Co-ordinator has committed a Policy violation against you, your complaint should be filed with your the Region Co-ordinator, who will make a decision and forward it to the other Region Co-ordinators who will vote on it. 4 INITIATION OF POLICY MODIFICATION ------------------------------------- A referendum on policy modification is invoked when a majority of the AtariNet Regional Co-ordinators inform the Zone Co-ordinator that they wish to consider a proposed new version of Policy. 4.1 ANNOUNCEMENT AND RESULTS NOTIFICATION Proposed changes to Policy are distributed using the same structure which is used to distribute nodelist files. Results and announcements related to the referendum are distributed by the Co-ordinator structure as a part of the weekly nodelist file. If it is adopted, the Zone Co-ordinator sets the effective date for a new policy through announcement in the weekly nodelist difference file. Effective date will be not more than one month after the close of balloting. 4.2 ELIGIBILITY TO VOTE Each member of the AtariNet Co-ordinator structure at and above Network Co-ordinator is entitled to one vote. (Hub Co-ordinators do not vote). In the case of the position changing hands during the balloting process, either the incumbent or the new Co-ordinator may vote, but not both. If a person holds more than one Co-ordinator position, they still receive only one vote. Network Co-ordinators are expected to assess the opinions of the members of their network, and to vote accordingly. A formal election is not necessary, but the Network Co-ordinator must inform the net of the issues and solicit input. The network Co-ordinator functions as the representative of the rank and file members of AtariNet. 4.3 VOTING MECHANISM The actual voting mechanism, including whether the ballot is secret and how the ballots are to be collected, verified, and counted, is left to the discretion of the Zone Co-ordinator. Ideally, ballot collection should be by some secure message system, conducted over AtariNet itself. In order to provide a discussion period, the announcement of any ballot must be made at least two weeks before the date of voting commencement. The balloting period must be at least two weeks. 4.4 VOTING ON A WHOLE POLICY DOCUMENT Given that Policy is intertwined and self referencing, a relatively simple change may require several alterations of the document. In order to simplify the process, balloting is done on choices between whole documents, rather than individual amendments. In the simplest case, this means voting yea or nay to a new document. If a number of alternatives are to be considered, they must be presented as whole documents, from which one is chosen. 4.5 DECISION OF VOTE A Policy amendment is considered in force if, at the end of the balloting period, it has received a majority of the votes cast. For example, if there were 350 eligible voters, 100 of which cast a vote, then at least 51 affirmative votes would be required to declare the amendment in force. In the case of multiple policy changes which are considered on the same ballot, a version must receive more than 50% of the votes cast to be consid- considered ratified. "Abstain" is a valid vote in this case, effectively being a vote for not changing the current policy as it simply increases the number of votes required to ratify the proposed change. 5 HOW TO OBTAIN A NODE NUMBER ------------------------------- You must first obtain a current nodelist so that you can send mail. You do not need a node number to send mail, but you must have one in order for others to send mail to you. The first step in obtaining a current nodelist is to locate a AtariNet bulletin board. Most bulletin board lists include at least a few AtariNet systems, and usually identify them as such. Use a local source to obtain documents because many networks have detailed information available which explains the coverage area of the network and any special requirements or procedures. Once you have a nodelist, you must determine which network or region covers your area. Regions are numbered 100,200,300,400 for now. They will always be divisable by 100. Networks are more restricted in area than regions, but are preferred since they improve the flow of mail and provide more services to their members. If you cannot find a network which covers your area, then pick the region which does. Once you have located the network or region in your area, send a message containing a request for a node number to node zero of that network or region. The request must be sent by netmail, as this indicates that your system has mailing capability. You must set up your software so that the from-address in your message does not cause problems for the Co-ordinator who receives it. If you pick the address of an existing system, this will cause obvious problems. If your software is capable of using address -1/-1, this is the traditional address used by potential sysops. Otherwise use net/9999 (e.g. if you are applying to net 123, set your system up as 123/9999). Many nets have specific instructions available to potential sysops and these procedures may indicate a preference for the from-address. The message you send must include at least the following information: 1) Your real name. 2) Your voice telephone number 3) The name of your system. 4) The city and state where your system is located. 5) The phone number to be used when calling your system. 6) Your hours of operation for netmail and BBS. 7) The maximum baud rate you can support. 8) The type of mailer software and modem you are using. Your Co-ordinator may contact you for additional information. All information submitted will be kept confidential and will not be supplied to anyone except the person who assumes the Co-ordinator position at the resignation of the current Co-ordinator. You must indicate that you have read, and agree to abide by, this document and all the current policies of AtariNet. Please allow at least two weeks for a node number request to be processed. If you send your request to a Regional Co-ordinator, it may forwarded to the appropriate Network Co-ordinator. 6 ECHOMAIL AND ECHOMAIL CONFERENCES -------------------------------------- This section sets forth policy governing Echomail within AtariNet. The basic policy of Echomail is to promote communication in Echomail Conferences in a lawful, friendly manner consistent with the general principles of AtariNet. This section applies to Echomail conferences on the "AtariNet Backbone" 6.1 GENERAL 6.1.1 PROHIBITION ON ILLEGAL ACTIVITIES Any Node which knowingly distributes or allows to be entered into Echomail conferences any messages containing or promoting illegal activities or information shall be deemed to have violated general AtariNet policy. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which would result in criminal prosecution. 6.1.2 CENSORSHIP The use of Censorship in the passing or distribution of echomail will be considered a violation of this section and will not be tolerated. An exception to this provision shall be the deletion and not censorship of messages by any Sysop which may lead to legal action against that Sysop. No echomail shall be modified in any manner which could potentially cause duplicates. 6.1.3 OPEN ACCESS CONFERENCE This is a non-restricted conference open to all users who are willing to follow the posted conference rules. 6.1.4 INTER-NETWORK CONFERENCES Inter-Net conferences shall conform to general AtariNet policy in addition to any foreign network's provisions. Inter-Network links shall be set up according to procedures laid down in General AtariNet policy. It shall be the duty of those providing the INTER-NETWORK CONFERENCE links to remove foreign net distribution identifiers which will adversely affect the distribution of the Echomail conference while in AtariNet. The INTER- NETWORK CONFERENCE links maintained in AtariNet shall be operated in a manner not to interfere with the foreign network's distribution of Echomail. 6.1.5 SEEN-BY LINE Under the current topology (the routing structure of Echomail), SEEN-BY lines play an important part in reducing duplicate messages. The stripping of SEEN-BYs (except Inter-Network EchoGates) will not be allowed unless approved by the ZEC. 6.1.6 COUNTERFEIT MESSAGES Entering or knowingly distributing counterfeit messages shall be considered a violation of AtariNet policy enforceable under the terms of AtariNet policy. As used in this paragraph, a counterfeit message is defined as any message entered using another person's name, handle or node address with the intent of deceiving others about the true author of the message. No handles shall be used to enter messages to knowingly provoke, inflame or upset participants in a conference with the purpose of deceiving others about the true identity of the author. 6.1.7 DEFAMATORY POSTING The posting of any DEFAMATORY MESSAGE will not be tolerated and shall lead to disciplinary action under the terms of General AtariNet policy. The posting of substantiated facts shall not be considered a violation under this section. 6.1.8 ADDING OR REMOVING CONFERENCES FROM THE MAINSTREAM In order to add an Echo to the AtariNet backbone, you should first leave a message in the A_Echo area with your idea. A total of 5 Sysops and 2 Hosts must request it in order for it to be placed on the backbone. Note that the 2 Hosts count as Sysops also. 6.1.9 MESSAGE STANDARDS Until the adoption of a superceding standard, the following Echomail message standards will apply: a) Eight-bit characters (ASCII 128-255) and non-printing low-order codes (ASCII 2-31) are prohibited, except 8Dh(soft character). This is not intended to discourage participation of foreign zones or networks, which may permit said characters. Any echomail processor should pass information exactly as it was received, without stripping any non-standard characters. b) Origin lines are limited to 79 characters including the required ending of a proper network address (i.e. Zone:Net/Node.Point with zone and point being optional). c) Tear lines are limited to 35 characters including the required "--- " lead-in. These may ONLY contain packer or editor program identification. Tear lines for message editors are discouraged. If an editor adds a tear line, it should also add an origin line to avoid multiple tear lines. d) "Extra" origin lines (ZoneGating) are to be limited to essential information only. This consists of the required lead-in plus the network name "Gateway" and optionally the software ID followed by a Zone:Net/Node address. e) SEEN-BY addresses must be in sorted order. Multiple AKA's or other network addresses are not allowed in SEEN-BY lines. 7 ENFORCEMENT -------------- Enforcement of this section shall be under the provisions of General AtariNet policy. Complaints concerning Echomail violations defined under this section may be filed by the aggrieved individual, the conference moderator or by any level of Echomail Co-ordinator. All complaints made pursuant to this section must be made within 60 days of the date of occurrence or discovery. Complaints shall be filed under the provisions of AtariNet Policy, with a copy to the respective EC. Any questions? If you have problems setting up your node, getting echomail or AFDS feeds to work, or you are confused about anything pertaining to AtariNet operation, then feel free to contact me on 919-859-9449 (local to Raleigh, NC). This is my voice line and I'd appreciate it if you considered it confidential information and not give it out to anyone but other sysops interested in AtariNet. I won't set up your node for you (that's half the fun of FIDONET), but I can give general pointers that you might want to consider when setting up your node (i.e., how domains work, etc.). My expertise is in Atari FIDO-related software...so if you don't have an Atari, I might not be much help except in a general sense. If you already have FIDONET working on your system, then you've got most of the battle won. Before calling, please read your docs again as that might answer some of your questions or solve your problems and save us a bit of time. I am here to serve you, not vice versa...so if you have any suggestions as to how I might do the job better, please let me know. I hope I prove worthy of your support in this endeavour... SunFox