F I D O N E W S -- Volume 14, Number 15 14 April 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. | +----------------------------------------------------------------------+ WHERE IS THE IC? Table of Contents 1. EDITORIAL ................................................ 1 No news is good news? .................................... 1 2. GETTING TECHNICAL ........................................ 2 FSC-0057 - Conference Managers - Request Specs ........... 2 FSC-0058 - New way of addressing in FidoNet .............. 11 3. COORDINATORS CORNER ...................................... 20 Nodelist-statistics as seen from Zone-2 for day 101 ...... 20 4. NOTICES .................................................. 21 Future History ........................................... 21 5. FIDONET SOFTWARE LISTING ................................. 22 Latest Greatest Software Versions ........................ 22 6. FIDONEWS PUBLIC-KEY ...................................... 27 FidoNews PGP public-key listing .......................... 27 7. FIDONET BY INTERNET ...................................... 28 8. FIDONEWS INFORMATION ..................................... 30 FIDONEWS 14-15 Page 1 14 Apr 1997 ================================================================= EDITORIAL ================================================================= Everyone must be licking their cyberwounds this week since there are no .ARTs or .LETs or .COLs this week. That leaves so much space for clearing out these FSC docs. [grin] Either that or everyone is perfectly happy in FidoNet. It's a FIRST! Enjoy it while it lasts. But what's happening in the International Coordinator election? C.B. ----------------------------------------------------------------- FIDONEWS 14-15 Page 2 14 Apr 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing FidoNet History series of technical publications related to the ops of FidoNet. They have been reformatted to 70 columns where required and any tables may be askew. Node numbers and/or phone numbers may be outdated.] Ed. Document: FSC-0057 Version: 003 Date: 07-Dec-92 Conference Managers - Specifications for Requests December 7, 1992 Fabiano Fabris Joaquim H. Homrighausen 2:285/304.100@fidonet 2:270/17@fidonet Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Revision 3 presents several additions and enhancements over the previous revision. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. 1 Purpose This document will explore the methods implemented by various conference managers which process requests (in net mail form) for changes to the conference mail links on the system on which they are in use. Until now, it would appear that no real standard exists, so most software authors have either tried to emulate another program, or to create a new method of their own, or both. Here, an attempt will be made to define a standard, one which tries to maintain compatibility with methods already in use, while also extending them to provide new functions. 2 Conventions The names of the commands described in the following paragraphs are given in upper case, for legibility. However, a conference manager should be able to interpret them even if they are given in lower or mixed case. FIDONEWS 14-15 Page 3 14 Apr 1997 Similarly, conference names, or tags, are given in upper case, but the conference manager should be able to handle them even if typed in lower or mixed case. Optional information is enclosed with square brackets, while variable information is enclosed with angle brackets. For example: +CONF [,R=] indicates that the section within square brackets is optional, and if supplied, requires a parameter after the equals sign. Some conference managers may allow commands to be abbreviated to the shortest non-ambiguous string. For example, %LIST might be reduced to %L. 3 Format of the request A request to a conference manager is generally made in a net mail message containing specific information in some of the fields. In particular, the addressee is the name of the conference manager itself, and the subject of the message is a password assigned by the sysop of the system running the program. For example: From: John Doe, on 2:123/56 To: Program, on 2:234/0 Subject: password Here the first problem is encountered. Each of the existing programs recognizes a different addressee. For this reason it is proposed that all such programs recognize requests made to a single, "standard" addressee, besides any other they may wish to implement. The term "ConfMgr" has been arbitrarily chosen, and should be used by those programs which adhere fully to all the standards proposed in this document. The text of the message itself contains the request proper, and is the subject of the following paragraphs. 4 Linking and Unlinking of conferences. The current methods for requesting that a conference be linked are basically two: +CONFNAME CONFNAME For reasons of uniformity, it is proposed that all conference manager programs recognize the first method. Requests that a conference be unlinked are given by: FIDONEWS 14-15 Page 4 14 Apr 1997 -CONFNAME It might be interesting to implement some form of pattern matching, similar to the unix shell. The following basic wildcards should be considered: * matches zero or more characters ? matches any one (not zero) character Since the requests are processed top-down, a request of the form +CONFNAME -* would be redundant, since the ConfMgr would link CONFNAME from the first line, and then immediately unlink it again because of the second line, which requests that all linked conferenecs be unlinked. It should also be possible to specify more than one conference tag on the same line. For example: +CONF1 CONF2 CONF3 would link the three conferences CONF1, CONF2 and CONF3. 5 Rescanning Conference Mail Many conference managers currently allow a system to request that an area be "rescanned". In other words, the system receiving the request will export all mail in one or more areas to the requesting system. This may be accomplished by specifying the %RESCAN command in the body of the request. This will force the ConfMgr to generate a scan request for those areas which the remote system requested with the message containing the %RESCAN command. Rescans of a single area, newly linked, could be requested as follows: +CONFNAME, R[=] where 'n' is the number of messages in that area to be rescanned. (The space following the comma is optional, but allowed.) Rescanning has one serious drawback: dupes! It is very possible for the requesting system to have already set up the area with several downlinks. Thus, when the rescanned mail is received, it could be exported to other systems. In a tree-based topology, this is harmless, but in circular topologies this would create dupes. Thus, it is proposed that system receiving the rescan request FIDONEWS 14-15 Page 5 14 Apr 1997 add a kludge to the messages, so that they can be recognized by the requesting system and not re-exported. The proposed kludge is: ^ARESCANNED where is the network address, including domain, of the system from which the mail was rescanned. In alternative to a rescan, a sysop might request a "sample", consisting of a series of messages contained in a text file. The ConfMgr would export some or all messages from an area to a plain ASCII text file, and send it along with the reply, to the requesting system. A "sample" request would be made as follows: +CONFNAME, S[=] where 'n' indicates how many messages should be sampled. a) Updating Conferences Update requests allow a sysop to rescan or "sample" an area without having to first unlink from it, and then relink with the rescan or "sample" parameter. The format of this command is: =CONFNAME, [=] Thus a rescan request for the most recent 50 messages would be specified as: =CONFNAME, R=50 6 Information Requests Requests for information have until now taken two forms. In one case, they are given as switches after the password on the subject line, while in the second they are given as "commands" within the body of the message text. It is proposed that the second method be chosen as standard, since it is considerably more flexible. Below are listed the proposed commands: %HELP Sends a (pre-defined) help text to the requesting system, explaining how the ConfMgr is to be used. %LIST[,B] Lists the conferences currently available to the requesting system, on the basis of a method internal to the conference manager itself. This list would flag the areas which are already linked. The 'B' modifier FIDONEWS 14-15 Page 6 14 Apr 1997 would generate the list in binary format (see section 8e). %BLIST Equivalent to %LIST,B above. %QUERY Lists the conferences currently linked to the requesting system. %UNLINKED Lists the conferences which are available to the requesting system, but not currently linked. This is the logical difference between a %LIST and a %QUERY. 7 Remote Maintenance Besides these simple functions, it is becoming more and more interesting to make handling of the conference mail flow even more automatic. For this reason, for example, it might be useful to allow another sysop control over your own system, adding and removing conferences as need requires. Thus a hub or coordinator could automatically have a new area added to their conference lists, or discontinued ones removed. Naturally, the ConfMgr must be able to distinguish which system has the ability to make such changes, but that is beyond the scope of this document. It is proposed that a conference manager be able to automatically add a new conference to the system's list if/when it is detected. Thus no special commands would be required. The manager should be able to determine a default list of down- links for the new area, and also the "group" of systems which could then request it. However, should it be desired to explicitly create a new conference via remote, this could be done by including a line such as the following in the message text: &CONFNAME In order to remote delete an area, the requesting sysop should include a line like this in the body of the message text: ~CONFNAME Thus, if the system has remote privileges, the conference would be deleted (and optionally, all systems linked to the conference could be informed of this fact). Similarly, it would also be possible to allow a system to change the tag of a conference. This would be accomplished by a line such as: # OLD_NAME NEW_NAME FIDONEWS 14-15 Page 7 14 Apr 1997 The ConfMgr should inform all downlinks of the change by sending a net mail message. It might also be desirable to allow a sysop to make changes on behalf of another system. This could be done by inserting a special command at the beginning of the request itself. For example: From: John Doe, on 2:123/1 To: Program, on 2:987/65 Subject: password Text: %FROM: 2:234/56 +CONFNAME The %FROM command would make the ConfMgr carry out the changes as if the system 2:234/56 had requested them. The password should nonetheless be the one assigned to 2:123/1. 8 Further Automation In order to make the system more powerful, and to reduce the necessity for human intervention, several extensions are feasible. a) ARCmail Compression Method One interesting application is the possibility of allowing a remote system to change the compression program used to "pack" mail bound for his system. This could be done with the following command in the message to a ConfMgr: %COMPRESS where is one of the compression programs supported by the system. Of course, the remote system should also be able to determine which compression methods are available; this could be done with %COMPRESS ? Requests for an unsupported compression method should also be responded to with a list of those available. From the practical point of view, only systems which pick up their mail (as opposed to those to whom mail is sent) should be allowed to change the compression method used. How this distinction is achieved is beyond the scope of this document. b) Passwords A sysop should be able to change the password used to make requests to a ConfMgr without requiring the intervention of the other system's sysop. This could easily be done if the conference manager implemented the following command: FIDONEWS 14-15 Page 8 14 Apr 1997 %PWD The new password (case insensitive) would replace the current one as of the next request. c) Temporary Unlink Should a system's sysop be absent for a prolonged period of time, he might want to temporarily cut all conferences from his uplink. This could be accomplished with the %PAUSE command. This would tell the ConfMgr to temporarily stop sending conferences to that system. On his return, the sysop could reactivate them all with the %RESUME command. d) Forwarding Remote Requests If a conference manager receives a remote request to delete an area, it could very easily "forward" that request to all its downlinks by producing a similar request. In that way, a single request originating from, for example, a Region Coordinator, would result in the conference being deleted from all systems "below" him. Similarly, remote requests for conference name changes could also be passed on to downlinks. e) Automatic Requests for Conferences A conference manager should also be able to automatically request an area from an uplink. This would become necessary if, for example, it processed a request for an area not currently available on the system. In this case, it would scan a series of conference lists for the requested area, and if found, would send a request for that area. In order to be able to do this, the ConfMgr would need to have one or more lists of conferences from the uplinks. These lists could be produced on request by the ConfMgr itself. In order to simplify matters, a binary format is proposed. (Note that these are C-style structures, with everything which that implies.) This binary file is called a Binary Conference List (BCL). The file starts with a header, containing some basic system information: struct bcl_header { char FingerPrint[4]; /* BCL */ char ConfMgrName[31]; /* Name of "ConfMgr" */ FIDONEWS 14-15 Page 9 14 Apr 1997 char Origin[51]; /* Originating network addr */ long CreationTime; /* UNIX-timestamp when created */ long flags; /* Options, see below */ char Reserved[256]; /* Reserved data */ } The currently defined flags for the header are: BCLH_ISLIST 0x00000001L File is complete list BCLH_ISUPDATE 0x00000002L File contains update/diff information The BCL would then contain a series of entries having the following format: struct bcl { int EntryLength; /* Length of entry data */ long flags1, flags2; /* Conference flags */ char *AreaTag; /* Area tag [51] */ char *Description; /* Description [51] */ char *Administrator; /* Administrator or contact [51] */ } The flags currently defined are: FLG1_READONLY 0x00000001L Read only, software must not allow users to enter mail. FLG1_PRIVATE 0x00000002L Private attribute of messages is honored. FLG1_FILECONF 0x00000004L File conference. FLG1_MAILCONF 0x00000008L Mail conference. FLG1_REMOVE 0x00000010L Remove specified conference from list (otherwise add/upd). Thus, instead of scanning an AREAS.BBS style list, the ConfMgr would parse and use lists in the above format. Naturally, each list would be in some way "attached" to a node number, and a corresponding ConfMgr password. Each system may only have one master file, called anything they want. But when transmitted to other systems, this file must always be named ????????.BCL. The list would be generated in response to a FIDONEWS 14-15 Page 10 14 Apr 1997 %LIST, B command in the message text. f) Receipts It might be useful to have the ConfMgr generate a receipt to be sent to another system, perhaps a co-sysop or a sysop point node. This could be done with the command: %RECEIPT ,
embedded in the request message. For example: %RECEIPT JoHo,2:270/17 9 Comments in the request It should be possible for a sysop to insert a comment in the request made to a conference manager. These comments, naturally, would be destined to the sysop of the system, and not to the conference manager itself. Such comments should be placed at the end of the message, following a %NOTE command. In all cases except the above, the request can be deleted by the ConfMgr once processed, but messages containing comments should be retained. Note: the current method used is to supply comments after a tear-line. This practice is somewhat "messy", but it might be wise to support it until such time as all conference managers have implemented the %NOTE command. 10 Summary +CONFNAME[,R|S] Request to link to CONFNAME -CONFNAME Request to unlink from CONFNAME =CONFNAME,R|S Rescan or "sample" linked conference &CONFNAME Request to create CONFNAME ~CONFNAME Request to delete CONFNAME #OLD NEW Name change request %LIST[,B] List available areas, flag linked %QUERY Only list linked areas %UNLINKED List available but unlinked areas %HELP Send help text %FROM Simulate request from another system %RESCAN Rescan conferences linked in current request %COMPRESS Change compression method %PWD Change ConfMgr password %PAUSE Suspend link %RESUME Resume link %RECEIPT , Send copy of receipt to another system %NOTE Introduces comment to the sysop FIDONEWS 14-15 Page 11 14 Apr 1997 11 Final Note This document is to be considered as a suggestion for software developers to make their programs compatible with one another, so as to make life easier for the average sysop when dealing with conference managers. Feedback would be appreciated and can be sent to us at the addresses specified on the title page. Please send feedback via netmail only. -30- ----------------------------------------------------------------- Document: FSC-0058 Version: 002 Date: 01-Nov-1992 A New Way Of Addressing In FidoNet(r) Wim Van Sebroeck & Jan Spooren November 1st, 1992 This document replaces the now obsolete version 001 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 trademarks of Tom Jennings and Fido Software. A. Why a new Proposal : ------------------------ FidoNet has grown from a few single BBSs to a worldwide network of nodes. Because of that enormous growth, we have several kludge-lines just to write to someone else. And for every extra dimension a new kludge is necessary. (3D: ^AINTL ; 4D: ^AFMPT, ^ATOPT ; 5D: ^ADOMAIN). Every time a new dimension or addressing-system is invented, not only the packer/router software needs to be adjusted, but also the message editor and a whole series of other utilities, being virtually the whole FidoNet software. This is why we made this proposal: 1) to make life easier for programmers and developers. 2) to have a system that will have no problems with further backward- compatibility. (from this system on) 3) to have a system that is simple (in usage). 4) and to have a system that accepts every possible address. FIDONEWS 14-15 Page 12 14 Apr 1997 B. Proposal : -------------- To send a message one needs two things: the origin address and the destination address. (And for routing inter-domain messages you also need the address of the gateway). Until now, we needed four different kludge-lines when we wanted to send a message to another domain (^ADOMAIN, ^AINTL, ^AFMPT, ^ATOPT). To minimize these kludges we suggest the following: ^ADEST ^AORIG ^AROUTE These kludges are *not* followed by a colon (':'). 1) The ^ADEST kludge: this kludge contains the address where the message has to be sent to. In other words: it contains the destination address. is an ASCII string that may contain any readable character, (above and including 32 (space) and below ASCII 128), and is only terminated by the end-CR of the kludge-line. It is up to the mailprocessors of every domain (FidoNet compatible or not) if they regard the address as case- sensitive or not. The FORMAT of is :
[@] Where
is the valid username/address in the network , and cannot have any '@' of '/'-characters in it, while
can. The reason why '/' characters are not allowed in the -field, is because they are necessary to recognize a FidoNet-style address, since is optional for messages that won't be crossing domain- borders. (*) In other words: The domain is always the string behind the last @ sign in the field, except when domain would contain a '/'-character. In that case, is the default domain, and
is the complete string behind the DEST-kludge. Concerning FidoNet-compatible addresses, there are some extra rules, since FidoNet is one of these rare networks that haven't got the username in the address. A valid FidoNet
is made up like this: @ Where @ is mandatory and is a valid fidonet address. The FidoNet-address must contain at least the zone:net/node number. Point number is optional. Eg.: ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org will generate an outbound message for user 'Wim Van Sebroeck' at Fido-node 2:292/862.0 within FidoNet. The domain name for FidoNet FIDONEWS 14-15 Page 13 14 Apr 1997 is 'FidoNet.Org', and *not* just Fido, or FidoNet or whatever. This is not a waste of space, since the domain name can be omitted when the message remains in the default network. Only for messages crossing domain borders, the domain name is necessary. We opted for the '.org' and '.ftn' suffixes, in order to make interfacing to InterNet easier. Some more addressing-examples: ^ADEST Jan Spooren@2:292/852.0@Fidonet.Org ^ADEST 292/862-cosysops@2:292/850 ^ADEST TE880714%BANUFS11@BITNET ^ADEST Jack@OS/2.dev.itnet@itnet ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp The first example should be clear, since it will be the most frequently used addressing-style. The 4th example shows the kludge for a message to the address 'Jack@OS/2.dev.itnet', within domain 'itnet'. There is no problem whatsoever with the '/' character, because it is part of the
, and not of the . In the last example, the message has to be sent to the uucp- gateway, wich will send it on within the internet-network, with the destination-address: 'm2xenix!uunet!BANUFS.11BITNET!TE880714' Also this is a valid address: ^ADEST Wim Van Sebroeck@2:292/862.0@FidoNet.Org@SIGnet.ftn The message will be sent to 2:292/862.0@FidoNet.Org, within SIGnet.ftn. SIGnet will then send the message back to 2:292/862.0 in FidoNet. The message will cross the domain-borders twice. Apart from the fact that it may seem an annoying practice, technically the address is 100% OK. Information in the DEST-kludge will always override information in the FTS-0001 message header. FOOTNOTE: (*) For a proper understanding of this '/'-restriction, let's illustrate this by means of an example. If we send a message with a kludge like this: ^ADEST Wim Van Sebroeck@2:292/862 Then the mailprocessor could wrongly interpret the : It could decide the
to be 'Wim Van Sebroeck' in '2:292/862'. But with the '/'-restriction it is now clear that the address is 'Wim Van Sebroeck@2:292/862' in the default domain. 2) The ^AORIG kludge: this kludge contains the origin address. has the same restrictions as the . For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org FIDONEWS 14-15 Page 14 14 Apr 1997 or: ^AORIG Infomag.Dev@ITNet 3) The ^AROUTE kludge: this is needed to point to the gateway address, when sending a message to another domain. Since not all gateways are listed in the nodelist and because possibly not all intermediate systems are aware of a particular domain-name, it is necessary to add the address of the gateway. The gateway is a system within the default domain, that can send the message to the desired domain. The kludge can also be used, however, to point to a zonegate between different zones in one domain. In any case, for every domain-border that will be crossed, there needs to be one ROUTE-kludge to indicate the gateway. It should be obvious, that a FidoNet-address in a ROUTE-kludge never carries a username. The ROUTE-kludge always overrides the DEST-kludge. A system receiving a message should ALWAYS send the message to the address specified by the ROUTE-kludge, and NOT to the destination address. In other words, the ROUTE-kludge is not to be interpreted as a hint to a possible gateway, but must be regarded as a new destination address, and the message will always have to reach the gateway. The gateway will then change the ^AROUTE to a ^AROUTD kludge, in order to indicate that the gateway received the message, and to see to it that the message won't travel back to the gateway. This absolute priority of the ROUTE-kludge above the DEST-kludge is necessary, since otherwise messages could be bouncing between two nodes that both prefer different gateways to send the message to. The ROUTE- kludge also has nothing to do with the actual routing itself. The ROUTE-kludge only defines an intermediate address that has to be reached before the message reaches its final destination. How the message gets to this intermediate address doesn't matter: it may be direct or it may be routed through other systems. Remember that FidoNet is an amateur network, with each system paying its own phone bills! For example: ^AORIG Wim Van Sebroeck@2:292/862.0@Fidonet.Org ^AROUTE 1:105/42.0@Fidonet.Org ^ADEST m2xenix!uunet!BANUFS11.BITNET!TE880714@uucp C. Advantages and Disadvantages : --------------------------------- a) Advantages: - The main advantage is that one only needs two kludges to specify the origin and the destination address. (And that these kludges are always in a message). - The system is also very flexible because any address is possible. - Utilities must not be updated when a new address-dimension is created. - Inter-domain and inter-network messages are finally possible. - No limits are placed on both username and address-field length. - Perfect compatibility is ensured with future message and packet formats that will override FTS-0001. b) Disadvantages: - Please be so kind to write them to us. We can't figure what FIDONEWS 14-15 Page 15 14 Apr 1997 they could be? D. Implementation Notes : -------------------------- D.1. Processing an outgoing message. .-----+----------+-------------------------+------------------------- +-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------- -----+-----| | O1 | MsgFound | Find DEST/ROUTE | 1 Found fsc-58 kludge | O2 | | | | kludges in message | 2 Fsc-58 kludge not fnd | S8 | | | | | 3 Error occured | exit| | | | | 4 Dest is 1 of our AKAs | exit| |-----+----------+-------------------------+-------------------- -----+-----| | O2 | ReadKldg | | Take only 1st ROUTE and | O3 | | | | | 1st DEST-kludge | | |-----+----------+-------------------------+------------------------ -+-----| | O3 | ChkROUTE | Is there a ROUTE kludge | 1 Route kludge found | O4 | | | | | 2 No route kludge | O10 | |-----+----------+-------------------------+-------------------- -----+-----| | O4 | WeRoute? | Is ROUTE one of our | 1 Yes | O5 | | | | AKA's | 2 No | O9 | |-----+----------+-------------------------+-------------------- -----+-----| | O5 | DsblROUT | | Change ROUTE into ROUTD | O6 | | | | | and strip 'TOPT' and | | | | | | 'INTL'-kludges to our | | | | | | system. | | |-----+----------+-------------------------+------------------------ -+-----| | O6 | WeGate? | Are we a gateway to | 1 Yes | O7 | | | | another domain? | 2 No | O2 | |-----+----------+-------------------------+-------------------- -----+-----| | O7 | Needgate | Get next ROUTE/DEST-kldg| 1 Yes | O8 | | | | Is it another domain? | 2 No | O3 | |-----+----------+-------------------------+-------------------- FIDONEWS 14-15 Page 16 14 Apr 1997 -----+-----| | O8 | Gateway | | Do gatewaying-stuff | exit| | | | | Don't forget to strip | | | | | | @ from the | | | | | | | | |-----+----------+-------------------------+------------------------ -+-----| | O9 | SndROUTE | | SendMsg to ROUTE | S1 | | | | | (Temp. Dest = ROUTE) | | |-----+----------+-------------------------+------------------------ -+-----| | O10 | SndDEST | | SendMsg to DEST | S1 | | | | | (Temp. Dest = DEST) | | `-----+----------+-------------------------+------------------------ -+-----' D.2. Sending of an outgoing message SendMsg(Temporary_destination) .-----+----------+-------------------------+------------------------- +-----. |State| State | Predicate(s) | Action(s) | Next| | # | Name | | | St | |-----+----------+-------------------------+-------------------- -----+-----| | S1 | Looktabl | | Find node to route to | S2 | | | | | according to own routng | | | | | | scheme and msg-attribs. | | |-----+----------+-------------------------+------------------------ -+-----| | S2 | IsFsc58 | Lookup in table if node | 1 No, not fsc-58 compl. | S3 | | | | is fsc-58 compliant | 2 YES! Fsc-58 compliant | S8 | |-----+----------+-------------------------+-------------------- -----+-----| | S3 | FMPT | Has ORIG-kludge point# | 1 No | S4 | | | | | 2 Yes: Insert FMPT-kldg | | | | | | if not already present| | |-----+----------+-------------------------+------------------------ -+-----| | S4 | TOPT | Contains | 1 No | S5 | | | | temporary_destination | 2 Yes: Insert TOPT-kldg | | | | | a point-address ? | if not already present| FIDONEWS 14-15 Page 17 14 Apr 1997 | |-----+----------+-------------------------+------------------------ -+-----| | S5 | INTL | Compare ORIG and | 1 Zones equal | S6 | | | | temporary_destination | 2 Not eq. : Make INTL-k | | | | | | if not already present| | |-----+----------+-------------------------+------------------------ -+-----| | S6 | DOMAIN | Compare ORIG and | 1 Domains equal | S7 | | | | temporary_destination | 2 Not eq. : Domain-kldg | | | | | | if not already present| | |-----+----------+-------------------------+------------------------ -+-----| | S7 | Usernames| | Fill in FTS-1 dest and | S8 | | | | | orig usernames, accord. | | | | | | to ORIG and DEST except | | | | | | when ORIG/D names blank | | |-----+----------+-------------------------+------------------------ -+-----| | S8 | XportMsg | | Export message | Exit| `-----+----------+-------------------------+-------------------- -----+-----' D.3. Processing an incoming message: .-----+----------+-------------------------+------------------------- +-----. | I1 | ChkKldg | Find DEST/ROUTE/ORIG | If found: store kludges | I2 | | | | kludges in message | | | |-----+----------+-------------------------+------------------------ -+-----| | I2 | ChkFSC58 | Are DEST/ROUTE/ORIG | 1 Yes, fsc-58 compliant | I3 | | | | Kludges available? | 2 No, not fsc-58 compl. | I4 | |-----+----------+-------------------------+-------------------- -----+-----| | I3 | ChkTable | Is originator of packet | If not in lookup-table | I4 | | | | in lookup-table? ^^^^^^ | and should be, then | | | | | ( SEE SECTION E !) | add node to the table | | |-----+----------+-------------------------+------------------------ -+-----| | I4 | ChkDEST | Is message to us? | 1 Yes: store message | exit| | | | (Are we DEST?) | 2 No | I5 | |-----+----------+-------------------------+-------------------- -----+-----| | I5 | KeepTrans| Do we keep a copy of in-| 1 Yes: Store msg and -->| FIDONEWS 14-15 Page 18 14 Apr 1997 O1 | | | | transit mail ? :-( | 2 No: | O1 | `-----+----------+-------------------------+-------------------- -----+-----' E. Discussion of the Implementation Notes. ------------------------------------------ * O5, "DsblROUT" : It is clear that when a message travels through an intermediate system which is mentioned in a ROUTE-kludge, this ROUTE-kludge will have to be removed, because the message did arrive at this system. Instead of just deleting the whole kludge-line, the kludge will be changed in ROUTD. This is a much easier and faster process for a mailprocessor and it enables the recipient of the message to have some information about the route the message took. Because there is no FTS-0001 equivalent to the route-kludge, a system that is in a route-kludge needs to be FSC-0058 compliant. The intermediate systems to this ROUTE-system need not to be FSC- 0058 compliant: Our implementation notes assume a list of fsc-0058 compliant nodes (the 'lookup table'), that is continuously updated, when messages arrive from fsc-0058 systems. When a message is to be send on to a non-fsc-0058 system, the message will be converted to the old FTS-0001 format, including FMPT-, TOPT- and INTL-kludges. The destination-address in this (converted) message will then be the address of the first ROUTE-kludge. There is one tricky point: When such a message arrives at this ROUTE-system, the message can have TOPT (if the system is a pointsystem) and INTL kludges in the messagebody, due to the conversion to the FTS-0001 format. The ROUTE-system's mailprocessor will have to find these and strip them from the message. * S3 -> S7 : These stages perform the conversion to FTS-0001 format, in case the next receiving system will be non-fsc-0058 compliant. * I3, "ChkTable" : Care must be exercized: If we find FTS-0058 information in a message we don't know if the last system, or any of the previous systems the message passed is fsc-0058 compliant. We can only know for sure when the message was sent directly to us. That is (in FidoNet packet type 2) when the packet-orig address is the same as the message orig-address, or when the packet-orig address is the same as the last routd-kludge address. We are aware of the fact that the lookup-table won't be filled fast this way. But we don't want that: We only have to know if our 'surrounding' nodes, i.e., the nodes with which we have frequent connections, support fsc-0058. We also want to know if gateway systems are fsc-0058 compliant, because we have to put them in a ROUTE-kludge. But these should be just a few systems and the fact FIDONEWS 14-15 Page 19 14 Apr 1997 of their fsc-0058 compliance will be known easily. They can then be added manually. We do not even dare to suggest the use of a nodelist-flag, that could simplify this whole system of investigating the fsc-0058 compliance, in order to downgrade to the FTS-0001 level for non- compliant systems. F. Questions : --------------- Questions can always be sent to: Jan Spooren 2:292/852.0@Fidonet.Org Wim Van Sebroeck 2:292/862.0@Fidonet.Org --- End Of Proposal --- -30- ----------------------------------------------------------------- FIDONEWS 14-15 Page 20 14 Apr 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 101 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-073|Nodelist-080|Nodelist-087|Nodelist-094|Nodelist-101|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 9107| 9088 -19 | 9088 0 | 8900 -188 | 8837 -63 |32| | 2 | 15996|15956 -40 |15923 -33 |15922 -1 |15902 -20 |58| | 3 | 800| 800 0 | 800 0 | 800 0 | 800 0 | 3| | 4 | 547| 548 1 | 548 0 | 549 1 | 548 -1 | 2| | 5 | 87| 87 0 | 87 0 | 87 0 | 87 0 | 0| | 6 | 1088| 1088 0 | 1090 2 | 1090 0 | 1083 -7 | 4| +----+------+------------+------------+------------+------------+--+ | 27625|27567 -58 |27536 -31 |27348 -188 |27257 -91 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-15 Page 21 14 Apr 1997 ================================================================= NOTICES ================================================================= Future History 17 May 1997 Independence Day, Norway. 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. 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-15 Page 22 14 Apr 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= [reprinted from FidoNews 1414] Ed. Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 Well, I'm catching back up. Still waiting to hear about Gecho, though. Note: At the end of April, I'll be phasing out the old Macintosh 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 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 FIDONEWS 14-15 Page 23 14 Apr 1997 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.8 N G Michiel vd Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP QuickBBS 2.81 B S Ben Schollnick 1:2613/477 QUICKBBS RAR 2.00 C S Ron Dwight 2:220/22 RAR RemoteAccess 2.50 B S Mark Lewis 1:3634/12 RA Silver Xpress Door 5.4 O S Gary Petersen 1:290/111 FILES Reader 4.4 O S Gary Petersen 1:290/111 SXR44.ZIP Spitfire 3.51 B S Mike Weaver 1:3670/3 SPITFIRE Squish 1.11 T P Tech 1:249/106 SQUISH StealTag UK 1.c... O F Fred Schenk 2:284/412 STEAL_UK StealTag NL 1.c... O F Fred Schenk 2:284/412 STEAL_NL T-Mail 2.599I M S Ron Dwight 2:220/22 TMAIL Terminate 4.00 O S Bo Bendtsen 2:254/261 TERMINATE Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK TriBBS 11.0 B S Gary Price 1:3607/26 TRIBBS TriDog 11.0 T F Gary Price 1:3607/26 TRIDOG TriToss 11.0 T S Gary Price 1:3607/26 TRITOSS WaterGate 0.92 G S Robert Szarka 1:320/42 WTRGATE WWIV 4.24a B S Craig Dooley 1:376/126 WWIV WWIVTOSS 1.36 T S Craig Dooley 1:376/126 WWIVTOSS xMail 2.00 T S Thorsten Franke 2:2448/53 XMAIL XRobot 3.01 O S JoHo 2:201/330 XRDOS OS/2: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- ALLFIX/2 1.10 T S Harald Harms 2:281/415 AFIXOS2 BGFAX 1.60 O S B.J. Guillot 1:106/400 BGFAX Binkley Docs 2.60 M F Bob Juge 1:1/102 BDOC_260.ZIP BinkleyTerm 2.60 M F Bob Juge 1:1/102 BOS2_260.ZIP BinkleyTerm-XE XR4 M F Thomas Waldmann 2:2474/400 BTXE_OS2 CFRoute 0.92 O G C. Fernandez Sanz 2:341/70 CFR FIDONEWS 14-15 Page 24 14 Apr 1997 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 ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX ifmail-tx.rpm ...tx8.1 M G Pablo Saratxaga 2:293/2219 IFMAILTX.RPM Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK Amiga: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- CrashMail 1.23 T X Fredrik Bennison 2:205/324 CRASHMAIL CrashTick 1.1 O F Fredrik Bennison 2:205/324 CRASHTICK DLG Pro BBOS 1.15 B C Holly Sullivan 1:202/720 DLGDEMO GMS 1.1.85 M S Mirko Viviani 2:331/213 GMS Msged 4.00 O G Paul Edwards 3:711/934 MSGED Tobruk 0.33 T G Paul Edwards 3:711/934 TOBRUK FIDONEWS 14-15 Page 25 14 Apr 1997 TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPDOOR TrapDoor 1.86.b2 M S Maximilian Hantsch 2:310/6 TRAPBETA TrapToss 1.50 T S Rene Hexel 2:310/6 TRAPTOSS Atari: Program Name Version F C Contact Name Node Magic Name ---------------------------------------------------------------------- BinkleyTerm/ST 3.18pl1 M F Bill Scull 1:363/112 BINKLEY Semper 0.80beta M S Jan Kriesten 2:2490/1624 SMP-BETA Function: B-BBS, P-Point, M-Mailer, N-Nodelist, G-Gateway, T-Tosser, C-Compression, F-Fossil, O-Other. Note: Multifunction will be listed by the first match. Cost: P-Free for personal use, F-Freeware, S-Shareware, C-Commercial, X-Crippleware, D-Demoware, G-Free w/ Source Old info from: 01/27/92 --------------------------------------------------------------------- MS-DOS Systems Other Utilities Other Utilities -------------- Name Version Name Version -------------------- -------------------- Network Mailers 2DAPoint 1.50* Netsex 2.00b Name Version 4Dog/4DMatrix 1.18 OFFLINE 1.35 -------------------- ARCAsim 2.31 Oliver 1.0a D'Bridge 1.30 ARCmail 3.00* OSIRIS CBIS 3.02 Dreamer 1.06 Areafix 1.20 PKInsert 7.10 Dutchie 2.90c ConfMail 4.00 PolyXarc 2.1a Milqtoast 1.00 Crossnet 1.5 QM 1.00a PreNM 1.48 DOMAIN 1.42 QSort 4.04 SEAdog 4.60 DEMM 1.06 RAD Plus 2.11 SEAmail 1.01 DGMM 1.06 Raid 1.00 TIMS 1.0(mod8) DOMAIN 1.42 RBBSMail 18.0 EEngine 0.32 ScanToss 1.28 Compression EMM 2.11* ScMail 1.00 Utilities EZPoint 2.1 ScEdit 1.12 Name Version FGroup 1.00 Sirius 1.0x -------------------- FidoPCB 1.0s@ SLMail 2.15C ARC 7.12 FNPGate 2.70 StarLink 1.01 ARJ 2.20 GateWorks 3.06e TagMail 2.41 LHA 2.13 GMail 2.05 TCOMMail 2.2 PAK 2.51 GMD 3.10 Telemail 1.5* PKPak 3.61 GMM 1.21 TGroup 1.13 PKZip 1.10 GROUP 2.23 TIRES 3.11 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 FIDONEWS 14-15 Page 26 14 Apr 1997 Prune 1.40 MSG 4.5* XRS 4.99 SysNL 3.14 MsgLnk 1.0c XST 2.3e XlatList 2.90 MsgMstr 2.03a YUPPIE! 2.00 XlaxNode/Diff 2.53 MsgNum 4.16d ZmailH 1.25 MSGTOSS 1.3 ZSX 2.40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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-15 Page 27 14 Apr 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-15 Page 28 14 Apr 1997 ================================================================= FIDONET BY INTERNET ================================================================= This is a list of all FidoNet-related sites reported to the Editor as of this appearance. ============ FidoNet: Homepage http://www.fidonet.org FidoNews http://ddi.digital.net/~cbaker84/fidonews.html HTML FNews http://www.geocities.com/Athens/6894/ WWW sources http://www.scms.rgu.ac.uk/students/cs_yr94/lk/fido.html FTSC page http://www2.blaze.net.au/ftsc.html Echomail http://www.portal.ca/~awalker/index.html WebRing http://ddi.digital.net/~cbaker84/fnetring.html ============ Zone 1: http://www.z1.fidonet.org Region 10: http://www.psnw.com/~net205/region10.html Region 11: http://oeonline.com/~garyg/region11/ Region 14: http://www.netins.net/showcase/fidonet/ Region 15: http://www.smrtsys.com/region15/ Region 16: http://www.tiac.net/users/satins/region16.htm Region 17: http://www.portal.ca/~awalker/region17.htm Region 18: http://www.citicom.com/fido.html Region 19: http://home1.gte.net/bhamilt/index.htm ============ Zone 2: http://www.z2.fidonet.org ZEC2: http://fidoftp.paralex.co.uk/zec.htm Zone 2 Elist: http://www.fidonet.ch/z2_elist/z2_elist.htm Region 20: http://www.fidonet.pp.se (in Swedish) Region 24: http://www.swb.de/personal/flop/gatebau.html (in German) Region 25: http://members.aol.com/Net254/ Region 27: http://telematique.org/ft/r27.htm Region 29: http://www.rtfm.be/fidonet/ (in French) FIDONEWS 14-15 Page 29 14 Apr 1997 Region 30: http://www.fidonet.ch (in Swiss) Region 34: http://www.pobox.com/cnb/r34.htm (in Spanish) REC34: http://pobox.com/~chr Region 36: http://www.geocities.com/SiliconValley/7207/ Region 41: http://www.fidonet.gr (in Greek and English) Region 48: http://www.fidonet.org.pl ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: (not yet listed) Region 90: Net 904: http://members.tripod.com/~net904 (in Spanish) ============ Zone 5: (not yet listed) ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-15 Page 30 14 Apr 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-15 Page 31 14 Apr 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-15 Page 32 14 Apr 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- -----------------------------------------------------------------