F I D O N E W S -- Volume 14, Number 9 3 March 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. | +----------------------------------------------------------------------+ WANT YOUR MESSAGE IN THIS SPACE? SEND IT IN! Table of Contents 1. EDITORIAL ................................................ 1 No responses to last week's Questions .................... 1 2. ARTICLES ................................................. 2 Net 1:231 Has a New Web Page ............................. 2 'Anarchy' in Region 50 Russia - no RC? ................... 2 An Innocent Bystander .................................... 3 3. GETTING TECHNICAL ........................................ 6 FSC-0044 - Improved method of duplicate message detecti .. 6 4. COORDINATORS CORNER ...................................... 20 Nodelist-statistics as seen from Zone-2 for day 059 ...... 20 5. WE GET EMAIL ............................................. 21 Another Internet-FidoNet query ........................... 21 6. NET HUMOR ................................................ 24 Computer riddles? ........................................ 24 7. NOTICES .................................................. 25 Future History ........................................... 25 8. FIDONET SOFTWARE LISTING ................................. 26 Latest Greatest Software Versions ........................ 26 9. FIDONEWS PUBLIC-KEY ...................................... 32 FidoNews PGP public-key listing .......................... 32 10. FIDONET BY INTERNET ..................................... 33 11. FIDONEWS INFORMATION .................................... 35 FIDONEWS 14-09 Page 1 3 Mar 1997 ================================================================= EDITORIAL ================================================================= Quando Omni Flunkus Moritati strikes again. [See FidoNews 1351.] Seems to be a little uproar in Russia. USR is finally releasing the X2 firmware download for those who have V34s and haven't heard. The FSC in this week's Issue was written by Jack Decker who left FidoNet about three years ago but still reads the FidoNews and wanted to say 'hi' to those who remember him. His contact info appears at the end of his FSC today. We have a couple new FidoNet sites in the Internet section. There are no Headlines or film at eleven this week. C.B. ----------------------------------------------------------------- FIDONEWS 14-09 Page 2 3 Mar 1997 ================================================================= ARTICLES ================================================================= Net 1:231 Has a New Web Page by Richard Bash - 1:231/0 Internet: rmbash@cord.iupui.edu FidoNet 1:231 in Indianapolis, Indiana, is pleased to announce the creation of a web page for the Net. The URL is: http://www.oaktree.net/net231 While no astounding creation of art, the page lists all of the members of Net 231, their BBS names, BBS phone numbers and also provides links to web pages of the members of the Net. Documents such as POLICY4.DOC, the local Net operating guidelines and a node application form are also available via the web page. You are invited to visit the site and provide your constructive comments on ways to improve the page. ----------------------------------------------------------------- Elections of R50C went crazy By Mikhail Ramendik, 2:5020/145.43, ramen@average.org WARNING: this question caused much flame in the Russian sysop areas. I am not into it either side, in fact I'm not a Node at all. I just want to communicate an interesting story. It all started as usual. R50C, Basil Dolmatov 2:5020/140, has quietly resigned. Elections were announced, Kostya Boyko 2:5020/37 became Returning Officer. The elections were to end somewhere like February 17. But some mail was lost on the way to the RO. So the senders (an entire Net) requested a prolongation. The RO granted it to 22 Feb. Then... On 19 Feb he announced the results. Dmitry Zavalishin, 2:5020/32, won. He claimed that as the mail from the requestors has arrived, the vote was over, despite the public announcement of prolongation. Flame started here. But it did not end here. For the winner got only 44% of the votes that came, with Mikel Lavrentyev 2:5020/35 second with 23%. A second run - between these two was requested from the RO and finally granted by him. But... BY THIS TIME, THE OLD RC AND THE ZC HAVE RECOGNIZED THE NEW RC!!! So now we have no publicly accepted RC. Anarchy? ;) FIDONEWS 14-09 Page 3 3 Mar 1997 This situation is very dynamic. In fact it may change by the time this article reaches Fidonews. And I hold NO opinion on what side is right. But it calls us to some thoughts. What has become of the Net which started as just a union of friendly SysOps? Why has the Founding Father Tom Jennings left his creation? I have his answer here in a letter of July 1994. The text of the letter makes it clear that this information is not confidential. 8< Personally, I consider "policy4" to be a smelly old crock of shit. You can quote me on that, only you will find many people have heard me say it before... :-) Note that "POLICY4" contains valid procedural advice and information -- how to assign numbers, how to define a functional system, and such. For that it's fine. Otherwise, the actual policy is intended to let a small number of people control the behavior and speech of another, larger group of people. I immediately mistrust people who propose such things. If they are young enough, I give them time to get over it :-) 8< Do we NEED to have this structure, so that the RC elections become something like Presidential ones with all the necessary scandals? Surely the *backbone* needs management, but then the Net and the backbone are not the same, and one theoretically can be a node and not link to a backbone. I'm NOT proposing anything here. It's just food for thought. And - I apologize to Tom Jennings if it was not good to quote his letter. In fact, my secret desire is that he would show up here with an article explaining his thoughts. Perhaps we have grown old enough to understand. Mikhail Ramendik. Moscow, Russia. Team OS/2. ----------------------------------------------------------------- An Innocent Bystander Robert "Not a Sysop" Parson Jackalope Junction 1:3822/1 I've been reading Fidonews with great interest over the past several months (actually years, but that's another matter). Quite a few things have sparked my interest, and I thought I'd comment as an "interested bystander." (It's true, I'm really not a sysop.) I noticed a disturbing trend in the Coordinator's Corner that Zone 1 FIDONEWS 14-09 Page 4 3 Mar 1997 was losing roughly 200 nodes a week, so I started keeping my own stats on the Nodelist. There are some differences, which I attribute mainly to the differences in which we are compiling our stats, but generally turned up the same thing. At this rate, Zone 1 will cease to exist in midsummer 1998. By the way, according to the latest report published in Fidonews, the number of nodes in North America has now slipped below 10,000. My hat's off to Ward Dossche for compiling and making this analysis available. On this subject, someone noted a couple months ago that most of the nodes in Zone 2 are not BBSs. His description sounded like most of them were glorified points. If someone could explain this a bit better or clear up any misunderstanding on my part, I'd appreciate it. Someone else noted (I really should keep Fidonews archived on my computer and give these people the appropriate credit. But again, I'm not a Sysop) that a "State of the Network" message/address/whatever would be of interest. There are significant problems with Fidonet both technically and internally. He's in charge, at least nominally, and we should demand he say something. Election underway for IC and pending for Z1C? Without notice in Fidonews? After consulting Policy 4, it appears notice of elections is not necessary. Looks like something that needs to be fixed. And about that Policy 4... forget it. P4 doesn't work. It's outdated and the only reason it's pulled out is when somebody has some griping to do. Should The Powers That Are ever decide to update Fidonet Policy, don't bother with P4.whatever. Scrap the darn thing entirely, start fresh, skip a P5 even and go on to P6. My first recommendation is to split it into two documents. One that is specific to technical standards, the other for personnel matters (moderators, coordinators, and the ubiquitous etc). I also think a Fidonet Users' Guide for non-sysops would be very helpful. Since the latest Big Controversy seems to be Chris Baker's editorship of Fidonews, I thought I'd comment on that as well. I contacted Donald Tees about taking over the reigns about two years ago when he originally announced he was considering resigning. My vision was somewhat different from his and the (unwritten) mission of Fidonews. So, I opted out. Nobody else picked up the standard. Late last year, Donald disappeared from Fidonet. After several weeks hiatus, and apparently quite a bit of non-action on the part of those who had responsibility, Chris began publishing Fidonews. There are some things I would not have done, and a few things I wish I'd thought of. But generally, I think he's doing a good job with this thankless position. If there's somebody upset enough with Chris' editorship, there's nothing to stop them from publishing a competing Fidonews, as long as it doesn't actually call itself "Fidonews" or represent itself as the "Official Publication of Fidonet." I think anyone who tries will find out exactly how difficult it is. Now that I've rattled on a bit, I guess I should tell you what I bring FIDONEWS 14-09 Page 5 3 Mar 1997 to the table since I've noted I'm not a sysop: nothing. I'm just a user of a local BBS. And isn't bringing us users together what Fidonet is all about? I'm keenly interested in the continued viability of Fidonet. And frankly, it looks pretty shaky. Robert Parson 1:3822/1 ----------------------------------------------------------------- FIDONEWS 14-09 Page 6 3 Mar 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of a continuing series of FTSC Standards and Proposals and the FidoNet History series. These docs have been reformatted to 70 columns where necessary. Node numbers that appear in these docs are often no longer in service. Check your Nodelist for current listings of authors.] Ed. Document: FSC-0044 Version: 002 Date: 07-Oct-1990 An improved method of duplicate message detection and prevention Jack Decker 1:154/8@Fidonet Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is subject to the restrictions stated in the copyright paragraph below. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Purpose: The purpose of this document is to present a proposal for an improved method of duplicate message detection and prevention, that could eventually replace the existing PATH and SEEN-BY lines currently used within Fidonet. The principal advantages of this method over previous schemes is that it is fully Domain-, Zone-, and Point-aware, and that it adds far fewer bytes to a message than the current combination of SEEN-BY and PATH lines. It can also be run in parallel with existing SEEN-BY and PATH lines for an indefinite period, thus allowing a "transition period" of as long as is necessary for software to be converted. Copyright: This document is Copyright 1990 by Jack Decker. However, permission is granted for any and all non-commercial use, providing the contents of this document are not altered in any way. Also, permission is expressly granted for any use by developers of software primarily intended to be used in the Fidonet amateur communications network, or in any similar amateur communications network that primarily uses Fidonet technology and protocols, whether that software is commercial or not. Comments on this proposal, and suggestions for improvement are FIDONEWS 14-09 Page 7 3 Mar 1997 welcomed by the author. In particular, suggestions on how this proposal might be reworded to make the meaning clearer are especially welcome. A. Definition: In this document the characters ^A (caret and capital A) will be used to represent a 0x01 (SOH) byte. It will be most commonly used in reference to the "^APTH line", which will be a line that begins with a 0x01 byte immediately followed by the letters "PTH" (and then by additional data as specified below). B. Why a new method of duplicate message detection is needed: Most of the methods of duplicate message detection currently used in Fidonet echomail processing operate by trying to find some distinguishing characteristic of an echomail message (whether it be something deliberately included in the message, such as an EID, MSGID, etc. type of "kludge line", or something which is contained in all echomail messages, such as the message header). Typically, either the item being used for duplicate detection itself or a checksum of that item is then saved in a data file, and if another item comes in with that same distinguishing characteristic, the message is considered to be a duplicate message. The data files used to store previously-seen message data can occupy a significant amount of disk space if many conferences are carried on a system. Unfortunately, all such schemes seem to suffer from the drawback that under the proper circumstances, messages that are not duplicates of each other may be created with identifying characteristics that are similar enough to be falsely recognized as duplicates. The circumstances under which this can happen may differ from method to method, but none are totally foolproof. Thus, it's possible that messages may be deleted as duplicates even though in reality they are not duplicates, but rather they are simply messages that contain data that make them appear to be duplicates. The most common cause of duplicate messages is improper echomail topology (also known as the infamous "dupe loop"). While there are certainly other ways that duplicates can be generated, improper topology is far and away the leading cause. Further, many of the current duplicate elimination schemes will NOT catch most of the duplicates that are NOT generated as a result of improper topology (which is why duplicate messages are seen occasionally, even though duplicate message detection schemes are currently in use). Unfortunately, if a duplicate killer is to be effective, it must store the identifying characteristics for the last several thousand messages that have passed through a particular system. This not only uses up disk storage space, it consumes extra processing time during echomail processing, since each new arriving message must be compared to the data list in the attempt to determine if it is, indeed, a duplicate. A better approach would be to store within a message itself data that identifies it as having already been received by a particular system, before sending it on to another system. Then, if the same message FIDONEWS 14-09 Page 8 3 Mar 1997 came back to a given system in a "dupe loop", it would be possible to positively identify it as one that has already been seen on that particular system. And, since the data necessary to identify the message as a duplicate is stored within the message itself, it is possible to use this method without the necessity of storing great amounts of data on previously-seen messages (in many implementations this alone would save 10K or more of disk space per conference carried!). Were it not for the fact that the PATH line present in most echomail messages does not contain Zone or Point information, we could use it for that purpose. However, since it does not contain that information, it cannot and should not be used in that manner. Another drawback of the PATH line is that because it is physically located at the end of a message (after the SEEN-BY lines), if only the last part of a message is scrambled or deleted, the PATH line information will be lost. C. Proposal: 1) A new type of kludge line (commonly known within FIDONET as an "IFNA kludge line"), which combines certain characteristics of the existing PATH and SEEN-BY lines, will be placed into each echomail message. This line, known as the ^APTH line, will be placed at the TOP of the message (not necessarily the first line, but prior to the body of the message text). IMPORTANT: Support for the existing PATH and SEEN-BY lines will be retained as long as is necessary to accommodate everyone in Fidonet, but eventually the ^APTH line could possibly replace both the current PATH and SEEN-BY lines. 2) The ^APTH line will contain full five-dimensional addressing (Zone:Net/Node.Point@Domain), BUT elements that are the same as the previous entry in the line need not be repeated (except when a message passes to a new domain, in which case the full address of the first node in the new domain shall be given). When the "point" portion of an address stands alone, it shall be preceded by at least a "." character (to distinguish it from a node address). 3) If a system is importing messages and finds a message with its own address already in the ^APTH line, it will discard the message (unless that address is in the very last position on the line... this allows for the odd situation where a point or another task on the same system has already inserted the system's address in the ^APTH line, or where it is desirable to process the same message a second time). 4) One (and only one) modifier character may appear just AFTER any address on the ^APTH line. When using the ^APTH for duplicate message checking only, you may just skip past any such address, unless it's your own address (see examples later in this document). In that case, strip the address and the modifier character (in other words, if you see your own address but it's immediately followed by a modifier character, remove that address, add yours to the end of the ^APTH line, and toss the message anyway). The reason for doing this is to allow the design of an echomail processor that doesn't rely on SEEN- BY's. Such a processor could append a modifier character (such as a "!") to an address, in order to indicate that "this message hasn't FIDONEWS 14-09 Page 9 3 Mar 1997 really passed through this node, but don't send it back there" (which would be the equivalent of a SEEN-BY statement for that node, indicating that this message has already been sent to that node). Thus the ^APTH line could eventually take the place of SEEN-BY lines, but you could still have a "fully coupled" triangular or rectangular topology. In this case, you'd add the nodes that are part of that fully coupled topology to the ^APTH line BEFORE sending the message to them, but with the special character after the address. The receiver would know that the message didn't really pass through that node yet, but it should NOT send it to that node under any circumstances. (Please note that during the initial design of software to create ^APTH lines, you would not have to worry about generating the special case with the trailing modifier characters, you'd just have to be able to handle them as shown in the examples below if you came across one). D. Specifications and examples: The general specifications for a ^APTH line, and a general outline of how an incoming message might be processed follows. A valid ^APTH line will contain at a minimum the string ^APTH followed by a single space character and the network address of the system that created the ^APTH line, in Zone:Net/Node[.Point]@Domain format, where ^A is a 0x01 byte (SOH) and the point address is required only if the system is a point (specifically, a system that is NOT a point should not use .0). Once again, the FIRST Fidonet-technology address specified in a ^APTH line is expected to contain, at a minimum, Zone, Net, and Node numbers, and a valid Domain string preceded by the "@" character. If any of these are missing from the FIRST address, the line should be considered defective (exception: See Note 5, "Messages sent to/from non-Fidonet-technology networks"). It will be left to the discretion of the software author as to how to handle a message with a defective ^APTH line. Subsequent addresses in the ^APTH line are delimited by spaces and should contain only that information that is different from the previous entry on the line, except when a message passes into a new domain (in which case the full address of the first system in the new domain shall be given) or when a bossnode receives a message from a point, in which case the bossnode should append its node number only. Specific examples follow: a. If the Domain and Zone are the same as the previous address, but the net is different, then only Net/Node[.Point] should be used. b. If the Domain, Zone and Net are the same as the previous address, but the node is different, then only Node[.Point] should be used. c. If the Domain, Zone, Net, and Node are the same as the previous address, but the point is different, then only .Point should be used. Note that in this case, the period is FIDONEWS 14-09 Page 10 3 Mar 1997 included. d. If the Domain, Zone, Net, and Node are the same as the previous address, but the previous address contains a point specifier and the receiving system is not a point (i.e., it IS the bossnode), then only Node should be used. .0 (point zero) might also be a valid entry in this case, but only if the bossnode consistently identifies itself to other systems using a full five-dimensional address. For example, a message that originated on 1:234/5.6@Fidonet and went from there to 1:234/5 would contain a ^APTH line in this format: ^APTH 1:234/5.6@Fidonet 5 If the bossnode is also considered to be point zero, then ^APTH 1:234/5.6@Fidonet .0 Would be equally valid. In the case of a "fully connected" topology, nodes may be added to the ^APTH line even though a message has not actually passed through those nodes, to prevent the message from being sent to those nodes. Such nodes should have an exclamation point character ("!") appended to the end of the entry, immediately following the node or point number. These nodes should be added to the very end of a new or existing ^APTH line, after the address of the node which added them. For example, suppose that 157/200, 154/9, and 228/6 were in a "fully connected" topology. When a message was received by 157/200 and then sent to 154/9 and 228/6, the ^APTH line might look something like this: ^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 157/200 154/9! 228/6! When a message arrives on one of the nodes indicated by the exclamation point, the exclamation point entry should be removed, and the node should add itself to the end of the line in the normal manner. For example, after the message containing the above ^APTH line were received at 154/9, it would be modified to read: ^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 157/200 228/6! 154/9 Please note that at the time of this proposal, the exclamation point (!) is the ONLY "officially recognized" modifier character that can be expected to be appended to a ^APTH line address (except for the @Domain string, of course), however, the possibility remains that someone may figure out a good reason to use a different trailing character for some other (but similar) purpose, so I am allowing for that possibility by using the generic terminology "modifier character" rather than the more specific "exclamation point" throughout this document. The ^APTH line must be terminated with a carriage return and/or linefeed (a carriage return followed by a linefeed is preferred, and should be used by all systems capable of generating a carriage return/linefeed combination). FIDONEWS 14-09 Page 11 3 Mar 1997 There is no specified limit on the length of a ^APTH line. Each message should contain only one ^APTH line, even if it extends beyond the typical 80 column screen width. The ^APTH line is primarily intended for use by the conference mail processing software, so primary consideration is being given to ease of processing the line, rather than making it easily human-readable (most software will not display kludge lines hidden behind a ^A character in any event). E. Pseudo-outline of message processing Here is a suggested flow pseudo-outline showing one way that messages might be processed in a standalone program that runs between the import and export cycles of an existing conference mail processor such as ConfMail (this outline assumes that the standard Fido/Opus style *.msg files are used, though obviously that need not be the case): 1. Open *.msg file for input 2. Open temporary file for output 3. Copy header (first 190 bytes) from input to output file. The following operations begin immediately following this header. 4. Examine each line of input file (a line is delimited by a carriage return, linefeed, or any combination thereof) for one of the following: a. A blank line - Write to output and examine next line. b. A line containing spaces only - Write to output and examine next line. c. A line that begins with a 01 byte (SOH) - GoTo 5. d. A line that does not meet any of the above specifications. I. Create a line containing the string ^APTH followed by a single space character and your network address, in Zone:Net/Node[.Point]@Domain format, where ^A is a 0x01 byte (SOH) and the point address is required only if you are a point (specifically, a system that is NOT a point should not necessarily use .0). This line should be terminated with a carriage return and/or linefeed (a carriage return followed by a linefeed is preferred). II. Write the line created in 4.d.I. to the output file. III. Write the line input in 4. to the output file. IV. Goto 9. 5. If a line begins with a 0x01 (SOH) byte, examine the keyword immediately following it. a. If the keyword is NOT "PTH", write the entire line to output and examine the next line (go back to 4). FIDONEWS 14-09 Page 12 3 Mar 1997 6. If a line begins with ^APTH, examine each address in the line in turn. Addresses start immediately following the characters "PTH " (note the space). a. The FIRST Fidonet-technology address (not counting any pseudo-addresses consisting solely of "@Domain") is expected to contain, at a minimum, Zone, Net, and Node numbers, and a valid Domain string preceded by the "@" character. If any of these are missing from the FIRST Fidonet-technology address, the line should be considered defective (See Note 5, "Messages sent to/from non-Fidonet-technology networks", for information on "@Domain" entries). It will be left to the discretion of the software author as to how to handle a message with a defective ^APTH line. b. As each address is found, any Zone, Net, and Node numbers and Domain strings found should be stored in temporary variables, to be used as defaults for subsequent addresses when only a partial address is given. For example, the first address will contain a Zone number. This should be stored in a temporary variable and used as the default Zone for all subsequent addresses, until and unless another Zone number is seen in the line, at which time that Zone number should be stored in the temporary variable and used as the default Zone. c. If an address is found that consists entirely of the "@" character (as the first character of the address) followed by a domain name (with or without punctuation), all temporary variables (defaults) should be cleared (since any subsequent Fidonet-technology address should contain full Zone:Net/Node[.Point]@Domain information). Otherwise, such pseudo-addresses (consisting solely of @Domain) may be ignored at systems that do not serve as inter-network gateways (such entries are maintained only by inter-network "gateway" software). However, they should not under any circumstances be removed from the ^APTH line. 7. As each address is found, it should be compared against the system's address. If a match is found: a. Check to make sure that the address is not a point address if the system's address does not contain a point specifier. If the system's address is given without a point specifier, then it should not be considered a match if ANY point address is found in the ^APTH line address that is being compared (not even .0 - for example, if the address 1:234/5.0 is seen in the ^APTH line, and 1:234/5 is the given system address, then it is NOT a match). b. If the address does match exactly, check to see if a modifier character (specifically the "!" character) immediately follows the address. If it does, then that address must be removed from the line at that point. I. When removing an address, please make sure that you do not change the address of subsequent entries. This may FIDONEWS 14-09 Page 13 3 Mar 1997 require modification of the next entry on the line, if one exists. For example, suppose you had a "fully connected" topology where 1:157/200 sent an echo to both 1:154/9 and 1:154/970. The ^APTH line might end as follows: ..... 157/200 154/9! 970! However, after modification of the ^APTH line, it should read: ..... 157/200 154/970! 9 You can see that if 154/9 were simply deleted without regard to what follows on the line, the following (incorrect) line might result: ..... 157/200 970! 154/9 (THIS IS INCORRECT) The above is incorrect because 154/970 has been transformed into 157/970. II. After removing an address followed by a modifier character, continue to scan any remaining addresses in the ^APTH line in case a match is found later in the line. If no other matches are found, proceed as if no match had been found. Goto 8. c. Check to see if the address is the last one on the line (not counting addresses that have a modifier character immediately following them). If this address is followed only by the end of the line, or ONLY by addresses that have a modifier trailing character, then there is a very high probability that we have either inadvertently or deliberately processed this message twice, and it is not really a duplicate. In this case, the original *.msg file should be left untouched. I. Close both the input and output files. II. Delete the temporary output file. END. d. If a match is found, and it is not followed by a modifier character, and it is not the last address on the ^APTH line, then the message is a duplicate message and should be treated as such (either by deleting it, or moving it to a "bad messages" area or the netmail area). I. Close both the input and output files. II. Delete the temporary output file. III. Either delete or move the original .msg input file, as appropriate. END. 8. If the end of the ^APTH line is reached and a match has not been found, then add the system's address to the end of the ^APTH line. Then write the modified ^APTH line to the output file. I. If one or more addresses with an appended modifier character (used within "fully-coupled" topologies) are to be added to the ^APTH line, they should be added at the very end of the line, after the address of the FIDONEWS 14-09 Page 14 3 Mar 1997 system currently processing the message). 9. Copy the remainder of the input file to the output file. Close both files. 10. Delete the input file. 11. Rename the temporary output filename to the old input filename. END. [End of outline] F. Additional notes and clarifications: Note 1: In section 7.b.I. I mentioned the necessity of not simply deleting a node from the ^APTH line without checking to see if the next address in the ^APTH line needs to be modified. This can easily be accomplished if TWO sets of temporary variables are kept, for the CURRENT and PREVIOUS Domain, Zone, Net, and Node information (Point addresses are NOT kept as defaults, thus there is no need to store Point information). When reading the FIRST address in the ^APTH line, the Domain, Zone, Net, and Node information of that address would be stored in both the CURRENT and PREVIOUS variables. Thereafter, whenever a new Domain string or Zone, Net, or Node number is explicitly specified in a ^APTH line address, the new value(s) are stored in the CURRENT variables, but first the CURRENT values are moved to the PREVIOUS values. To help visualize this, let's again suppose we have a ^APTH line that ends as follows (all of these addresses are in Fidonet Zone 1): ..... 157/200 154/9! 970! Let's suppose that we are processing this message on 154/9, and will need to remove the 154/9! address. When we encounter 157/200, our variables will be set as follows: Previous | Current Domain Fidonet | Fidonet Zone 1 | 1 Net ? | 157 Node ? | 200 Now, when we read 154/9, our current values will be moved to the previous: Previous | Current Domain Fidonet | Fidonet Zone 1 | 1 Net 157 | 154 Node 200 | 9 We now have the data we need to determine what needs to be added to the next address, after we delete 154/9. In this case, we need only compare the Previous and Current addresses to determine which are UNEQUAL. In this case, the Zone and Domain are the same, but the Net FIDONEWS 14-09 Page 15 3 Mar 1997 and Node are not. So, if the following address lacks either the Net or Node, we'll have to add those. Now we delete the 154/9! and look at the next address, 970. At this point our variables will look like this: Previous | Current Domain Fidonet | Fidonet Zone 1 | 1 Net 154 | 154 Node 9 | 970 Again, we compare to see which addresses are UNEQUAL. In this case, only the NODE address is. So we know we do NOT have to add the NODE address, nor do we have to add the Zone or Domain information (because they were not different on the first compare). We only need add those address components which were unequal on the first compare, but equal on the second compare. So, in this case, the Net address must be added to the next address in the ^APTH line, leaving as a result: ..... 157/200 154/970! The current system address is then added back in at the end of the line, thus: ..... 157/200 154/970! 9 Note that whenever a new Domain is specified, the full address (four- or five-dimensional, depending on whether a point address is given) must be used. In other words, an address that includes an "@Domain" string but that does not also include the Zone, Net, and Node components of the address is considered invalid (it does not meet specifications). Note 2: In section 4.d it is suggested that, when a line that is neither blank nor a kludge line (that begins with a ^A character) is found, a ^APTH line be added at that point. However, there are reports that under certain circumstances (particularly when messages are "forwarded" or "hurled"), certain software may insert a non-kludge line prior to previously-existing kludge lines in a message. It should be recognized by software authors that a non-kludge line should NEVER be inserted in front of existing kludge lines located at the start of a message, if those kludge lines are still valid (and if they are NOT still valid, they should be removed. When a message is forwarded or hurled, it is probably desirable to remove duplicate control information since what is essentially happening is that the text of a previous message is being inserted into a NEW message. Since the message is new, the "old" duplicate control information is no longer valid). Software authors that are implementing the ^APTH line in their software should never search beyond the first text line of a message for the ^APTH line, because if one is found later in the text, it is in all probability an old ^APTH line that was inadvertently copied over from another message, and is not relevant to the current message. Note 3: This is an optional suggestion, for use during the transition FIDONEWS 14-09 Page 16 3 Mar 1997 period in which the ^APTH line has to coexist with more traditional PATH and SEEN-BY lines. If ^APTH line checking is being used during the import phase of echomail processing in a conference mail processor, it might be a good idea to optionally check to make sure that all ^APTH line addresses that are in the system's home Zone and Domain (including those with an appended modifier character) have been properly included in the SEEN-BY lines, and to add any that have not been so included. It should be obvious that ^APTH line addresses that are NOT in the system's home Zone and Domain should NOT be added to the SEEN-BY lines. If this feature is implemented, it may be a good idea to give the sysop the ability to enable or disable it by means of a command line switch or a configuration file option. Note 4: If nodes with trailing modifier characters are inserted into a ^APTH line for the purpose of indicating "SEEN-BY" nodes in a fully coupled topology, it is permissible (but not required) to include those nodes ONLY in the ^APTH lines of messages actually exported to the nodes participating in the circular topology. In other words, it's permissible to add such nodes to the ^APTH lines of messages during the import cycle, in which case messages with ^APTH lines containing the added nodes would be exported to all nodes. However, it's also permissible to add those nodes to the ^APTH line during the export cycle, including them only in the ^APTH lines of the nodes that need to see them. Please keep in mind that such nodes are added only to the END of the ^APTH line, AFTER the address of the system processing the message. In any event, it's up to the software author to implement this feature in such a manner that duplicates will not be created. Similarly, if a node RECEIVES a message containing a ^APTH line that lists nodes with trailing modifier characters, it is permissible to remove those nodes from the ^APTH line if it can be positively ascertained that they are no longer required. Generally speaking, this should NOT be done unless there is absolutely NO possibility of the message being exported to one of the nodes in question. Note that in most situations, if a ^APTH line contains a node with a trailing modifier character, but it is followed by a node number (other than your own) that does NOT have a trailing modifier character (that is, the node with the trailing modifier character is not one of the last nodes on the line), then it can usually be safely removed since it will have already "passed through" the fully-coupled topology. Using the previous example of 157/200, 154/9, and 154/970 participating in a fully-coupled topology, the ^APTH line as received at 154/9 and 154/970 might end as follows: ..... 157/200 154/9! 970! However, please note that if 157/200 also feeds other nodes that are NOT part of this particular fully coupled topology, there is no real reason they would have to see the "154/9! 970!" at the end of the line. However, there is no prohibition against including those nodes in the ^APTH lines of messages exported to other nodes. Once this example message arrives at 154/9, the ^APTH line would be changed to look like this: FIDONEWS 14-09 Page 17 3 Mar 1997 ..... 157/200 154/970! 9 Now, when this message is exported from 154/9 to another node (154/111 for example), that node may remove the "154/970!" as long as 154/9 remains in the ^APTH line, since as long as the message cannot be sent back to 154/9, it cannot re-enter the fully-coupled topology. The ^APTH line at this point (after the message is received on 154/111) might look like this: ..... 157/200 154/9 111 It would probably not be advisable to remove the "154/970!" at 154/9 in this example, even if the message has already been exported, because the message might need to be re-exported (such as when a new board picks up an echo feed). When in doubt, nodes with trailing modifier characters (other than your own) should be left in the ^APTH line. While there is a cost of a few extra bytes per message if you leave them in, it does not compare to the cost of the duplicate messages that could be generated if they are removed indiscriminately. Note 5: Messages sent to/from non-Fidonet-technology networks: When a message originates in, or is sent to, a non-Fidonet-technology network (a network that does not use the Zone:Net/Node.Point addressing format), it is permissible to indicate this in the ^APTH line by using the syntax "@Domain" standing alone. For example, a message that comes into Fidonet via a gateway from the Internet might show a ^APTH line as follows: ^APTH: @Internet 1:114/15@Fidonet 5 ... Note that in the above example, the first Fidonet-technology address must still contain, at a minimum, Zone, Net, Node, and Domain information. It's also permissible to show a non-Fidonet-technology network at some point in the ^APTH line other than at the beginning, if for some odd reason a conference starts out in a Fidonet-technology network, passes through a non-Fidonet-technology network, and then is picked up by another Fidonet-technology network. For example, ^APTH: [Fidonet addresses] ..... 114/5 15 @Internet 200:5000/400@Metronet Note that "@Internet" stands alone in the above example, meaning that the conference originated in Fidonet, passed into the Internet (where the ^APTH line was not maintained), and then back into a Fidonet- technology network (Metronet in this case). Note that any Fidonet- technology address that follows a standalone Domain specifier must contain, at a minimum, Zone, Net, Node, and Domain information. The question immediately arises, how do you maintain the original Fidonet-technology ^APTH line while the message passes through another (non-Fidonet-technology) network? This could be left solely to the discretion of the designers of the gateway software, but in order to FIDONEWS 14-09 Page 18 3 Mar 1997 maintain a standard that can be followed by authors of different gateway software packages, I suggest that the ^APTH line be converted to one or more lines that start with the keyword FtnPth (For "Fidonet- technology ^APTH line), with the @Domain address of the non-Fidonet- technology network to which the message is being passed inserted as the last entry in the list. For example, the following ^APTH line ^APTH: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 114/5 15 ... would be converted to the following ASCII text line in the message as sent to the Internet: FtnPth: 3:711/431.5@Fidonet 431 403 1:124/4210 4115 114/5 15 @Internet If the receiving network has a line length limitation, then it may be necessary to break the ^APTH line into multiple FtnPth lines. If the message is later passed back into a Fidonet-technology network, the gateway software should ideally be able to take the FtnPth information and convert it back to proper ^APTH line syntax, adding the name of the network that the message was received from if not the same as the last network indicated in the FtnPth line(s). Of course, if no FtnPth lines exist in message, then the gateway software should ideally create one, showing the network that the message was received from as the first entry in the ^APTH line. If this is done correctly (and if non-Fidonet-technology networks can be persuaded to leave the FtnPth lines intact), duplicate message detection can be maintained even if a message passes through a non- Fidonet network. In addition, those in the other network will have access to information showing where the message originated, which systems it passed through, and where it entered their network, which can be a big help in tracking problem messages. Finally, this information can be used to prevent undesirable message paths (for example, a message that enters Fidonet from a non-Fidonet-technology network and then is later sent back into that same network at a different gateway point, thus causing a potential duplicate message in the other network). Please note that in the above examples, references to @Internet are for example purposes only, and are not intended to specify the "correct" domain name (in preference to "UseNet" or "UUCP", for example). Determination of the "correct" domain name for non-Fidonet- technology networks may be left to those who operate the domain gateways. Jack Decker October 7, 1990 Change History: Version 001: 04/01/90 - Original document Version 002: 10/07/90 - Added support for Domains, and other minor modifications to the text (mostly error correction). FIDONEWS 14-09 Page 19 3 Mar 1997 [Jack Decker is still around and wishes me to include his greeting to FidoNet and give his Internet address for anyone who wishes to say hello or discuss his FSC. He may be reached at: jack@techknowtimes.com or jack@novagate.com or his homepage at: http://www.novagate.com/~jack He also recommends http://www.techknowtimes.com for tech types.] Ed. -30- ----------------------------------------------------------------- FIDONEWS 14-09 Page 20 3 Mar 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 059 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-031|Nodelist-038|Nodelist-045|Nodelist-052|Nodelist-059|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 9877| 9729 -148 | 9527 -202 | 9527 0 | 9405 -122 |34| | 2 | 16078|16067 -11 |16074 7 |16051 -23 |16116 65 |57| | 3 | 863| 863 0 | 846 -17 | 812 -34 | 807 -5 | 3| | 4 | 550| 549 -1 | 538 -11 | 541 3 | 541 0 | 2| | 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0| | 6 | 1072| 1072 0 | 1071 -1 | 1071 0 | 1088 17 | 4| +----+------+------------+------------+------------+------------+--+ | 28527|28367 -160 |28143 -224 |28089 -54 |28044 -45 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-09 Page 21 3 Mar 1997 ================================================================= WE GET EMAIL ================================================================= --- Following message extracted from NETMAIL @ 1:18/14 --- By Christopher Baker on Sat Mar 01 19:57:39 1997 From: Christopher Baker @ 1:18/14 To: Bob Satti @ 1:1/0 Date: 01 Mar 97 19:54:10 Subj: looking for Internet links to FidoNet ops CC: Bob Kohl, Martin Belcke, Dave Beach, Phillip Dampier CC: Dave Miller, Marv Carson, B Becker, Dallas Hinton, Ken Tuley CC: James Ray, Ward Dossche, David Nugent, Ariel Nardelli CC: Henk Wolsink, Kazuyoshi Shinada, Bruce Bodger, Jason Steck CC: Adrian Walker, Ed Georgen, Ken Wilson, Sid Balcom CC: Marge Robbins, Brandon Carnahan, Brian Bonfietti, John Mudge CC: Dave Anderson, Ben Hamilton, John Souvestre, George Peace CC: Roy Timberman, Peter Witschi in case you hadn't noticed, there is a new section in FidoNews that lists FidoNet-related webpages and websites for Zones, Regions, and Nets. these listings also appear on the official FidoNews webpage at: http://ddi.digital.net/~cbaker84/fidonews.html and at the FidoNews HTML page listed in the Masthead each week. i would appreciate all ZCs and RCs passing this request down their chain of command and to their ECs down the chain as well. i would like to know about any and all FidoNet-related pages out there. the only way i can get that info after little response to FidoNews requests is to send you and your downlinks this Netmail. for example, i have a listing for REC19 at ccove that no longer seems to exist. REC19? did you drop or change your webpage? Zones 4 and 5 don't have any links at all in the fidonet.org section. ZC4 and ZC5, do you have webpages down and over there? here is the current list as it appears in FidoNews: 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 FIDONEWS 14-09 Page 22 3 Mar 1997 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 http://www.dharmanet.org/BDO/net125.html Region 15: http://www.smrtsys.com/region15/ Region 16: http://www.tiac.net/users/satins/region16.htm http://www.tiac.net/users/satins/net330.htm Region 17: http://www.portal.ca/~awalker/region17.htm Region 18: http://www.citicom.com/fido.html Region 19: http://ccove.n-link.com/ ============ Zone 2: http://www.z2.fidonet.org ZEC2 http://fidoftp.paralex.co.uk/zec.htm Region 25: http://members.aol.com/Net254/ Region 29: http://www.rtfm.be/fidonet/ (in French) Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish) Region 36: http://www.geocities.com/SiliconValley/7207/ ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: (not yet listed) ============ Zone 5: (not yet listed) FIDONEWS 14-09 Page 23 3 Mar 1997 ============ Zone 6: http://www.z6.fidonet.org ============ -30- would any of you care to add your Internet info for publication in FidoNews and on the FidoNews webpage? please pass this request along. thanks. QOFM. Chris FidoNews Editor [in case you've been out of touch for 8 months] [grin] -30- ----------------------------------------------------------------- FIDONEWS 14-09 Page 24 3 Mar 1997 ================================================================= NET HUMOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" , Date: Thu, 20 Feb 97 08:15:31 -0600 Reply-To: "Mike Riddle" Subject: From another list.... PC Humour Q. What lizards like to sit on PCs? A. Monitors. Q. How do cold PC programmers feel? A. IC. Q. What do Wiccan computer experts ride in? A. A hex bus. Q. How do memory chip experts want their payment? A. In cache. Q. How do programmers write a debt notice? A. I/O U. Q. How did the Hunchback of Notre Dame surf the Net? A. With a quasi-modem. Q. How is Seagate like a rutted road? A. They both make hard drives. Q. What kind of lingerie do lady programmers like? A. Softwear. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ United States of A-moo-rica's state of the week: Moonesota -30- ----------------------------------------------------------------- FIDONEWS 14-09 Page 25 3 Mar 1997 ================================================================= NOTICES ================================================================= Future History 17 May 1997 Independence Day, Norway. 25 May 1997 Independence Day, Argentina. 6 Jun 1997 National Commemoration Day, Sweden. 11 Jun 1997 Independence Day, Russia. 1 Jul 1997 Canada Day - Happy Birthday Canada. 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 Future History, please send a note to the FidoNews Editor. ----------------------------------------------------------------- FIDONEWS 14-09 Page 26 3 Mar 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 All right, I admit it. I've been slacking off. I didn't get anything done this week. Sigh. The good news is that the old info section is down to under 40 percent, so we're seeing some real progress there. Phased out this week: "OS/2 Systems" Section Phase-out highlights: This week: "Amiga" Section Deadline for info: 14 Mar 1997. Last week: "Atari ST/TT" Section Deadline for info: 7 Mar 1997. -=- 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.1 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.0 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 FIDONEWS 14-09 Page 27 3 Mar 1997 FrontDoor 2.12 M S JoHo 2:201/330 FD FrontDoor 2.20c M C JoHo 2:201/330 FDINFO GIGO 07-14-96 G S Jason Fesler 1:1/141 INFO GoldED 2.50 O S Len Morgan 1:203/730 GED 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 1.11 O F Damian Walker 2:2502/666 INFOMAIL InfoMail/386 1.20 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.73a B P Christopher Baker 1:374/14 OPUS O/T-Track 2.63a O S Peter Hampf 2:241/1090 OT PcMerge 2.7 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 Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TriBBS 10.0 B S Patrick Driscoll 1:372/19 TRIBBS TriDog 10.0 M S Patrick Driscoll 1:372/19 TRIDOG TriToss 10.0 T S Patrick Driscoll 1:372/19 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 FIDONEWS 14-09 Page 28 3 Mar 1997 BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2 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 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.10 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.9 M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx7.9 M G Pablo Saratxaga 2:293/2219 IFMAILTX 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 CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK FIDONEWS 14-09 Page 29 3 Mar 1997 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 Atari: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY 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 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 FIDONEWS 14-09 Page 30 3 Mar 1997 XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25 MSGTOSS 1.3 ZSX 2.40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BBS Software Macintosh Other Software Name Version --------- Name Version -------------------- -------------------- FBBS 0.91 Network Mailers MacArd 0.04 Hermes 1.6.1 Name Version Mantissa 3.21 Mansion 7.15 -------------------- Mehitable 2.0 Precision Sys. 0.95b Copernicus 1.0 OriginatorII 2.0 Red Ryder Host 2.1 Tabby 2.2 PreStamp 3.2 Telefinder Host StuffIt Classic 1.6 2.12T10 Other Software SunDial 3.2 Name Version TExport 1.92 -------------------- TimeStamp 1.6 Point System ArcMac 1.3 TImport 1.92 Software AreaFix 1.6 Tset 1.3 Name Version Compact Pro 1.30 TSort 1.0 -------------------- EventMeister 1.0 UNZIP 1.02c Copernicus 1.00 Export 3.21 Zenith 1.5 CounterPoint 1.09 Import 3.2 Zip Extract 0.10 MacWoof 1.1 LHARC 0.41 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Amiga Network Mailers Other Software ----- Name Version Name Version -------------------- -------------------- BBS Software BinkleyTerm 1.00 Areafix 1.48 Name Version TrapDoor 1.80 AReceipt 1.5 -------------------- WelMat 0.44 ChameleonEdit 0.11 4D-BBS 1.65 ConfMail 1.12 Falcon CBCS 1.00 ElectricHerald 1.66 Starnet 1.0q@ Compression FFRS 1.0@ TransAmiga 1.07 Utilities FileMgr 2.08 XenoLink 1.0 Name Version Fozzle 1.0@ -------------------- Login 0.18 AmigArc 0.23 MessageFilter 1.52 NodeList Utilities booz 1.01 Message View 1.12 Name Version LHARC 1.30 oMMM 1.50 -------------------- LhA 1.10 PolyXAmy 2.02 ParseLst 1.66 LZ 1.92 RMB 1.30 Skyparse 2.30 PkAX 1.00 Roof 46.15 TrapList 1.40 UnZip 4.1 RoboWriter 1.02 Zippy (Unzip) 1.25 Rsh 4.07a Zoo 2.01 Tick 0.75 TrapToss 1.20 |Contact: Maximilian Hantsch 2:310/6| Yuck! 2.02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BBS Software Atari ST/TT Name Version ----------- -------------------- FIDONEWS 14-09 Page 31 3 Mar 1997 FIDOdoor/ST 2.5.1 Network Mailers Other Utilities FiFo 2.1v Name Version Name Version LED ST 1.00 -------------------- -------------------- QuickBBS/ST 1.06* The Box 1.95* ApplyList 1.00@ Burep 1.1 Compression ComScan 1.04 Utilities NodeList Utilities ConfMail 4.10 Name Version Name Version Echoscan 1.10 -------------------- -------------------- FDrenum 2.5.2 ARC 6.02 ParseList 1.30 FastPack 1.20 LHARC 2.01i EchoFix 1.20 Import 1.14 PackConvert sTICK/Hatch 5.50 oMMM 1.40 STZip 1.1* Pack 1.00 UnJARST 2.00 Trenum 0.10 WhatArc 2.02 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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-09 Page 32 3 Mar 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-09 Page 33 3 Mar 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 http://www.dharmanet.org/BDO/net125.html Region 15: http://www.smrtsys.com/region15/ Region 16: http://www.tiac.net/users/satins/region16.htm http://www.tiac.net/users/satins/net330.htm Region 17: http://www.portal.ca/~awalker/region17.htm Region 18: http://www.citicom.com/fido.html Region 19: http://ccove.n-link.com/ ============ Zone 2: http://www.z2.fidonet.org ZEC2 http://fidoftp.paralex.co.uk/zec.htm Region 25: http://members.aol.com/Net254/ Region 29: http://www.rtfm.be/fidonet/ (in French) Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish) FIDONEWS 14-09 Page 34 3 Mar 1997 Region 36: http://www.geocities.com/SiliconValley/7207/ ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: (not yet listed) ============ Zone 5: (not yet listed) ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-09 Page 35 3 Mar 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-09 Page 36 3 Mar 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-09 Page 37 3 Mar 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- -----------------------------------------------------------------