F I D O N E W S -- Volume 14, Number 21 26 May 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. | +----------------------------------------------------------------------+ REMEMBER MEMORIAL DAY AND THOSE WHO GAVE ALL Table of Contents 1. EDITORIAL ................................................ 1 Chugging right along? .................................... 1 2. LETTERS TO THE EDITOR .................................... 2 FTSC Nominations Re-opened ............................... 2 It can't work response ................................... 4 Looking for FidoNet systems in Miami ..................... 5 3. COLUMNS .................................................. 6 Lock and Load: Guerilla Marketing for BBSes .............. 6 4. GETTING TECHNICAL ........................................ 8 FSC-0071 - Distributed FREQ (DFREQ) Specs ................ 8 FSC-0073 - Encrypted Msg Identification for FidoNet ...... 12 FSC-0074 - Echomail Specification ........................ 14 5. COORDINATORS CORNER ...................................... 23 Nodelist-statistics as seen from Zone-2 for day 143 ...... 23 6. NET HUMOR ................................................ 24 What if Dr. Seuss wrote tech manuals? .................... 24 7. ADVERTISE YOUR FREE SERVICE/EVENT ........................ 25 Announcing the CRICKET_ECHO .............................. 25 Announcing the WRESTLING_CHAT Echo ....................... 25 8. NOTICES .................................................. 26 Future History ........................................... 26 9. FIDONET SOFTWARE LISTING ................................. 28 Latest Greatest Software Versions ........................ 28 10. FIDONEWS PUBLIC-KEY ..................................... 33 And more! FIDONEWS 14-21 Page 1 26 May 1997 ================================================================= EDITORIAL ================================================================= Several notices, an answer, a request for Miami FidoNet info, some technical stuff, a Dr. Seuss parody, nothing negative, nothing personal, and not too long. [grin] C.B. ----------------------------------------------------------------- FIDONEWS 14-21 Page 2 26 May 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Sat May 24 12:43:12 1997 From: Bruce Bodger @ 1:170/400 To: fidonews @ 1:1/23 Date: 24 May 97 10:25:54 Subj: FTSC Nominations Re-opened Chris, Please publish the below message in the upcoming FidoNews. Thank you. Submitted to FidoNews this date by Bruce Bodger FTSC NOMINATIONS RE-OPENED Adrian Walker and I have discussed the plans for the FTSC election and we have decided that for several reasons we would delay the vote until 01 August 97; 1. Both of us are going to be extremely busy, and unable to give this our full attention for the next few weeks. 2. It is clear to us that there are several more nominations "waiting in the wings" which missed the earlier nomination period. 3. We will shortly be into the summer vacation period, and delaying the vote a short while will avoid much of that. ==================== NOMINATIONS REOPENED ==================== Effective immediately, nominations for Standing Members have been reopened. For reference, here are the details of the nomination process: FTSC members are appointed for a two year renewable term. [50 % of appointments on initial formation of the FTSC shall be for a 3 year renewable term, to ensure continuity of the Committee on expiry of the terms.] To be selected as a FTSC member, an individual must be a Fidonet node, and should be actively involved in Fidonet. Examples include having put out a Fidonet-related product or having updated a product in the preceding two years, or having experience as a Coordinator, Echomail Coordinator or mail or file FIDONEWS 14-21 Page 3 26 May 1997 Hub. Standing members may be nominated Fidonet-wide by all of the following methods: 1. any RC or REC 2. a nominating committee established for the purpose by the FTSC 3. a nominating committee established for the purpose by the ZCC =============== ACTION REQUIRED =============== Since there is no nominating committee at this stage, those persons interested in becoming a Standing Member of the FTSC should state their interest to any currently-serving RC or REC and request that the RC or REC nominate them either by message in the FTSC_PUBLIC echo, or by netmail to Bruce Bodger (1:170/400), who is administering the nomination list. The closing date for such applications to be an active Standing Member of the FTSC will be Friday 01 August 1997. At that time a list of all applicants having been properly nominated will be published, and the voting process will then be followed as defined in FTA-1001. ================ CURRENT NOMINEES ================ NAME NODE # NOMINATOR NODE # POS'N Ron Bemis 1:124/1113 Ben Hamilton 1:124/7008 REC19 Bjorn Felten 2:203/208 Mats Wallin 2:201/329 RC20 Rune Johansen 2:210/20 Stein-Ivar Johnsen 2:212/8 RC21 Cristoffer Crusell 2:204/701 Mats Wallin 2:201/329 RC20 Joaquim Homrighausen 2:201/330 Mats Wallin 2:201/329 RC20 Tobias Burchhardt 2:2448/400 Mats Wallin 2:201/329 RC20 Mats Wallin 2:201/329 James Ray 1:124/8002 RC19 Mike Bilow 1:323/107 Jerry Schwartz 1:142/928 RC16 Thomas Waldmann 2:2474/400 Detlef Nick 2:2454/410 RC24 Tom Schlangen 2:2450/10 Detlef Nick 2:2454/410 RC24 Jason Steck 1:285/424 James Ray 1:124/8002 RC19 Carlos Fernandez Sanz 2:341/70 Carlos Hermida 2:348/603 REC34 Colin Turner 2:443/13 Mats Wallin 2:201/329 RC20 Peter Karlsson 2:206/221 Mats Wallin 2:201/329 RC20 Odinn Sorensen 2:236/77 Morten Mertner 2:235/100 RC23 Zorch Frezberg 1:205/0 Ed Georgen 1:2222/258 REC11 Goran Eriksson 2:201/505 Stefan Andersson 2:203/216 REC20 Robert Szarka 1:320/42 Ed Georgen 1:2222/258 REC11 Benjamin Schollnick 1:2613/477 David Moufarrege 1:2613/404 RC13 ---ooo000ooo--- FIDONEWS 14-21 Page 4 26 May 1997 ----------------------------------------------------------------- --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Fri May 23 00:09:09 1997 From: Ivy Iverson @ 1:154/170 To: FidoNews Editor @ 1:18/14 Date: 16 May 97 02:39:24 Subj: It can't work? * Original to: Clay Tannacore (1:372/4) Hi, Clay; I am sitting here reading your letter in FidoNews, and the thought strikes me that no matter WHAT happens in the politics of FidoNet, _ALL_ of the private nets - FidoNet, MufoNet and the rest), are very ill because of a virus. That virus is Internetitus! I am so damn sick and tired of all the political "campaigning," (read that as "Mud-slinging"), crap in FN_SYSOP that I dropped the echo. (I turned it on again, but only because of the INTBBS_WEEK echo which we are trying to get started, and the International BBS week which is being planned.) If we cannot get some publicity for our BBSes and recruit new systems into the nets, FidoNet and all the rest will become nothing more than a memory in some oldtimer's mind - a story to be told on some obscure home page somewhere, a reference in an old book on the history of the Internet. When that happens, and we are headed that way just as surely as if the phone company went out of business, please tell me what will all the politics, the name calling, the hard feelings, the high blood pressure of the current election matter? Have you read the message I posted which started the INTBBS_WEEK idea? If not, I will be more than happy to send you a copy! From where _I_ sit, the network's political issues won't make a penny's worth of difference when the last BBS pulls the plug for the last time. When we, (FidoNet SysOps in several European countries including Holland), get INTBBS_WEEK on the North American backbone, PLEASE get it and participate, ok? I am excited about it and you will be too! Catch you later... Let's keep the nets alive! Ivy Iverson SysOp: Ivy's WALL BBS 1:154/170 -30- FIDONEWS 14-21 Page 5 26 May 1997 ----------------------------------------------------------------- Date: Sat, 24 May 1997 21:09:34 -0400 From: Richard Pence To: cbaker84@digital.net Subject: bbs list to whom it may concern; i'm interested in obtaining a list of bulletin boards in the Miami, FL, area which are in the Fidonet network. any information on updated lists would be appreciated. thank you, richard pence miami, fl ----------------------------------------------------------------- FIDONEWS 14-21 Page 6 26 May 1997 ================================================================= COLUMNS ================================================================= Lock and Load: Guerilla Marketing for BBSes Robert Parson (1:3822/1) I had fully intended there to be a column last week. Time grabbed me by the lapel and wouldn't let go. Which is why I don't envy Editor Chris Baker. Onward: The first thing to remember about reporters is that they are not the enemy. Yes, the general image of BBSes within the media has been tarnished. But with proper cleaning that image can be shiny. We've talked about News Releases, but that's the easy part. The hard part comes when a reporter calls to interview you. As you can tell, I put a lot of emphasis on News Releases. Most are thrown away. But some really do result in news stories and some are filed away for future reference. Keep sending out those news releases and you will eventually become The Expert in the field. At first, you came to the media because you have something you want to say. But now, they are coming to you because you have something that they want to know. Rule number one: Return your calls. I know that sounds rather obvious, but you'd be amazed at how many news sources don't return phone calls. Rule number two: Don't lie. If you get caught, you'll get nailed to the wall. If you accidentally pass along some incorrect information, admit it at the first opportunity. Rule number two-and-a-half: Don't buffalo your way through something you don't know. If you don't know, refer the reporter to someone who does know. Sure it may mean less press for you, but that's better than being perceived as a fool. Rule number three: If the reporter is coming to see you, be neatly groomed. That doesn't mean you have to wear a suit and tie. Just don't look like you fell off a train. If you know and understand those three basic rules, you'll get along rather well with reporters. But there are some gaps to fill in. Some interviews will simply be conducted on the phone. A reporter may call to get some information on a breaking story, or get more information on the news release you sent him/her. Be patient. Reporters are representative of the public as a whole. They use computers at work, they are comfortable with them, but for the most part they don't go beyond what is required for them to know. They aren't techno-phobic, but they aren't going out their way to FIDONEWS 14-21 Page 7 26 May 1997 learn everything they can, either. Chances are the average reporter knows enough about computer communications to log onto the internet, grab e-mail, send a reply, and check into a couple news-oriented Websites. You may have to lead them through some issues. My favorite analogy is "If you can drive a car, you can drive a computer." Visual aids are always nifty. TV reporters like lots of movement. Give them lights blinking on a modem, animated ANSI, messages scrolling up the screen. Anything that conveys motion. For print journalists, a few static screen shots and a picture of you doing some work. If you have a room full of computers, a modem pool or whatever, they're usually quite happy about having pictures of tech-stuff from floor to ceiling. The entire time you are talking with a reporter, maintain your professional image. You can still be casual, but you are serious about your work as a Sysop. Don't lose your head on controversial topics. Which brings me to this point: If a reporter comes with an agenda don't get angry with him/her. Acknowledge that agenda. You read that right. But you have the opportunity to amend the agenda, and possibly even change it. "Porn on BBSes? Yes. But it is no more prevalent than it is in the community at large. Here, check out this Missing Children's Echo..." Always find some way to cast a negative issue in a positive light. And never pass up the opportunity to invite someone to call your BBS. What do BBSes and Newspapers have in common? We'll talk about that in two weeks. Got a BBS newsletter? or maybe a comment you want to keep out of netmail? Send it to: Robert Parson 2501 Phoenix Fort Smith, AR USA 72901 Remember: if you want an evaluation of your newsletter please send a self addressed stamped envelope. ----------------------------------------------------------------- FIDONEWS 14-21 Page 8 26 May 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing publication of FidoNet Technical Standards and proposals for FidoNet History. These documents have been reformatted to 70 columns where required and any tables or diagrams may be askew as a result. Node numbers and phone numbers may be out of date. In this week's group, FSC-0072 has not been published due to its size [110K]. It is available as FSC-0072.ZIP for freq here and other sites. FSC-0072 is the HYDRA Protocol Specs.] Ed. Document: FSC-0071 Version: 001 Date: 17-Jan-1993 Distributed FREQ (DFREQ) Specifications Bill Auclair, FidoNet 1:141/545 January 17, 1993 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. Distributed File Requests: What Are They? ------------------------------------------ DFREQ programs are designed to allow both sysops and users to make Distributed File Requests from other BBS systems listed in FidoNet or compatible nodelists. There are several major differences between Distributed File Request methodology (hereafter referred to as DFREQ) and existing FidoNet FREQ and/or file distribution formats. FidoNet file request technology was designed only for the direct transmittal of file requests from one system to another. DFREQ technology allows routing of file requests from the originating system along a user-configurable "chain" of systems, ending at the target node. This methodology allows the setup of no-cost, local routing paths for file requests between distant systems that would normally incur long-distance phone charges. How DFREQs Work --------------- Distributed File Request methodology can be separated into 2 main parts-- the REQUEST and the ACKNOWLEDGEMENT. FIDONEWS 14-21 Page 9 26 May 1997 The REQUEST represents the initial stage, in which DFREQ data from the originating system has not yet reached its target, and thus carries no accompanying requested files with it. DFREQ data may be relayed via file or netmail message attach through any number of intermediate systems on its way to its ultimate target, which is defined by the contents of the request file. The path taken by the request to its target is determined by routing data used by the DFREQ processors of participating nodes in the chain. The ACKNOWLEDGEMENT is the result of a processed request, and is created whether or not the requested files are available at the target system. The DFREQ information formerly carried by the request is used to create the acknowledgement, set its destination back to the originating system, file- or netmail-attach requested files (if any) for transmission, and/or provide information as to why requested file(s) were unavailable at the target system. Request data is deleted by the target system after the acknowledgement is created. The path taken by the acknowledgement back to the originating system again depends upon the routing configurations of the chain nodes, but need not be the same as the path previously travelled by the request. ASCII text files are used to transport DFREQ information between nodes. These carrier files are similar in form and function to the .TIC files used by the TICK file echo utility. The DFREQ process starts when a user generates a DFR file containing file request information, using the local or on-line mode of a DFREQ processor. DFR Files --------- DFREQ data for the REQUEST stage is transmitted using a file with a .DFR (Distributed File Request) extension. The filename is a randomly-generated 8-digit number. DFR files carry information on the net/node of the originating system, net/node of the target system, the name of the user who originated the request, the filenames and descriptions of the files to be requested, the path travelled by the request on its way to the target system, and date/time stamps indicating when the request was processed by each node in the path. DFRs are transmitted via file or netmail message attach. DFA Files --------- DFREQ data for the ACKNOWLEDGEMENT phase is transmitted using a file with a .DFA (Distributed File Acknowledgement) extension. The 8-digit filename of the previously processed DFR request file is retained. DFA files carry FIDONEWS 14-21 Page 10 26 May 1997 information on the net/node of the originating system (formerly the target system in the DFR file), the net/node of the target system (formerly the originating system in the DFR file), the name of the user who generated the request, the filenames and descriptions of successfully requested files, and the filenames and associated error information for any unsuccessfully requested or unavailable files. The full path information from the previously processed DFR file is retained, and is appended with path and datestamp information representing the travel of the DFA file back to its new target, the source of the original DFREQ. DFAs are transmitted via file or netmail attach. Error Messages -------------- When requests for any or all files in a DFREQ can not be fulfilled for some reason, information as to why the request was not satisfied is included in the DFA file, replacing the file descriptions of the unavailable files. Reasons for file unavailability can include: o File(s) not found or not available at target system o OKFile path does not exist on target system o File(s) not found in inbound area-- node xxx/xxx DFA files may be appended with error information by any processing system in the chain back to the originating node, depending upon where the error condition occurs. DFR/DFA File Formats -------------------- DFR and DFA files are ASCII text files that transport DFREQ information between systems. The DFR file is used during the REQUEST stage of the transaction. The DFA file is used during the ACKNOWLEDGEMENT stage of the transaction. New DFR files are created by the DFREQ processor using its local or on-line user mode. A random 8-digit numeric filename and .DFR extension are assigned to the file. File format for a newly-created DFR is shown below: Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair Origin 141/545 Requestor Bill Auclair Target 141/455 File LOGON.LZH 2969 01-17-90 generic telix log-on script The first line of the DFR holds information identifying the program/version used to create it. No empty spaces are allowed above this line, or between any of the lines that follow. FIDONEWS 14-21 Page 11 26 May 1997 The second line of the DFR contains Origin information. This indicates the net/node number of the system which generated the DFR. The third line of the DFR contains Requestor information. This provides the name of the user who initiated the DFREQ. The fourth line of the DFR contains Target information. This indicates the net/node number of the system which is to receive the DFR and process it to deliver requested files. All lines beginning with the "File" identifier contain filename and description information taken from remote file lists. Filenames and descriptions must be separated by at least one space. No empty lines are allowed after File information. When a DFR is sent to another system, that system's net/node information is appended to it, along with date and time stamp information indicating when the DFR was processed by the system. This information accompanies the DFR throughout its entire journey. A DFR file with Path information appended to it is shown below: Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair Origin 141/545 Requestor Bill Auclair Target 141/455 File LOGON.LZH 2969 01-17-90 generic telix log-on script Path 141/507 15 Nov 92 07:40:31 Information contained within the DFR file above indicates it has already traveled through the intermediate system 141/507 on its way from Origin system 141/545 to Target system 141/455. No empty lines are allowed after Path information. When a DFR file reaches its Target destination, it is converted into a DFA file, and its file requests are evaluated by the target system. Conversion of DFRs to DFAs is done by retaining the DFR filename, changing the .DFR extension to .DFA, and reversing Origin and Target data. Thus, a DFR file originally named 12345678.DFR from Origin 141/545 for Target 141/455 becomes 12345678.DFA from Origin 141/455 for Target 141/545, as shown below: Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair Origin 141/455 Requestor Bill Auclair Target 141/545 File LOGON.LZH 2969 01-17-90 generic telix log-on script Path 141/507 15 Nov 92 07:40:31 Path 141/485 15 Nov 92 08:02:55 FIDONEWS 14-21 Page 12 26 May 1997 Path 141/455 15 Nov 92 08:15:23 Path 141/455 15 Nov 92 08:15:25 Note the dual Path lines for the Target system. The first line represents processing as a DFR, the second represents processing as a DFA. The successfully-processed DFA file is returned to the system that originated the DFREQ, along with the accompanying requested file. The DFA as received and processed by the originating system is shown below: Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair Origin 141/455 Requestor Bill Auclair Target 141/545 File LOGON.LZH 2969 01-17-90 generic telix log-on script Path 141/507 15 Nov 92 07:40:31 Path 141/485 15 Nov 92 08:02:55 Path 141/455 15 Nov 92 08:15:23 Path 141/455 15 Nov 92 08:15:25 Path 141/485 15 Nov 92 10:01:06 Path 141/507 15 Nov 92 10:27:35 Path 141/545 15 Nov 92 10:31:59 If the Target system receiving the DFR file cannot satisfy the DFREQ, the file description for the unavailable file contained in the new DFA is replaced with error information. The DFA is then transmitted back to the system that originated the DFREQ. Error information contained within the DFA file as returned to the originating system is shown below: Created by GOFER v0.05a, Copyright (C) 1992 by Bill Auclair Origin 141/455 Requestor Bill Auclair Target 141/545 File LOGON.LZH !ERR018! File Not Available From 141/455 Path 141/507 15 Nov 92 07:40:31 Path 141/485 15 Nov 92 08:02:55 Path 141/455 15 Nov 92 08:15:23 Path 141/455 15 Nov 92 08:15:25 Path 141/485 15 Nov 92 10:01:06 Path 141/507 15 Nov 92 10:27:35 Path 141/545 15 Nov 92 10:31:59 -30- ----------------------------------------------------------------- | Document: FSC-0073 | Version: 001 | Date: 28th July 1993 FIDONEWS 14-21 Page 13 26 May 1997 | Author: John Mudge ENCRYPTED MESSAGE IDENTIFICATION FOR FIDONET *DRAFT I* FIDONET TECHNICAL COMMENT Author : John Mudge Fido : 1:352/111 Date : 25FEB1993 ABSTRACT: The following document proposes a standard for encrypted message identification for Fidonet and Fidonet-based electronic mail systems. The proposed standard will assist in encrypted-message detection. The standard consists of mandatory and suggested portions; however the term "mandatory" does not mean that any Fidonet product must implement this standard; it simply means that those that do claim to implement this standard must do so in the way described. 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. BACKGROUND: Currently, Fidonet encrypted messages are not uniquely identified. A variety of schemes are in place to determine whether a message received by a Fidonet node has been encrypted, but all of them involve encryption method specific tests. Current Fido Policy (Policy4) prohibits routing encrypted material through systems which have not given specific prior approval. This FSC proposes a method of identifying such traffic, but makes no effort to determine what action should be taken after the identification. IFNA KLUDGE LINES: Fidonet supports a general method for sending additional information embedded in a message known as the "IFNA kludge line". This is a line of text beginning with the ASCII SOH character (^A). The characters following SOH are a word indicating the type of kludge line, and the remainder of the line contains information specific to that type. This standard introduces a new type of kludge line, the ENC. FORMAT OF A MESSAGE ID - MANDATORY: The mandatory portion of the ^AENC line shall consist of the Ascii SOH character immediately followed by the uppercase characters ENC and a colon and one space. FIDONEWS 14-21 Page 14 26 May 1997 FORMAT OF A MESSAGE ID - SUGGESTED: It is suggested, though not required, that the unique part of all ^AENC lines consist of a unique product identifier following the same format as specified in FSC-0046 for ^APID kludge lines and identifying the program used for encryption. This product identifier will allow message editors to invoke the appropriate decryption software. EXAMPLE: ^AENC: PGP2.1 with PGP21 to be replaced with a two digit hex identifier at such time as a central product registry exists. IMPLEMENTATIONS: As of this writing, several products are being written, notably by Fredric Rice and GK Pace, to implement this proposal. Examples of currently available programs are GENMSG V1.30 and PGP-TOSS. SUMMARY: As of this date, no public repository exists for encryption/decryption product registration, but the FTSC is suggested as is the application form presented in FSC-0022. I am publishing this information as a Fidonet technical comment in hopes that other Fidonet products will eventually incorporate all or part of this standard as well, and that it will eventually form part of a Fidonet Technical Standard. CREDITS: I would like to thank all of the pioneers of Fidonet for making all of this possible. The ^AENC proposal is the result of the collective efforts of many of the participants of the Fido PUBLIC_KEYS echo. Much of the wording and structure for this document I stole from authors of previous FSC authors. Special thanks go to GK Pace and Fredric Rice for their ongoing programming efforts in support of public-key encryption systems. -30- ----------------------------------------------------------------- | Document: FSC-0074 | Version: 001 | Date: 28th July 1993 | Author: John Souvestre, David Troendle, Bob Davis, George Peace | | FTS-0004.002 -- proposed FIDONEWS 14-21 Page 15 26 May 1997 EchoMail Specification June, 1992 This document began as the Conference Mail System User Manual By Bob Hartman t/a Spark Software FidoNet(tm) node 132/101 (currently 1:104/501) Used with permission Revision 2: 06 Jun 1991 John Souvestre, David Troendle, Bob Davis 29 Oct 1991 John Souvestre, David Troendle 28 Jan 1992 George Peace 02 Jun 1992 George Peace ECHOMAIL DEFINED EchoMail is a technique that permits several nodes on a network to share a message base. It is similar in concept to the conferences available on commercial information services but is most closely related to the Usenet system consisting of thousands of systems world wide. All systems sharing a given conference see any messages entered into the conference by any of the participating systems. This can be implemented in such a way as to be totally transparent to the users of a particular system. In fact, they may not even be aware of the network being used to move their messages about from node to node! Unfortunately, EchoMail has disadvantages as well. Many users who are not educated about EchoMail systems do not realize the messages transmitted cost MANY sysops (system operators) money, not just the local sysop. This is an important consideration in EchoMail and should not be taken lightly. In a conference with 100 systems participating the cost per message can be quite high. BRIEF HISTORY OF ECHOMAIL In late 1985, Jeff Rush, a Fido sysop in Dallas, wanted a convenient means of sharing ideas with the other Dallas sysops. He created a system of programs he called Echomail, and the Dallas sysops' Conference was born. Within a short time sysops in other areas began hearing of this marvelous new gadget and EchoMail took on a life of its own. Today the FidoNet public network boasts a myriad of FIDONEWS 14-21 Page 16 26 May 1997 conferences varying in size from a handful of participants to Sysop conferences with hundreds of participants. It is not uncommon for a system to carry hundreds or more conferences and share those conferences with 10 or more nodes. HOW ECHOMAIL WORKS Today's EchoMail processing is functionally compatible with the original EchoMail utilities. In general, the process is: - A message is entered into a designated area on a FidoNet compatible system. - This message is "Exported" along with some 'control information' to each system "linked" to the conference through the originating system. - Each receiving system "Imports" the message into the proper Conference Mail area. - The receiving systems then "Export" these messages, along with additional control information, to each of their own EchoMail links. - Return to the import step. The method is quite simple in general. Of course, following the steps literally means messages would never stop being Exported and transmitted to other systems. This obviously would not be desired. The information contained in the 'control information' section is used to prevent exporting the same message more than once to a single system. MESSAGE CONTROL INFORMATION Control information is associated with each EchoMail message. This information consists of certain special lines placed inside the message. These lines are typically inserted automatically by the program which prepares or processes the message, not by the person writing it. In FTS-0001 terminology, these control information lines shall be inside the "text" field of a "packed message". Control information lines shall contain only ASCII characters, from 32 to 126, except the first character of the path line and as noted elsewhere in this document. This limitation applies only to control information lines. Alphabetic characters in required literal strings (AREA, Origin, SEEN-BY, and PATH) are case-sensitive. All control information lines shall be terminated with ASCII character 13 (carriage return). These required control information lines determine how FIDONEWS 14-21 Page 17 26 May 1997 EchoMail is handled: 1. Area line There shall be exactly one area line in an exported message. The AREA line: - Shall be the first line of the text and thus shall immediately follow the packed message header. This position is "offset 0" of the "text" portion of the packed message. - Shall be formatted as: AREA:CONFERENCE AREA: is a required five character upper case literal. CONFERENCE is the name of the conference. The conference name is composed of ASCII characters in the range 33 to 96 and 123 to 126. The conference name shall be no more than 60 characters in length. The AREA line is added when a conference is "Exported" to other systems. It is based upon information found in a configuration file for the designated message area. This field is used by receiving systems to "Import" messages into the correct EchoMail area. Some implementations insert a Ctrl-A (0x01) immediately preceding the AREA: literal (^AAREA:CONFERENCE). Six months after adoption of this document the ^AAREA: format shall be processed equally with the AREA: format when either occurs in received packets. 2. Origin Line There shall be exactly one origin line in a message. It shall be placed in the message following all user entered information and immediately before the remaining control information lines. The origin line: - Shall begin with the eleven character literal: *Origin: - Is optionally followed by user/system defined data in the ASCII range 32 to 126. - Shall end with a FidoNet network address enclosed in parenthesis: FIDONEWS 14-21 Page 18 26 May 1997 ([:]/[.][@]) - Shall be no more than 79 characters long including the required lead-in and address information. - Shall be inserted into the message at the originating system. The complete line might look like: * Origin: Conference Mail BBS (1:132/101) 3. Seen-by Lines Seen-by lines are the focus of EchoMail distribution control information. They are used to determine which addresses (systems) have received messages. There can be as many seen- by lines as required to store the necessary information. Seen-by lines consist of "SEEN-BY:", followed by a list of net/node numbers corresponding to the systems which have received that message. The net/node number of each system to which a message is exported is added to the seen-by lines at the time of export. There shall be exactly one set of seen-by lines in a message. Seen-by lines: - Shall follow the origin line. - Shall begin with the nine character literal: SEEN-BY: - Shall contain a list of net/node numbers. - Shall be no more than 80 characters long including the required literal. The complete lines might look like: SEEN-BY: 104/1 501 132/101 113 136/601 1014/1 SEEN-BY: 1014/2 3 The list of net/node numbers: - Shall identify at least one address. "Blank" seen-by lines shall not be transmitted. - Shall be sorted in ascending net/node order. - Shall not contain repeated node numbers. - Shall use only "2D" net/node notation. - May use short form address notation where a net number is FIDONEWS 14-21 Page 19 26 May 1997 listed once on any one line. These 2 lines are equivalent: SEEN-BY: 104/1 104/501 132/101 132/113 136/601 SEEN-BY: 104/1 501 132/101 113 136/601 Some implementations insert a Ctrl-A (0x01) immediately preceding the SEEN-BY: literal (^ASEEN-BY:). Six months after adoption of this document the ^ASEEN-BY: format shall be processed equally with the SEEN-BY: format when either occurs in received packets. 4. Path Lines Path lines identify a list of net/node numbers that processed a message before it reached the current system. There can be as many path lines as required to store the necessary information. This is different from seen-by lines, in that seen-by lines list list all systems to which the message has been sent while path lines list the systems which have processed the message. There shall be exactly one set of path lines in a message. Path lines: - Shall follow seen-by lines. - Shall be the last line(s) in the text field of a packed message. - Shall begin with the seven character literal: ^APATH: The ^A is a special character which stands for Control-A (ASCII character 1), and is required at the beginning of each path line. - Shall contain a list of net/node numbers. - Shall be no more than 80 characters long including the required literal. The complete path line might look like: ^APATH: 132/101 1014/1 The list of net/node numbers: - Shall identify at least one net/node number. "Blank" path lines shall not be transmitted. - Shall not be sorted. They shall remain in the order representing the actual "path" along which the message FIDONEWS 14-21 Page 20 26 May 1997 traveled. - Shall use only "2D" net/node notation. - Shall begin with the net/node of the originating system. - Shall not be deleted during processing. The original path information shall be maintained from origin to final destination. ECHOMAIL TOPOLOGY The way in which systems link together for a particular conference is called the "EchoMail Topology." It is important to know this structure for two reasons: - It is important to have a topology which is efficient in the transfer of the EchoMail messages. - It is important to have a topology which will not cause systems to see the same messages more than once. Efficiency can be measured in a number of ways: - Least time involved for all systems to receive a message - Least cost for all systems to receive a message - Fewest phone calls required for all systems to receive a message. Users of EchoMail systems have determined (through trial and error) the best measure of efficiency to be a combination of all three measurements. Balancing the equation is not trivial, but some guidelines can be offered: - Have nodes form "stars" for distribution of EchoMail. This arrangement has several nodes all receiving their EchoMail from the same system. In general the systems on the "outside" of the star poll the system on the "inside". The system on the "inside" in turn polls other systems in a similar star configuration to receive the EchoMail that is being passed on to the "outside" systems. - Utilize fully connected polygons with few vertices. Nodes can be connected in a triangle (A sends to B and C, B sends to A and C, C sends to A and B) or a fully connected square (all corners of the square send to all of the other corners). This method is useful for getting EchoMail messages to each node as quickly as possible. All of these efficiency guidelines have to be tempered with the guidelines dealing with keeping duplicate messages from being exported. Duplicates will occur in any topology that forms a closed polygon that is not fully connected. Take for FIDONEWS 14-21 Page 21 26 May 1997 example the following configuration: A ----- B | | | | C ----- D This square is a closed polygon that is not fully connected. It is capable of generating duplicates: 1. A message is entered on node A. 2. Node A exports the message to node B and node C placing the seen-by for A, B, and C in the message as it does so. 3. Node B sees that node D is not listed in the seen-by and exports the message to node D. 4. Node C sees that node D is not listed in the seen-by and exports the message to node D. At this point node D has received the same message twice - a duplicate was generated. Normally a "dup-ring" will not be as simple as a square. Generally it will be caused by a system on one end of a long chain accidentally connecting to a system on the other end of the chain. This causes the two ends of the chain to become connected, forming a polygon. In FidoNet this problem is reduced somewhat by having a regional EchoMail star distribution architecture that maintains EchoMail connections within regions of the world. Within that architecture only a small number of prearranged systems (regional collection systems) make inter-regional connections. This architecture, along with multiple daily connections, results in an efficient topology which typically allows global distribution within 24 hours. THE PATH LINE AND TOPOLOGY The PATH line stores the net/node numbers of each system having actually processed a message. This information is useful in correcting the biggest problem encountered by nodes running an Echomail compatible system - the problem of finding the cause of duplicate messages. How does the PATH line help solve this problem? Take the following path line as an example: ^APATH: 107/6 107/312 132/101 This shows that the message was processed by system 107/6 and transferred to system 107/312. It further shows system 107/312 transferred the message to 132/101, and 132/101 processed it again. Here's another example: FIDONEWS 14-21 Page 22 26 May 1997 ^APATH: 107/6 107/312 107/528 107/312 132/101 This shows the message having been processed by node 107/312 on more than one occasion. Based upon the earlier description of the 'information control' fields in Echomail messages, this identifies an error in processing. This further shows node 107/528 as the node which apparently processed the message incorrectly. In this case the path line can be used to help locate the source of duplicate messages or topology problems. In a conference with many participants it becomes almost impossible to determine the exact topology used. In these cases the use of the path line can help a moderator or distributor of a conference track any possible breakdowns in the overall topology, while not substantially increasing the amount of information transmitted. Having this small amount of information added to each message pays for itself very quickly when it can be used to help detect a topology problem causing duplicate messages to be transmitted to each system. -30- ----------------------------------------------------------------- FIDONEWS 14-21 Page 23 26 May 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 143 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-115|Nodelist-122|Nodelist-129|Nodelist-136|Nodelist-143|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 8675| 8519 -156 | 8430 -89 | 8367 -63 | 8277 -90 |31| | 2 | 15992|15952 -40 |15904 -48 |15879 -25 |15855 -24 |59| | 3 | 800| 800 0 | 800 0 | 800 0 | 761 -39 | 3| | 4 | 547| 548 1 | 543 -5 | 543 0 | 543 0 | 2| | 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0| | 6 | 1083| 1083 0 | 1083 0 | 1083 0 | 1077 -6 | 4| +----+------+------------+------------+------------+------------+--+ | 27184|26989 -195 |26847 -142 |26759 -88 |26600 -159 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-21 Page 24 26 May 1997 ================================================================= NET HUMOR ================================================================= Date: Thu, 08 May 1997 17:44:41 -0700 From: Shari Organization: OREGON - USA To: webheads@softdisk.com Subject: Dr. Seuss' technical manual References: Sender: owner-webheads@softdisk.com Reply-To: webheads@softdisk.com --- WHAT IF DR. SEUSS WROTE TECHNICAL MANUALS? If a packet hits a pocket on a socket on a port, and the bus is interrupted as a very last resort, and the address of the memory makes your floppy disk abort, then the socket packet pocket has an error to report! If your cursor finds a menu item followed by a dash, and the double clicking icons put your window in the trash, and your data is corrupted 'cause the index doesn't hash, then your situation's hopeless, and your system's gonna crash!!! If the label on your cable on the gable at your house says the network is connected to the button on your mouse, but your packet wants to tunnel to another protocol, that's repeatedly rejected by the printer down the hall, and your screen is all distorted by the side effects of gauss, so your icons in the window are as wavy as a souse, then may as well reboot and go out with a bang, 'cause as sure as I'm a poet, the sucker's gonna hang!! When the copy of your floppy's getting sloppy on the disk, and the microcode instructions cause unnecessary RISC, then you have to FLASH your memory and you'll want to RAM your ROM. Quickly turn off your computer and be sure to tell your Mom!! ----------------------------------------------------------------- FIDONEWS 14-21 Page 25 26 May 1997 ================================================================= ADVERTISE YOUR FREE SERVICE/EVENT ================================================================= Emanuel Edwards 1:348/963 emanuel@pangea.ca Hello all Cricket Lovers: This ad is to inform you that there is a cricket echo now on fidonet. All Sysops in England, Pakistan, India, Australia,South Africa and the West Indies that carry fidonet please request the cricket_echo on your bbs. The echo tag is called CRICKET_ECHO. The cricket_echo describe all aspects on how the game is played, the latest scores and upcoming tours and events in the cricket world. Please request the cricket_echo onto your bbs and let's start chatting about this beautiful and intersting game. Thanks you Emanuel Moderator. ----------------------------------------------------------------- Emanuel Edwards 1:348/963 emanuel@pangea.ca Hello all Wrestling Fans: This ad is to inform you that there is a new wrestling echo on the fidonet backbone. The echo tag is called WRESTLING_CHAT. Wrestling Fans in North American and around the world if you want to hear about all the latest wrestling news and upcoming events this is the echo to be on. All you sysops request the WRESTLING_CHAT on you BBS. The Wrestling_chat offer a freedom of speech atmosphere and there are great wrestling fans on that echo that echo. ----------------------------------------------------------------- FIDONEWS 14-21 Page 26 26 May 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-21 Page 27 26 May 1997 Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 14-21 Page 28 26 May 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= [This is a repeat of the SOF from 1420.] Ed. Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 Note: Mid-May, I will phase out the entire "Old Info" section. As always, I'll be happy to process any information I get, either before or after it is phased out. -=- 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 FIDONEWS 14-21 Page 29 26 May 1997 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 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 FIDONEWS 14-21 Page 30 26 May 1997 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 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 ---------------------------------------------------------------------- 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-21 Page 31 26 May 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 ---------------------------------------------------------------------- BinkleyTerm/ST 3.18pl2 M F Bill Scull 1:363/112 BINKLEY JetMail 0.99beta22 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 Old info from: 01/27/92 --------------------------------------------------------------------- MS-DOS Systems Other Utilities Other Utilities -------------- Name Version Name Version -------------------- -------------------- Network Mailers 2DAPoint 1.50* Netsex 2.00b Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35 -------------------- ARCAsim 2.31 Oliver 1.0a D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02 Dreamer 1.06 Areafix 1.20 PKInsert 7.10 Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a Milqtoast 1.00 Crossnet 1.5 QM 1.00a PreNM 1.48 DOMAIN 1.42 QSort 4.04 SEAdog 4.60 DEMM 1.06 RAD Plus 2.11 SEAmail 1.01 DGMM 1.06 Raid 1.00 TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0 EEngine 0.32 ScanToss 1.28 Compression EMM 2.11* ScMail 1.00 Utilities EZPoint 2.1 ScEdit 1.12 Name Version FGroup 1.00 Sirius 1.0x -------------------- FidoPCB 1.0s@ SLMail 2.15C ARC 7.12 FNPGate 2.70 StarLink 1.01 ARJ 2.20 GateWorks 3.06e TagMail 2.41 LHA 2.13 GMail 2.05 TCOMMail 2.2 PAK 2.51 GMD 3.10 Telemail 1.5* PKPak 3.61 GMM 1.21 TGroup 1.13 PKZip 1.10 GROUP 2.23 TIRES 3.11 FIDONEWS 14-21 Page 32 26 May 1997 GUS 1.40 TMail 1.21 NodeList Utilities Harvey's Robot 4.10 TosScan 1.00 Name Version HeadEdit 1.18 UFGATE 1.03 -------------------- HLIST 1.09 VPurge 4.09e EditNL 4.00 ISIS 5.12@ WEdit 2.0@ FDND 1.10 Lola 1.01d WildMail 2.00 MakeNL 2.31 Mosaic 1.00b WMail 2.2 Parselst 1.33 MailBase 4.11a@ WNode 2.1 Prune 1.40 MSG 4.5* XRS 4.99 SysNL 3.14 MsgLnk 1.0c XST 2.3e XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00 XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25 MSGTOSS 1.3 ZSX 2.40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Key to old info: + - Netmail Capable (Doesn't Require Additional Mailer Software) * - Recently Updated Version @ - New Addition -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Please send updates and suggestions to: Peter Popovich, 1:363/264 ----------------------------------------------------------------- FIDONEWS 14-21 Page 33 26 May 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-21 Page 34 26 May 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://rhub.hex.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-21 Page 35 26 May 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-21 Page 36 26 May 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-21 Page 37 26 May 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-21 Page 38 26 May 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- -----------------------------------------------------------------