Volume 7, Number 46 12 November 1990 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | FidoNet (r) | | \ \\ | | International BBS Network | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Thom Henderson, Dale Lovell Chief Procrastinator Emeritus: Tom Jennings Copyright 1990, Fido Software. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact Fido Software. FidoNews is published weekly by and for the Members of the FidoNet (r) International Amateur Electronic Mail System. It is a compilation of individual articles contributed by their authors or authorized agents of the authors. The contribution of articles to this compilation does not diminish the rights of the authors. You are encouraged to submit articles for publication in FidoNews. Article submission standards are contained in the file ARTSPEC.DOC, available from node 1:1/1. 1:1/1 is a Continuous Mail system, available for network mail 24 hours a day. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, Box 77731, San Francisco CA 94107, USA and are used with permission. Opinions expressed in FidoNews articles are those of the authors and are not necessarily those of the Editor or of Fido Software. Most articles are unsolicited. Our policy is to publish every responsible submission received. Table of Contents 1. ARTICLES ................................................. 1 Ask A Coordinator ........................................ 1 GATEWAY POLICY??? Hunh?? What?? .......................... 3 LDS_PRIVATE Echo Now Available ........................... 5 SGANet - Student Government Global Mail Network .......... 6 NewStyle Packets ......................................... 8 Why Not? (Because it is too simple?) ..................... 15 2. COLUMNS .................................................. 17 A View from the Bridge ................................... 17 3. LATEST VERSIONS .......................................... 18 And more! FidoNews 7-46 Page 1 12 Nov 1990 ================================================================= ARTICLES ================================================================= Paul Knupke, Jr. Fidonet 1:3603/110.9 Eggnet 99:9010/35 Ask A Coordinator Recently a new participant in the SYSOP echo said "I thought this echo was for civil discussions between sysops." SYSOP and CIVIL are oxymoron. Where is a sysop to go when they want to get real answers and have discussions where they won't be attacked for their personal opinions? I thought about this for a while and came to the conclusion that SYSOP is a lost cause and the only thing to do is start a brand new echo where flames and personal attacks will not be tolerated. Ask A Coordinator, ASK_A_C, is an echo devoted to sysops and users who want to ask questions and carry on friendly conversation. Topics include: Policy (current and proposed), echomail, software, how the network operates, and many more topics. ASK_A_C is open to everyone who is willing to converse in a friendly manner. The only people who are not welcome are those who flame and attack others (there is an echo for those people already.) I invite all Coordinators to participate in this open discussion forum. I am working to move this echo to backbone as soon as possible. All current and former *C's and *EC's are invited to join me in this ground breaking of this echo devoted to open the channel of discussion between the coordinator structure and the grunt sysops and their users. It is the coordinators who keep our network together but it is the grunt sysops and their users who benefit from their contributions. Distribution is being worked on but initially it will be available from 1:3603/110 (MO, HST/V42, N3603/R18 echomail hub) in Clearwater, Florida and soon after 151/1003 (R18EC). Contact Neil Lauritsen (1:3603/110) for a link into ASK_A_C. Paul Knupke, Jr. Moderator - ASK_A_C FidoNews 7-46 Page 2 12 Nov 1990 ----------------------------------------------------------------- FidoNews 7-46 Page 3 12 Nov 1990 Jim Deputy Moderator Kinknet Echoes Zone Coordinator Adult Links Network EggNet Supreme Court Chief Justice 1:103/158, 99:99/105, 69:69/0 Gateway Policy... Well, to be honest, it looks like I probably ought to quit read- ing FidosNews again, and wait for the announcements in the Node- list, where they are supposed to be posted. It would probably result in my blood-pressure staying down much better. Especially since they aren't being made there anymore. Sorry for the long lead in at the top, but I am speaking on this subject matter on much more than one level. I've just read Matt Whelan's version of the New GATEWAY LAW that the **C's have decided to inflict us with. It's nice to see that FidoNet doesn't want to tell the other networks how to operate. Now would SOMEONE PLEASE TELL THAT TO FIDONET!!!!! I'm beginning to think that maybe folks like Jack Decker, Jason Steck, The ROUSTER, and a few of the other so-called rabble rousers aren't all that far off base. I am beginning to feel that the SS-Elite are moving in on us along with BIG BROTHER! First off, what's this contract crap at the end of the Gateway policy? Come on! If you aren't telling other networks how to operate, what the heck do you call it? This is supposed to be a hobby not a business. Second, the article immediately following Matt's GATEWAY POLICY, by Tony Davis quite calmly announces that "1:1/100@FIDONET will accept and deliver domain addressed network netmail to the do- mains of: Fidonet Alternet Eggnet Rbbsnet Network Kinknet" I find this very interesting. Who died and elected either Tony Davis or Matt Whelan GOD? I believe I have to claim that I am KinkNet. Or at least I have the right to that claim. After all, I started the KinkNet echoes over two years ago, and am the modera- tor of the echo conferences tied together under that banner. FidoNews 7-46 Page 4 12 Nov 1990 KinkNet is not a DOMAIN! KinkNet is nothing more than a group of Echoes. KinkNet operates in the DOMAIN of Adult Links (Zone 69) of which I am also the Zone Coordinator. IT DOES NOT OPERATE WITHIN THE DOMAIN OF FIDONET!!! As the moderator of the KinkNet echoes, I have entered into no agreement authorizing such a gateway. As the Zone Coordinator of Adult Links, likewise I have authorized no such gateway, nor has it even been discussed with me. I have further not discussed or agreed to Adult Links or KinkNet DOMAIN titles with anyone. I am glad to see that FidoNet has not made any decisions for KINKNET or Adult Links! Hence, EFFECTIVE IMMEDIATELY 1:1/100@FIDONET is not authorized to gate any traffic into either KINKNET or Adult Links, until such time as an agreement is reached. Be it further known, KINKNET is not a DOMAIN! And the word KINK- NET may not be used as a DOMAIN tag. Speaking as the EggNet Supreme Court Chief Justice, I am not aware of any such agreement existing in EggNet either. Should one have been reached there would be an applicable 99/1 address. There is no such address in the current Egglist. Nor has an announcement been made by the EggNet Inter Network Liaison of such an agreement. Further, in EggNet in particular, after look- ing over the contents of the Gateway Policy, EggNet as a whole would have to vote as to whether or not such an agreement could be put in place for inter-network operation. No such election is currently scheduled. Mr. Davis doesn't have either an Adult Links (required by A_LINKS policy) or EggNet Address. And Mr. Davis in the past has ex- hibited strong ANTI-Other Network ideals. (Circa FidoCon '89). Now, someone PLEASE say something to convince me that FIDONET isn't out to run the other networks! I wonder, did the rest of the networks find out about this scheme the same way I did? ----------------------------------------------------------------- FidoNews 7-46 Page 5 12 Nov 1990 Jeff Murphy 1:344/10 Ephrata, WA, USA LDS_PRIVATE Echo Now Available On behalf of it's participants, I wish to announce the existence of a private echo for Latter-day Saints (Mormons). Currently all connections are being managed by Charles Simpkinson, 1:347/3 in Boise, ID. Those of you interested in such things will know that the MORMON echo already exists on the backbone, and is fairly well used by its limited audience. However, for some time now the echo has permitted considerable discussion of religious views - which is to say that anti-Mormons are having a field day. Some of us had the erroneous idea that MORMON meant just that: a forum for members of The Church of Jesus Christ of Latter-day Saints to discuss issues of interest to themselves. We were apparently mistaken; most of the "burning questions" raised in there deal with issues that are fundamental to our religion, in that they question the basic premises upon which the Church is built, arguing for example that Joseph Smith was no prophet at all, the Book of Mormon a total fraud, etc. In other echos, we call this flaming. In that one, it was called intellectual curiosity or righteous indignation. The echo has not been placed on the backbone in order to avoid the conflicts which come from non-members and apostates. We would probably do so if we could figure out a way to prune the tree when one of these worms wanders in ['scuse my French]. However, the echo is available currently throughout the west from various boards. We invite Latter-day Saints to might wish to participate to contact Charles at 1:347/3. ----------------------------------------------------------------- FidoNews 7-46 Page 6 12 Nov 1990 SGANet - Student Government Global Mail Network Now linking student leaders in 32 countries SGANet, started in May 1990, is a global electronic mail discussion group for student governments and student leaders to use to discuss campus issues, education, and governance. SGANet is a group of seven free and open e-mail discussions in which student leaders can discuss ideas, share information, or request information with student leaders worldwide. The practical effect of the system is to place the participating student leaders in one room. SGANet supports the following: free and open discussion areas, an automated directory of users, archives of discussions, and an automated group of file libraries with information about student governance, SGAnet, and future plans. SGANet, although relatively new, now reaches student associations in 32 countries on six continents. Until recently, our only publicity was word of mouth. It is our hope that SGANet, in the future, will provide a reliable, interactive media which will serve as a foundation for meaningful student union on the regional, national and even global level. Simone Botti, of Italy, recently initiated a debate on drafting a universal Charter on Student Rights which would be drafted later this year when we have reached a sizeable fraction of the universities in the 70 countries served by the Internet. SGANet is collectively maintained by an international team of moderators and network liasions. Moderators help us keep the network running and work primarily on technical issues. Network liasions help us reach universities in a given region and help prospective users with difficulties ranging from e-mail problems to langauge barriers. SGANet can be reached through the following networks: BITNET/EARN, the Internet (serves over 70 countries), CompuServe, Usenet, and Fidonet. SGANet provides the following discussion areas, and related file libraries: SGANet@VTVM1.BITNET (Global discussion) SGANet-N@VTVM1.BITNET (North American universities) SGANet-S@VTVM1.BITNET (South American universities) SGANet-E@VTVM1.BITNET (European Universities) SGANet-A@VTVM1.BITNET (Asian/Australian Universities) SGAN-SAV@VTVM1.BITNET (Student Association of Virginia, USA) USGA-L@SIUCVMB.BITNET (Illinois Universities, USA) SGANET-T@VTVM1.BITNET (Technical discussion group) FidoNews 7-46 Page 7 12 Nov 1990 Automatic subscriptions can be taken by sending the following message to LISTSERV@VTVM1.BITNET SUBscribe (Network name) (Your name, affiliation, country) We are interested in making SGANet, and its five regional networks, available through Fidonet. Our ultimate goal is to provide a forum in which student leaders can share information, and plan strategy worldwide; and also to make the discussions available to as wide an audience as possible. If you would be interested in joining SGANet and/or making SGANet available to your users contact one of the following: Brian McConnell SGANet System Moderator FidoNet= 1:114/15 Internet= bmcconne@vtssi.vt.edu UNITED STATES Abhik Biswas, SGANet System Co-Moderator UNITED STATES Bitnet= jutbaaa@iupoak.bitnet Daniel Kalchev SGANet-E (Europe) Moderator BULGARIA Daniel Kalchev Fidonet= 2:359/1 ----------------------------------------------------------------- FidoNews 7-46 Page 8 12 Nov 1990 NewStyle Packets A Proposal for the Next Generation of of FidoNet Mail Packers Third Draft 10 November 1990 jim nutt 1:114/30@fidonet Introduction FidoNet has been using the Type II style packet for some five years or more now with good results. However, at this point, the Type II format has been extended an amazing number of ways using the "Kludge" hidden line facility provided by a leading ^A (ASCII SOH) on a line of text. It is my belief that the time has come to move to a newer technology for handling packets, one that is inherently extensible and easily handled by a number of systems. Such a system should be able to handle such varied things as integrated text/graphics and other special attributes of messages. Such a system has been proposed by Garth Kidd and is expanded upon here. Basic Format Essentially, this format would break a message into a number of "chunks". Each chunk would be a maximum of 4,294,967,306(!) bytes long including its header and may contain any type of data. A chunk header would be 21 bytes long and would consist of a 4 byte chunk type tag followed by an 8 byte length field. The length field does *not* include the 12 bytes of the chunk header. Chunks would be unterminated. In C, a chunk structure would look like this: struct chunk { char type[4]; char len[8]; /* 32 bit length of data field, 8 hex digits */ unsigned char data[len]; /* not really, this isn't legal c, but it gets the idea across */ }; Certain chunk types require that a FidoNet address be represented in a 24 byte hex format. This address would be comprised of the domain, zone, net, node, and point expressed as the following C structure: struct address { FidoNews 7-46 Page 9 12 Nov 1990 char domain[8]; char zone[4]; char net[4]; char node[4]; char point[4]; }; The domain name is *not* null terminated, it is however, null padded to eight characters. If the first character of the domain name is null, then the remainder of the domain field is to be considered absent. This offers a space savings of 7 bytes per address when operating in a non-domain aware Network. All other fields are 4 hex digits, again, with NO terminating nul character. It was chosen to use an ASCII representation of numbers (in hex) to avoid byte ordering problems and to enhance portability across 7 bit transport layers. Chunk Types Chunk type names are exactly four characters long, padded with spaces if necessary. Chunk types not recognized by a program would be passed along and ignored. Chunk types that are marked with an asterisk (*) must be recognized by a conforming installation. Chunk types marked with a C are considered control chunks, while those marked with D are data chunks. Unmarked chunks are delimiters or informational. I would propose the following base chunk types: * BEGB A chunk indicating the beginning of a bundle. This chunk may contain optional information identifying the bundle. CRTR Indicates the software and revision level used to create this bundle. Applies only to entire bundles. * PSWD Password for the entire bundle, or if within "BEGM"/"ENDM" a single message. If the password in this chunk does not match a predefined password on the receiving system one of two actions occurs. If the receiving system is the final destination of the bundle or message, the bundle or message is discarded, optionally with a message being sent back to the sender saying so. If the bundle or message is only passing through, it will not be made visible to the sysop of the routing system, regardless of any options that may be set to the contrary. Obviously, this is lightweight security, but it is better than FidoNews 7-46 Page 10 12 Nov 1990 nothing! * BEGM A chunk indicating the beginning of a message, this chunk may contain optional information identifying the message. * ROUT C Binary address of next destination for this message or bundle. In other words, if a message from 123/456 is going to 456/789 but is routed through an intermediary system (say 321/654) this address would be that of the intermediary system. This address would be a two dimensional address in the sender's current zone and domain. This address would be represented in C as: struct route_address { char net[4]; char node[4]; }; This chunk may be applied to either a single message or an entire bundle. If the chunk length is 24, then the route address is a full five dimensional address comprising domain, zone and point information as described above in "Basic Formats", otherwise the chunk length is 4 and the address is in the format described above. * TO C Name and address of receiver in ascii. The address in this field may be anything, so long as the system at the "ROUT" address can make sense of it. * FROM C Name and address of sender in ascii. This may be anything so long as it is possible for the receiver to reply via the address in this field. * ATTR C Attributes of the message. See Appendix 2 for a complete list of message attributes. Length is 8. * NUMB Serial number of this message on originating system. This chunk is fixed as an 8 byte hex word. Length is 8. * RPLY Address and serial number of the message this message is a reply to. This chunk is a 24 byte hex address followed by a 8 byte hex word. Length is 32. FidoNews 7-46 Page 11 12 Nov 1990 * ATCH C Name of a file attached to this message * FREQ C Name of a file requested from receiving system. This would incorporate the same type of update request logic as is currently used by WaZoo mailers. A separate "FREQ" chunk is required for each file requested. * AREA C Echomail only, signifies the echomail area this message belongs to. * DOMN C Echomail only, list of domains, as 8 byte ASCII strings (null-padded, but not necessarily null- terminated), that have seen this message. * ZONE C Echomail only, list, as four byte hex words, of zones that have seen this message. This chunk is cleared each time the message enters a different domain and the name of the domain the message is exiting is added to the "DOMN" chunk. * NET C Echomail only, list, as four byte hex words, of all nets that have seen this message. This chunk is cleared upon export to another zone and the exporting node's zone number is added to the "ZONE" chunk. * NODE C Echomail only, list, as four byte hex words, of all nodes in the current net that have seen this message. This chunk is cleared each time the message enters a new net and the number of the net the message is exiting is added to the "NET " chunk. * PONT C Echomail only, list, as four byte hex words, of all point systems that have seen this message. This chunk is cleared upon export to another node and the node number of the exporting system is added to the "NODE" chunk. * PATH List of the systems this message has passed through to reach this system, in order. This includes all systems in all zones and domains. All addresses would be 24 byte hex as defined in the section "Basic Formats" * TEXT D The text of the message TXAT D Text attribute change. Allows for font changes, underlining, etc. See Appendix 4 for the basic set of text attributes. FidoNews 7-46 Page 12 12 Nov 1990 BITS D A bitmap. To be defined (MacPaint? Windows? PCX? TIFF?) BITC D Bitmap continuation. GRPH D A vector drawing. To be defined (PostScript? HPGL?) * ENDM A chunk indicating the end of a message. This chunk may optionally contain information identifying the message it terminates. * ENDB A chunk indicating the end of the bundle, anything after this can be safely ignored. This chunk may optionally contain information identifying the bundle it terminates. Other Considerations Chunk style packets could not be sent as *.PKT files as they are not backward compatible with type II packets. I propose that chunk style packets be called bundles and sent as *.BUN files, with compressed bundles sent as *.B?? where ?? is the compression method used (see Appendix 1 for extensions). Bundle file names should be unique for at least a one week cycle, a 32 bit serial number expressed in hexadecimal should prove adequate for most applications. Experimental chunk types are provided for by the provision that unrecognized chunk types be passed through and ignored. Systems that know how to use a particular chunk type (say, BITS) can, while systems that don't understand it may ignore it. Chunks should appear in a bundle in roughly the same order as they appear above, with control and informational chunks (PATH, ROUT, etc) appearing before data chunks (TEXT, BITS, GRPH). Control Chunk tag name assignments are controlled by Appendix 3 of this document. New chunk tags may be added and old ones revised by revision of this document. Message attribute assignments are controlled by Appendix 2 of this document. New attributes may be assigned by revision of this document. Bundle file extensions are controlled by Appendix 1 of this document. New extensions may be defined and old ones revised by revision of this document. Finally, text attributes are controlled by Appendix 4 of this document. Conclusion FidoNews 7-46 Page 13 12 Nov 1990 I doubt I have covered all possible or desirable chunk types in this document. I do believe however, that enough have been defined to get started with. Chunks offer a highly flexible, extensible system of bundling mail. New types of chunks may defined as needed to accomodate advances in technology and FidoNet. Additionally, this would further separate the application and transport layers of FidoNet, yielding less confusion as to their respective roles. It may be noticed that this structure is extremely similar to the IFF format as used on Amiga computers and introduced by Electronic Arts Software. While inspired by IFF, this system has been simplified somewhat and changed to be more easily transportable between computers using different byte orders and processors. All fields defined in this document are 7 bit ascii and should be easily parsed by any system. Appendix 1 - Compression Extensions Compressed bundles would indicate the type of compression used by the following file extensions: Extension Creator --------- ------- .BUN Uncompressed .BPK PKZip .BLH LHarc .BAR ARC .BDW DWC .BPA PAK .BZO ZOO .BPX PKXarc Appendix 2 - Message Attributes Message attributes are expressed as an 8 byte hex word. (32 bit binary) Multiple attributes may be ORed together. The following attributes have been assigned. 0000000000000001 Privileged (sysop or addressee access only) 0000000000000010 Encrypted 0000000000000100 Crash (high priority) 0000000000001000 Direct (send directly to recipient system, no routing) 0000000000010000 Hold for pickup Appendix 3 - Defined Chunk Tags The following chunk tags are defined in this document: FidoNews 7-46 Page 14 12 Nov 1990 BEGB NET FROM TEXT AREA NODE ATTR TXAT ENDB PSWD CRTR PONT NUMB BITS BEGM ZONE RPLY BITC ROUT DOMN ATCH GRPH TO PATH FREQ ENDM Appendix 4 - Text Attributes The text attribute is a four byte hex word (16 bit binary). Multiple attributes may be ORed together. Attributes are toggles. The following attributes have been assigned: 00000000 Reset all text attributes 00000001 Underline 00000010 Bold 00000100 Italic 00001000 Font Change 00010000 Size Change 00100000 Color Change The font, size and color change attributes are followed by a one byte binary word selecting the font, size and color to change to. In the case of changing two or all three of these attributes at the same time, the selectors will follow the attribute word in the order; font, size, color, with unnecessary fields being omitted. ----------------------------------------------------------------- FidoNews 7-46 Page 15 12 Nov 1990 Paul Knupke, Jr. Pointless Perception FidoNet 1:3603/110.9 Eggnet 99:9010/35 Why Not? (Because it is too simple?) Has anyone considered the simplist method of holding elections in Fidonet lately? How about one vote for each sysop of Fidonet and the outcome is decided by who has the most votes or whether there are more yes or no votes for implementation of policy. The policy of "no vote = no" has got to stop! In the United States of America officials are elected for the most part by a minority of the people who are eligible to vote because not everyone is interested in politics. Why can't Fidonet employ such a simple method to elect the *C and *EC structure and to decide if a new policy document will become the law. Those who are interested will vote and those who aren't won't. Those who don't vote have no right to complain about the results of their non participation in an election. I propose the following election procedure. Once a year all *C positions are put up for reelection by those under the position. Before any nominations and elections occur a vote counter would be needed. The vote counter should be outside the net or region that the election is taking place. In the ZC case the current IC would ask a non *C sysop within their zone to serve as vote counter. Nominations would be sent to the vote counter via net mail. All names received before a set date would appear on the ballot. The ballot would be sent to the *C for distibution. The nomination and election time frame will be one week (7 days) each. If a candidate gets a majority on the first ballot they are declared the winner. If no single candidate gets a majority of votes the two highest vote getters will run against each other for a runoff election. The highest vote getter is then declared the winner. The individual sysops would vote for their Net Coordinator, their Regional Coordinator and their Zone coordinator. No matter how many times a sysop's name appears in the nodelist they get one vote. The time frame I am describing is 4 weeks long. The first week of the month (first through the seventh day) is the nomination period. The second week (eighth day through fourteenth day) is the election period. The third week (fifteenth day through the twenty-first day) is to tally votes. The fourth week (twenty- second day through the twenty-eighth day) is the runoff week (if necessary.) The results will be published with in 5 days of the ending of the election and runoff. FidoNews 7-46 Page 16 12 Nov 1990 Elections for the NCs, RCs and ZCs will not occur at the same time but about 4 months apart so that the new coordinators will be settled into their positions. There is one problem with the above procedure that I need to address. What happens if the newly elected coordinator wants to run for a higher office. I propose that if the coordinator wins the election for the higher office the runner-up in the previous election takes over the lower position. The runner up in any *C election would be called the Alternate *C. In the event the current *C decides to not continue as a *C or drops out of the network for any reason the A*C would assume the position until the next election. All *Cs can run for re-election. A good *C will be re-elected in most cases and a unpopular *C will not be. In a few weeks I'll be discussing the *EC structure and election procedure. It differs from the *C election method because the *EC jobs are a technical job and the *C jobs are mostly administrative jobs. ----------------------------------------------------------------- FidoNews 7-46 Page 17 12 Nov 1990 ================================================================= COLUMNS ================================================================= A View from the Bridge "Captain's Log, Stardate 9011.11..." by The Captain, 1:107/583@FidoNet 520/583@AlterNet 9:807/1@PNet You know, it seems a lot of idiots who don't have anything better to do have been jumping up and down about what's being published in FidoNews. "IT'S NOT FIDONET RELATED!" they scream in long, tedious articles (as opposed to short, tedious columns like mine). Let's ask ourselves a question: What does "Fidonet related" MEAN, and just who the u&rz are YOU to judge what should get published or not? There's a long standing tradition with FidoNews, going back almost SEVEN YEARS that if it's sent in, it gets printed. With some folks, its a selling point of joining the network! Yet certain people with narrow minds object to their being "forced" to distribute a file which on average is smaller than the usual DAILY echomail bundle once a week, simply because it has something in it THEY don't care to read. SO, they make a verbal stink about it without doing anything constructive. Sound familiar? Can YOU say "echomail"? I thought you could... Needless to say I continue to support the policy of "All the News that Fits We Print" with FidoNews. I happen to be directly responsible for that being the motto of AlterNet's AlterNews. If someone has something to say that they feel is important enough that they'll write up an article and send it on their dime to FidoNews, we oughta publish it. If you don't like that, don't read it. If you're a *C and don't like distributing it, don't be a *C. Nobody's FORCING you. The only time I can remember disliking something in FidoNews was Tom Jennings's (remember him? He invented the network...) article on gay rights. I didn't object to his subject matter, but felt that his profanity should have been editted before publishing. Other people felt differently, that it should never have been published at all. To those people I remind: "This Is A Hobby." And some day THEY might be the ones who want to have something published. Good day. ----------------------------------------------------------------- FidoNews 7-46 Page 18 12 Nov 1990 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version DMG 2.93 Phoenix 1.3 TAG 2.5g Fido 12s+ QuickBBS 2.64 TBBS 2.1 Lynx 1.30 RBBS 17.3A TComm/TCommNet 3.4 Kitten 2.16 RBBSmail 17.3B Telegard 2.5 Maximus 1.02 RemoteAccess 0.04a TPBoard 6.1 Opus 1.13+ SLBBS 1.77 Wildcat! 2.50 PCBoard 14.5 Socrates 1.10 XBBS 1.15 Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.40 EditNL 4.00 ARC 7.0 D'Bridge 1.30 MakeNL 2.31 ARCAsim 2.30 Dutchie 2.90C ParseList 1.30 ARCmail 2.07 FrontDoor 1.99c Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.14 Crossnet v1.5 SEAdog 4.51b XlatList 2.90 EMM 2.02 TIMS 1.0(Mod8) XlaxDiff 2.35 Gmail 2.05 XlaxNode 2.35 GROUP 2.16 GUS 1.30 HeadEdit 1.15 InterPCB 1.31 LHARC 1.13 MSG 4.1 MSGED 2.00 MSGTOSS 1.3 PK[UN]ZIP 1.10 QM 1.0 QSORT 4.03 Sirius 1.0x SLMAIL 1.36 StarLink 1.01 TagMail 2.40 TCOMMail 2.2 Telemail 1.27 TMail 1.15 TPBNetEd 3.2 TosScan 1.00 UFGATE 1.03 FidoNews 7-46 Page 19 12 Nov 1990 XRS 3.40 XST 2.2 ZmailQ 1.12 OS/2 Systems ------------ Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Maximus-CBCS 1.02 BinkleyTerm 2.40 Parselst 1.32 ConfMail 4.00 EchoStat 6.0 oMMM 1.52 Omail 3.1 MsgEd 2.00 MsgLink 1.0C MsgNum 4.14 LH2 0.50 PK[UN]ZIP 1.02 ARC2 6.00 PolyXARC 2.00 Qsort 2.1 Raid 1.0 Remapper 1.2 Tick 2.0 VPurge 2.07 Xenix/Unix ---------- BBS Software Mailers Other Utilities Name Version Name Version Name Version MaximusCBCS 1.02.Unix.B0 BinkleyTerm 2.30b Unzip 3.10 ARC 5.21 ParseLst 1.30b ConfMail 3.31b Ommm 1.40b Msged 1.99b Zoo 2.01 C-Lharc 1.00 Omail 1.00b Apple CP/M ---------- FidoNews 7-46 Page 20 12 Nov 1990 Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Daisy v2j Daisy Mailer 0.38 Nodecomp 0.37 MsgUtil 2.5 PackUser v4 Filer v2-D UNARC.COM 1.20 Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Red Ryder Host 2.1 Tabby 2.2 MacArc 0.04 Mansion 7.15 Copernicus 1.0 ArcMac 1.3 WWIV (Mac) 3.0 LHArc 0.33 Hermes 1.01 StuffIt Classic 1.6 FBBS 0.91 Compactor 1.21 TImport 1.92 TExport 1.92 Timestamp 1.6 Tset 1.3 Import 3.2 Export 3.21 Sundial 3.2 PreStamp 3.2 OriginatorII 2.0 AreaFix 1.6 Mantissa 3.21 Zenith 1.5 Eventmeister 1.0 TSort 1.0 Mehitable 2.0 UNZIP 1.02c Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Paragon 2.07+ BinkleyTerm 1.00 AmigArc 0.23 TrapDoor 1.50 AReceipt 1.5 WelMat 0.42 booz 1.01 ConfMail 1.10 FidoNews 7-46 Page 21 12 Nov 1990 ChameleonEdit 0.10 ElectricHerald1.66 Lharc 1.21 MessageFilter 1.52 oMMM 1.49b ParseLst 1.30 PkAX 1.00 PK[UN]ZIP 1.01 PolyxAmy 2.02 RMB 1.30 TrapList 1.12 UNzip 0.86 Yuck! 1.61 Zoo 2.01 Atari ST -------- Bulletin Board Software Network Mailer Other Utilities Name Version Name Version Name Version FIDOdoor/ST 1.94 BinkleyTerm 2.40 ConfMail 4.02 Pandora BBS 2.41c The BOX 1.20 ParseList 1.30 QuickBBS/ST 0.60 ARC 6.02 GS Point 0.61 FiFo 2.0b LHARC 0.60 LED ST 0.10 BYE 0.25 PKUNZIP 1.10 MSGED 1.96S SRENUM 6.2 Trenum 0.10 OMMM 1.40 Archimedes ---------- BBS Software Mailers Utilities Name Version Name Version Name Version ARCbbs 1.44 BinkleyTerm 2.03 Unzip 2.1TH ARC 1.03 !Spark 2.00d ParseLst 1.30 BatchPacker 1.00 FidoNews 7-46 Page 22 12 Nov 1990 + Netmail capable (does not require additional mailer software) * Recently changed Utility authors: Please help keep this list up to date by reporting new versions to 1:1/1. It is not our intent to list all utilities here, only those which verge on necessity. ----------------------------------------------------------------- FidoNews 7-46 Page 23 12 Nov 1990 ================================================================= NOTICES ================================================================= The Interrupt Stack 13 Nov 1990 Third anniversary of Fidonet in Austria (zone 2, region 31). 14 Nov 1990 Marco Maccaferri's 21rd Birthday. Send greetings to him at 2:332/16.0 16 Nov 1990 100% Democratically elected administration takes over the coordination structure in Zone-4 Latin America 1 Jan 1991 Implementation of 7% Goods and Services Tax in Canada. Contact Joe Lindstrom at 1:134/55 for a more colorful description. 16 Feb 1991 Fifth anniversary of the introduction of Echomail, by Jeff Rush. 31 Mar 1991 Jim Grubs (W8GRT) was issued his first ham radio license forty years ago today. His first station was made from an ARC-5 "Command Set" removed from a B-17 bomber. 12 May 1991 Fourth anniversary of FidoNet operations in Latin America and second anniversary of the creation of Zone-4. 8 Sep 1991 25th anniversary of first airing of Star Trek on NBC! 7 Oct 1991 Area code 415 fragments. Alameda and Contra Costa Counties will begin using area code 510. This includes Oakland, Concord, Berkeley and Hayward. San Francisco, San Mateo, Marin, parts of Santa Clara County, and the San Francisco Bay Islands will retain area code 415. 1 Feb 1992 Area code 213 fragments. Western, coastal, southern and eastern portions of Los Angeles County will begin using area code 310. This includes Los Angeles International Airport, West Los Angeles, San Pedro and Whittier. Downtown Los Angeles and surrounding communities (such as Hollywood and Montebello) will retain area code 213. FidoNews 7-46 Page 24 12 Nov 1990 1 Dec 1993 Tenth anniversary of Fido Version 1 release. 5 Jun 1997 David Dodell's 40th Birthday If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. -----------------------------------------------------------------