F I D O N E W S -- Volume 14, Number 22 2 June 1997 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ THE RIOT STARTS TOMORROW Table of Contents 1. EDITORIAL ................................................ 1 How about a contest or another new Section? .............. 1 2. LETTERS TO THE EDITOR .................................... 2 IGATOR by Argus .......................................... 2 International BBS Week Echo Correction ................... 2 Bring Back FIDONET.NA .................................... 3 3. ARTICLES ................................................. 5 North American Backbone Problems ......................... 5 4. GETTING TECHNICAL ........................................ 7 FSC-0075 - ISDN capability flags in the Nodelist ......... 7 FSC-0076 - Proposal for NetMail AreaTags ................. 10 FSC-0077 - Type-10 Packet Format ......................... 14 FSC-0078 - Gateway between FidoNet compatible networks ... 20 5. COORDINATORS CORNER ...................................... 25 Nodelist-statistics as seen from Zone-2 for day 150 ...... 25 6. NET HUMOR ................................................ 26 7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 28 FidoNet Echos via the Internet from 1:141/635 ............ 28 8. ANSWERS OF THE WEEK ...................................... 30 Old Nodelists available in Zone 2 by appointment ......... 30 9. NOTICES .................................................. 32 Future History ........................................... 32 10. FIDONET SOFTWARE LISTING ................................ 34 Latest Greatest Software Versions ........................ 34 And more! FIDONEWS 14-22 Page 1 2 Jun 1997 ================================================================= EDITORIAL ================================================================= Let's have a contest to name the new network the Echomail weenies want to move into when FidoNet refuses to adjust to their skew of what FidoNet is and does! The new name should certainly be self-contained in eight characters for historical if not MSDOS plurality. That name should express as succinctly as possible the all-consuming Echomailness of the newly moved into network. It might even have some kind of oblique reference to its former FidoNet origin like TailDog or FleaNits. [snicker] After all, the EWs don't want to become yet another superfluous FTN based solely on Echomail that will eventually dry up and blow away like its predecessors such as EggNet and AlterNet do they? They've got to fight for the right to coopt FidoNet without infringing that trademark. And in an unrelated vein, next week there will be two more Sections available for submissions to FidoNews. The first will be .TRU for True Stories of FidoNet and the second will be .FIC for wannabe FidoNet Fiction writers [which could include Echomail weenies' standard bleats]. The ARTSPEC.DOC will be updated to include the new Section extensions and hatched out into FIDONEWS and SOFTDIST file echos. The True Stories will be essays about FidoNet-related events in the personal lives of Sysops and/or Users. FidoNet Fiction will be imaginary FidoNet-related short stories or novellae or poems or limericks. In either case, remember this is a family publication and nothing illegal gets published. [grin] Well, it's later than usual this week. We've been having a lot of lightning storms and tornado watches and warnings today and the system has been offline a lot to avoid frying. Please note that the R19 Internet listing has changed once again. C.B. ----------------------------------------------------------------- FIDONEWS 14-22 Page 2 2 Jun 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Tue May 27 22:26:02 1997 From: Max Masyutin @ 2:469/84 To: Christopher Baker @ 1:18/14 Date: 26 May 97 16:11:18 Subj: Fidonews FIDONET BY INTERNET Hello Christopher! About "FIDONET BY INTERNET" section of fidonews. We are the developers of IGATOR - Fidonet-Internet gateway - our URL is http://www.ritlabs.com/igator/ We are also working in direction of fidonet transferring via internet channels, and have written a multinode mailer that can simultaneously transfer fidonet netmail/echomail/files over dialup and ip using standard FTS technology. Argus is now widely used in Russia, especially be hubs, and some nodes in UK and US began to use Argus as a primary mailer. Argus home page is http://www.ritlabs.com/argus/ Max. [Argus Team] --- * Origin: max@ritlabs.com (2:469/84) ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Sun Jun 01 00:37:10 1997 From: David Chord @ 3:771/1560 To: Christopher Baker @ 1:18/14 Date: 27 May 97 16:33:24 Subj: INTBBSWK.ART It's been brought to my attention that I made an error with a previous note on International BBS Week and it's support echo, INTBBS_WK. The error was mentioning the echo as INTBBS_WEEK. Could anyone who has set this area up as INTBBS_WEEK please change it to the correct INTBBS_WK. Also, links are needed to Zones 2, 4, 5 and 6, as well as distribution around the rest of Z1 and Z3. If you could help with this, please do so. Dave FIDONEWS 14-22 Page 3 2 Jun 1997 Support International BBS Week! Peek in INTBBS_WK for details --- timEd 1.10 ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Sun Jun 01 19:18:16 1997 From: Cindy Ingersoll @ 1:2623/71 To: Editor @ 1:1/23 Date: 30 May 97 16:17:46 Subj: Bring Back FIDONET.NA -=> Note: Copied (from: z1_backbone) by C I A using timEd. I am proposing the reformation of fidonet.na. The way I figure, if enough people in enough regions support the concept, we can approach the main distrib hubs (George Peace, John Souvestre, Ken Wilson) and ask them to host it for us. I know at least George Peace is willing to include other nets in his bulk feed, so I don't see him rejecting an request to pass around fidonet.na. The technical aspects we need to accomplish are, who maintains the fidonet.na, how echos are to be added/removed to/from it, and a minimum set of 'rules'. Please, let's open a discussion on this, perhaps someone can assist in getting a 'fidonet.na discussion' echo on the backbone, so we can hash out some ideas. I had in mind, for adding echos, to have say, 5 nodes from each region 'vote' that they will carry and participate in the echos. Much better than the current '2 rec' voting echos are at the mercy of now :) As for a minimal set of rules, we'll prolly be arguing for a while. But I think the concept of an alternative backbone is overdue, and I hope we can get together and create it :) A good start, along with the creation of an echo for discussion, would be to begin assembling a list of ftp/transx/vfossil and other Internet-fido feeds. I would like to suggest to our Editor of Fidonews Chris Baker, add a new section to the weekly fidonews, a list in hierarchial order, from T3's to 28.8s, all the system's who have fidonet available across the Internet. Here's my current list, please feel free to send additions! :) Spd | Node# | Operator | Services | rate -------------------------------------------------------------------- T1 | 1:270/101 | George Peace | FTPHUB | $30 monthly FIDONEWS 14-22 Page 4 2 Jun 1997 33.6 | 1:2604/104 | J. Mclaughlin | FTPHUB, VFOSSIL | $1 monthly | | | | Origin: Fly By Night * HaXeD HeXeD HiXed * (609)653-1FLY! (1:2623/71) ----------------------------------------------------------------- FIDONEWS 14-22 Page 5 2 Jun 1997 ================================================================= ARTICLES ================================================================= North American Backbone Problems -by Jon Gentil 1:232/211.0 The North American Backbone (NAB for short) is undergoing tremendous alterations of itself, and it's causing some disturbances in the FidoNet community. Take for example the FLAME echo. I don't really like the FLAME echo, and really don't hate it either. But when it's removed from distribution simply because the Backbone feels that it's causing trouble, there's a problem. Which echo will they remove next? The TOTT_* echos pose a potential hazard to it's readers. The CHATTER echo has mean people in it. The FILEFIND echo doesn't have enough real people posting there. What next? And did you notice the second-to-last paragraph of this week's Backstat.na? It reads: --------------------------------------------------[BACKSTAT.NA]---- Each region is normally offered 1 link to each ZHub. Exceptions are made after agreement between the REC, Z1EC, and the ZHub subject to the ability to handle the additional load. Individual net/node connections to ZHubs are made on the basis that the node will serve as a Region Hub, the exception being connections local to the ZHub. ----[END]---------------------------------------------------------- Note "Individual net/node connections to ZHubs are made on the basis that the node will serve as a Region Hub." Does that mean that every node connected to a ZHub serves as a Region Hub? That's what it says. So we have 100+ Rhubs now. !!! Ever notice how the BOFAQ is constantly changing? Who radified it? Who must obey it? Anyone? Everyone? Why is a private distribution system allowed to use the term ZHub if it's private? I thought that Hubs were public. The requirements to be a Hub of the NAB are that you must have a link to a ZHub and you must have at least one downlink, yet Ken Wilson (1:12/12), a ZHub, has no downlinks. Do they pardon those that are "Insiders?" Did you notice how conviently the Backbone changed their policy of who is the OBO? Possibly in fear that someone that wants to abolish the OBO Council and return the Backbone to a public system? Write your NC's, NEC's, RC's, REC's, ZC, ZEC, and even me telling FIDONEWS 14-22 Page 6 2 Jun 1997 us your opinion of the North American Backbone. Articleize it in FidoNews. ----------------------------------------------------------------- FIDONEWS 14-22 Page 7 2 Jun 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing FidoNet History republication of the extant FidoNet Standards and Proposal documents. They have been reformatted to 70 columns where required and some tables may be askew as a result. Node numbers and phone numbers may be out of date.] Ed. | Document: FSC-0075 | Version: 001 | Date: 23rd October 1993 | Author: Jan Ceuleers ISDN capability flags in the Nodelist A proposal by Jan Ceuleers, 2:292/857 version 0.4, October 3rd 1993 1 Introduction The Integrated Services Digital Network is a worldwide overlay network, offering the same services as the PSTN (Public Switched Telephone Network) and more. Its basic bearer capability is a digital bit stream of 64000 bits/s, as opposed to the audio channel with a 3.1 kHz bandwidth provided by the PSTN. Transferring data across the ISDN can be done in one of two ways: - by using the telephony services the ISDN provides. In this mode, a standard modem can continue to be used. Some modulation schemes currently in use are V.32bis, PEP, ZyXEL, HST, V.32, etc. We already have nodelist flags for these cases. - by using ISDN's 'native' mode. In this case, a number of protocols (either or not ISDN-specific) are used, such as V.110, V.120, X.75 etc. This document aims to define the way in which nodes are to advertise their ISDN capabilities in the nodelist, irrespective of whether or not ISDN-only nodes should be in the nodelist in the first place. This latter problem is to be solved by the politicians. Descriptions of ISDN equipment and compatibility with POTS (Plain Old Telephone Service) equipment are beyond the scope of this document. More detailed information on ISDN is also not provided; readers are referred to the literature (e.g. 'Computer Networks' by Andrew Tanenbaum). FIDONEWS 14-22 Page 8 2 Jun 1997 2 Different flavors of the same protocol Some ISDN protocols have different flavors, some of which differ only marginally, but others are quite distinct. For the techies among the readership: examples of both cases can be found in the 1988 definition of V.110. There are two variants of the frame structure used in the 56kbps synchronous mode (marginal difference), while there is quite a major difference between the synchronous and asynchronous versions of V.110. Since FidoNet applications are essentially character-based, the asynchronous versions of protocols will be preferred over the synchronous-ones(1). This applies to V.110 and V.120 and to any other such protocol. If there is an option, 8 data bits, no parity and 1 stop bit will be used in preference over all other possible combinations. (This is in line with the FOSSIL spec). 3 Speeds Some protocols (such as V.110) can be used at different speeds. Certain implementations of these protocols may not support some of these speeds. The baud rate field in the nodelist should not be used for indicating the maximum speed an ISDN node is capable of, since ISDN capability flags could (technically) co-exist with normal modem capability flags(2). 4 Nodelist flags ISDN-related nodelist flags consist of a prefix, a protocol indicator and an optional (set of) suffixes. The prefix is the capital letter I (for ISDN). The protocol indicator is one of the strings defined in paragraph 5 below. The suffix indicates the way in which the implementation deviates from the preferred implementation, as indicated in paragraphs 2 and 3. The possible suffixes are: Onnn The only bit rate supported = nnn * 100 (e.g. IV110O384 means that this node only supports V.110 asynchronous at 38400 bps and at no other speeds. 1. As a matter of fact, there are no provisions for advertising the synchronous versions of such protocols. FIDONEWS 14-22 Page 9 2 Jun 1997 2. ISDN technology indeed allows for the possibility of both modem and ISDN-specific datacom connectivity on the same 'telephone' number. Pnnnnn Maximum packet size supported in bytes. This is a layer 2 packet protocol parameter. Communication between two nodes is only possible if either end's maximum packet size is not exceeded. Leading zeroes are to be omitted. Rnnn Highest bit rate supported = nnn * 100 (e.g. IV110R192 means that this node does not support V.110 asynchronous at 38400 bps, but does support all other standardised rates up to and including 19200 bps) Wn Window size. The window size must be less than the modulo value (i.e. in modulo 8, the maximum window size is 7). If more than one suffix is used, the suffixes will be sorted in ascending order. 5 Protocols This section defines the meaning of the base protocol indicators. The aim is to have this base protocol indicator cover the majority of cases, so that suffixes will only rarely be required. 5.1 V.110 The protocol indicator is V110. When specified without suffixes, the IV110 nodelist flag indicates V.110 asynchronous capability at bit rates up to and including 38400 bps. 5.2 V.120 The protocol indicator is V120. When specified without suffixes, the IV120 nodelist flag indicates V.120 asynchronous capability. Due to the nature of the protocol, the O and R suffixes are irrelevant. There is no explicit mention of frame size in the V.120 specifications. However, since Q.921 is the layer-2 protocol of V.120, one might assume the frame size of Q.921, which is 260 bytes. Frame sizes larger than that should be negotiated between sysops. 5.3 T.90 (X.75) FIDONEWS 14-22 Page 10 2 Jun 1997 The protocol indicator is T90. Base protocol parameters are: modulo: 8 window size: 2 packet size: 2048 bytes Currently, there is no standardized method for negotiation of the modulo mode (Recommendation ITU- TS T.90 reserves this subject for further study), all T.90-capable nodes should answer in modulo-8 mode. Itis therefore useless to advertise modulo- 128 capability. This also limits the maximum window size to 7. Some implementations have a maximum frame length of 130 bytes and a maximum window size of 1. This would be documented as IT90P130W1. The 1992 version of the T.90 standard specifies a method for in-band negotiation of frame length and window size. 5.4 Other protocols Additional protocols can be added to this document (and thus assigned a nodelist flag) if sufficient technical information is made available. Neither X.25 on B nor on D have been added, because there is no room in the nodelist for the X.25 address. 6 Conversion from old to new The ISDNA, ISDNB and ISDNC nodelist flags are already in use in zone 2. The table below shows the relationship between old and new. new old IV110O192 ISDNA IV110O384 ISDNB IT90 ISDNC IV110 ISDNA,ISDNB IV110O384,IT90 ISDNB,ISDNC ---===--- -30- ----------------------------------------------------------------- FIDONEWS 14-22 Page 11 2 Jun 1997 | Document: FSC-0076 | Version: 001 | Date: 03rd December 1993 | Author: Steve T. Gove A Proposal for NetMail AreaTags. Steve T. Gove 1:106/6.0@fidonet Status of this document: ======================== This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. General Introduction: ===================== Within the FTN networks today is the ability to belong to a variety of networks. These can include, but are not limited to, FidoNet, RBBSNet, AlterNet, etc. Within each of these specific networks is the ability to pass "NetMail" both routed and direct. But what if someone belongs to many of these networks? How does one differentiate netmail between them? Currently, NetMail does NOT allow for an AreaTag to allow for specifying between different Domains. I propose that this change. My proposal is to allow for the areatag, for netmail, to be called "NETMAIL". current netmail - none current echomail - AREA: ex. AREA:Binkley proposed netmail - NETMAIL: ex. NETMAIL:FidoNet ex. NETMAIL:RBBSNet This would allow for multi domain'd netmail to be seperated into seperate sub-directories to allow our netmail readers to differentiate between them and allow for replying based on their originating Domain. Compatability ============= "Compatibility is a set of abilities which, when taken as a whole, make it safe to list a net or node in the FidoNet nodelist." I believe that utilization of my proposal, will FIDONEWS 14-22 Page 12 2 Jun 1997 allow for full backwards compatability with reguard to netmail and will allow, at the same time, for forward progress to be achieved, both, within the fidonet community and with other FTN networks. NetMail Definition: =================== NetMail is a driving force behind FidoNet, and allows for the communication between two individuals anywhere in the world. See FTS-0001.015 for details on netmail packet structure. Required Control Information: ============================ An "AREA:" tag is what makes the difference between netmail and echomail. This would change the definition between NetMail and EchoMail, as practiced today. This proposal, however, would not effect EchoMail. NetMail would now, simply, have an areatag named "NETMAIL". The NETMAIL line must be the first line in an netmail message's body. A NETMAIL line's format is simply: NETMAIL: The NETMAIL tag is specifically _not_ preceded by a ^a. Where is the unique name of the NetMail's origin. Area names should not begin with the plus or minus ("+" or "-") symbols. Area names must not contain control characters (less than ASCII character 32, a space). Leading and trailing spaces on the area name should be ignored (and preferably not produced). Compares on the netmail name should be case insensitive. NetMail names are generally kept as short as possible while still maintaining uniqueness and some sense of which Domain the NetMail belongs to. EchoMail Definition: ==================== Echomail, sometimes called broadcast or conference mail, is netmail (ref. FTS-0001) containing additional control information that allows it to be "echoed" (forwarded) from node (site) to node. Echomail is divided into areas, or conferences, with unique names. Acknowledgements: ================ Tom Jennings who "created" Fidonet. FIDONEWS 14-22 Page 13 2 Jun 1997 Jeff Rush who "created" echomail. Mark Kimes - 1:380/16@fidonet (fsc-0068.a01) Related documents: ================== FTS-0001 (transport layer, packet format, various kludge lines) Policy4 (whether you agree or not...!) PSEUDO-CODE =========================================================== For historical reasons, the term packet is used in FidoNet to represent a bundle of messages, as opposed to the more common use as a unit of communication, which is known as a block in FidoNet. An Inbound Mail packet arrives. (0000fff1.mo0) The packet is unpacked and b498c880.pkt is found. A "Tosser" looks at the *.pkt for an areatag, IF AREA: THEN (EchoMail) toss to appropriate area, IF NETMAIL: THEN toss to "Tosser" defined netmail area according to domain, IF NOT AREA: OR NETMAIL: THEN *.pkt is (old-style) netmail toss to "Tosser" defined netmail area. Sample "Tosser.CFG" file excerpt ----------------------------------------------------------- NetArea FidoNet E:\Mail\NM_Fido NetArea RBBSNet E:\Mail\NM_RBBS NetArea AlterNet E:\Mail\NM_AltNt NetArea OtherNet E:\Mail\NM_OtrNt BadArea BAD_MSGS D:\Bad_Msgs DupeArea DUPES E:\Mail\Dupes LocalArea Bad_Mail D:\Bad_Mail LocalArea Bad_GMD D:\Bad_GMD LocalArea WIMM D:\WIMM EchoArea File_Announce D:\File_Announce 1:106/6 EchoArea MHS D:\MHS\Mail\Users\Steve 1:124/1301 EchoArea Test D:\T\Test 1:106/6 .1 EchoArea R19SysOp D:\R\R19Sysop 1:106/2000 -30- FIDONEWS 14-22 Page 14 2 Jun 1997 ----------------------------------------------------------------- | Document: FSC-0077 | Version: 001 | Date: 03rd December 1993 | Author: Jason Steck Type-10 Packet Format An FSC Standard Proposal I. Introduction: Over time, the traditional FidoNet FTS-0001 "Type 2" packet format has been repeatedly shown to be inadequate in a wide variety of advanced implementations. The inadequacies of the type-2 format have been particularly evident in multi- zone and multi-domain environments. When type-2 was originally established, it was sufficient to existing networking needs. FidoNet was the "only show in town" and the 2-dimensional net/node arrangement was easily adequate to the requirements of the network. However, growth in FidoNet required the introduction of "zones" to separate large geographical areas from each other. The advent of echomail led directly to the creation of sub-node "point" systems, adding a fourth dimension to the addressing scheme. The explosion in recent years of similar-technology, non-FidoNet networks has required the addition of a fifth dimension, the "domain" to differentiate between potentially conflicting addresses in different networks. The 2-dimensional type-2 format is clearly inadequate to a 5-dimensional addressing requirement. Various schemes have evolved to attempt to compensate for the failings of the type-2 environment. Type 2.2 (FSC-0045) and type-2+ ("capability word" -- FSC-0039) packet format modifications have been devised to attempt to modify the packet format to include necessary addressing information. Further, a plethora of message text "kludge lines" (lines hidden behind an ASCII #01 character) have been inserted to provide additional addressing information required by modern implementations. The major failing of all these schemes, however, comes when they run square-on into the "real world". Competing implementations often use slightly different formats or requirements within packet formats and kludge lines. The mere existence of kludge lines impose significant performance and message test size and content penalties for mail processors. This proposal seeks to establish a new packet format which would resolve the problems and inadequacies presented by the existing formats. In acknowledgment of the fact that a theoretical proposal is useless without a practical implementation, this proposal has been implemented in the JMail 2.10 (and later) versions of electronic mail processors. In the interests of reverse-compatibility, it FIDONEWS 14-22 Page 15 2 Jun 1997 is STRONGLY RECOMMENDED that any implementations of this proposal include some mechanism for supporting older formats and their popular modifications. This proposal establishes a detailed packet format including packet header and internal message structure. The format assumes the utilization of the FidoNet-style zone:net/node.point@domain addressing format. Other addressing formats, such as UUCP RFC-822 domain addressing and/or "bang-path" addressing are not directly supported by this format. II. The 5-Dimensional Address The 5-dimensional address consists of the elements (in hierarchical order) domain, zone, net, node, and point. The full ASCII representation of this is "zone:net/node.point@domain". Where the point number is zero (a full node system as opposed to a dependent point system), the period (.) and the point number (0) may be excluded. Implementations with size concerns may desire to include some facility to "assume" or "guess" at particular elements of a particular address based on prior addresses or user- supplied criteria. This capability also has advantages when dealing with older formats which supply less than complete information. III. Type-10 Packet Format A. Conventions All binary numerical values in a type-10 packet are stored in Intel's byte-swapped format. Within this document, all binary numerical values will be given in hexadecimal notation (base-16) using the (#) designator and right-justified with leading zeros. For example, a single-byte value of 10 would be designated as "#0A" while a word-length, two-byte value of 10 would be designated as "#000A". "NULL" is equivalent to either a #00 byte or #0000 word value. B. File Naming Conventions -- *.P10 Type-2 packet formats established the convention of using the PKT extension on file names. This naming convention enabled mail-processing software to easily determine which files within a given directory were intended to be processed. In order to prevent conflicts and preserve easy reverse- compatibility, it is necessary for any upgraded format to utilize a different file naming convention. Type-10 packets are named with an extension of P10. This has the additional effect of providing an easy new path for additional standards -- for example, a theoretical type-11 packet could use, without conflict, an extension of P11. FIDONEWS 14-22 Page 16 2 Jun 1997 Archived type-10 mail packets may use the same archiving file name conventions established for type-2 packets. Indeed, the different file naming convention of type-10 packets allows the inter-mixing of packet types within a single archive. C. Packet Header The PacketAddressRecord contains a complete 5- dimensional address. (* Address structure -- Pascal notation *) PacketAddressRecord = RECORD Domain : ARRAY[1..8] of char; Zone, Net, Node, Point : integer; END; /* Address structure -- C notation */ struct PacketAddressRecord {char domain[8],int zone,int net,int node,int point}; A packet header must appear at the beginning of each type-10 packet file. (* Packet Header structure -- Pascal notation *) PacketHeaderRecord = RECORD PktType : byte; PktFrom,PktTo : PacketAddressRecord; PktPWd : ARRAY[1..8] of char; ProdCode : word; ProdVer : word; END; /* Packet Header structure -- C notation */ struct PacketHeaderRecord {unsigned char PktType,struct PacketAddressRecord PktFrom, struct PacketAddressRecord PktTo, char PktPWd[8],unsigned int ProdCode, unsigned int ProdVer] The PktType field contains a numerical value indicating the packet type format of the rest of the packet. The PktType field of a type-10 packet will always contain the value #0A. This value has been placed in byte 0 of the file to provide a convenient upgrade path for future packet formats. The PktFrom field contains a PacketAddressRecord structure indicating the address of the sending system. The PktTo field contains a PacketAddressRecord structure indicating the address of the destination system. The PktPWd field may contain a 1-8 byte (NULL padded) password for the securing of links between systems. If the link has no password protection, this field will contain 8 NULL bytes. The ProdCode field contains a 0-65535 numerical value FIDONEWS 14-22 Page 17 2 Jun 1997 indicating the product code assigned by a relevant standards committee for the software package producing the packet. The ProdVer field contains a 0-65535 value. The hi- order byte contains the major version number and the low- order byte the sub-version number. The ProdCode and ProdVer fields are used to detect and assist in the elimination of format errors produced by errant software implementations. D. Packet Body Format After a packet header, a type-10 packet will contain any number of packet "blocks". Individual blocks may not exceed 30720 bytes (30 kilobytes) in length. (This allows for easy buffering and data manipulation.) Each block is prefaced with a "block header" to define the type of information contained within the block: (* Block header structure -- Pascal format *) BlockHeaderRecord = RECORD BlockID : longint; BlockType : byte; BlockLen : word; BlockCRC : word; END; /* Block header structure -- C format */ struct BlockHeaderRecord {long int blockid, unsigned char BlockType, unsigned int BlockLen, unsigned int BlockCRC} The BlockID field is used for error-checking purposes. It must alwasy be set to #22AAE0. The BlockType field contains a numerical value from 0- 255 indicating the type of data contained within the block: #00 - Packet Terminator Block. (BlockLen and BlockCRC fields must be set to #0000.) This block indicates an end- of-file. Data beyond this point will be ignored. #01 - Command Block. This block is for system-to- system commands and requests. This block is not yet implemented and will be detailed in a future revision to this document. #02 - Message Header Block. #03 - Seen-by Block. #04 - Path Block. #05 - Message Text Block. (More than one successive #05 block may be used to hold the text of messages greater than the maximum block size. In theory, this allows for truly unlimited-length message capability. However, implementations which intend to communicate with older, type- 2 are realistically limited to message sizes which can be adequately buffered by type-2 processors.) The BlockLen field indicates the number of bytes within the block. The BlockCRC field is optional. If the value of field FIDONEWS 14-22 Page 18 2 Jun 1997 is other than #0000, then the field will contain the CRC value of the field data (excluding the Block Header). This allows for some degree of integrity-checking on packet data. Following each Block Header will be BlockLen bytes of data of the type specified in the BlockType indicator. A normal message would break down into a Message Header block (#02) followed by a Seen-by Block (#03), followed by a Path Block (#04), followed by one or more Message Text Blocks (#05). Some data areas will contain structured sub-fields. These are as follows: #02 - Message Header Block. Each sub-field within this data block will be prefaced with a numerical sub-field identifier, followed by a single byte indicating the length (in bytes) of the sub-field, followed by the appropriate sub-field. Sub-fields are as follows: #01 - From Name. This is the ASCII name of the person who originally wrote the message. This sub- field is required on all messages. #02 - To Name. This is the ASCII name of the person to whom the message is directed. This sub-field is required on all messages. #03 - Subject. This is the ASCII representation of the originator-entered subject. #04 - Date/Time Group (binary -- length byte will always be #04). This is the date and time the message was originally entered. It is stored in the 32-bit "longint" format. This is a "packed" time format used by MS-DOS to store file date/time records. This or a #05 sub-field is required on all messages. #05 - Date/Time Group (ASCII -- length byte will always be #13). This is an ASCII date/time representation of the origination date/time of the message in the format specified in the FTS-0001 document (DD MMM YY HH:MM:SS) This or a #04 sub-field is required on all messages. #06 - MSGID line. This is an FSC-0036 compliant MSGID line. It is a required sub-field on all echomail messages. #07 - Origin Address (PacketAddress Format -- length byte will always be #10). This is the network address of the originating system of the message. This sub-field is required on all messages. #09 - Destination Address Override (PacketAddress Format -- length byte will always be #10). This sub- field contains an override for the destination address of the corresponding messages. Processors should determine that each message is destined for the address listed in the PacketHeaderRecord except where specifically overridden in a #09 sub-field. #0A - Echomail Area Name. This sub-field indicates the echomail area that the message is being FIDONEWS 14-22 Page 19 2 Jun 1997 distributed in. This sub-field is required on all echomail messages. #0B - Origin Line. This sub-field contains the origin line for echomail messages. This sub-field is optional, but is realistically required on all implementations which intend to communicate using any older type-2 format. #0C - FLAGS line. This sub-field contains the message attributes in FSC-0053 format. The leading ASCII #01 (control-A) character should be excluded from this sub-field, but implementations should be tolerant of common minor FSC-0053 variations. #0D - Tear Line: This sub-field contains a tearline (not to exceed 35 characters including the leading "---" characters. This line is required on all echomail messages. #0E - PID Line: This sub-field contains the optional Product Identification (PID) line. #0F - REPLY: This sub-field contains the optional REPLY field, used with MSGID lines for message thread linking purposes on echomail messages. #03 - Seen-by Block. The Seen-by Block contains address information of the systems which have "seen" an echomail message. This data is used to prevent sending multiple copies of messages to a single system. Seen- by blocks are required on all echomail messages. Implementations will append information for all addresses the local system is sending the current message to prior to actually sending any message. Seen- by information for systems not in the same domain as the destination system must be excluded. The local system's address information in a minimal requirement on all messages. The data is a series of two-byte integers. The first four integers indicate (in order) the zone, net, node, and point number of the first address in the list. This address serves as a "base" from which other addresses "evolve" as explained below: Positive value (greater than or equal to 0): node number (zone and net information same as previous address and point number equals 0). Negative number (less than zero EXCEPT -32768): number multiplied by -1 equals new net number (absolute value). Next number will be new node number. "Reset number" (-32768): indicates new full address block. Next four integers will equate to (in order) the zone, net, node, and point number of next address in seen-by list. Later addresses will "evolve" from this number. This storage format allows for an extremely flexible and compact method of storing seen-by information. FIDONEWS 14-22 Page 20 2 Jun 1997 #04 - Path Block. This block contains the addresses that the current message has passed through. This information is maintained across all domain boundaries. Whenever a system processes a message, it adds its own address to the end of this list. Address records are stored in PacketAddressRecord format. IV. Development and Implementation Assistance As this is a proposal for a new standard, it is reasonable to expect ambiguities and problems to eventually develop in potential implementations of the standard. The author of this standard is available to clarify matters of interpretation or ambiguity or problems in coding or implementation of the standard. Public-domain code "snippets" of critical portions of the standard implementation will be made available when necessary and feasible. The author may be reached at the addresses below: Jason Steck 1:285/424@FIDONET PROZ Software 200:5000/400@METRONET 12105 W. Center Rd #103 39:70/200@LDSSNET Omaha, NE 68144 42:1009/424@CANDYNET Ready Room BBS (402)691-0946 -30- ----------------------------------------------------------------- | Document: FSC-0078 | Version: 001 | Date: 11th April, 1993 | | Clovis Lacerda, 4:808/2 Gateway between Fidonet compatible networks Author: Clovis Lacerda, Brazil Fido : 4:808/2 Email : clovis@ear.anpe.br Date : March, 1993 Copyright 1993, Clovis Lacerda. All rights reserved. The right to distribute for non-commercial use is granted to the Fidonet Technical Standards Committee, provided that no fee is charged. This may be posted on electronic BBSs which charge no fee for accessing this document. Any and all other reproduction or excerpting requires the explicit written consent of the author. FIDONEWS 14-22 Page 21 2 Jun 1997 INTRODUCTION Many networks, using the Fido technology, are being created everywhere. It is now time to implement a means to provide gateway capability between these networks. Some proposals were made, but, as far as I know from reading most of the FSC standards, none of them actually play with the basic standards of Fidonet, as established in FSC-0001. It is time to think of other ways in which to improve Fido technology based on what is universally available, rather than relying on the infamous ^A kludges that many software packages out there don't use, or worse, ignore systematically. ABSTRACT From now on, the word FakeNet will be used to refer to any Fido- compatible network that is not in the Fidonet nodelist, thus using node numbers not found in the 1-thr-6 Fidonet zones. A Fakenet uses its own nodelist. There is a large number of Fakenets all over, one not knowing the existence of the other, some using the same node numbers in their own nodelists. We shall try to put these networks together, not by forcing any of them into a single nodelist, but by making one aware of the existence of the others, and providing gateways in each of these networks so that mail can flow in both directions. IMPLEMENTATION For a gateway to be implemented, extra information must be provided in the netmail. Normally, two user names, From: and To: define the sender and the addressee. The node numbers go "inside" the netmail and have their existences checked in the nodelist of the network in question by the local running software. Since we now have 2 networks, the extra information must be the remote node in the destination network, which obviously cannot be found in the local nodelist, and the local node that must reach the remote addressee, otherwise a reply cannot be made. Suppose, for example, that there are 2 Fakenets, one based in zone 10 (network 1), the other one in zone 11 (network 2), and that user John Green in node 10:100/1 wants to send a netmail to Paul Brown in 11:200/1. In both networks, a gateway node (common to both nodelists) must be provided. Let's say that node 10:10/1 is the gateway in network 1, named "Gateway system A" and node 11:11/1, named "Gateway system B" is the gateway in network 2. What John, from network 1, will have to do is: Send a netmail to his local gateway node, which is 10:10/1. In the To: field, he will put, besides the name of the addressee, Paul Brown, PAUL'S NODE NUMBER, 11:200/1, inside (). This is the extra information needed for the gateway to work. What will happen FIDONEWS 14-22 Page 22 2 Jun 1997 is: This netmail, in the domain of network 1, will travel the route and reach the gateway, 10:10/1. This gateway system must do the following: Change the domain of the netmail from network 1 to network 2. This means that any reference to node numbers in the netmail header must be updated. Thus, the netmail will now have the node 11:11/1 as the originating node, and 11:200/1 as the destination node, "hardcoded" in its header. But we can see that John's node number must be provided, otherwise Paul will not be capable of replying. This is done by the gateway software that includes John's node number in his From: name field, inside (). When Paul receives John's netmail, he will reply, and the From: field will automatically become the new To: field, and will contain John's name and node number. The netmail will reach back 11:11/1 and the process will be exactly the same, finally reaching John. In resume, this is the odyssey of John's netmail to Paul: 1 - John enters his message to Paul. Since Paul is not in John's network, John will have to use the gateway. He sends a netmail to his local gateway system, 10:10/1 which looks like this: From: John Green, John's BBS (10:100/1) To : Paul Brown (11:200/1), Gateway System A (10:10/1) Re : Hello ------ body of message ...... Note that John had to MANUALLY enter Paul's node number and put it in the To: field, together with Paul's name. This netmail is addressed to Gateway System A, node 10:10/1. 2 - After arriving in 10:10/1, the gateway software will create a new netmail that looks like this: From: John Green (10:100/1), Gateway System B (11:11/1) To : Paul Brown, Paul's BBS (11:200/1) Re : Hello ---- body of message.... Note that John's node number was inserted in the From: field, which is the information needed for the bidirectional gateway to work. 3 - This netmail is now in the domain of network 2. It will travel the normal route and reach Paul. When he replies, the local message editor will make the From: field become the To: field. The FIDONEWS 14-22 Page 23 2 Jun 1997 netmail-reply will look like this: From: Paul Brown, Paul's system (11:200/1) To : John Green (10:100/1), Gateway System B (11:11/1) Re : Hello ---- body of new message..... This netmail will travel the route and reach 11:11/1. The process now is exactly the one used to gate the original netmail from network 1 to 2. The gateway software will create a new netmail that looks like this: From: Paul Brown (11:200/1), Gateway System A (10:10/1) To : John Green, John's system (10:100/1) Re : Hello ---- body of new message.... Note that Paul's node number was inserted in the From: field, finishing the gateway process. The only trade-off in the current proposal is obvious. The limited length of the name fields, which, according to FSC-0001, is 36 characters long, and that may not allow the inclusion of the person's node number in it. For example, if John's full name were John Green Richardson Smith Jr., he would have sent his netmail to Paul, but the gateway system would fail when attempting to include his node, 10:100/1 together with his name. In this case, the netmail is bounced back with a warning message, and it will be John's responsibility to change his name to a shorter one or use an alias. It seems that more and more people are being practical and using only 2-word names, so this is a problem that can be easily worked out by the local BBS operator. Lastly, ^aINTL kludges must be issued in all netmails gated between the 2 networks. This proposal follows FSC-0034 and FSC-0001. It also allows immediate aplication, since it relies on what is Fidonet in essence, FSC-0001. A gateway package was implemented for this purpose. MailGate (c), besides gating netmail and echomail between 2 or more Fakenets, also provides transparent gateway between a Fakenet and Internet, integrating lists and news with echomail and also providing a BBS with the feature of creating its own lists, that can flow as echomail through a Fido-compatible network, through the gateway between 2 fakenets, and also through Internet, as a mailing list. CONCLUSION Enhancing technology and creating new oportunities, necessary ingredients to allow systems and sysops to play their freedom of FIDONEWS 14-22 Page 24 2 Jun 1997 choice, are the best keys to improve Fidonet technology and make it really become the de facto standard, no matter which new network is created every day. I don't know how suitable this proposal is in regard to the incoming problem Fidonet is facing, or will have to face, when all the nodelist zones split apart, since the size of the nodelist is growing alarmingly. This document is not perfect and may contains wrong conclusions. Should you have suggestions and constructive criticisms, please contact the author. My thanks to those who were prompt in helping me through the technical aspects of Fidonet and in the last days routed my emails when trying to reach FTSC, (it finally reached the right place, Australia) especially Tom Jennings, Randy Bush and David Nugent. Thanks to Mitch Davis for helping me with some technical details. By no means am I saying that they support or have even read this document, it's only a thank you note. Fidonet is a trademark of Tom Jennings and Fido software, to whom we all owe many thanks for the origin and spirit of Fidonet. MailGate is a trademark of Clovis Lacerda -30- ----------------------------------------------------------------- FIDONEWS 14-22 Page 25 2 Jun 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 150 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-122|Nodelist-129|Nodelist-136|Nodelist-143|Nodelist-150|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 8519| 8430 -89 | 8367 -63 | 8277 -90 | 8277 0 |31| | 2 | 15952|15904 -48 |15879 -25 |15855 -24 |15835 -20 |59| | 3 | 800| 800 0 | 800 0 | 761 -39 | 765 4 | 3| | 4 | 548| 543 -5 | 543 0 | 543 0 | 543 0 | 2| | 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0| | 6 | 1083| 1083 0 | 1083 0 | 1077 -6 | 1078 1 | 4| +----+------+------------+------------+------------+------------+--+ | 26989|26847 -142 |26759 -88 |26600 -159 |26585 -15 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-22 Page 26 2 Jun 1997 ================================================================= NET HUMOR ================================================================= Date: Fri, 23 May 1997 22:19:14 -0700 From: Shari Organization: OREGON - USA To: webheads@softdisk.com Subject: The Newbie's Song Sender: owner-webheads@softdisk.com Reply-To: webheads@softdisk.com The Newbie's Song (Based on the Major General's song from "The Pirates of Penzance", Gilbert & Sullivan) By Anonymous Author I am the very model of a Usenet individual, I've information meaningless and ultimately trivial, I know the basic elements of alien biology, And all the hidden secrets of the Church of Scientology, I've seen "The Wrath of Khan" and every Star Trek film that followed it, I moan about my Servicecard and how the cash till swallowed it, About the laws on handguns I am sending off a counterblast, With many cheerful facts about the way you can MAKE MONEY FAST! ALL: With many cheerful etc. I'll tell you why the Japanese are taking over Panama, And why the USA is still a better place than Canada, In short, in matters meaningless and ultimately trivial, I am the very model of a Usenet individual. ALL: In short, in matters meaningless and ultimately trivial, He is the very model of a Usenet individual. I post in alt.revisionism lies about the Holocaust, I cut my .sig to twenty lines, I didn't want to, I was forced, I really can't believe the "Good Times" virus to be mythical, And Clinton's raising taxes which is, frankly, bloody typical, I've upset several people on alt.flame, I really don't know how, And sent a thousand business cards to Mr. and Mrs. Shergold now, I have a very poor grip of political geography, And absolutely no involvement (yet!) in child pornography, ALL: And absolutely no, etc. I've paid two-fifty dollars for the Nieman-Marcus recipe, And told the Spanish tourist's tale about the toothbrush pessary, In short, in matters meaningless and ultimately trivial, I am the very model of a Usenet individual. ALL: In short, in matters meaningless and ultimately trivial, He is the very model of a Usenet individual. FIDONEWS 14-22 Page 27 2 Jun 1997 In fact, when I know what is meant by "binary" and "FTP", When I know how to decode porno JPEGs from a .uue, When I can handle HTML, Telnet, mail and IRC, And when I know the words initialised to form "http", When I have learnt what topics are acceptable in talk.bizarre, When I know more of Usenet than the tailpipe of a motor-car, In short, when I've a smattering of elementary netiquette, You'll say a better individual has never surfed the Net. ALL: You'll say a better individual, etc. For my technical experience, although I claim to know it all Could barely serve to run the installation disk from AOL; But still, in matters meaningless and ultimately trivial, I am the very model of a Usenet individual. ALL: But still, in matters meaningless and ultimately trivial, He is the very model of a Usenet individual. -30- ----------------------------------------------------------------- FIDONEWS 14-22 Page 28 2 Jun 1997 ================================================================= ADVERTISE YOUR FREE SERVICE/EVENT ================================================================= New haven, CT USA - 06/01/97 - Fidonet echos are available for internet users. Smokey's Lair BBS, formally of Dallas, TX, more recently of New Haven, CT, has been watching the current trend of disappearing FidoNet BBSes with alarm. The quality of available echos and conferences on these systems far outweighs ANYTHING that can be found on the internet. The FidoNet echos have experts in all fields, have good in depth conversation without the spamming that is found so often on the net. In hopes that we can help bring back life to some of the conferences and echos that are dropping like flies we have made them available to those of you fidonet users that have lost your local BBSes or just prefer the ease of use of the internet. It is our hope that you will once again re-join the FidoNet family. Here is how it works: 1. You must have an internet connect, be it dial-up, employer network, or anything else that connects you. If your using a LAN, you must know how to get through the firewall. I'm sorry we can't help you on that one. 2. You must have a newsreader. This could be something like Microsoft netNews, Netscape News, Chameleon, Trumpet, or Free Agent from Forte. I use Free Agent and find it the best. 3. Find the location in your setup that defines the news server. Change this to newn.com 4. Connect and let it pick up a listing of all news groups. This can take 10 or 15 minutes, so be prepared to wait. 5. You can subscribe to any newsgroup, but be aware, the only active ones are the FidoNet ones. These all start with "fido." and the echo name. 6. Once you have selected those that you want to read, have at `em. Please follow the moderators rules for each echo. Remember, in FidoNet NO ADVERTISING is allowed except where specifically included. This includes spam (Internet junk mail). Please, if you are trying to read an echo and find no activity for a couple days, send me net-mail. This can either be done to Chris Molnar @ 1:141/635 or cmolnar@newn.com. Most likely I haven't turned on the echo, but will be happy to do it for you. A word to echo moderators: We are a FidoNet node, the echos are NOT being gated to the internet. We are not passing these echos to other systems, we insist that the users connect to our system to read and post. FIDONEWS 14-22 Page 29 2 Jun 1997 A word to the users: We maintain a log that includes your machine name, host, and internet feed for every article posted. This is an electronic signature and is yours. We will not tolerate abuse, this includes spamming. Please do not jeopardize our system, but help us try and maintain the Fido Family. If you run an FTC compatible network, and you would like your net added to this type of distribution please contact us, we will not charge for this service. Please, however be aware the following rules apply: 1. We will not place long distance calls to carry your network. You may however drop mail packets off via FTP. It is your responsibility to get and receive mail from us. We do not charge for carrying your network, and we maintain a dedicated internet connect, therefore we believe that you can maintain the cost of distribution to and from us. 2. We will not carry multiple AKAs. We believe the FidoNet address structure can easily identify our system and if you want us to make your network available to internet users, you can adjust. 3. We do not screen users accessing the echos. We do not screen the messages being sent. We are an information provider and the content of your network is not our business. This protects us from legal harm. However, we believe that you as the Network Coordinator are responsible for following US law when creating and administering your network. Be it that your network originates outside or inside the United States as we are proudly a U.S. based system. Please ask us if you have any questions! ----------------------------------------------------------------- FIDONEWS 14-22 Page 30 2 Jun 1997 ================================================================= ANSWERS OF THE WEEK ================================================================= --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Mon May 26 12:50:54 1997 From: Ralf Mahler @ 2:2433/401 To: Christopher Baker @ 1:18/14 Date: 25 May 97 11:57:11 Subj: old nodelists Hello Christopher! === Cut === D:\VAR\FILES\FIDO\HISTORY\NODELIST\1990UV 26.10.93 0.23 27033 0 jun84-1.pcx 26.10.93 0.25 22128 0 jun84-2.pcx 26.10.93 0.27 17951 0 jun84-3.pcx 11.11.94 23.50 8452 0 node1984.328 2.10.94 21.53 10930 0 node1984.342 2.10.94 21.54 10469 0 node1984.363 2.10.94 21.55 12289 0 node1985.004 3.10.86 8.00 93042 0 node1986.276 8.01.88 8.00 223103 0 node1988.008 10.09.88 16.06 319929 0 node1988.253 16.06.89 15.26 440725 0 node1989.167 4.08.89 1.25 464876 0 node1989.216 26.01.90 22.01 525064 0 node1990.026 30.03.90 9.06 584373 0 node1990.089 25.05.90 17.20 636935 0 node1990.145 29.06.90 23.13 654078 0 node1990.180 17.08.90 15.26 690316 0 node1990.229 D:\VAR\FILES\FIDO\HISTORY\NODELIST: 27.12.91 12.00 1144152 0 ndiff_91.zip since day 144 9.09.95 16.21 2168996 0 ndiff_92.zip 9.09.95 16.17 2670637 0 ndiff_93.zip 9.09.95 16.06 3344477 0 ndiff_94.zip 7.01.96 14.48 2872017 0 ndiff_95.zip 1.01.97 9.09 2604931 0 NDIFF_96.ZIP 2.01.92 10.43 362441 0 nlist_91.zip 10.11.94 17.14 416414 0 nlist_92.zip 1.01.93 19.32 597289 0 nlist_93.zip 7.01.94 16.18 795059 0 nlist_94.zip 9.09.95 16.32 1021029 0 nlist_95.zip 6.01.96 15.45 1105455 0 nlist_96.zip 4.01.97 18.52 940509 0 NLIST_97.ZIP === Cut === These files may be placed on hold - no f'req possible. CM-System: +49-2131-745559 , but only X.75 (BRI) FIDONEWS 14-22 Page 31 2 Jun 1997 cheers, Ralf. -30- ----------------------------------------------------------------- FIDONEWS 14-22 Page 32 2 Jun 1997 ================================================================= NOTICES ================================================================= Future History 3 Jun 1997 2 years since FidoNet had an International Coordinator. 6 Jun 1997 National Commemoration Day, Sweden. 12 Jun 1997 Independence Day, Russia. 1 Jul 1997 Canada Day - Happy Birthday Canada. 9 Jul 1997 Independence Day, Argentina. 1 Aug 1997 International FidoNet PENPAL [Echo] meeting in Dijon, France 13 Oct 1997 Thanksgiving Day, Canada. 1 Dec 1997 World AIDS Day. 10 Dec 1997 Nobel Day, Sweden. 12 Jan 1998 HAL 9000 is one year old today. 22 May 1998 Expo '98 World Exposition in Lisbon (Portugal) opens. 1 Dec 1998 Fifteenth Anniversary of release of Fido version 1 by Tom Jennings. 31 Dec 1999 Hogmanay, Scotland. The New Year that can't be missed. 1 Jan 2000 The 20th Century, C.E., is still taking place thru 31 Dec. 15 Sep 2000 Sydney (Australia) Summer Olympiad opens. 1 Jan 2001 This is the actual start of the new millennium, C.E. -- If YOU have something which you would like to see in this FIDONEWS 14-22 Page 33 2 Jun 1997 Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 14-22 Page 34 2 Jun 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 A fairly quiet week around here. Things seems to be settling down into some sense of order... -=- Snip -=- Submission form for the Latest Greatest Software Versions column OS Platform : Software package name : Version : Function(s) - BBS, Mailer, Tosser, etc. : Freeware / Shareware / Commercial? : Author / Support staff contact name : Author / Support staff contact node : Magic name (at the above-listed node) : Please include a sentence describing what the package does. Please send updates and suggestions to: Peter Popovich, 1:363/264 -=- Snip -=- MS-DOS: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- Act-Up 4.6 G D Chris Gunn 1:15/55 ACT-UP ALLFIX 4.40 T S Harald Harms 2:281/415 ALLFIX Announcer 1.11 O S Peter Karlsson 2:206/221 ANNOUNCE BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BDOS_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_DOS CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR CheckPnt 1.0a O G Michiel vd Vlist 2:500/9 CHECKPNT FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FASTECHO FastEcho/16 1.45a T S Tobias Burchhardt 2:2448/400 FE16 FidoBBS (tm) 12u B S Ray Brown 1:1/117 FILES FrontDoor 2.12 M S JoHo 2:201/330 FD FrontDoor 2.20c M C JoHo 2:201/330 FDINFO GEcho 1.00 T S Bob Seaborn 1:140/12 GECHO GEcho/Plus 1.11 T C Bob Seaborn 1:140/12 GECHO GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GED GoldED/386 2.50 O S Len Morgan 1:203/730 GEX GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN Imail 1.75 T S Michael McCabe 1:1/121 IMAIL FIDONEWS 14-22 Page 35 2 Jun 1997 ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT InfoMail/86 1.21 O F Damian Walker 2:2502/666 INFOMAIL InfoMail/386 1.21 O F Damian Walker 2:2502/666 INFO386 InterEcho 1.19 T C Peter Stewart 1:369/35 IEDEMO InterMail 2.29k M C Peter Stewart 1:369/35 IMDEMO InterPCB 1.52 O S Peter Stewart 1:369/35 INTERPCB IPNet 1.11 O S Michele Stewart 1:369/21 IPNET JD's CBV 1.4 O S John Dailey 1:363/277 CBV Jelly-Bean 1.01 T S Rowan Crowe 3:635/727 JELLY Jelly-Bean/386 1.01 T S Rowan Crowe 3:635/727 JELLY386 JMail-Hudson 2.81 T S Jason Steck 1:285/424 JMAIL-H JMail-Goldbase 2.81 T S Jason Steck 1:285/424 JMAIL-G MakePl 1.9 N G Michiel vd Vlist 2:500/9 MAKEPL Marena 1.1 beta O G Michiel vd Vlist 2:500/9 MARENA Maximus 3.01 B P Tech 1:249/106 MAX McMail 1.0 M S Michael McCabe 1:1/148 MCMAIL MDNDP 1.18 N S Bill Doyle 1:388/7 MDNDP Msged 4.10 O G Andrew Clarke 3:635/728 MSGED41D.ZIP Msged/386 4.10 O G Andrew Clarke 3:635/728 MSGED41X.ZIP Opus CBCS 1.79 B P Christopher Baker 1:374/14 OPUS O/T-Track 2.66 O S Peter Hampf 2:241/1090 OT PcMerge 2.8 N G Michiel vd Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS RAR 2.00 C S Ron Dwight 2:220/22 RAR RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA Silver Xpress Door 5.4 O S Gary Petersen 1:290/111 FILES Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE Squish 1.11 T P Tech 1:249/106 SQUISH StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL Telegard 3.02 B F Tim Strike 1:259/423 TELEGARD Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TosScan 1.01 T C JoHo 2:201/330 TSINFO TransNet 1.00 G S Marc S. Ressl 4:904/72 TN100ALL.ZIP TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE WWIV 4.24a B S Craig Dooley 1:376/126 WWIV WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL XRobot 3.01 O S JoHo 2:201/330 XRDOS OS/2: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2 BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2 FIDONEWS 14-22 Page 36 2 Jun 1997 CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2 FleetStreet 1.19 O S Michael Hohner 2:2490/2520 FLEET GEcho/Pro 1.20 T C Bob Seaborn 1:140/12 GECHO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM GoldNODE 2.50 O S Len Morgan 1:203/730 GEN ImCrypt 1.04 O G Michiel vd Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP Msged/2 4.10 O G Andrew Clarke 3:635/728 MSGED41O.ZIP PcMerge 2.3 N G Michiel vd Vlist 2:500/9 PCMERGE RAR 2.00 C S Ron Dwight 2:220/22 RAR2 Squish 1.11 T P Tech 1:249/106 SQUISHP T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL2 Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK XRobot 3.01 O S JoHo 2:201/330 XROS2 Windows (16-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL FrontDoor APX 1.12 P S Mats Wallin 2:201/329 FDAPXW Windows (32-bit apps): Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- Argus 95 2.62 M S Max Masyutin 2:469/77 ARGUS95 Argus NT 2.62 M S Max Masyutin 2:469/77 ARGUSNT Argus NT/IP 2.62 M S Max Masyutin 2:469/77 ARGUSIP BeeMail 1.0 M C Andrius Cepaitis 2:470/1 BEEMAIL Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BW32_260.ZIP CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR GoldED 2.50 O S Len Morgan 1:203/730 GEO GoldED Docs 2.50 O S Len Morgan 1:203/730 GEM Maximus 3.01 B P Tech 1:249/106 MAXN Msged/NT 4.10 O G Andrew Clarke 3:635/728 MSGED41W.ZIP PlatinumXpress 2.00 M C Gary Petersen 1:290/111 PXW-INFO T-Mail 2.599I M S Ron Dwight 2:220/22 TMAILNT WinFOSSIL/95 1.12 r4 F S Bryan Woodruff 1:343/294 WNFOSSIL.ZIP WinFOSSIL/NT 1.0 beta F S Bryan Woodruff 1:343/294 NTFOSSIL.ZIP Unix: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ifmail 2.10 M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX ifmail-tx.rpm ...tx8.2 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK Amiga: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL FIDONEWS 14-22 Page 37 2 Jun 1997 CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPDOOR TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPBETA TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS Atari: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ApplyList 1.00 N F Daniel Roesen 2:2432/1101 APLST100.LZH BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY BTNC 2.00 N G Daniel Roesen 2:2432/1101 BTNC JetMail 0.99beta T S Joerg Spilker 2:2432/1101 JETMAIL Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser, C-Compression, F-Fossil, O-Other. Note: Multifunction will be listed by the first match. Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial, X-Crippleware, D-Demoware, G-Free w/ Source Please send updates and suggestions to: Peter Popovich, 1:363/264 ----------------------------------------------------------------- FIDONEWS 14-22 Page 38 2 Jun 1997 ================================================================= FIDONEWS PUBLIC-KEY ================================================================= [this must be copied out to a file starting at column 1 or it won't process under PGP as a valid public-key] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 Comment: Clear-signing is Electronic Digital Authenticity! mQCNAzINVLcAAAEEAM5dZN6t6j5Yc0kl7qegVFfiBeVoteuhDg4ay8h43u38Q4kO eJ9Mm7J89wXFb9vgouBVb4biIN6bTWCwcXTbGhBe5OIceLvluuxuEKsaIs/UwXNe Ogx5azIPhRfC7MJDe41Z8tMEBuHY/NE88cuxQ8yXWO126IRttavu6L/U5BwRAAUR tCRGaWRvTmV3cyBFZGl0b3IgPDE6MS8yM0BmaWRvbmV0Lm9yZz6JAJUDBRAyGwFS JZMgw7eCKz0BAZl0A/9xrfhpsEOqGiPfjy2qd9dv6tvSVPPVFu+Wy1lGTHYtuTtg FIN3fQ47AM3XzqHxWRWvp/xZYgR6sRICL7UFx94ShYBQc7CyqBBZKA0IvIWqXP/g c4Br+gQJR6CLiQK7TUyjUbqNbs6QAxuNUi4xFQM+O2Gene5/iTjHFmmSDj2C9YkB FQMFEDIOmHDTQ6/52IG1SQEBQ78H/Rz/mleIrtZwFIOhzy3JH4Z6FUTfZuM9nPcs 1ZLjZCPptHvY7wEYJWGr03lPPJ6tj1VBXwTrWJTf/hOLsoi00GKV8t1thjqGDo23 O91/bSQ+Vn0vBQ2vOEJys8ftxdoLJAyI5YLzHVT+RsMTQLIXVuPyrNcKs1vC2ql+ UDHpU1R+9cG9JUEHpGI6z0DPnQ74SKbQH3fiVBpHhYx4BmvcBC4gWQzKMkDWFiq3 8AssIZ7b9lWl3OBgQ4UM1OIDKoJyjRewIdKyl7zboKSt6Qu8LrcsXO3kb81YshOW ZpSS3QDIqfZC4+EElnB15l4RcVwnPHBaQY0FxUr4Vl4UWM36jbuJAJUDBRAyDpgY q+7ov9TkHBEBAQGoA/sFfN07IFQcir456tJfBfB9R5Z6e6UKmexaFhWOsLHqbCq6 3FGXDLeivNn6NTz81QeqLIHglTuM3NP1mu8sw215klAG8G3M1NA2xLw7Eqhspze2 raGvNeEwxl8e+PY9aZwBj4UWU+CmIm6QNiP0MtvR7QYDIKn5mZCDc3CLmr942IkB FQMFEDIOh0O8AhTPqRipPQEB4EYH/1gkDmdHL6lbEkFuQLrylF+weBl0XQ+kv7ER vWXYrvIrkppxtc4VAge6CXXEbOGJnvkFHgyNZzO9Q9O64QsmZvjip+4lhDLeNrdH X9DizS4YKXxkSKr9Yltmn2/AlBCx6jwcDIfkqy/P1tNWcikxZZMd6KryK0Wsres9 Ik12OmVmJjQSxb5bS6Q8aYUbV3qwosGXTqy+BzYh/UYAX/XJIWa5kxFVSPKFSZ+5 toiSzANd9SpHPEogGvQDHJlJ23lmsMx/6uHsR1LTsQ8su8zIk92XyqePJTjlMx2j D7KJWNR7Zzu4QHCXBkga5W8l2FfPk7D3+o7bXTLRuR1yTYGdNoiJAJUCBRAyDhwt SlKLwP4OFW0BAdaMA/9rcWQlSq44K9JuJ7fZUgt9fwxGreTud9fC8DvlbUW79+CA AHLTLLagcEF1OKsWzVBWcA2JEAp+TUTqktRN0oD8vnaw3uNJd1G5KK59hw0WR8x1 v4ivypbSjiq95Y3gBunb7WjpyiFRWDlm0PrKrWHtbWzjnpPIpetln1UuqsSfbokB FQIFEDIOG9C3N61ZQ4Dr/QEBIzMH/1VxxztmBPBszbjZLDO8Svcax9Ng8IcWpcDy WqHCAA2Hoe5VtMD0v6w31ZgVqTPIvCark2Y/aTR1GofiuN9NUqbVV534AgAYLzYk DMT1swsPvqDTpOYgQl6PCGh6A5JGAbWJfKkX9XCUHJAAmiTsEVRNnjOgL+p6qjoh EfIG8CGehghWSRKl5eGeDAtbXupZKNjFI1t2XV+ks0RFQ/RPuTH7pF7pk7WO6Cyg +Dk2ZMgua0HRL1fXvHKb5Xzr3MVgsbAl5gP8ooIiD9MI/x5Irh3oo58VyoEZNBs/ Kz+drGFDPljcS6fdiVCFtYIzMrshY6YsfLi0aB8fwOvFtxgBqli0J0NocmlzdG9w aGVyIEJha2VyIDwxOjE4LzE0QGZpZG9uZXQub3JnPrQoQ2hyaXN0b3BoZXIgQmFr ZXIgPGNiYWtlcjg0QGRpZ2l0YWwubmV0Pg== =61OQ -----END PGP PUBLIC KEY BLOCK----- File-request FNEWSKEY from 1:1/23 [1:18/14] or download it from the Rights On! BBS at 1-904-409-7040 anytime except 0100-0130 ET and Zone 1 ZMH at 1200-9600+ HST/V32B. The FidoNews key is also available on the FidoNews homepage listed in the Masthead information. ----------------------------------------------------------------- FIDONEWS 14-22 Page 39 2 Jun 1997 ================================================================= FIDONET BY INTERNET ================================================================= This is a list of all FidoNet-related sites reported to the Editor as of this appearance. ============ FidoNet: Homepage http://www.fidonet.org FidoNews http://ddi.digital.net/~cbaker84/fidonews.html HTML FNews http://www.geocities.com/Athens/6894/ WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html FTSC page http://www2.blaze.net.au/ftsc.html Echomail http://www.portal.ca/~awalker/index.html WebRing http://ddi.digital.net/~cbaker84/fnetring.html ============ Zone 1: http://www.z1.fidonet.org Region 10: http://www.psnw.com/~net205/region10.html Region 11: http://oeonline.com/~garyg/region11/ Region 13: http://www.smalltalkband.com/st01000.htm Region 14: http://www.netins.net/showcase/fidonet/ Region 15: http://www.smrtsys.com/region15/ [disappeared?] Region 16: http://www.tiac.net/users/satins/region16.htm Region 17: http://www.portal.ca/~awalker/region17.htm REC17: http://www.westsound.com/ptmudge/ Region 18: http://www.citicom.com/fido.html Region 19: http://www.compconn.net ============ Zone 2: http://www.z2.fidonet.org ZEC2: http://fidoftp.paralex.co.uk/zec.htm [shut down?] Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm Region 20: http://www.fidonet.pp.se (in Swedish) Region 24: http://www.swb.de/personal/flop/gatebau.html (in German) Region 25: http://members.aol.com/Net254/ FIDONEWS 14-22 Page 40 2 Jun 1997 Region 27: http://telematique.org/ft/r27.htm Region 29: http://www.rtfm.be/fidonet/ (in French) Region 30: http://www.fidonet.ch (in Swiss) Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish) REC34: http://pobox.com/~chr Region 36: http://www.geocities.com/SiliconValley/7207/ Region 41: http://www.fidonet.gr (in Greek and English) Region 48: http://www.fidonet.org.pl ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: (not yet listed) Region 90: Net 904: http://members.tripod.com/~net904 (in Spanish) ============ Zone 5: (not yet listed) ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-22 Page 41 2 Jun 1997 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Christopher Baker Editors Emeritii: Tom Jennings, Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Sylvia Maxwell, Donald Tees "FidoNews Editor" FidoNet 1:1/23 BBS 1-904-409-7040, 300/1200/2400/14400/V.32bis/HST(ds) more addresses: Christopher Baker -- 1:18/14, cbaker84@digital.net cbaker84@aol.com cbaker84@msn.com (Postal Service mailing address) FidoNews Editor P.O. Box 471 Edgewater, FL 32132-0471 U.S.A. voice: 1-904-409-3040 [1400-2100 ET only, please] [1800-0100 UTC/GMT] ------------------------------------------------------ FidoNews is published weekly by and for the members of the FIDONET INTERNATIONAL AMATEUR ELECTRONIC MAIL system. It is a compilation of individual articles contributed by their authors or their authorized agents. The contribution of articles to this compilation does not diminish the rights of the authors. OPINIONS EXPRESSED in these articles ARE THOSE OF THE AUTHORS and not necessarily those of FidoNews. Authors retain copyright on individual works; otherwise FidoNews is Copyright 1997 Christopher Baker. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact the original authors, or the Editor. =*=*=*=*=*=*=*=*= OBTAINING COPIES: The most recent issue of FidoNews in electronic form may be obtained from the FidoNews Editor via manual download or file-request, or from various sites in the FidoNet and Internet. PRINTED COPIES may be obtained by sending SASE to the above postal address. File-request FIDONEWS for the current Issue. File-request FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSEnn.ZIP] for a FIDONEWS 14-22 Page 42 2 Jun 1997 particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [7], i.e., FNWSFEB7.ZIP for all the Issues from Feb 97. Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 14 for 1984 - 1997, respectively. Annual Volume archives range in size from 48K to 1.4M. INTERNET USERS: FidoNews is available via: http://www.fidonet.org/fidonews.htm ftp://ftp.fidonet.org/pub/fidonet/fidonews/ ftp://ftp.aminet.org/pub/aminet/comm/fido/ *=*=* You may obtain an email subscription to FidoNews by sending email to: jbarchuk@worldnet.att.net with a Subject line of: subscribe fnews-edist and no message in the message body. To remove your name from the email distribution use a Subject line of: unsubscribe fnews-edist with no message to the same address above. *=*=* You can read the current FidoNews Issue in HTML format at: http://www.geocities.com/Athens/6894/ STAR SOURCE for ALL Past Issues via FTP and file-request - Available for FReq from 1:396/1 or by anonymous FTP from: ftp://ftp.sstar.com/fidonet/fnews/ Each yearly archive also contains a listing of the Table-of-Contents for that year's issues. The total set is currently about 11 Megs. =*=*=*= The current week's FidoNews and the FidoNews public-key are now also available almost immediately after publication on the Editor's new homepage on the World Wide Web at: http://ddi.digital.net/~cbaker84/fidonews.html There are also links there to jim barchuk's HTML FidoNews source and to John Souvestre's FTP site for the archives. There is also an email link for sending in an article as message text. Drop on over. =*=*=*=*=*=*=*=*= A PGP generated public-key is available for the FidoNews Editor from FIDONEWS 14-22 Page 43 2 Jun 1997 1:1/23 [1:18/14] by file-request for FNEWSKEY or by download from Rights On! BBS at 1-904-409-7040 as FIDONEWS.ASC in File Area 18. It is also posted twice a month into the PKEY_DROP Echo available on the Zone 1 Echomail Backbone. *=*=*=*=* SUBMISSIONS: You are encouraged to submit articles for publication in FidoNews. Article submission requirements are contained in the file ARTSPEC.DOC, available from the FidoNews Editor, or file-requestable from 1:1/23 [1:18/14] as file "ARTSPEC.DOC". ALL Zone Coordinators also have copies of ARTSPEC.DOC. Please read it. "Fido", "FidoNet" and the dog-with-diskette are U.S. registered trademarks of Tom Jennings, P.O. Box 410923, San Francisco, CA 94141, and are used with permission. "Disagreement is actually necessary, or we'd all have to get in fights or something to amuse ourselves and create the requisite chaos." -Tom Jennings -30- -----------------------------------------------------------------