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