F I D O N E W S -- Volume 14, Number 4 27 January 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. | +----------------------------------------------------------------------+ HAPPY BIRTHDAY PERI HORNER! Table of Contents 1. EDITORIAL ................................................ 1 SuperBowl edition? ....................................... 1 2. ARTICLES ................................................. 2 The PALMTOPS Echo ........................................ 2 3. GETTING TECHNICAL ........................................ 3 FSC-0024 - Proposal for a Type-3 Mail Bundle ............. 3 FSC-0025 - AVATAR information ............................ 16 4. COORDINATORS CORNER ...................................... 23 Nodelist-statistics as seen from Zone-2 for day 024 ...... 23 5. WE GET EMAIL ............................................. 24 ACLU Cyber-Liberties Update .............................. 24 6. NET HUMOR ................................................ 29 Geekonics - the next step? ............................... 29 7. WANTED ................................................... 32 Looking for Mr. Surveyed equipment? ...................... 32 8. NOTICES .................................................. 33 Future History ........................................... 33 Update on the WebRing status for FidoNet World Wide Web .. 34 9. FIDONET SOFTWARE LISTING ................................. 36 Latest Greatest Software Versions ........................ 36 10. FIDONEWS PUBLIC-KEY ..................................... 43 FidoNews PGP public-key listing .......................... 43 11. FIDONET BY INTERNET ..................................... 44 12. FIDONEWS INFORMATION .................................... 46 FIDONEWS 14-04 Page 1 27 Jan 1997 ================================================================= EDITORIAL ================================================================= Just a little bit early in compilation so I can watch those Packers do unto the Patriots what they did unto my Jaguars! [snicker] [Football for your non-Zone 1 folks.] The WebRing server is still in transition. Those of you still trying to link your webpages to the FidoNet webring please note the notice at the end of this Issue. I will advise all when they get it back up. I got an inquiry from a fellow in Denmark [who seems to have written a FidoNet to Internet mail/file handling utility for Windows95] about writing an article for FidoNews detailing his invention. I told him to go ahead and send me one. In the meantime, if you want to look at his effort [it's 19 pounds sterling], his site is at: http://www.terminate.com/fido2int.htm Other than those, it's been a slow week here at FidoNews. Still no new ASCII art or .BIOs. [sigh] Go Packers! [grin] C.B. ----------------------------------------------------------------- FIDONEWS 14-04 Page 2 27 Jan 1997 ================================================================= ARTICLES ================================================================= The PALMTOPS ECHO by Jim Henry, 1:273/408, jim@airgunhq.com The PALMTOPS echo is a new echo I started for users of various Palmtop computers, such as but not limited the HP 100LX and HP 200LX. What IS a Palmtop? More than just an electronic organizer, a Palmtop is a real PC no larger than a video cassette, and most are considerably smaller. The HP Palmtops fit easily into a shirt pocket and are loaded with built in software, such as Lotus 1-2-3, an appt. scheduler, phone book, word processor, telecommunications, scientific calculator, Quicken, and more. Then you can add even more software depending on what your needs are. Among the other software I have added, is a ballistics program I can use at the range, and 1ST Reader, the combination terminal program and Qwkmail reader from Sparkware. Using 1st Reader on my Palmtop, I have been able to reclaim what other-wise would be lost or un-productive time. I can catch up on my email when stuck in the waiting room at my car dealer, or doctor's office. Beats the heck out of reading 6 month old magazines! Waiting in the car to pick up my kids after school is another opportunity to read and reply to mail on my Palmtop. The PALMTOPS echo is not yet on the backbone, but please do join us and help make it happen. Pick up a feed from me at 1:273/408, or Jim Balcom at 1:109/334. One final warning: Palmtops are addictive! ----------------------------------------------------------------- FIDONEWS 14-04 Page 3 27 Jan 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of a continuing project of re-publishing all the FidoNet Technical Standards and Proposals in numerical order. It is also part of the FidoNet History series begun by this Editor. Documents have been reformatted to the 70 column limit where required and some tables may be distorted as a result. Anyone wishing unmodified forms should file-request the actual file.] Ed. FSC-0024 - A Proposal for a Type-3 Mail Bundle - Oliver McDonald Notes on Type three bundlers. The first important note is that without Wynn Wagner's work on FTSC-0014, none of this would have come to fruition. I owe him a great debt in this area, as well as the debt for Opus itself that got me into this. Thanks Wynn. Type 3 bundlers offer opportunities for new levels of sophistication in mail processing. As the first step Aurora Computer Technologies plans to provide the minimum specified by the existing Type 3 bundle specifications with one minor addition. This addition is the inclusion of the features of ReMapper. This addition is not a required inclusion for other software authors producing a Type 3 bundler. To sum up, standard required features are: Must be able to create and unbundle Type 2 Bundles (See FSC-0001) Must be able to create and unbundle Type 3 Bundles (See attached) Must be able to Toss EchoMail from either Type 2 OR 3 bundles Must generate an update-required message for the sysop if the MinorVersion changes. Must generate an update-required message if it encounters a misc packet type it does not recognize. Initial optional features are: May Duplicate the functionality of ReMapper. May automatically generate an F.Req. from source of bundle when the minor version changes. May generate an F.Req from source of bundle if it encounters a misc packet type it does not recognize. All error messages are placed in Matrix Mail messages to the Sysop. Will create outbound bundles on the fly from the inbound FIDONEWS 14-04 Page 4 27 Jan 1997 bundle. Does not need to scan these messages. Note, if this option is exercised it is IMPERATIVE that the areas are scanned prior to the unbundle process. Type 3.0 proposal (preliminary) This proposal allows for automatic updating of the Type 3 bundle to allow for further revisions and enhancements. Thus we will refer to it as a Type 3.0 with further versions becoming Type 3.1 etc. All multi-byte data forms (int/long) are considered to have the MSB first and the LSB last. Int is two bytes, and Long is four. Bundle Header struct _BundleHeader { struct _Address B_Destination; struct _Address B_Origination; unsigned nybble B_BundlerVersionMajor; unsigned nybble B_BundlerVersionMinor; unsigned byte B_ProductCode; unsigned byte B_VersionMinor; unsigned byte B_VersionMajor; unsigned long B_CreationTime; unsigned byte B_Password[8]; }; Bundle Header Notes This works out to 32 bytes which is a nice size to work with. Here follows a short explanation for each field: "B_BundlerVersionMajor/Minor" provide for version numbers from 0.0 to 16.16, this should be enough for all except TJ. "B_ProductCode" is the FTSC assigned product code. This can be used to identify just which type 3 bundler created the bundle; it should not be considered an error if this is unidentified, and need not be processed on unbundling but MUST be included _correctly_ at the bundling stage. "B_VersionMinor" is a version number that will initially start at Zero and is used to allow non backward compatible changes to Type 3 bundles, such as header length change. If this is LOWER in the bundle than the corresponding version number in the unbundler it should abend. It is suggested that a short message be written to the Sysop in NETMAIL with as much information gleaned from the header as possible. (All info up to and including "B_VersionMajor".) FIDONEWS 14-04 Page 5 27 Jan 1997 "B_VersionMajor", always 3. This and all data prior to this point is position dependant and will never be changed in future Type 3.0 bundle revisions. "B_CreationTime" is an Unix 1970 based creation time indicating the time/date the bundle was created. "B_Password" is a NULL padded character array that may contain uppercase alpha bytes or ASCII digits. It should not contain lowercase characters, punctuation, control characters etc. A maximum of 8 characters are significant. Struct _Address struct _Address { unsigned int Zone; unsigned int Net; unsigned int Node; unsigned int Point; }; struct _AddressShort { unsigned int Net; unsigned int Node; }; Bundle Footer Struct _BundleEnd { Unsigned Byte E_Packet_Type /* Always 0 * / }; Bundle Footer notes. All bundles end with this packet. It is not optional and the packet should be considered grundged if it is missing. Area header Struct _AreaHeader Unsigned byte E_Packet_Type /* Always 1 */ Unsigned byte E_NameLength /* Actual bytes in E_NAME */ Unsigned Byte E_Name[1] /* Variable length field */ Area Header Notes The area header packet marks the start of a sequence of messages destined to the same message area. The area indicated in the Area Header will remain valid until either the end of the bundle OR another Area Header is FIDONEWS 14-04 Page 6 27 Jan 1997 encountered. E_Name will usually contain the area name of the echo area that subsequent messages should go. If E_NameLength is zero then the subsequent messages should go the NetMail area. Any messages that occur prior to the first Area Header in a bundle should also go to the Netmail area. The Maximum value for E_NameLength is 63. E_Name is NOT null terminated. Message Header Struct _MessageHeader { Unsigned byte M_Packet_Type /* Always 2 */ Struct _Address M_Destination /* Final Destination */ Struct _Address M_Origin /* Where the message was entered */ Unsigned Long M_CreationTime /* When the message was entered */ Unsigned int M_Attributes /* FTSC bitweights */ Unsigned byte M_FromLength Unsigned byte M_ToLength Unsigned byte M_SubLength Unsigned byte M_From[1] Unsigned byte M_To[1] Unsigned byte M_Sub[1] }; Message Header Notes Every message begins with a message header packet. It should be created by the system where the message originated. If there are any intermediate stops along the way it is the responsibility of the intermediate systems along the way to maintain all of the information without modification. None of M_From, M_To, or M_Sub are to be NULL terminated. Message Body Struct _Text { Unsigned byte T_Packet_Type /* Always 3 */ Unsigned int T_ByteCount /* # of bytes ( < 0x1000 ) */ Unsigned byte T_Data[1] /* Variable length field */ Message Body Notes: FIDONEWS 14-04 Page 7 27 Jan 1997 The message body is considered one or more _Text packets. No _Text packet will be more that 1000H bytes long (that's 4096 to the terminally base 10 folks). Of course there may be a near infinite number of _Text packets per bundle/Message header, but you are absolutely positively guaranteed that with the type 3.x method you will never need a buffer larger than 1000H. In addition to ASCII values 20h through 7Eh (inclusive) the following control codes are legal for TEXT data. Note that and are NOT in this list, thus type three packers will eliminate spurious 0Dh's. 0Ah Forced / 10h Replicate Other control characters and values 7Fh and above are symptomatic of a grundged message. Replicate is a three byte sequence: . For example if a packet contains the bytes 10h, 20h, 09h it should be expanded in the message body as nine characters. There is no minimum or maximum line length, it is assumed that the reader can supply the appropriate line wraps. One "line" of a message may cross from one _Text packet to another. EchoMail: Struct _EchoMailInfo { Unsigned byte EI_Packet_Type /* Always 4 */ Struct _EID EI_Parent /* Up message thread */ Struct _EID EI_Child /* Down message thread */ Unsigned byte EI_SeenByCount Unsigned byte EI_PathCount Struct _AddressShort EI_SeenBy[1] Struct _Address EI_Path[1] ); EchoMail notes: The EI_Child and EI_Parent fields are used to reconstruct the message thread. Type 3 bundles uses binary seenby and path FIDONEWS 14-04 Page 8 27 Jan 1997 information, but should convert to a normal seenby/path in the unbundled messages. If the auto-rebundleing is used it is not necessary to process the seenby's into the unpacked messages. It is suggested that if this approach is used it is HEAVILY tested prior to implementation, and that it still store the data somewhere for retrieval in case of unresolved dupe problems. Cargo Info. Struct _PointInfo { Unsigned byte CI_Packet_Type /* always 05h */ Unsigned byte CI_File Count /* Number of files */ Unsigned byte CI_FileName[1] /* Filenames (10 bytes */ }; Cargo Info Notes The Cargo info packet will only be found in a Type 3 arcmail bundle that contains files. It will always be the always second packet in a bundle. Node info Struct _NodeInfo Unsigned byte NI_Packet_Type /* always 06h * / Unsigned int NI_Flags /* Flags for node */ }; This packet is sent to a Type 3.x node in the first bundle to be sent to that node. The bundler should detect that the node can accept a Type 3.x bundle from a nodelist flag. It will automatically generate this packet at that point. Should a type 3.x bundle come from a node that is not identified in the nodelist as type 3.x capable the bundler should mark that node as Type 3.x capable and generate a warning message. NI_Flags, is a bit mapped field that identifies the characteristics of the node. Some of this information will duplicate that information found in the nodelist. This is used as a check. Bit: Meaning: 0: Type 3 1: Packing Protocol Bits. 2: " " " 3: " " " 4: |Bits 3 & 4 are used together FIDONEWS 14-04 Page 9 27 Jan 1997 5: |to determine mail handleing. 6: Ingate 7: OutGate 8: Net Host 9: Net Hub A: B: C: D: E: Sent info F: Got Info Bits 1, 2, & 3 are used to determine how mail may be packed for this node (SEA, PKWare, ZOO) Bits 1 & 2 & 3: Meaning: 000: No packing. 001: SEA Archive format. 011: PKWare LZW packing format. 100: ZOO Compression system. Note that these bits were intended to be combined, so that if a node could handle ZOO and SEA Archives it would set the bits to '101'. Since by definition PKWare can handle SEA format Arc's it is considered standard to set both bits for a PKWare capable system. Bits 4 and 5 are used to determine how mail should be sent to this node (CM, hold, direct) Bit 4 & 5: Meaning: 00: Direct 01: Continous 11: Hold The sysop should be able to clear the sent info bit should the status of his system change (ie becomeing an NC). Zone gates may be identified by the fact that they are in Net 1 and they are both an ingate and an outgate. The zone they are the gate for is identified by their node number. MiscInfo (IFNA Kludge). Struct _MiscInfo { Unsigned byte MI_Packet_Type /* Always 06h -FFh, assigned by FTSC */ Unsigned byte MI_ByteCount /* # of bytes of miscinfo */ Unsigned Byte MI_WhoKnows[1] /* Misc Stuff */ }; MiscInfo Notes: FIDONEWS 14-04 Page 10 27 Jan 1997 The Misc info packet(s) are the last packets associated with a message, there may be more than one in extreme circumstances, but this should prove to be unlikely. The bundler must retain any information in these packets unchanged if it is a routed message. This is a catch all packet that replaces the dreaded IFNA kludge. It is designed to only be used as an interim method. At present all IFNA kludges are handled in other special purpose packets, it is foreseen that any further kludges will be handled only by miscinfo packets until the Type 3.x bundle specification can be updated and coded to handle the new data. MiscInfo packets in the range 80h - F0h should be preserved if not understood. It should be considered an error condition to find a MiscInfo packet with in the range 04h - 7Fh, this range is reserved for future expansions on Type 3 packets. Packets in the range F1h - FFh should be unpacked AND a warning message should be generated. These numbers will be used on an extremely temporary basis as they are designed for ESSENTIAL IFNA kludges and will be added into the Type 3.x specification as quickly as possible. Arcmail and Type 3.x Type 3.x bundlers support arcmail much the same way that the type 2 bundlers do. There are some enhancements in the arcmail naming scheme however, that help reduce system overhead for routed mail. For arcmail destined for type 2 based systems the old reliable method of arcmail file naming will be used, IE: NNNNnnnn.ww# Where NNNN is a four hex digit net number, nnnn is a four hex digit node number, ww is a two character weekday-name identifier, and # is the packet number for that day. Type 3.x packers SHOULD generate the day name correctly rather than the OMMM 1.08 cyclic method. Here follows a suggested Type 3.x ArcMail naming scheme, basically a modification of Roeland Meyer's original proposal. I have been made aware that Roeland has some things to say on this, but there seems to be a communications break between us, so until I can contact him I will stick with this. For Arcmail destined to a Type 3.x system (with Type 3.x bundles internally), a variation of the method first proposed by Roeland Meyer will be used. Here follows a quick synopsis: FIDONEWS 14-04 Page 11 27 Jan 1997 New address specifier (Re-edited by Oliver McDonald) This is designed for the Type 3.0 Arcmail naming convention of: ZZNNNOOO.Fxx | | | || | | | |`----> Incremental sequence number, base 10, max = 99d | | | | Starts at 00 and counts to '99' then wraps | | | | back to 00. No "Day-of-week" info. | | | | This is strictly to avoid bundle collisions. | | | | An 'empty' version of the bundle is kept | | | | around to help the router remember what the | | | | last sequence number was. | | | | | | | `-----> Flag to indicate bundle type | | | Allowed values: | | | 'All non-specified flags are reserved. | | | 'U' - ZOO File bundle | | | 'V' - ZOO Mail only bundle for a Point. | | | 'W' - ZOO Mail only bundle | | | 'X' - File bundle | | | 'Y' - Mail only bundle for a point. | | | 'Z' - Mail only bundle | | | For files with the 'Y' flag it is | | | sent as per normal until it reaches the | | | node specified by the arcname. At this | | | point the node will unarc the FIRST bundle | | | in the arc, and read the Message Header, | | | and then attach the bundle to the point | | | specified. | | | For File bundles if the files are to be | | | forwarded, the node will unarc the bundle | | | in the arc. It will check the message header | | | for address (match against name), and will open | | | the Cargo Info Bundle, and attach those files | | | to the destination. | | | Note: If the addresses do not match it considered FIDONEWS 14-04 Page 12 27 Jan 1997 | | | an error to forward the files. | | | Note: The point address is not considered for | | | matching purposes. | | | | | `--------> Node address, base 36, max = 56,654d | | Allowed values: '000' to 'ZZZ' | | This is the Node part of the destination | | address of the bundle. | | Special values: | | '000'- Destination is the Net Host given by | | ZNNN, not forwarded to any Nodes. | | 'ZZZ'- This a broadcast bundle to ALL Nodes | | in the Net given by ZNNN, as | | well as, the Net Host given by same. | | | `-----------> Net address, base 36, max = 55,654d | Allowed values: '000' to 'ZZZ' | This is the Net part of the destination | address of the bundle. | Special values: | '000' - Destination is the ZoneGate given by | ZZ, not forwarded to any Nets. | 'ZZZ' - This a broadcast bundle to ALL Nets | in the Zone given by ZZ, as well as, | the ZoneGate given by same. | `--------------> Zone address, base 36, max = 1,294d Allowed values: '00' to 'ZZ' This is the Zone part of the destination address of the bundle. Special values: '00' - Destination is the current ZoneGate. 'ZZ' - This a broadcast bundle to ALL ZoneGates given by the NodeList, as well as, the ZoneGate given by same. Note, Point numbers are specifically NOT included in the file name identifier. There were a couple of reasons for this; first, we wanted to allow the maximum range of Zone:Net/Node numbers to be available; second, anyone running points should not be FIDONEWS 14-04 Page 13 27 Jan 1997 doing so on a minimal system anyway. Note(2), Special bundle names (ZZZ or 000) are implemented optionally by the destination. You should not assume that it will work. A future Type 3.x spec will include password protection for this. The logic for providing for up to 100 packets allowable to a specific node is that I have seen cases of a :CM Net Host generating in excess of 10 messages for a node in one day, and the next logical number is 100. Should a Type 3.x destination fall outside the range available to the Type 3.x arcmail limits, then the bundler will fall back and use the Type 2 arcmail naming scheme. Notes on Zone Gates With type 3 bundles the ZoneGates software load is MUCH easier, all it has to do is simply forward the Type 3.x bundle. It is suggested that it may be VERY desirable to have Type 3.x bundlers duplicate the functionality of the Zone Gate software. At the very least it is STRONGLY suggested that ZoneGates upgrade to Type 3.x capable bundlers as soon as they become available. Notes for Type 3.x Developer's: The latest specs for Type 3.x will be available in the FTSC library at all times and at 1:342/1. Developer's who register with 1:342/1 will have upcoming changes netmailed to them as they are confirmed. Any upcoming change notices will have a date officially implemented. This date will always be in the future and should be considered an official release date of the new Type 3.x standard. Every attempt will be made to allow developer's a reasonable time period to upgrade to the new standard. It is important that developer's attempt to meet this date as these changes are usually NOT backward compatible. Code samples will also be F.Req'able from 1:342/1 as the magic file name TYPE3x where x is the latest revision to the Type 3 standard. Should a developer be unable to meet the release date he should notify the FTSC and/or 342/1 immediately. The release date is based on an estimate made by Aurora Computer Technologies. If there is a good reason the release date will be pushed back, and ALL developers will be notified. As the new Type 3.x standard will not be official until the release date no developer will release his code early. On that subject, care should be taken by the FIDONEWS 14-04 Page 14 27 Jan 1997 developer to let no new format bundles escape his beta test systems. There are a couple of approaches we recommend for this, the first is to have beta test versions only generate the new format bundle for specific zone:net/node addresses, the second is to set up a completely separate private net for testing purposes. Release method: Since the bundler will automatically spread news of itself with use, a simple zero effort release program may be used. As different versions of the Type 3.x bundlers will require different operating environments, you should try to get your bundler made available on Echo-BackBone and Echo Hub systems. The reasoning behind this, is that it is from these systems that the existence of the new bundler will become common knowledge. The other place to send it would be the Zone, Regional, and maybe Net Coordinators. Future of Type 3 Since the Type 3 format proposed provides for a new level of information exchange in Matrix mail I provide here a few advance hints of what is planned. AutoEcho built in. Replace AutoEcho/AreaFix with automatic security. This security is such that the hub will not need to pick a password and send it in netmail to the downstream node prior to the downstream node requesting echos. Instead, the downstream node will request an echo, at which point the Hub's bundler will generate a netmail message to the Hub Sysop. Now the hub Sysop may decide to give it to him. If he does, he simply tells his bundler to start sending it downstream to him. Now since this last paragraph has already confused people, I will provide a scenario with names. Here in Net 342 we have our NEC as Brian McCullough (BDMc for short), and our REC is Steve Barnes (SB). We have BDMc requesting the echo NET_DEV from SB. The sequence is as follows: BDMc requests NET_DEV. BDMc's bundler sees this and generates the echo request packet. This packet is bundled and sent to SB. SB's bundler finds the bundle. SB's bundler sees that BDMc is authorized to have that echo. SB's Bundler generates an acknowledge packet and starts sending the echo to BDMc. BDMc's Bundler gets the acknowledge and sets up the FIDONEWS 14-04 Page 15 27 Jan 1997 area. BDMc's Bundler will use the password it was sent for future requests. If there was a problem with access to the requested echo Steve Barnes would have received a NetMail message from his bundler and he would be able to make a decision at this point. Other than that he need not even be in the country. Minor details on this, the Hub (or upstream node) can specify levels of permission for this autoecho request process, and deny certain echos to certain downstream nodes. If a downstream node requests a denied echo, the upstream node's bundler will again generate a netmail message to the Hub Sysop informing him of what happened. This will probably be implemented as a downward compatible upgrade with the request for new software triggered by the first request for a new echo. Note, if standard distribution applies this should never generate a request. However as things do not always work that way, the automatic notification and optional file request should solve any major problems. The Future of the Aurora Type 3 Bundler Fowarding of bundles that costs money. All forwarded bundles that will cost money will be marked as HOLD unless either the receiving OR the sending node are marked as send-to or accept-from appropriately. All keywords will be valid in these cases. This is a completely backwards compatible change. Forwarding Cost bundles from Points. The forwarding of cost bundles from points will be done on the basis of a credit that the point has. The credit will be monitored in the USER.BBS file, with the record number corresponding to the point number. This is a completely backwards compatible change. Final Notes: Final Note: Would all those planning on writing a Type 3.0 bundler please contact me (Oliver McDonald) via NetMail (1:342/1). Final Note(2): There are already some planned extensions to Type 3.0, they will not be strictly required and will not create a new VersionMinor number, but will add functionality, and will when used require an update. It is my feeling that if you are aware of these plans, you will be able to integrate them FIDONEWS 14-04 Page 16 27 Jan 1997 better at the point they are "officialized". It is not my desire to become the only Type 3.x developer out there. It is merely my desire to be able to be one of them, and also to be able to make Type 3.x so attractive to all that everyone will want to run it. Final Note(3): Send Code (tm, Bob Hartman). Final Note(4): Convince me(tm) of suggested changes. Kudos: Thanks to all the people in Net_Dev who have made suggestions and comments on this proposal as I worked on it. Your comments are appreciated (even those I have not used). I would like to especially thank the following people: Wynn Wagner III FSC-0014 and support. Roeland Meyer Work on ArcName routing. Randy Bush Suggestions and support. Brian McCullough Sounding board and Cattle Prod. -30- ----------------------------------------------------------------- /* FSC-0025 Pittsburgh, PA 23 August 1988 A V A T A R Advanced Video Attribute Terminal Assembler and Recreator George A. Stanislav 129/39 Historical Overview Wynn Wagner III, the author of Opus-CBCS, developed a method of storing video control codes in a file sent to the Opus caller which was meant as a replacement of ANSI escape codes. Its main advantages were: o The codes are smaller than ANSI, thus needing less disk storage space. o The codes are in the binary form easily interpreted by the computer (ANSI sequences use ASCII). o The same file can be sent to callers who do or do not have FIDONEWS 14-04 Page 17 27 Jan 1997 the ability of interpreting ANSI codes - in the former case the codes are first translated to ANSI, in the latter they are ignored. Because of lack of an appropriate name, Wynn temporarily named the codes oANSI with the understanding that a better name was needed. When I started working on my TinyTerm communications program, I had the idea that if Opus-CBCS could send the "oANSI" codes directly over the phone lines, it would speed up the communications considerably. A typical ANSI sequence contains 4 times as many bytes as the codes developed by Wynn Wagner. A phone call to Wynn resulted in two things: o TinyTerm can interpret the "oANSI" codes and translate them to ANSI, then send them to stdout where they are converted to colors by ANSI.SYS. o Opus-CBCS, starting with gamma version 1.10.iii, will send the codes without converting them to ANSI sequences. (It will still send ANSI codes to users without the proper terminal software.) I took over the coding of the part of Opus handling the video codes. I realized the codes were offering us much more power than just translating them to ANSI escape sequences. I proposed to call the codes AVATAR, the Advanced Video Attribute Terminal Assembler and Recreator. Wynn readily accepted the new name. The Two Levels of Avatar Avatar is more than a video attribute controller. It is a protocol which, if need be, can totally eliminate the interference of line noise. However, this document is not concerned with the advanced topics of Avatar (which no program is using as of this writing). A full Avatar session with all its advanced features starts by exchanging the AVINIT packets. The caller sends a packet which describes the video capabilities of his/her system. It also contains the caller's name, password and some other optional information. It also tells the BBS if the user is calling in person or just emulating a BBS session with an Avatar terminal program. The called system (the BBS) replies to the AVINIT packet with a packet that informs the user of his current status, e.g. you can stay till 16:30 GMT, or you are denied access, or I am processing mail now but you can call back at 10:43 GMT, etc. Until such AVINIT packets are exchanged, only the Avatar commands that were part of the original oANSI codes can be sent from the BBS to the caller. The caller's term program should send no Avatar commands, with the exception of function key codes, before the AVINIT packets are exchanged. This assures that a BBS program which does not support full Avatar can still take advantage of the faster transfer of video codes using Avatar as opposed to ANSI escape sequences. It also FIDONEWS 14-04 Page 18 27 Jan 1997 permits the caller whose term program does not support full Avatar but can interpret the basic codes to take advantage of the term program's abilities. The two levels of Avatar then are: a full session and a basic session. This document is concerned with the BASIC Avatar session only. The full session will be defined in a separate document. Basic Avatar Commands Before the AVINIT packets are exchanged, the BBS can send the basic Avatar commands if so permitted by the user's choice, typically recorded in the user datafile (e.g. USER.BBS). Because Avatar is window oriented, in a basic session the full screen is considered the default window. Further, the default color of the window is assumed to be 3 (cyan text on a black background). All bytes are taken at their face value without escaping. However, save for one exception described below, no basic Avatar code will have the high bit set. Therefore, the term program should reset the high bit of all bytes except as described below. The basic commands are: <^L> - clear the current window and set current attribute to default. In the basic session this means: Clear the screen and set its attribute to 3. <^Y> - Read two bytes from the modem. Send the first one to the screen as many times as the binary value of the second one. This is the exception where the two bytes may have their high bit set. Do not reset it here! <^V> <^A> - Set the color attribute to . The default attribute remains unchanged. However, all text will be displayed in until the next ^V^A, ^V^B, or ^L. <^V> <^B> - Turn the high bit of current attribute on. In other words, turn blink on. <^V> <^C> - Move the cursor one line up. Do nothing, if you already are at the top line of the current window. <^V> <^D> - Move the cursor one line down. Do nothing if you already are at the bottom line of the current window. <^V> <^E> - Move the cursor one column to the left. Do nothing if you already are at the leftmost column of the current window. <^V> <^F> - Move the cursor one column to the right. Do nothing if you already are at the rightmost FIDONEWS 14-04 Page 19 27 Jan 1997 column of the current window. <^V> <^G> - Clear the rest of the line in the current window using the current attribute (not to be confused with the default attribute). <^V> <^H> - Move the cursor to the position within the current window. Comments: Current attribute and default atribute are not necessarily the same. Whenever the window is cleared by the <^L> command, the current attribute is made equal to the default attribute. There is also another command to make the current attribute equal to the default attribute. However, this command is not a part of the basic Avatar command set and therefore cannot be used before the AVINIT packets are exchanged. Whatever characters are sent to the screen, they should be displayed using the CURRENT attribute. There is an exception to this, but only after the AVINIT packets have been exchanged. The attribute byte is an eight-bit value. As basic Avatar can only transfer 7-bit commands, the high bit of the attribute byte can be set only by the <^V> <^B> command. The byte of the <^V> <^A> command should be AND-ed with 7F (hexadecimal). The colors set by the attribute byte are the same as are the colors of the text mode of an IMB color graphics adapter. That means the bits of the attribute byte have the following meaning: bit: 7 6 5 4 3 2 1 0 - - - - - - - - | | | | | | | | | | | +---+---+ +-----+-----+ | | | | | | | | | | text color | | | | background color | blink If the blink bit is set, the text is blinking, else it is not blinking. The bits of background color can have values 0 - 7, the bits of the text color can have values 0 - 15. The value indicates the following colors: 0 black FIDONEWS 14-04 Page 20 27 Jan 1997 1 blue 2 green 3 cyan 4 red 5 magenta 6 brown 7 gray (i.e. non-itense white) 8 dark gray 9 light blue 10 light green 11 light cyan 12 light red 13 light magenta 14 yellow 15 white (intense) Colors 8 - 15 are the same as 0 - 7 but with high intensity. Please note that these values are different from the numbers used by ANSI escape codes. The Function Key Codes An Avatar capable BBS can accept function keys from the remote caller. This feature is optional (for the term program) but highly recommended. On an IBM (compatible) computer this means that if a caller hits a function key (e.g., left arrow, page up, F7, insert, alt-H, etc.), the term program should send two bytes to the Avatar capable BBS: A binary zero followed by the keyboard scancode. Please note that control keys (^A, ^B, etc.) are not function keys but have an ASCII value which is the only byte that should be transfered. There are two keys on the IBM keyboard that do have an ASCII value but also offer a separate scan code. These are the gray-plus and the gray- minus. If one of these keys is hit, treat it as a function key - send the binary zero followed by the scan code. This way if the BBS treats them differently from a regular plus and minus keys, the caller can take advantage of the keys. On the other hand, BBS writers who do not want to assign the gray keys a special value, should watch for their codes and treat them as a regular plus and minus. Systems that use a different keyboard layout (and scan codes) than IBM can emulate IBM by declaring which keys are considered the arrows, f- keys, etc. If you have the arrow keys, for example, but their scan codes are different, still send the binary zero and the scan code that an IBM keyboard would assign to that particular key. This should be transparent to the user. There is an obvious problem here. All terminal programs I have seen use function keys internally. A switch is needed so the user can decide whether a function key is meant for the internal use of the term program or it should be transfered to the BBS. Most but not all IBM clones have a scroll lock key, some even have an LED indicator on it. The IBM programs could use that as a switch to know what the user FIDONEWS 14-04 Page 21 27 Jan 1997 means by hitting a function key. Since some compatibles do not have a scroll lock key (e.g. Tandy 1000), the Avatar capable BBS should never expect the combination to be transfered. That way the term program can use to switch between the local and remote use of function keys if the scroll lock key is not available. Conclusion This should about summarize the basic Avatar commands. I have written this document one day before leaving for Fidocon '88 realizing it would be nice to give the software developers (both of BBS's and term programs) something before releasing the specs of the full Avatar implementation. Here is also some sample C code. It assumes you have some low level communications functions of your own. For the screen output it uses Turbo C library, but you can use anything you want. */ #include int def_attr = 3; int cur_attr = 3; int lastline = 25; int lastrow = 80; /* WARNING: This code has not been tested. It is just meant as an example */ void pascal avatar() { int c,i,j; switch (mgetchar()) /* Read a char from the modem */ { case 12 : textattr(cur_attr = def_attr); /* ^L */ clrscr(); break; case 25 : c = mgetchar(); /* ^Y */ j = mgetchar(); for (i = 0; i < j; i++) cprintf("%c",c); /* print in color */ break; case 22 : switch(mgetchar()) /* ^V */ { case 1 : cur_attr = mgetchar() & 0x7f; textattr(cur_attr); break; case 2 : cur_attr |= 0x80; textattr(cur_attr); break; case 3 : if ((i = wherey()) > 1) gotoxy(wherex(),i - 1); FIDONEWS 14-04 Page 22 27 Jan 1997 break; case 4 : if ((i = wherey()) < lastline) gotoxy(wherex(), i + 1); break; case 5 : if ((i = wherex()) > 1) gotoxy(i - 1,wherey()); break; case 6 : if ((i = wherex()) < lastrow) gotoxy(i + 1,wherey()); break; case 7 : cleol(); break; case 8 : i = mgetchar(); gotoxy(mgetchar(),i); } } } -30- ----------------------------------------------------------------- FIDONEWS 14-04 Page 23 27 Jan 1997 ================================================================= COORDINATORS CORNER ================================================================= Nodelist-statistics as seen from Zone-2 for day 024 By Ward Dossche, 2:292/854 ZC/2 +----+------+------------+------------+------------+------------+--+ |Zone|Nl-362|Nodelist-003|Nodelist-010|Nodelist-017|Nodelist-024|%%| +----+------+------------+------------+------------+------------+--+ | 1 | 10452|10370 -82 |10370 0 |10177 -193 |10063 -114 |35| | 2 | 16104|16056 -48 |15979 -77 |15936 -43 |15938 2 |56| | 3 | 876| 869 -7 | 868 -1 | 865 -3 | 863 -2 | 3| | 4 | 556| 552 -4 | 554 2 | 553 -1 | 558 5 | 2| | 5 | 93| 93 0 | 93 0 | 93 0 | 93 0 | 0| | 6 | 1075| 1073 -2 | 1073 0 | 1073 0 | 1072 -1 | 4| +----+------+------------+------------+------------+------------+--+ | 29156|29013 -143 |28937 -76 |28697 -240 |28587 -110 | +------+------------+------------+------------+------------+ ----------------------------------------------------------------- FIDONEWS 14-04 Page 24 27 Jan 1997 ================================================================= WE GET EMAIL ================================================================= --- Following message extracted from FIDONEWS @ 1:18/14 --- By Christopher Baker on Fri Jan 24 14:24:21 1997 From: Mike Bilow To: Christopher Baker Date: 23 Jan 97 04:52:22 Subj: ACLU Cyber-Liberties Update * Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2. * Originally from ACLU Cyber-Liberties Update Owner to Mike Bilow. * Original dated: Jan 22 '97, 20:45 From: "ACLU Cyber-Liberties Update Owner"@newmedium.com To: cyber-liberties@aclu.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACLU Cyber-Liberties Update Wednesday, January 22, 1997 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CONTENTS: * Reno v. ACLU Update: Government's Brief Asserts Unprecedented Powers to criminalize Online Speech * ACLU Files Suit against New York State Internet Censorship Law * Georgia Internet Case Update * Northwestern University Defends Free Speech on the Internet * ACLU Speaks on Cyber-Liberties * About the Cyber-Liberties Update ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Reno v. ACLU Update: Government's Brief Asserts Unprecedented Powers to criminalize Online Speech After reviewing the Justice Department's brief on the Communications Decency Act filed late yesterday with the U.S. Supreme Court, the ACLU said that the government is seeking unprecedented powers to criminalize speech on the Internet. The ACLU said that the government's 55-page brief in Reno v. ACLU is "at odds with the extensive factual findings of the trial court," which ruled last June that censorship provisions of the CDA unconstitutionally restricted free speech. "The government's arguments, if adopted, would justify blanket censorship not just on the Internet, but in traditional forums such as libraries and bookstores," said Christopher Hansen, an ACLU national staff attorney on the Reno v. ACLU legal team. FIDONEWS 14-04 Page 25 27 Jan 1997 Further, he noted that the government's brief makes the astounding claim that it is protecting the First Amendment by censoring free speech on the Internet, asserting that a fear of encountering "indecency" online could deter potential users from exercising their First Amendment interest in accessing the new medium. "It is supremely ironic that the government now says it is protecting the First Amendment rights of Americans by threatening people with jail for engaging in constitutionally protected speech," Hansen said. The kind of "indecency" identified by government witnesses in the lower court included words and images displayed online by organizations such as the ACLU, Planned Parenthood, Stop Prisoner Rape, Human Rights Watch and Critical Path AIDS Project, all plaintiffs in Reno v. ACLU, Hansen said. The Supreme Court announced today that it would hear oral argument in the case on Wednesday, March 19, at 10:00 a.m. Each side will be given a half-hour to present their arguments. According to the briefing schedule set by the Court, plaintiff's answering briefs are due on February 20. The government's final, or reply brief, is due on March 7. In addition to the government's brief, three sets of plaintiff groups filed friend-of-the-court briefs on Tuesday in support of the government's position: Enough is Enough (along with eight other plaintiffs), Morality in Media, and a group of members of Congress led by former Senator J. James Exon (D-Neb.), who sponsored the Communications Decency Act. Complete information on the ACLU's challenge to the CDA, including a chronology, trial briefs, affidavits, courtroom transcripts, and a backgrounder on Supreme Court procedures in the case, are available online at the ACLU's website (http://www.aclu.org) and America Online site (keyword: ACLU). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * ACLU Files Suit against New York State Internet Censorship Law The American Civil Liberties Union, the New York Civil Liberties Union, the American Library Association and others last week filed a lawsuit seeking an injunction against a New York statute criminalizing free speech in cyberspace. At an interactive news conference, the groups said they were filing suit because the law, aimed at shielding minors from "indecency," is an unconstitutional content-based restriction on free speech that would reduce adult communications to levels acceptable for a six-year-old. The ACLU said that the New York law is similar to the federal Communications Decency Act, which the ACLU, the ALA and others successfully challenged in federal district court in Philadelphia after it became law last February. In addition, a separate three-judge panel in New York found the CDA unconstitutional on First Amendment FIDONEWS 14-04 Page 26 27 Jan 1997 grounds. The Philadelphia case, Reno v. ACLU, is currently under review by the Supreme Court, and the New York case is pending in the Supreme Court. Section 235.21(3) of the New York Penal Law, which became effective on November 1, 1996, makes it a crime to disseminate "indecent" materials that are "harmful to minors" through any computer communications network. "Like the federal CDA, the New York law is technically and economically infeasible to enforce, it blocks speech that has value to a great many people, and it ignores effective alternatives available both to protect children and to protect free speech," said Ann Beeson, an ACLU national staff attorney and member of the Reno v. ACLU litigation team. The ACLU is also lead counsel in ALA v. Pataki. "Anyone who thinks children will be protected by this law is sadly mistaken," Beeson said. "Experts estimate that at least 40 per cent of information on the Internet originates from non-U.S. sites, which minors will still be able to access. The only group this law really protects is politicians, who can claim they are passing 'tough' legislation. Everyone else is out in the cold." Today's lawsuit is the second such challenge to a state cybercensorship law, according to the ACLU. The first was filed by the ACLU and others in September against a statute in Georgia, now scheduled to go to trial in late January. The ACLU said it has been monitoring state regulation of the Internet and that currently, over 20 states have considered such laws. Plaintiffs in the case are the American Library Association, the Freedom to Read Foundation, the New York Library Association, the American Booksellers Foundation for Free Expression, Westchester Library System, BiblioBytes, Association of American Publishers, Interactive Digital Software Association, Magazine Publishers of America, Public Access Networks Corp. (PANIX), ECHO, NYC Net, Art on the Net, Peacefire and the American Civil Liberties Union. Additional materials on the New York lawsuit, including the complaint, plaintiff statements, and a RealAudio recording of the news conference can be found at http://www.aclu.org/news/nycdahome/html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Georgia Internet Case Update An evidentiary hearing is scheduled for January 30 in ACLU v. Miller, the ACLU challenge to a Georgia Internet law. The Georgia law makes it a crime to use a name that "falsely identifies" a speaker on the Internet, without distinguishing whether the person communicating had any intent to deceive or defraud or simply wanted to keep his or her identity unknown. The complaint also states that the law may prohibit web links by making it a crime to publish information "using" trade names, logos or other symbols, again without regard to the nature of the use, and without any definition of what constitutes "use" on a computer FIDONEWS 14-04 Page 27 27 Jan 1997 network. At the January 30 hearing an expert witness for the ACLU is scheduled to demonstrate the Internet to the court. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Northwestern University Defends Free Speech on the Internet The ACLU congratulates Northwestern University for its stance in support of free speech. Recently, controversy arose around the web page of Associate Professor Arthur R. Butz, who had posted Holocaust revisionist opinions to his page on the university's servers. Despite numerous complaints, the University declined to ask the professor to remove the web page, and when pushed on the topic referred to campus policy on intellectual freedom as it relates to computer usage: Intellectual Freedom: The network is a free and open forum for the expression of ideas, including viewpoints that are strange, unorthodox, or unpopular. The network administrators place no official sanctions upon the expression of personal opinion on the network. However, such opinions may not be represented as views of Northwestern University. As the University stated, Professor Butz made it clear that he was presenting his own views and in no way representing the views of the University, and any censorship was therefore inappropriate. The ACLU supports such free speech codes for university computers. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * ACLU Speaks on Cyber-Liberties Barry Steinhardt, Hartford Chapter ACLU, February 12, 7 p.m., Rittenberg Lounge, Trinity College, Hartford, Ct. The Connecticut CLU can be reached at 860-247-9823. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACLU Cyber-Liberties Update Editor: Lisa Kamm (kamml@aclu.org) American Civil Liberties Union National Office 132 West 43rd Street New York, New York 10036 To subscribe to the ACLU Cyber-Liberties Update, send a message to majordomo@aclu.org with "subscribe Cyber-Liberties" in the body of your message. To terminate your subscription, send a message to majordomo@aclu.org with "unsubscribe Cyber-Liberties" in the body. The Cyber-Liberties Update is archived at http://www.aclu.org/issues/cyber/updates.html For general information about the ACLU, write to info@aclu.org. ~~~~~~~~~~~~~~~ Lisa Kamm http://www.aclu.org FIDONEWS 14-04 Page 28 27 Jan 1997 kamml@aclu.org This Message was sent to cyber-liberties Origin: N1BEE BBS +1 401 944 8498 (1:323/107) -30- ----------------------------------------------------------------- FIDONEWS 14-04 Page 29 27 Jan 1997 ================================================================= NET HUMOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" , Date: Mon, 20 Jan 97 11:06:03 -0600 Reply-To: "Mike Riddle" Subject: Fwd: FW: Geekonics spoken here. ==================BEGIN FORWARDED MESSAGE================== >From: CHARLES ORIEZ Organization: New Dream Network To: ringmasters-all-l@webring.org Subject: Webring Server Status Content-Transfer-Encoding: 7bit Sender: owner-ringmasters-all-l@webring.org Hello, For those of you who don't think you should be receiving this message, please ignore it. As I'm sure you already know, the Webring server is still offline. While we were expecting to move the machine to another location last week, the plans fell through due to power problems at the phone company that won't be fixed until late next week. The move will probably take place the following Monday or Tuesday. Unfortunately, while the system is still connected at the old location, it crashed last Friday and we haven't been able to get into the building to restart it; we're still trying to get ahold of the guy with the keys. I *hope* that we can reach him on Monday or Tuesday, but I can't promise anything. In any case, don't worry. The Webring is not going anywhere.. at the absolute worst, I will be back online in two weeks when the new server arrives. Most likely, it will be back online next week sometime. When the move does take place, it will be offline for anywhere from a few hours to a day or two depending on how fast the DNS changes propogate to your service provider. (A number of you have also wondering if the address will change.. while the physical location will be different, the URL will still be www.webring.org.) Thanks for your patience-- sage -- | Sage Weil | sage@newdream.net -30- FIDONEWS 14-04 Page 35 27 Jan 1997 ----------------------------------------------------------------- FIDONEWS 14-04 Page 36 27 Jan 1997 ================================================================= FIDONET SOFTWARE LISTING ================================================================= Latest Greatest Software Versions by Peter E. Popovich, 1:363/264 [This is last week's edition from 1403.] Ed. The backlog is actually getting winnowed down to something manageable. I guess I'm actually starting to get caught up... ;-) I added my first Atari entry this week and have a couple of others pending. I also finally got enough info about GoldED to get it added. Given that my "todo" queue is almost empty, I'm going to encourage everyone to check to make sure every package they use is listed and for each package that isn't listed, netmail me with the names of the package and contact info for the author or a support site. I actually got caught up enough to twiddle my thumbs, so I think I can handle a few extra suggestions... ;-) Also, since I've fallen way behind my original estimates for phasing out the old info section, I've reformatted it a little to reduce the space it takes. Phased out this week: SuperComm 0.99 and TAG 2.5g Phase-out highlights: This week: Telegard 2.7 and TPBoard 6.1 Deadline for info: 31 Jan 1997. Last week: TBBS 2.1 and TComm/TCommNet 3.4 Deadline for info: 24 Jan 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 FIDONEWS 14-04 Page 37 27 Jan 1997 ---------------------------------------------------------------------- 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 van der 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 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 van der 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 van der Vlist 2:500/9 MAKEPL Marena 1.1 beta O G Michiel van der 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.00 O G Paul Edwards 3:711/934 MSGED 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 van der Vlist 2:500/9 PCMERGE PlatinumXpress 1.3 M C Gary Petersen 1:290/111 PX13TD.ZIP 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 FIDONEWS 14-04 Page 38 27 Jan 1997 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.30 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 FastEcho 1.45a T S Tobias Burchhardt 2:2448/400 FE2 FleetStreet 1.18 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 van der Vlist 2:500/9 IMCRYPT Maximus 3.01 B P Tech 1:249/106 MAXP Msged 4.00 O G Paul Edwards 3:711/934 MSGED PcMerge 2.3 N G Michiel van der 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.00 O G Andrew Clarke 3:635/728 MSGNT400.ZIP FIDONEWS 14-04 Page 39 27 Jan 1997 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.8g M G Eugene Crosser 2:293/2219 IFMAIL ifmail-tx ...tx7.8 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 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 --------------------------------------------------------------------- BBS Software MS-DOS Systems Name Version -------------- -------------------- TBBS 2.1 Other Utilities Other Utilities TComm/TCommNet 3.4 Name Version Name Version Telegard 2.7* -------------------- -------------------- TPBoard 6.1 2DAPoint 1.50* Netsex 2.00b WildCat! 3.02* 4Dog/4DMatrix 1.18 OFFLINE 1.35 XBBS 1.77 ARCAsim 2.31 Oliver 1.0a ARCmail 3.00* OSIRIS CBIS 3.02 Network Mailers Areafix 1.20 PKInsert 7.10 Name Version ConfMail 4.00 PolyXarc 2.1a -------------------- Crossnet 1.5 QM 1.00a D'Bridge 1.30 DOMAIN 1.42 QSort 4.04 Dreamer 1.06 DEMM 1.06 RAD Plus 2.11 Dutchie 2.90c DGMM 1.06 Raid 1.00 Milqtoast 1.00 DOMAIN 1.42 RBBSMail 18.0 FIDONEWS 14-04 Page 40 27 Jan 1997 PreNM 1.48 EEngine 0.32 ScanToss 1.28 SEAdog 4.60 EMM 2.11* ScMail 1.00 SEAmail 1.01 EZPoint 2.1 ScEdit 1.12 TIMS 1.0(mod8) FGroup 1.00 Sirius 1.0x FidoPCB 1.0s@ SLMail 2.15C Compression FNPGate 2.70 StarLink 1.01 Utilities GateWorks 3.06e TagMail 2.41 Name Version GMail 2.05 TCOMMail 2.2 -------------------- GMD 3.10 Telemail 1.5* ARC 7.12 GMM 1.21 TGroup 1.13 ARJ 2.20 GROUP 2.23 TIRES 3.11 LHA 2.13 GUS 1.40 TMail 1.21 PAK 2.51 Harvey's Robot 4.10 TosScan 1.00 PKPak 3.61 HeadEdit 1.18 UFGATE 1.03 PKZip 1.10 HLIST 1.09 VPurge 4.09e ISIS 5.12@ WEdit 2.0@ NodeList Utilities Lola 1.01d WildMail 2.00 Name Version Mosaic 1.00b WMail 2.2 -------------------- MailBase 4.11a@ WNode 2.1 EditNL 4.00 MSG 4.5* XRS 4.99 FDND 1.10 MsgLnk 1.0c XST 2.3e MakeNL 2.31 MsgMstr 2.03a YUPPIE! 2.00 Parselst 1.33 MsgNum 4.16d ZmailH 1.25 Prune 1.40 MSGTOSS 1.3 ZSX 2.40 SysNL 3.14 XlatList 2.90 XlaxNode/Diff 2.53 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OS/2 Systems ------------ Other Utilities Other Utilities BBS Software Name Version Name Version Name Version -------------------- -------------------- -------------------- ARC 7.12 oMMM 1.52 Kitten 1.01 ARC2 6.01 Omail 3.1 SimplexBBS 1.04.02+ ConfMail 4.00 Parselst 1.33 EchoStat 6.0 PKZip 1.02 Network Mailers EZPoint 2.1 PMSnoop 1.30 Name Version FGroup 1.00 PolyXOS2 2.1a -------------------- GROUP 2.23 QSort 2.1 BinkleyTerm(S) 2.50 LH2 2.11 Raid 1.0 BinkleyTerm/2-MT MSG 4.2 Remapper 1.2 1.40.02 MsgLink 1.0c Tick 2.0 SEAmail 1.01 MsgNum 4.16d VPurge 4.09e - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Xenix/Unix 386 Other Utilities -------------- Name Version -------------------- BBS Software Network Mailers ARC 5.21 Name Version Name Version C-LHARC 1.00 -------------------- -------------------- MSGLINK 1.01 oMMM 1.42 FIDONEWS 14-04 Page 41 27 Jan 1997 Omail 1.00 |Contact: Willy Paine 1:343/15,| ParseLst 1.32 |or Eddy van Loo 2:285/406 | Unzip 3.10 VPurge 4.08 Zoo 2.01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FIDONEWS 14-04 Page 42 27 Jan 1997 BBS Software Atari ST/TT Name Version ----------- -------------------- 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tandy Color Computer 3 (OS-9 Level II) Other Utilities -------------------------------------- Name Version -------------------- BBS Software Compression Utility Ascan 1.2 Name Version Name Version AutoFRL 2.0 -------------------- -------------------- Bundle 2.2 RiBBS 2.02+ Ar 1.3 CKARC 1.1 DeArc 5.12 EchoCheck 1.01 OS9Arc 1.0 FReq 2.5a UnZip 3.10 LookNode 2.00 UnLZH 3.0 ParseLST PReq 2.2 RList 1.03 RTick 2.00 UnBundle 1.4 UnSeen 1.1 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 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-04 Page 43 27 Jan 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-04 Page 44 27 Jan 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 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 29: http://www.rtfm.be/fidonet/ (in French) Region 36: http://www.geocities.com/SiliconValley/7207/ ============ Zone 3: http://www.z3.fidonet.org ============ Zone 4: ============ FIDONEWS 14-04 Page 45 27 Jan 1997 Zone 5: ============ Zone 6: http://www.z6.fidonet.org ============ ----------------------------------------------------------------- FIDONEWS 14-04 Page 46 27 Jan 1997 ================================================================= FIDONEWS INFORMATION ================================================================= ------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ------- Editor: Christopher Baker Editors Emeritii: Thom Henderson, Dale Lovell, Vince Perriello, Tim Pozar, Tom Jennings, 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 cbak.rights@opus.global.org (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 1996 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 FIDONEWS 14-04 Page 47 27 Jan 1997 FNEWS for the current month in one archive. Or file-request specific back Issue filenames in distribution format [FNEWSDnn.LZH] for a particular Issue. Monthly Volumes are available as FNWSmmmy.ZIP where mmm = three letter month [JAN - DEC] and y = last digit of the current year [6], i.e., FNWSMAY6.ZIP for all the Issues from May 96. Annual volumes are available as FNEWSn.ZIP where n = the Volume number 1 - 12 for 1984 - 1995, respectively. Annual Volume archives range in size from 48K to 1.2M. 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. =*=*=*=*=*=*=*=*= FIDONEWS 14-04 Page 48 27 Jan 1997 A PGP generated public-key is available for the FidoNews Editor from 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- -----------------------------------------------------------------