Volume 7, Number 4 29 January 1990 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief: Vince Perriello Editors Emeritii: Dale Lovell Thom Henderson Chief Procrastinator Emeritus: Tom Jennings FidoNews is published weekly by the International FidoNet Association as its official newsletter. 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. Copyright 1989 by the International FidoNet Association. All rights reserved. Duplication and/or distribution permitted for noncommercial purposes only. For use in other circumstances, please contact IFNA at (314) 576-4067. IFNA may also be contacted at PO Box 41143, St. Louis, MO 63141. Fido and FidoNet are registered trademarks of Tom Jennings of Fido Software, 164 Shipley Avenue, San Francisco, CA 94107 and are used with permission. We don't necessarily agree with the contents of every article published here. Most of these materials are unsolicited. No article submitted by a FidoNet SysOp will be rejected if it is properly attributed and legally acceptable. We will publish every responsible submission received. Table of Contents 1. EDITORIAL ................................................ 1 Sorry about that! ........................................ 1 2. ARTICLES ................................................. 2 A moderated echomail conference processor (pt.1) ......... 2 Third Annual PMFCLP Announced! ........................... 11 3. FOR SALE ................................................. 15 BBS Fax Server for Sysops and Users ...................... 15 CIMN Update .............................................. 18 4. LATEST VERSIONS .......................................... 20 Latest Software Versions ................................. 20 5. NOTICES .................................................. 23 And more! FidoNews 7-04 Page 1 29 Jan 1990 ================================================================= EDITORIAL ================================================================= It appears that sometime this weekend my system in Connecticut decided to take a break from its busy schedules and, well, "crash" might be the right word. Now this may not seem like too big a deal, except that I currently spend most of my time (and in fact reside) in New Hampshire, where I am now employed. And I was unable to get my sister on the phone to go see what my little toy computer system was up to until today. That's not good. I was really proud of the fact that I got the FidoNews out by midnight every Sunday. I guess that's the way things go. But I apologize to anyone who is inconvenienced in any way by this delay. I'm also setting up a backup strategy. I have arranged to have a system which is regularly maintained (meaning its SysOp actually can and usually does reach out and physically touch it every day) set up as a routing point for FidoNews submissions and F.Req's. So there will be a change in the 1:1/1 listing, specifically for the purpose of assuring that I get stuff for FidoNews on time to produce it every week --- and also to assure that you will be able to get that file when you call. I don't expect this situation to repeat itself. I'm truly sorry it even happened once. ----------------------------------------------------------------- FidoNews 7-04 Page 2 29 Jan 1990 ================================================================= ARTICLES ================================================================= Jack Decker 1:154/9, 11:154/8 A MODERATED ECHOMAIL CONFERENCE PROCESSOR -or- MY TWO BITS' WORTH This article describes a proposed improvement to echomail that would require only minor modifications to existing software (but if you want a greater programming challenge, I will make some additional suggestions later). HISTORICAL BACKGROUND A little over a year ago, an alternative to echomail was introduced called "GroupMail". The original GroupMail program was designed and released by System Enhancements Associates (SEA), Inc. GroupMail offered some advantages over echomail, but also had some drawbacks. Some of the advantages included fact that SEEN-BY's did not need to be included in the messages (considerably reducing the size of messages as transmitted), that the possibility of generating duplicate messages was reduced to nil (as long as the conference wasn't ported to or from echomail!), and that conferences could be fully moderated. Some of the disadvantages were that conferences could be fully moderated (some saw this as "censorship"), a separate GroupMail processor was needed (meaning you had to run two separate conference mail processors if you wanted to run both GroupMail and Echomail), conferences were sent via a "File Update Request" mechanism that some software didn't support, one or more small packets were sent for each conference (rather than one large packet containing all conferences - this increased connect time required to obtain conferences), and GroupMail packets could only be sent in ARCed format (a more efficient archiving method, such as ZIP or LHARC could not be used). Because of these and other factors, GroupMail gained wide acceptance only in Alternet, and then only in Alternet within the United States. One of the reasons that GroupMail may not have gained acceptance was that it was created by System Enhancement Associates. At the time of GroupMail's introduction (right after the conclusion of the infamous SEA vs. PKWare lawsuit), several sysops in Fidonet expressed a low opinion of SEA... and a number of sysops felt so strongly anti-SEA that they refused to use any SEA products, or even carry SEA products on their boards for downloading. This anti-SEA sentiment probably caused some sysops to refuse to even consider using GroupMail. FidoNews 7-04 Page 3 29 Jan 1990 A larger problem, however, was that GroupMail processors were not available for all the various types of hardware configurations that are now participating in Fidonet-technology networks. Thus, in some cases, GroupMail had to be converted to standard echomail in order to provide feeds to those systems. For some reason, this conversion process didn't always work perfectly, with the result that many duplicate messages were generated at the points where these conversions took place. Since GroupMail processors were created with the assumption that duplicate messages could not occur, no dupe checking was performed by GroupMail processors. Some sysops abandoned the use of GroupMail due to the number of dupes created in the GroupMail-Echomail conversion. Now, suppose that you could have all the advantages of GroupMail with none of the disadvantages? Would you like to get conferences without nine or ten lines of SEEN-BY's in each message? Would you like to get these as part of your regular echomail delivery, and not have to run additional software (beyond what you use with normal echomail) to handle these conferences? Would you like to participate in moderated conferences, where the moderator actually has the power to keep the "twits" from posting messages? (I'll have more to say about conference moderation vs. "censorship" later). My proposal (which I'll call "moderated echomail"), in its most basic form, makes two very minor changes to the way echomail is currently handled: 1) TWO BITS are reserved in each message header to indicate whether a message is true echomail, upbound to the moderator's system, downbound from the moderator's system, or local only. 2) Echomail processors are modified slightly as shown below. THE ADDED TWO BITS The first question is, where do we put these two bits, and what are they used for? Consider a typical message header, which includes the following information: MsgHType = Record fromUser : array[1..36] of Char; toUser : array[1..36] of Char; Subject : array[1..72] of Char; datetime : array[1..20] of Char; timesRead : Word; DestNode : integer; OrigNode : integer; FidoNews 7-04 Page 4 29 Jan 1990 Cost : Word; origNet : integer; Destnet : integer; DestZone : integer; Origzone : integer; filler : Array[1..4] of char; Backlink : Word; Attribute : Word; FwrdLink : Word; end; Note that the above header record structure is as used by Henk Weavers in Dutchie, and includes integers (2 bytes each) for originating and destination Zone information followed by four bytes of "filler". Originally, these eight bytes were supposed to be used for two 32-bit timestamps showing when the user originally wrote the message, and when the message arrived on-line (?) but it appears that hardly anyone ever actually used them in that manner. Unfortunately, we can't count on the four "filler" bytes being set in any particular manner and there's always the possibility that someone may actually be putting a timestamp there. However, note the "Cost" field above. Virtually no one uses it in any case, but it's totally meaningless in an echomail message. Therefore, I propose that top two bits of the second byte of this cost field be reassigned for use in echomail messages only (this would NOT change the specification for netmail at all): Instead of: Cost : Word; We'd use: Filler : Char; EchoMsgType : Char; Where the echo message type would be defined as follows: Bits 5-0 Reserved for future use Bits 7-6 Used as follows: Bit 6 Bit 7 ----- ----- Regular Echomail 0 0 Moderated echomail upbound to moderator 1 0 Moderated echomail downbound from moderator 0 1 Local message 1 1 Note that the above scheme gives us compatibility with existing echomail, because most echomail processors now simply stuff a zero byte into this field. So if we are connecting with a board that doesn't know about this new scheme, we'll still be able to do regular echomail with them. FidoNews 7-04 Page 5 29 Jan 1990 A bit of explanation about the four possible message types that can be indicated by this scheme: Regular echomail is what we're all getting now. It's totally unchanged from the present system of echomail distribution. Moderated echomail upbound travels only in an upbound direction to the moderator's system. When a message is entered locally, Bit 6 is set and from there on the message travels upstream only, and only to one system (your feed for the conference). Moderated echomail downbound travels only in a downbound direction to systems that you feed. It is never sent back upstream to the moderator's system (that would cause dupes). Local messages never leave the board on which they're posted. They are simply ignored by the echomail processor. This would allow the Sysop of a board to post a message to users of a particular echo (a notice that the echo feed will be interrupted, or perhaps a permanent post of the conference rules) without that message being exported to any other board. MODIFICATIONS TO THE CONFERENCE MAIL PROCESSOR In the following discussion, I'm going to use a sample fragment of an AREAS.BBS file, as currently used by ConfMail and several other programs. All node numbers used as examples are picked at random for example purposes only. Lets say that you're getting the FOR-SALE conference from 123/4 and feeding it to 398/2, 321/7, and 234/999. Your entry in the AREAS.BBS file would look something like this: D:\MSG\FOR-SALE FOR-SALE 123/4 398/2 321/7 234/999 Now, if the FOR-SALE conference remained as regular echomail, the above line could remain exactly as shown above with a moderated echomail processor. It would be treated exactly as it is today. But, suppose that it became a moderated conference. In that case you might use something like the following: D:\MSG\FOR-SALE FOR-SALE -u123/4 -d398/2 321/7 -e234/999 As you see, switches have been added to indicate that various nodes are to be treated differently. While each author of an echomail processor might use a different method to achieve the same result, I would suggest that a typical echomail processor might allow the following switches (note that the use of ANY of these switches [with the possible exception of -a or -p] indicates that the conference is moderated echomail as opposed to regular echomail): FidoNews 7-04 Page 6 29 Jan 1990 -a My address - if used, overrides the defaults in CONFIG.DOG or MAIL.SYS (or whatever). Use this address when adding an ORIGIN line or adding to a PATH line in messages in this conference (if more than one address follows this switch, use the first in the ORIGIN line but insert all into the PATH line. Normally there should never need to be more than one address following this line, but multiple addresses should be allowed for coping with unusual circumstances). -d Addresses following are "downlinks" (nodes you feed the conference to). You may or may not have one or more of these (unless you're a moderator, then you must have at least one of these). -e Feed the conference to these systems as regular echomail. This switch should not be used unless absolutely necessary, in order to feed a conference to nodes incapable of running any moderated echomail processors. -m This switch is NOT followed by a net/node, but is used to indicate that YOU are the moderator for this conference. This is mutually exclusive with -u. You must have at least one node listed under a -d switch (if you're a moderator, then you've got to have "downlinks" to feed the conference to!). -p This switch is NOT followed by a net/node, but is used to indicate that this conference is "passthru" (not carried on your system, but passed through to other systems). -u Only ONE address is allowed to follow this switch, and that is the address of your "uplink" (your feed) for this conference. -x This switch is NOT followed by a net/node, and is only valid when the -m switch is also used. It indicates that messages in this conference should be exported any time the "export" function of the moderated echomail processor is invoked (normally, messages in conference areas where you are the moderator would NOT be exported unless a special command line switch is used, in order to give you time to review the messages first. This switch overrides that, and indicates that the messages should be exported any time messages are exported from the areas that you do not moderate). The moderated echomail processor should consider any of the following an error (to aid in dupe message elimination and detecting improper setup): * A -d or -e switch is used but a -m or -u is not * A -m switch is used but no -d switch is used * A -x switch is used but no -m switch is used * More than one node is listed after a -u switch * The same net/node number appears twice in the line FidoNews 7-04 Page 7 29 Jan 1990 Please note that the above listing of switches is just an example of one possible implementation. Various software authors may (and probably will) choose to do things in a slightly different manner. Now lets consider how the moderated echomail processor should handle various situations that may occur. The first caveat is that any duplicate message checking built into the echomail processor should be used with moderated echomail, but keep in mind that moderated echomail WILL pass through some systems twice (once in the upbound direction and again in the downbound direction... but note that only a very small percentage of the total echo traffic will be passed upbound in most cases). So if you are checksumming parts of the message header when checking for dupes, be sure to include the Echo Message Type byte in your calculations (or keep the data for previously seen upbound messages separate from the data for previously seen downbound messages). Please note that the participants of the NET_DEV (Network Software Developers') echo conference have been trying to forge an agreement on some type of standardized message ID kludge line that would be used for duplicate message checking, so you may want to check in that echo conference (or with the Fidonet Technical Standards Committee) to determine if any agreement has been reached in this regard. Also, a moderated echomail processor should never attach SEEN-BY lines to a moderated echomail message EXCEPT when echoing that message to an "echomail only" node as specified by the "-e" switch. In that case, it should attach a SEEN-BY line containing its own address (including any AKA's specified in the CONFIG.DOG or MAIL.SYS file, and/or specified by the "-a" switch). A moderated echomail processor should ALWAYS use a Zone number in PATH line statements (in fact, full four-dimensional Zone:Net/Node.Point addressing should be permitted in the PATH). It should not be necessary, however, to repeat redundant information. For example, a message originating on 1:123/4, going to 1:444/2, then to 1:444/4 and finally to 1:448/7 might have a PATH line that looks like this: ^aPATH: 1:234/4 444/2 4 448/7 The above rule (that the Zone MUST be used) becomes important when you consider the next duplicate message elimination feature: A moderated echomail processor should NEVER send a message to a node that already appears in the PATH line, under any circumstances! In order for this to be effective, two assumptions are made in regard to the PATH line: FidoNews 7-04 Page 8 29 Jan 1990 1) It contains full Zone:Net/Node[.Point] addressing information 2) The moderator's system strips the path line (and starts a new one) before releasing messages to the downbound stream (note that if this is objectionable, the old PATH line could be preserved but the kludge line token changed to ^aUPTH to keep the upbound path line separated from the downbound one). Let's consider what happens when upbound messages arrive at the moderator's system. First, the normal dupe checking is performed. Second, messages are verified as being "good" (okay to toss into the downbound stream) by the following tests: 1) Does the message have the "upbound" bit set? A message should never arrive on the moderator's system with only the "downbound" bit set (if one does, it's probably a dupe and should not be sent back out!). 2) Is the message flagged as regular echomail? If so, then are any nodes in the AREAS.BBS file flagged with the /e switch? If not, it's a bad message, otherwise one of the nodes in the PATH line should match one of the nodes flagged with the /e switch (see below). If the incoming messages meet the above tests, the moderated echomail processor should change the EchoMsgType flag to "Moderated echomail downbound" and strip the existing PATH line from the message (or rename it to ^aUPTH as mentioned above). A new PATH Line should be started containing the Moderator's address. The message should then be tossed to the appropriate message area. Depending on how the system is set up, these messages could be tossed to the downlinks immediately, or could be held until the moderator has a chance to review the messages and cull out any inappropriate ones (this would probably be controlled by a command line or control file option of the conference mail processor). In any event, these messages would be tossed in the same manner as a downbound message sent by any other node (see below). At systems OTHER THAN the moderator's system, the following tests would be performed on incoming messages: First, normal dupe checking would be performed. Then, the EchoMsgType flag would be tested, and action would be taken according to the results of that test: 1) If the message is upbound, any SEEN-BY lines would be stripped, the system's address would be added to the PATH line, and the message would be sent ONLY to the uplink (feed) for that conference. After it has been packed to the uplink, the message should then be removed from the message area (it will come back as a downbound message from the moderator's system). FidoNews 7-04 Page 9 29 Jan 1990 2) If the message is downbound, any SEEN-BY lines would be stripped, the system's address would be added to the PATH line, and the message would be sent ONLY to the downlinks (nodes you feed) for that conference. Note that there are two types of nodes you might be feeding: Those that take the conference as moderated conference mail (specified by the -d switch) and those that take the conference as regular echomail (specified by the -e switch). In the case of nodes that receive the conference as regular echomail, a SEEN-BY line will have to be added containing the system's own address (including any AKA's specified in the CONFIG.DOG or MAIL.SYS file, and/or specified by the "-a" switch). 3) If the message is flagged as regular echomail, but is going into a moderated conference area, then one of the nodes listed in the PATH line (not necessarily the last one) should be the same as one of the nodes specified with the "-e" switch in the AREAS.BBS file. The search should begin with the LAST node in the PATH line and compared to ALL of the nodes specified with the "-e" switch. If the LAST node in the PATH line doesn't match, then the NEXT TO LAST node should be compared, and so on until the entire PATH line has been searched (in a reverse direction). If a match is found, then the message is assumed to be "good" and the EchoMsgType flag should be changed to indicate that the message is upbound, the SEEN-BY line(s) should be stripped, and it should be further handled as any other upbound message (as indicated in #1 above). The only other consideration is what happens when someone leaves a message locally, via the BBS or a message editor. These messages should be flagged as upbound, and have an ORIGIN line and a PATH line appended (if necessary) and then handled as in #1 above. Keep in mind that some BBS programs may append their own ORIGIN, PATH, or SEEN-BY lines which may have to be stripped or checked for validity. Please note that there are a couple of peculiarities of this scheme: First, you can convert a conference from moderated echomail to regular echomail, in order to provide a feed to those nodes incapable of handling moderated echomail. But you simply can't convert a non-moderated (regular Echomail) conference to a moderated one at any downstream point. If you receive the conference as non-moderated, you have to pass it along that way. This makes sense if you stop and think about it. Second, if you convert a moderated conference to regular echomail, the nodes receiving a feed from you will eventually get back a second copy of any message originating on their system (or on the system of anyone else that they in turn echo the conference to). Therefore, they should be prepared to accept the occasional dupe of their own messages when it comes back downstream through your system (normally, their dupe killer will automatically kill it for them). It would be possible to watch for these messages to come back downstream FidoNews 7-04 Page 10 29 Jan 1990 and kill them automatically, but that would require a lot of code and a lot of effort (translation: I can't think of a good way to do it). For this reason, it's a good idea to convert moderated conferences to echomail only for "leaf nodes" (nodes that run conferences on their own systems but don't feed them to anyone else) under your system. If "least cost routing" considerations make it necessary for nodes that you feed as echomail to in turn feed the conference to someone else, you should keep a close eye on the topology to make sure that they aren't feeding the conference back into the network at some other point (the dupe checking and security measures built into this scheme make it very unlikely that they could cause a serious dupe problem, but they could still be running up someone's phone bill or increasing the amount of time someone is spending processing echomail). The above is the basic proposal. Next week I'll discuss an optional addition (an improvement, I hope!) to the above scheme. ----------------------------------------------------------------- FidoNews 7-04 Page 11 29 Jan 1990 * * * A N N O U N C E M E N T * * * Third Annual Poor Man's FidoCon and Lake Party (in TEXAS) --------------------------------------------------------- All SYSOPS and their family, pets, and assorted accoutrements are cordially invited to attend this fine three-day weekend. SPONSOR: Net 106 of Houston, Texas and other friends of our Net. DATES: April 20, 21, 22. [ The Friday, Saturday, and Sunday following EASTER. ] PLACE: Big Creek Park Pavillion (and campsites) on Lake Sommerville in Burleson County, Texas. EVENTS: Volleyball; swimming; boating; fishing; other water sports; chattin'; and eatin'. SATURDAY PICNIC: pot-luck, do-it-your-way communal feast. There may be a special treat in-addition to the regular fare. Come and try it! BIKE RIDE: Saturday morning Early Bird Tour and Ride through the Deer Meadow. CAMPING: Six campsites are with the Pavillion. There are a good number adjacent to the Pavillion Point. Well-lit,clean, maintained restrooms are nearby. Water is also available; but no electricity at the Pavillion. Here are DIRECTIONS to the Region 19 Picnic: From OKC: Take IH35 thru Dallas or Ft. Worth to WACO. In Waco,take Hwy 77 to CAMERON. Go left on TX 36 to CALDWELL. About 10 miles south of Caldwell on TX36 is LYONS. On the north edge of Lyons turn right onto FM 60. You should see a sign for Big Creek Park. Its about 6 - 8 miles from Lyons. Turn left onto the road to the park. From Austin: Take US 290 East approx. 89 miles to BRENHAM. At the west FidoNews 7-04 Page 12 29 Jan 1990 edge of Brenham, turn left onto TX36 and go north approx. 20 miles thru the town of SOMMERVILLE to LYONS. Turn left at the second road which should be FM 60. From Dallas: Follow same directions as for OKC. From Ft. Worth: Follow same directions as for OKC. From Arkansas: Take IH30 west to DALLAS and then take IH35 (east) south and follow the OKC directions. From Louisiana: Take IH10 to HOUSTON. Take 'Loop 610 North' around the edge of the inner city. You'll cross US 59 and then IH45. Keep going. Take US 290 towards Austin. It's 73 miles to BRENHAM. Follow the bypass around town. It becomes TX36. Do not turn to follow US 290 to Austin. Stay headed North. Approx. 18 miles northeast, you'll pass thru the town of SOMMERVILLE. There is one motel here. Continue thru town and over the rise to the little crossroads berg of LYONS. There are two places you can turn left. Take the second one. This should be FM 60. Approx. 8 miles to Big Creek Park. From San Antonio: Take IH35 north all the way to AUSTIN. At the north edge of Austin, turn right onto US 290. Follow the Austin directons. You can cut across on TX 21 at PAIGE. Go to CALDWELL. Turn south on TX 36. About 10 miles you'll reach LYONS. At the very edge of Lyons you should turn right on FM 60. Approx. 8 miles to the Park which will be on your right. From El Paso: Take IH 10 to JUNCTION. About 22 miles east of Junction take US 290. Follow US 290 north thru AUSTIN. You'll turn right to the east toward HOUSTON. Follow the Austin directions. From All Directions - At Big Creek Park ======================================= FidoNews 7-04 Page 13 29 Jan 1990 After you enter Big Creek Park, turn right at the sign directing you to the campground. Tell the gate attendant that you are with the Houston Bird/\Dog Society. Follow the campground road staying to the left at every fork until you reach the Pavillion. DETAILS: LYONS to Big Creek Park turnoff is 3.8 miles. Gate is 3.3 miles further. Campground is 0.1 mile from Gate. Restrooms to left just beyond gate. 0.3 mile from Gate is first fork. Stay LEFT. 0.1 mile to next fork. Stay LEFT. To right are electric campsites. Big Rest Rooms at this fork. Also dumpster. 0.2 mile to Pavillion Point. Open area. MARINA (one (1) mile from Gate. Deer Meadow. Brand new building with groceries and ice and fishing pier. ACCOMODATIONS: ============== AT BIG CREEK PARK: Ample campsites. $8 with water. $10 with electricity and water. In nearby locations for those not camping : AT MARINAS: Big Creek Marina: 6 cabins with icebox and stove. No tv. high wood steps. Telephone across road. 3 cabins with _two_ bedrooms and 3 cabins with _one_ bedroom. Reservations must be for TWO nights whether you stay or not! No credit cards. $5.00 key deposit. Advance deposit of $25.00. TELEPHONE: 1-409-596-1616 2 - bedroom unit $40.00 per night. 1 - bedroom unit $35.00 per night. OverLook Park Marina: 6 blue and white cabins. Single rooms. No steps. Same owners, same conditions. TELEPHONE: 1-409-289-2651 FidoNews 7-04 Page 14 29 Jan 1990 1 - room unit $45.00 per night. SCREEN SHELTERS: $15.00 per night. CALDWELL: 13.7 miles from LYONS. Surry Inn; Varsity Motel, and Texan motel (low dive). Two resturants next door to Surry Inn. Wal-Mart next to Varsity. Nice grocery stores here! STOCK UP!!! Interesting METAL SCULPTURE STUDIO on BASTROP hwy. Check it out. Neat! BRENHAM: 19.5 miles from LYONS. Preference Inn and (?) Motel - across from McDonalds on Hwy. 290. Coach Lite Motel (2 sites) is 1.2 west of Brenham on hwy 290 toward AUSTIN (the Austin folk may want to stay here!). Judge's resturant, sunday buffet, bowling alley, etc.. SOMMERVILLE: 3.5 miles from LYONS. One motel on southside of town. No grocery stores! Several drive-in markets. FOUR places to eat. 1) D's Diner - 24 hrs. just relocated into larger, newer, formerly vacant resturant. 2) Schopp's (?) local greasy spoon in center of town. 3) COUNTRY INN -* best food* !!! Steaks, club sandwiches, and baked potatos very popular. Own meat.. hudge pieces! 4) Dairy Queen. Heritage Museum. Nature Museum at Corp of Engineers Headquarters. Primarily Railroad with Loading Pens for _cattle_. Sommerville Motel - 1-409-596-1000 BRYNA/COLLEGE STATION: Approx. 30 miles east on Tx 60. Many places here, including a Motel Six. ( Submitted by Net 106, via Justin Marquez, 1:106/100 ) ----------------------------------------------------------------- FidoNews 7-04 Page 15 29 Jan 1990 ================================================================= FOR SALE ================================================================= Richard Shockey Fido 1:100/617.6 BULLETFAX from NUNTIUS Attention Bulletin Board Operators! BulletFax - A NEW service for your users! BulletFax turns your BBS into a FAX server! BulletFax is a "demand publishing" tool for Bulletin Board Systems. Callers now have the ability to retrieve documentation from a BBS that can include extensive graphics. That documentation is then printed out at the callers fax machine. There is no need to download a document, load into a word processor or graphics editor and then print out. The Fax machine in essence becomes a "remote graphics printer". With BulletFax, a caller can access an unlimited document base of information limited only by the size of your hard drive. BulletFax is particularly well suited for the maintainance and delivery of large technical document bases or large catalogs of product or price information in the commercial environment. Complete text string search facilities are avaiable in BulletFax. Searches can be made against either file names or abstracts created when the documents are loaded into the system. APPLICATIONS ? Well, for starters, how about - Price Sheets ... Brochures ... Catalogs ... Stock Info ... Technical Drawings ... Advertisements ... Coupons ... Graphics ... BulletFax is designed with the BBS system operator in mind. It is easy to install, and documents may be located anywhere on the system. If you run a BBS, you will find BulletFax easy to configure. Extensive security is built into BulletFax, including password protection and document security protection. Complete call transactions are maintained, as well as user record logs. BulletFax may be configured as simply as to allow anyone to fax documents back to their fax, to as complex as running a fully secured system where users must be verified before document access is given. FidoNews 7-04 Page 16 29 Jan 1990 Documents may be grouped together in different security levels. There is also a hidden SysOp document function available. BulletFax can be configured in two ways. With two lines..one for the bbs and one for the fax card, faxes are transmitted as soon as the request is made WHILE THE CALLER IS STILL ON LINE. With a single line the fax transmission begins as soon as the caller logs off the BBS. BulletFax uses the Intel Connection Co-Processor. With the additional use of the Intel 2400b option card, your BBS can be configured to receive fax transmissions as well. The use of the 2400b option card also saves on valuable slot space inside your PC if you use internal modems. Faxable files are stored on the system in simple ASCII format or in .PCX .DCX file formats. BulletFax will work with any BBS system that has "Doorway" capability (drop to dos). It will work with single line versions of programs like TBBS, FIDO, OPUS, RBBS, Wildcat!, and WWIV. BulletFax also comes bundled with a registered copy of Marshall Dudley's DOORWAY program, which you will find useful for your other Drop To Dos functions. Nuntius Corporation Nuntius is a software development firm and complete value added reseller of computer related fax systems. Nuntius has acted as consultants to many Fortune 500 companies on the strategic use of fax throughout the entire enterprise. Nuntius is developing a number of fax related products for the OS/2 operating system. Nuntius BulletFax Nuntius is currently developing a stand alone version of BulletFax that will not require the use of a BBS. In addition Nuntius is developing techniques for the use of Bullet-Fax in Multi-Line BBS systems. Call for further information and details. Available now. For more information dial into the Nuntius BBS and BulletFax demonstration system at (314) 947-7689 12/2400 - N,8,1 FidoNet 1:100/617 or call Nuntius Voice at (314) 768-0109. PRICE: BulletFax Program without Intel Connection Co-Processor. $249.00 BulletFax with Intel Connection Co-Processor and all Connection Co-Processor software. $949.00 Nuntius has other Fax related software products available. We also offer FaxBack . This system allows any anyone with a touch tone telephone and access to a fax machine the ability to retrieve documents automatically using voice processing technology. For a demonstration call (314) 947-1710. FidoNews 7-04 Page 17 29 Jan 1990 Nuntius Corporation 1904 Merrill Drive St. Charles, MO 63301 FidoNet 1:100/617 BulletFax is a trademark of Nuntius Corporation FaxBack is a trademark of Intel Corporation ----------------------------------------------------------------- FidoNews 7-04 Page 18 29 Jan 1990 Computer Information Monthly News! CIMN(sm) Copyright 1989, 1990 Beyond my wildest expectations, that is the only way I can describe the interest in the DISKazine I have created. At present there are approximately 50 different places around the United States and Canada who are/have file requested the file. In addition to this I forwarded a diskette with both Black and White and the Color program to the Software Distribution Network coordinator. I have also received numerous request on how to get a copy without going through the file request route or from places where FReq is not practical. In reply to those who are interested because in some cases you have not left a return address I provide the following. Computer Information Monthly News may be obtained by sending $1.00 US, for one months issue to: High Mesa Publishing 13 Osage Drive Los Lunas, NM 87031 I must inform you the CIMN program itself is strictly FREEWARE, you are not being required to pay for the program. The $1.00 will be used to purchase: a. Diskette 1 ea. .50 b. Stamps 1 ea. Some cases 2. .25 c. Labels 2 ea. .10 d. Envelope 1 ea. .10 I realize the above does not come to exaclty one dollar, but I feel that sending change through the mail is a waste of your time and mine. An since you may want to receive the next 12 issues of the magazine you may send the amount necessary to cover the number of issues you would like to receive. Again I would like to Thank those of you who have FReq'ed the file and remind everyone it can be file requested 23 hours per day. The file names to request are: CIMN.ARC OR ZIP..........COLOR VERSION CIMNBW.ARC OR ZIP........BLACK & WHITE VERSION ================================================================= HIGH MESA RANGER'S BBS (301/1) JAKE HARGROVE HIGH MESA PUBLISHING, 13 OSAGE DR, LOS LUNAS, NM 87031 USA FidoNews 7-04 Page 19 29 Jan 1990 ----------------------------------------------------------------- FidoNews 7-04 Page 20 29 Jan 1990 ================================================================= LATEST VERSIONS ================================================================= Latest Software Versions MS-DOS Systems -------------- Bulletin Board Software Name Version Name Version Name Version Fido 12q+ Phoenix 1.3 TBBS 2.1 Lynx 1.30 QuickBBS 2.61* TComm/TCommNet 3.4 Kitten 2.16 RBBS 17.2B TPBoard 6.0 Opus 1.03b+ RBBSmail 17.2 Wildcat! 2.10* Network Node List Other Mailers Version Utilities Version Utilities Version BinkleyTerm 2.30 EditNL 4.00 ARC 6.02 D'Bridge 1.30* MakeNL 2.20 ARCA06 2.20* Dutchie 2.90C ParseList 1.30 ARCmail 2.0 FrontDoor 1.99b* Prune 1.40 ConfMail 4.00 PRENM 1.47 SysNL 3.01* EMM 2.02 SEAdog 4.51b XlatList 2.90 Gmail 2.01 XlaxDiff 2.32 GROUP 2.16 XlaxNode 2.32 GUS 1.30* LHARC 1.13 MSG 4.0 MSGED 1.99 PK[UN]ZIP 1.02* QM 1.0 QSORT 4.03 StarLink 1.01 TCOMMail 2.2 TMail 1.12 TPBNetEd 3.2 TossScan 1.00* UFGATE 1.03 XRS 3.10 ZmailQ 1.10* Macintosh --------- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version FidoNews 7-04 Page 21 29 Jan 1990 Red Ryder Host v2.1b3 Macpoint 0.91* MacArc 0.04 Mansion 7.12 Tabby 2.1 ArcMac 1.3 WWIV (Mac) 3.0 StuffIt 1.51 TImport 1.331 TExport 1.32 Timestamp 1.6 Tset 1.3 Timestart 1.1 Tally 1.1 Mehitabel 1.2 Archie 1.60 Jennifer 0.25b2g Numberizer 1.5c MessageEdit 1.0 Mantissa 1.0 PreStamp 2.01 R.PreStamp 2.01 Saphire 2.1t Epistle II 1.01 Import 2.52 Export 2.54 Sundial 2.1 AreaFix 1.1 Probe 0.052 Terminator 1.1 TMM 4.0b UNZIP 1.01* Amiga ----- Bulletin Board Software Network Mailers Other Utilities Name Version Name Version Name Version Paragon 2.00+* BinkleyTerm 1.00 AmigArc 0.23 TrapDoor 1.11 booz 1.01 WelMat 0.35* ConfMail 1.10 ChameleonEdit 0.10 Lharc 1.00* ParseLst 1.30 PkAX 1.00 RMB 1.30 UNzip 0.86 Zoo 2.00 Atari ST -------- Bulletin Board Software Network Mailer Other Utilities FidoNews 7-04 Page 22 29 Jan 1990 Name Version Name Version Name Version FIDOdoor/ST 1.5c* BinkleyTerm 1.03g3 ConfMail 1.00 Pandora BBS 2.41c The BOX 1.20 ParseList 1.30 QuickBBS/ST 0.40 ARC 6.02* GS Point 0.61 LHARC 0.51 PKUNZIP 1.10 MSGED 1.96S SRENUM 6.2 Trenum 0.10 OMMM 1.40 + 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-04 Page 23 29 Jan 1990 ================================================================= NOTICES ================================================================= The Interrupt Stack 1 Feb 1990 Deadline for IFNA Policy and Bylaws election 5 Jun 1990 David Dodell's 33rd Birthday 5 Oct 1990 21st Anniversary of "Monty Python's Flying Circus" If you have something which you would like to see on this calendar, please send a message to FidoNet node 1:1/1. ----------------------------------------------------------------- FidoNews 7-04 Page 24 29 Jan 1990 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Thom Henderson 1:107/528 Chairman of the Board Les Kooyman 1:204/501 President Fabian Gordon 1:107/323 Vice President Bill Bolton 3:3/0 Vice President-Technical Coordinator Kris Veitch 1:147/30 Secretary Kris Veitch 1:147/30 Treasurer IFNA COMMITTEE AND BOARD CHAIRS Administration and Finance * By-laws and Rules John Roberts 1:385/49 Executive Committee (Pres) Les Kooyman 1:204/501 International Affairs * Membership Services Jim Vaughan 1:226/300 Nominations and Elections Steve Bonine 1:1/0 Public Affairs David Drexler 1:147/30.20 Publications Irene Henderson 1:107/9 Technical Standards Rick Moore 1:115/333 Ethics * Security and Privacy * Grievances * * Position in abeyance pending reorganization IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Courtney Harris 1:102/732 Don Daniels 1:107/210 11 John Rafuse 1:12/900 Phil Buonomo 1:107/583 12 Bill Bolton 3:711/403 Mark Hawthorne 1:107/238 13 Fabian Gordon 1:107/323 Tom Jennings 1:125/111 14 Ken Kaplan 1:100/22 Irene Henderson 1:107/509 15 Kevin McNeil 1:128/45 Steve Jordan 1:206/2871 16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628 17 Kathi Crockett 1:134/30 Dave Melnik 1:107/233 18 Andrew Adler 1:135/47 Jim Hruby 1:107/536 19 Kris Veitch 1:147/30 Burt Juda 1:107/528 2 Henk Wevers 2:500/1 Karl Schinke 1:107/516 3 Matt Whelan 3:54/99 John Roberts 1:147/14 -----------------------------------------------------------------