F I D O N E W S -- Volume 14, Number 16 21 April 1997 +----------------------------+-----------------------------------------+ | The newsletter of the | ISSN 1198-4589 Published by: | | FidoNet community | "FidoNews" | | _ | 1-904-409-7040 [1:1/23] | | / \ | | | /|oo \ | | | (_| /_) | | | _`@/_ \ _ | | | | | \ \\ | Editor: | | | (*) | \ )) | Christopher Baker 1:18/14 | | |__U__| / \// | | | _//|| _\ / | | | (_/(_|(____/ | | | (jm) | Newspapers should have no friends. | | | -- JOSEPH PULITZER | +----------------------------+-----------------------------------------+ | Submission address: FidoNews Editor 1:1/23 | +----------------------------------------------------------------------+ | MORE addresses: | | | | submissions=> cbaker84@digital.net | +----------------------------------------------------------------------+ | For information, copyrights, article submissions, | | obtaining copies of FidoNews or the internet gateway FAQ | | please refer to the end of this file. | +----------------------------------------------------------------------+ SEND ME A DOLLAR! Table of Contents 1. EDITORIAL ................................................ 1 Same old same old ........................................ 1 2. LETTERS TO THE EDITOR .................................... 2 MS Word Macro Virus reported ............................. 2 3. ARTICLES ................................................. 3 Eating Crow .............................................. 3 FIDO Toes Up ............................................. 4 4. COLUMNS .................................................. 7 Lock and Load: Guerilla Marketing for BBSes ............. 7 5. GETTING TECHNICAL ........................................ 9 FSC-0059 - Newsgroup Interchange within FidoNet .......... 9 FSC-0060 - Calculation and Usage of CRCs ................. 19 6. COORDINATORS CORNER ...................................... 23 Nodelist-statistics as seen from Zone-2 for day 108 ...... 23 7. NET HUMOR ................................................ 24 April Fool's Pranks for Programmers ...................... 24 Changing a lightbulb the Internet way .................... 26 8. NOTICES .................................................. 28 Future History ........................................... 28 9. FIDONET SOFTWARE LISTING ................................. 30 Latest Greatest Software Versions ........................ 30 10. FIDONEWS PUBLIC-KEY ..................................... 35 FidoNews PGP public-key listing .......................... 35 11. FIDONET BY INTERNET ..................................... 36 And more! FIDONEWS 14-16 Page 1 21 Apr 1997 ================================================================= EDITORIAL ================================================================= Another disaffected and long-time Sysop is calling it quits in this Issue; citing burnout. [sigh] It's unfortunate that this hobby is taken so seriously by some that it affects their enjoyment. There are pinheads in Echomail but then that's what Echomail is for, isn't it? You've got to ignore them. Taking it to heart is the road to disappointment and burnout. On a happier note, Region 13 has elected a new Region Coordinator with no bloodshed and no uproar. David Moufarrege has taken over the daily Coordination ops on the eastern seaboard. He has already set up a new webpage for Region 13 at: http://www.smalltalkband.com/st01000.htm and this now appears in the Zone 1 list at the end of the Issue and on the FidoNews webpage. I was hoping to have a report of the election from the R13 Election Coord but if it's enroute it won't make it this week. Still no sign of the uucpGate at 1:13/10 or its replacement. I need a new gateway to use for outbound email here. I've tried the local one used by my former Net but it doesn't like my uucp format for some reason and bounces my traffic. I don't need one to be local. If I can use your uucpGate, please let me know via Netmail or email. The addresses are in the Masthead at the end of every Issue. There is a new date in the Future History section this week. I hope it doesn't last but fear it will. You figure out which one it is. [sigh] If any of you column writers of past Issues wish to restart your efforts or if any of you closet columnists wish make regular contributions, check ARTSPEC.DOC and have at it! FidoNews is only what FidoNet, at large, makes it. C.B. ----------------------------------------------------------------- FIDONEWS 14-16 Page 2 21 Apr 1997 ================================================================= LETTERS TO THE EDITOR ================================================================= From: "Mike Riddle" To: "Baker, Christopher" Subject: Fwd: New MS WORD Email spread virus ==================BEGIN FORWARDED MESSAGE================== >From: Frank Cox >Subject: New MS WORD Email spread virus The official MICROSOFT web page acknowledges that their wordprocessor, WORD (all versions) and their Internet mail product, MSMAIL are vulnerable to another macro type virus that CAN be spread by Email described as follows: ShareFun.A Virus Information ShareFun.A is a new virus that utilizes MSMail and Microsoft Word to spread itself three-fold throughout your email network. Also known as the "ShareTheFun" virus, it is spread by using MSMail email messages and attaching itself as an embedded document. The subject line of the email reads "You have GOT to read this!" ShareFun.A is a WordBasic virus, running in Word 6 and Word 95. It has also been found in Word 97 Visual Basic for Applications (VBA), after the infected Word 95/6.0 document has been opened in Word 97. The virus runs and infects the Word environment whenever an infected Word document is opened. Details are available at: http://www.microsoft.com/word/freestuff/mvtool/virus_fun.htm Frank Cox Chief Deputy Public Defender, Marin County Hall of Justice, Rm 139 San Rafael, CA 94903 voice: 415 499 6340 fax: 415 499 6898 fcox@marin.org http://midas.co.marin.ca.us/mc/pd/index.html ===================END FORWARDED MESSAGE=================== ----------------------------------------------------------------- FIDONEWS 14-16 Page 3 21 Apr 1997 ================================================================= ARTICLES ================================================================= Eating Crow - A FidoNet Diet By: Clay Tannacore 1:372/4 For the last several months I have from time to time been engaged in writing guest editorials for FIDONEWS. You on the other hand have been condemned to either reading them, or scooting past this section, so that you might indulge yourself in the technical aspects of FidoNet, one of the most celebrated portions of FIDONEWS, assuredly. Of course, you haven't been entirely immersed in the body of knowledge (aka technologies) of FIDONEWS, by no means. Some of you fine, fellow SysOps have instead been preoccupied with *flaming* me via NetMail, in various Echoes, and by even placing late night calls to my home. Why? Well, it's simple. I have had the audacity to question FidoNet, and POLICY 4. Apparently these subjects are taboo, if the writers opinion varies in any way from standard operating procedures, or the status quo. I obviously stumbled into the area of our association reserved exclusively for *The Blessed Ones* of our brotherhood. Because of this unholy transgression, I have been placed on a diet of *CROW*. That's right, I am now "eating crow" as my mainstay, my only allowable meal until I learn to communicate with the masses, and conform to the mind set of the majority. I must undergo *reprogramming* in my mental attitude towards FidoNet, POLICY 4, and any imbecilic procedure that is contrived by the *Almighty* powers that be. So, henceforth I will *not* indulge in any criticism, animadversions, or any other commentary concerning FidoNet, nor will I even express my opinion that POLICY 4, requires unequivocal modifications. No longer will I be the *one* dissenting voice in this association. Now that I find total harmony alive and well in FidoNet. Now that I have been shown the *proper* path I must take to coexist in this federation. Now, I resign myself to becoming assimilated into the *true* brotherhood of Fido Net SysOps. No longer will I allow my testosterone to rule me. I will become yet another cretin in the fraternity of SysOps, in the land of FidoNet. . . All the above crap aside, I *have* decided to *shut up* (loud applause) and leave well enough alone. I have been gutted by Network Coordinators, an RC or two, and more damn SysOps than are listed in the NODELIST. So, with *everybody* telling me how wrong I am about POLICY 4, and FidoNet as a hole (OOPs, I meant whole), and with only a few (about 4 percent) SysOps in agreement with my views, I think it is time I faded off into obscurity and allow you folks who read this news-letter, to get a bigger dose of FTSC-0001 type literature to digest from now on. I do want to thank all of the guys/gals who have had to suffer through my odious attacks on POLICY 4, and the general *C structure of FidoNet. I never *really* expected to see any changes made in the way this association is operated. I was, however hoping that will FIDONEWS as my outlet, some positive dialog would evolve. Some did, but only for a short time. Then it seemed that the voices that were FIDONEWS 14-16 Page 4 21 Apr 1997 raised, dissolved. Either because of disappointment when noting was seemingly getting done , or because of inter network intimidation. Whatever the case, as expected, nothing has changed. The new motto for FidoNet, and the old motto, is still; "STATUS QUO for FIDO", sung to the tune of "God Bless Armenia" (and that ain't America). . . While I'm thanking people, let me thank a guy who has (probably) the least appreciated job, in this organization. Chris(topher) Baker, the Editor of FIDONEWS. I know this guy has spent enough of his personal money on phone calls alone, to place a substantial down payment on a 98 Mercedes. A damn shame too, in my opinion. I think each Net in *every* region should help support FIDONEWS, with a once a year contribution of say, ten cents per node per month, or a one time a year payment by the SysOp of one dollar ($1.00). Now, this one should get me a group of new words to add to my vocabulary. . .[smile] So long folks, See All of You, On The Internet. . .(BS) ----------------------------------------------------------------- FIDO Toes Up by Tom Johannsen, 1:104/540 Has anyone paid attention to the size of the nodelist lately? It's shrinking. Why? The internet? Lack of interest? Politics? Technology? None of the above? How about all of the above. I've been in FIDO almost since it's inception. I watched it grow until it broke the nodediff processors and sent everyone back to the drawing board. I've watched the in-fighting and the birth of the term Fight-o-Net. I've watched the gradual decline of the comradeship, the friendship, that was the purpose of FIDO to begin with. I can remember a time when you could actually call the (now zc) on the phone and get help with anything you needed. He actually listened, he MADE time for you. I watched FIDO grow from a hodge-podge collection of BBS' to the formation of nets to the ultimate - zones. Now nodes in the U.S. are declining so fast that the growth of other zones cannot even keep up with the attrition. Zone 1 is now outnumbered. The reason? All of the above. FIDO is being overrun by "all of the above". The INTERNET because of it's easy accessibility, it's timeliness of both files and responses. You can send and receive response messages clear around the world in less than a day. You can chat with anyone anywhere, you can get the most recent files written. You don't need to even keep any archives. The i-net has it all. EXCEPT for friendliness. It's very antiseptic. You rarely ever meet the people you come into contact with. The LACK OF INTEREST is due primarily because of selfishness and greed. People don't run BBS' or call BBS' for the fun factor, as they used to. Most sysops that are just starting out in FIDO now do it for purely selfish reasons. They already know what they are getting into and have decided to *use* fido to get what they want, whether it is FIDONEWS 14-16 Page 5 21 Apr 1997 files or echos or experience. A very few do it "just for the fun of it" and they rarely last over a couple of years. They soon find out just how bad it REALLY is. They volunteer to be a hub or become an NEC or NC. Then reality hits. They find out just how little anyone cares in FIDO. The POLITICS have caused a large part of the attrition. Policy 4 was initially written to act as a GUIDE to helping people in the net. Now it's used more as a CLUB to pound with. It's selectively enforced and NEVER fairly. Policy 4 is in shambles. It needs re-writing. When it was written we foresaw growth, but not to the extent that actually occurred, particularly in the area of echomail. However, P4 will never be redone. Why? Laziness and Politics, along with apathy and resistance to change. Instead of creating a document that would promote the growth of the net, the only thing I see are inputs that are submitted by someone "with an axe to grind". Or I see someone with a good idea being shot down by someone without a clue as to why FIDO exists. There is no ACTIVE participation by anyone that can get the job done. They lurk, they read, but they don't participate. Why? Because it might tarnish their image to align themselves with an unpopular idea. So long as they don't have the "moxy" to stand up and go for it, P4 will *forever* be P4. The TECHNOLOGY of FIDO has fallen terribly short of reality. There was a time when FIDO sysops were asked for help on many cutting edge programs/equipment. Now???? When was the last time you saw a 300 baud modem? Statistics say that there are 2323 of them out there somewhere. There's a whole 9 (count 'em, nine) 1200 baud modems and so on to 9600 baud modems. Of those listed as 9600, roughly 2/3rds are v.34 types. Why does the nodelist not reflect the true speeds? Politics? Laziness? Or some other lame excuse. Other nets have been using true speeds for some time now in THEIR nodelists. Why can't FIDO? Don't ask someone. They will tell you that it's because some software cannot handle them. Technology??? If that's the case then why don't they update the software? However, we know that's not the case. If it were then how is it the other nets use the same software and get the job done. In Summary. FIDO is a dinosaur with it's brain in it's tail. The problem is that the tail was cut off and the message hasn't reached the rest of it's body yet. If it doesn't learn to adapt and improve it's technology, it's dead (or close to it), for zone 1 at least, and just doesn't know it. The only thing the sysops of FIDO can agree on is to DISagree. This DISagreement is DISagreeable and DISgraceful to those that have any pride left. Others just don't care I guess. It's a shame. No one in FIDO seems to care what image FIDO has. I've become a minority. All those years of work on building and promoting FIDO by myself and other "old-timers" has gone for naught. Others that really CARED have already left. Even the founder is no longer in the nodelist. Maybe Tom J. was right. I know that soon I'll follow the rest of the "old-timers" and leave FIDO. Why? Because it is beyond help. It has become Deaf, Dumb, and Self-Serving. Fresh FIDONEWS 14-16 Page 6 21 Apr 1997 ideas are voiced to deaf ears. Software writers are leaving because of the dumb antiquated technology and requirements. Improvements are frowned on OR ignored. New concepts or new ideas are rejected out of hand. Am I bitter? NO! Am I "out to get someone"? NO! Am I sad? Yes. Roll over FIDO, point your toes up, get comfortable, and play dead. Actually, the FIDO I knew is not playing. It IS dead. ----------------------------------------------------------------- FIDONEWS 14-16 Page 7 21 Apr 1997 ================================================================= COLUMNS ================================================================= Lock and Load: Guerilla Marketing for BBSes Robert Parson 1:3822/1 I hope you did your homework. In our last column I asked you to collect up information about your local newspapers and radio and tv stations, and advised you we would be sending them some information. Those of you who have since also downloaded the "BBS Guide to Public Relations" probably know what I'm going to talk about next. That's right, we're going to talk about News Releases. The News Media is your friend. Yes. They really can be. I know that the image of BBSes in the media is not generally a happy one, but you can turn that around with a grass roots effort. All it takes is your wordprocessor and your fax modem. Anyone who's seen a movie or tv show about journalists knows that there are five "W's" that must be answered: Who, What, When, Where, and Why. You don't need to write a lot to get all those in. I once wrote a news story about a traffic fatality in two sentences. ("A 68 year old (city) man was killed in a traffic accident today. Police say (name) slipped off a curb at (street) in (city) and was hit by a car driven by (another name).") The main issue, though, is that there must be something going on. You can't just say "Joe Blow invites everyone to call his BBS." You could, but it means nothing. What is going on at your BBS that might entice someone to call? How about some recently added Fidonet Echos? Now you have something. So crack open that wordprocessor and let's crunch some words. First, you need a headline. Something like "NEWSBOB BBS EXPANDS" Now, the news release. (I'm making up some echos here, obviously) "NEWSBOB Computer Bulletin Board System (BBS) has added several new message areas that are share messages with BBSes around the world. The new areas are 'Newsbob,' discussions about Award Winning Broadcast Journalist Robert Parson; 'Bobmobile,' discussions about his car; and 'Bobsquad,' discussions about his wife and three children. "The message areas are shared internationally, or 'echoed,' with roughly 25 thousand BBSes through FIDONet, the oldest and largest amateur message network. Fidonet carries messages with topics ranging from abortion to zymurgy. "NEWSBOB BBS can be reached by anyone with a computer by dialing XXX XXX XXXX with their modem. "For more information call Robert Parson at XXX XXX XXXX" FIDONEWS 14-16 Page 8 21 Apr 1997 Let's break this down into its five components: Who, which in this case is a thing: Newsbob BBS. What: New Echos. When: Recently (not stated, but understood). Where: locally, or alternatively, in Cyberspace (that is an actual place now, according to the latest Associated Press style). Why: expand the offerings of the BBS. You don't have to be a particularly brilliant writer. But if you include all the necessary information, your News Release will, at the very least, be readable. There's also information about how the echos are distributed, how to get on the BBS, and just as importantly, how to get hold of someone to talk to in case a reporter has some questions. In most cases, if there is now contact information, a News Release will be dumped into the trash. Make sure your News Release is checked for spelling. Although it probably won't be dismissed out of hand for spelling errors, it does look unprofessional. And professional is the image we're shooting for, right? Finally, try to keep your News Release to one page. Most reporters will read the first couple paragraphs and act on it, file it, or trash it. Now print it out on that letterhead you ordered (or designed on your DTP), and drop it in the mail to the media contacts you made in your previous calls. Yes, you can send a fax if you prefer. Do NOT expect anyone to call, and do NOT expect your News Release to result in a story in the paper or broadcast media. You are competing with the normal news of the day, plus possibly hundreds of faxes and letters from others trying get space or airtime. A couple years ago, I helped a local BBS wage a Media Campaign. It took about two months of weekly faxed News Releases before it finally resulted in a story. There are other things you can have in a News Release besides additions to your BBS. You could include anticipation of the 10 thousandth caller (or 100 thousandth, or whatever), with a follow up of who that person was. A gaming tournament. My favorite: local angles to national stories. For instance, I contacted a local Internet Service Provider this year to see if it was having the same connection problems AOL was having due to the explosive growth of the Internet (they claimed they weren't). Be creative with your topics for News Releases. Nearly anything your BBS is doing can become a possible news story. It's simply a matter spinning it correctly. Next time, we'll talk about how to handle those media scallywags. Robert Parson ----------------------------------------------------------------- FIDONEWS 14-16 Page 9 21 Apr 1997 ================================================================= GETTING TECHNICAL ================================================================= [This is part of the continuing series of FidoNet History articles highlighting the FidoNet Technical Standards and Proposals that guide the programmers who make our hobby operate. They have been reformatted to 70 columns where required and any tables may be askew as a result. Node numbers and phone numbers may be out of date.] Ed. Document: FSC-0059 Version: 001 Date: 08-Mar-1992 Newsgroup Interchange within FidoNet Jack Decker 1:154/8@fidonet A proposed standard for the interchange of USENET News messages among FidoNet nodes. Status of this document: This FSC suggests a proposed protocol for the FidoNet(r) community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited. Fido and FidoNet are registered marks of Tom Jennings and Fido Software. Introduction: This document defines the standard format for the interchange of USENET news messages among FidoNet nodes. It incorporates by reference the document RFC-1036, "Standard for Interchange of USENET Messages" by M. Horton of AT&T Bell Laboratories and R. Adams of the Center for Seismic Studies. A copy of RFC-1036 should be included in the distribution archive of this standard. However, RFC-1036 is NOT applicable in its entirety to FidoNet. Therefore, unless specifically referenced elsewhere in this document, only section 2 of RFC-1036 should be considered part of this standard. Section 3, which deals with "control messages", may be implemented in FidoNet on an optional basis, and if processing of control messages is included in a FidoNet implementation, it should be done in accordance with section 3 of RFC- 1036 to the extent possible. Section 4 of RFC-1036 is *NOT* applicable to FidoNet (except for section 4.3, which will be discussed later) and therefore is NOT included as part of this standard. Section 5 of RFC-1036 is a treatise on the News Propagation Algorithm used within UseNet, and should be studied even though it is not directly applicable to FidoNet, in particular because it contains a discussion on the prevention of loops (what we in FidoNet commonly refer to as "dupe loops"). Please note that FidoNet implementations do not recognize nor support what is referred to as the "old format" or the "A format" in section 2 FIDONEWS 14-16 Page 10 21 Apr 1997 of RFC-1036. The goal of this document is to define a standard for the interchange of news messages between FidoNet nodes in a format that will also be acceptable to UseNet hosts. In order to simplify the creation of software that conforms to this standard, we do not intend to support every news format that has ever existed in UseNet. The standard described in RFC-1036 is used by the majority of UseNet hosts, and therefore it is the standard that will be adopted in this document. This standard will contain three sections: General theory of newsgroup transmission, Format and protocols of batched newsgroups, and the translation of newsgroup messages to and from FidoNet message format. 1. General theory of newsgroup transmission: Prior to the introduction of the DoveMail program, the usual method of gating a UseNet newsgroup into FidoNet was to convert it to FidoNet echomail, and then send it to "downstream" nodes in echomail format. This method is still used at the majority of gateway systems at this writing. Unfortunately, no conversion process is perfect, and some useful control information is usually lost in the conversion. In addition, most FidoNet echomail processors don't handle long messages (which are fairly common in newsgroups) well at all, and many gateway systems either try to split these messages into multiple parts (a somewhat awkward process) or discard them entirely. Because the duplicate message detection algorithms used in many FidoNet echomail processors incorrectly identify some of the parts of a split message as duplicates, parts of long messages often get "lost" when transmitted as echomail. Also, UseNet allows a message to be posted to multiple newsgroups, and when such messages are converted to echomail, it may be necessary to create multiple copies of the message (one for each echomail area that it would be placed in), thus increasing the transmission time for such messages. Even normal-length newsgroup messages may be falsely discarded as duplicates by some "downstream" echomail processors. The reason this is a particular problem in newsgroups converted to echomail is because some echomail processors use a checksum of parts of FidoNet message headers to determine if messages are duplicates. Since all newsgroup messages are assumed to be addressed to "All", and since some gateway software uses the date and time that the message was converted to echomail rather than the original date and time from the message, it's quite possible that the remainder of the message header contains information that is similar enough to information in another message's header to cause it to be discarded as a duplicate message. This happens far more frequently with converted newsgroup messages than with messages originally entered as echomail. Finally, when a BBS user enters a reply to a news message that has been converted to echomail, in many cases the information is simply not available in the original message to generate a proper "References:" line in the reply, as required by RFC-1036. If the original message contained a "Followup-To:" line, which requires that replies be posted to a different newsgroup than the one in which the FIDONEWS 14-16 Page 11 21 Apr 1997 original message was entered, this line may not transmitted in the message as converted to echomail. And even if this information is available, no echomail processor currently available will modify the reply message as required (to add the "References:" line where necessary, or to move the message to a different area if it is a reply to a message that contained a "Followup-To:" line). Under this proposed standard, none of the UseNet message header information is lost in transmission between nodes, and reply messages can be generated that conform to UseNet specifications. If a message is posted to multiple newsgroups, it is only transmitted once (instead of multiple times as it might be if converted to echomail). Also, long messages are not truncated or changed in transmission between nodes, and finally, there is no chance that a message will be improperly discarded as a duplicate. The main thing to remember is that under this standard, news messages are never converted to echomail. Echomail is an irrelevant concept in this context, since we are not passing echomail between nodes. Instead, newsgroups are transmitted in the native format specified by RFC-1036, and tossed directly from batched newsgroup packets to the FidoNet message format (e.g. the *.msg format) if necessary. Keep in mind that most FidoNet BBS software uses the same general format not only for echomail messages, but also for netmail and local message areas, so it is not necessary to transmit messages between nodes in echomail format if another format is more suitable for the type of message being transmitted. 2. Format and protocols of batched newsgroups: When newsgroup messages are transmitted between systems, the individual messages must conform to the specifications of section 2 of RFC-1036, and section 3 of this document. Where section 3 of this document defines a more restrictive standard than RFC-1036, this document shall take precedence. When transmitting news messages between FidoNet nodes, they must be sent in a batched newsgroup file (as described in section 4.3 of RFC- 1036) unless some other format is agreed upon in advance. The transmission of unbatched news messages, or the use of any batching method other than that described in section 4.3 of RFC-1036 shall be considered non-standard. Please note that RFC-1036 section 4.3 refers to this batching process as combining several messages into "one large message", but we will refer to this "one large message" as a "batched newsgroup file", or a "UseNet format mail packet" rather than as a "large message", since FidoNet systems do not normally handle large "messages". When messages pass through a FidoNet system on their way to other nodes, the header lines in the message may be modified to conform with the standards given here. However, the text (body) of a message should NEVER be altered (one exception: Carriage Returns MAY be converted to Line Feeds in order to conform to this standard, but this is neither required nor expected of software). The standard format for sending a batched newsgroup file to other FIDONEWS 14-16 Page 12 21 Apr 1997 FidoNet nodes is as follows: First, as will be noted in section 3 of this document, individual lines of the batched newsgroup file must be terminated with Line Feeds only, and the file must NOT contain Carriage Return characters (ASCII 13). Batched newsgroup files shall be transmitted between FidoNet nodes as files named using the filename ????????.PKU, where the eight character root name can be any of the hexadecimal digits 0 - 9 or A - F. The .PKU extension (which stands for "PacKet - Usenet format") is the news equivalent of the .PKT file used to transmit FidoNet format netmail and echomail between nodes. Batched newsgroup files with the filespec ????????.PKU may be archived into a standard mail archive file (bearing the extension *.MO?, *.TU?, *.WE? ... *.SU?). It is assumed that the receiver of batched newsgroup files will take any necessary steps to make sure that both *.PKU and *.PKT files are extracted from incoming mail archive files before the mail archive files are deleted. In certain cases, this may mean that an external unarchive shell may have to be used, instead of allowing the echomail processor to call the unarchiver (typical external unarchive shell programs at this writing are GUS, POLYXARC, and SPAZ). A batched newsgroup file awaiting transmission may be stored in a FidoNet system's "outbound" area in uncompressed form, prior to being archived for transmission or sent in uncompressed form. It is suggested that when a system uses the .OUT extension to indicate an uncompressed netmail or echomail packet, the .UUT extension be used to indicate an uncompressed batched newsgroup packet. It is expected that a .UUT file in a system's "outbound" area will be treated in much the same way as an .OUT file, except it will be renamed to a file with an extension of .PKU (rather than .PKT) before being archived into the mail archive. This implies that the root name of the .UUT file will contain the net number and node number of the destination system, expressed as four hexadecimal digits each for net and node numbers, in the same manner as the root name for a FidoNet .OUT file is constructed. The root filename of the *.PKU file should be an eight digit hexadecimal number, with leading zeroes used if necessary, in order to make an eight character root filename. It is suggested that this hexadecimal number be based on time of year, with 00000000.PKU generated at exactly midnight on January 1 and FFFFFFFF.PKU generated at just a moment before midnight on December 31. However, it is permissible to use the same algorithm that is used to generate the root filename for *.PKT files. The normal sequence for transmission of messages between FidoNet nodes might then be described as follows: a. Messages created on the originating system are placed into a batched newsgroup file conforming to the specifications of RFC-1036 section 4.3. When this batched newsgroup file is destined for another FidoNet node, it will have a filename of the format: FIDONEWS 14-16 Page 13 21 Apr 1997 [4 hex digit net number][4 hex digit node number].UUT This file will then be placed in the outbound mail area for packing. b. A mail packing program will examine the outbound mail area and, upon finding the .UUT file, will rename it to a file with an extension of .PKU, and then shell to a compression program in order to place the *.PKU file into a new or existing mail archive file for the destination node. Mail archive files bear extension names consisting of the first two letters of a day of the week (in the English language) plus a numeric character in the range 0 - 9 (for example, .MO5 or .TH7). The method of compression for the mail archive is as agreed upon between the originating and destination nodes. No "standard" method of compression for the mail archive is specified in this document. NOTE: If the compression program fails for any reason (such as running out of disk space), the mail packing program MUST rename the .PKU file back to the original *.UUT filename before exiting. Since batched newsgroup files do not contain a header that indicates the destination node, there would be no way to determine the proper destination node if the file were not renamed back to the original filename. c. The mail archive is transmitted in the usual manner by a FidoNet compatible mailer, or such other means as may be agreed upon in advance by the sysops of the originating and destination nodes. d. At the destination system, the individual files are extracted from the mail archive. *.PKT files are processed in the usual manner to extract any netmail or echomail messages, while *.PKU files are processed by software designed to handle batched newsgroup files. In this context, such files could be "handled" by re-processing the messages and batching them to be sent on to one or more additional node(s), or by tossing the messages to the local message base, or both. Please note that this standard does not anticipate that batched newsgroup files will be converted to FidoNet echomail at any point along the way. It is realized that this may indeed happen, but such conversions should be considered as something to be avoided if at all possible due to the problems discussed in section 1 of this document. 3. Translation of newsgroup messages to and from FidoNet message format: NOTE: Where applicable, the standards defined in this section for messages shall apply not only to locally created messages, but also to all messages sent to "downstream" FidoNet nodes. In this context, "FidoNet message format" means that format in which messages commonly reside on a FidoNet BBS. At this writing, there are three formats commonly used for message storage on FidoNet systems, but other formats may be in use as well. The three most common formats are the "*.msg" format as used by the original Fido program (and a host of programs since), also commonly referred to as the "single message per file format"; the "Hudson" format, used by QuickBBS, Remote Access, and some other products; and the "Squish" FIDONEWS 14-16 Page 14 21 Apr 1997 format used by the Maximus BBS and the "Squish" echomail processor. Because there are so many message formats, some other programs have taken the approach of trying to convert UseNet news into echomail, creating *.PKT files which can theoretically be processed by any FidoNet system. However, since the *.PKT files are processed by the echomail processor, all the limitations and pitfalls associated with converting newsgroup messages to echomail come into play. The preferred way of handling incoming messages would be to have the BBS (or message reader/editor) software directly read batched newsgroup files. In this way, the files would not have to be "processed" per se. As new batched newsgroup files arrived on a system, they could simply be concatenated to the existing message base, and then a utility could be run that would build an index to the message base, in a manner somewhat similar to the way "flat file" message bases are currently implemented on some BBS's. Of course, you'd need to occasionally run a utility to delete old messages in order to keep the message base from growing too large, and new messages entered on the system would have to be exported from the system in a separate batched newsgroup file. However, at this writing no FidoNet-compatible BBS or message editor is capable of directly reading a batched newsgroup file. The second most preferable method is to convert news messages directly to the message format used by that system. At this writing the DoveMail software includes utilities (NewsToss and NewsScan) that can convert batched newsgroup files to and from messages in the *.msg (single message per file) format. It should be possible to convert batched newsgroup files to and from other FidoNet message formats as well. The method in which messages are stored on a BBS, and the method in which it is determined which new (locally-entered) messages need to be exported from the system will necessarily be implementation-specific. One method that can be used with *.msg type message bases is to maintain a "high water mark" in 1.msg, similar to the "high water mark" used for echomail messages, and additionally to mark messages received from other nodes as "sent" when they arrive, and locally- entered messages as "sent" when they have been exported, and to never re-send a message marked as "sent". When tossing incoming messages, duplicate messages can be detected by comparing the contents of the "Message-ID:" line with those of previously received messages. This may be slow processing considerably, however, and would require storage of a history file of "previously seen" messages. Another method is to look in the "Path" line and see if we are already listed in the path; if so, the message is a duplicate and should be deleted. This method is faster and does not require maintenance of a history file, but will not guard against duplicate messages arriving from one's feed that have not passed through the system twice (for example, a message that arrived from two different paths). Fortunately, UseNet folks seem to understand the need for proper topology, so those types of dupes are relatively rare. FidoNet sysops taking UseNet feeds must understand that it is IMPERATIVE that a feed of any one newsgroup be obtained from only ONE FIDONEWS 14-16 Page 15 21 Apr 1997 source, especially if they are then passing that newsgroup to any "downstream" nodes. This absolutely does NOT imply that geographic restrictions on newsgroup distribution are necessary or desirable! Additional comments on preventing "loops" can be found in section 5 of RFC-1036, in the discussion of the News Propagation Algorithm. Please note that only two methods of loop prevention are included in this standard: 1) The history mechanism. Each host keeps track of all messages it has seen (by their Message-ID) and whenever a message comes in that it has already seen, the incoming message is discarded immediately. 2) Not sending a message to a system listed in the "Path" line of the header, or to the system that originated the message (which, in practice, should be listed in the Path line). No other methods of dupe loop prevention are acceptable. In particular, checksums of portions of the message header or message itself are NOT permitted to be used for loop prevention, except perhaps as a method to quickly identify POTENTIAL duplicate messages before doing a full string comparison with the Message-ID data in the history file. In no case should a checksum be used as the SOLE method of determining whether a message is a duplicate. When newsgroup messages are created for transmission to other systems, or when received messages are transmitted other systems, the individual messages must conform to the specifications of section 2 of RFC-1036. However, in order to simply programming of software designed to handle such messages, the following modifications to the standard are proposed for use within FidoNet. Please note that these are slightly more restrictive than the standard permitted by RFC-1036: a. The "old format" or "A format" described in section 2 of RFC-1036 is NOT supported in FidoNet. Only the format detailed in RFC-1036 (sometimes referred to as the "B" News format) is supported. The vast majority of UseNet sites currently use the "B" News format. b. The UseNet standard permits the use of "white space" to separate certain items in the message header, with "white space" defined as blanks or tabs. It also states that "the Internet convention of continuation header lines (beginning with a blank or tab) is allowed." However, it should NOT be ASSUMED that "continuation header lines" will be used in any message. It is suggested that when creating newsgroup messages for transmission to other systems, the use of tab characters be avoided in header lines, and that "continuation header lines" NOT be used, even if this means that a header line will be considerably longer than the length of a screen line. Software that creates FidoNet-format messages (for display to BBS callers) from batched newsgroup files (that is, newsgroup message tossers) should break up such extra-long header lines, using a single space character ONLY (NOT a tab!) at the start of "continuation header lines." Since batched newsgroup files received from