Volume 6, Number 8 20 February 1989 +---------------------------------------------------------------+ | _ | | / \ | | /|oo \ | | - FidoNews - (_| /_) | | _`@/_ \ _ | | International | | \ \\ | | FidoNet Association | (*) | \ )) | | Newsletter ______ |__U__| / \// | | / FIDO \ _//|| _\ / | | (________) (_/(_|(____/ | | (jm) | +---------------------------------------------------------------+ Editor in Chief Dale Lovell Editor Emeritus: Thom Henderson Chief Procrastinator Emeritus: Tom Jennings Contributing Editors: Al Arango 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 available for network mail between NMH-1 hour to NMH+1 hour. At all other times, netmail is not accepted although submissions can be uploaded. 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. The contents of the articles contained here are not our responsibility, nor do we necessarily agree with them. Everything here is subject to debate. We publish EVERYTHING received. Table of Contents 1. ARTICLES ................................................. 1 Adding GroupMail to a BinkleyTerm/ConfMail System ........ 1 SEA Letter: XlatList ..................................... 14 New Echo for WATSON Users ................................ 17 2. COLUMNS .................................................. 18 The Old Frog's Almanac - Part the Three (and last) ....... 18 3. LATEST VERSIONS .......................................... 21 Latest Software Versions ................................. 22 4. NOTICES .................................................. 23 The Interrupt Stack ...................................... 23 5. REPORTS .................................................. 24 And more! FidoNews 6-08 Page 1 20 Feb 1989 ================================================================= ARTICLES ================================================================= Jack Decker Fidonet 1:154/8 LCRnet 77:1011/8 NetWork 8:70/8 ADDING GROUPMAIL TO A BINKLEYTERM/CONFMAIL SYSTEM [This article is NOT copyrighted and may be freely distributed. Use of the information contained herein is at your own risk, and just might cause your hard drive to be reformatted, your modem to transfer the contents of your bank account to the Gnomes of Zurich (whoever they are), or your dog to meet up with a family of skunks underneath your computer room window, or even worse. What you see here is the result of a few days of intense hacking (I'm using the original meaning of that noble word), which may or may not have led me to accurate and insightful conclusions. Don't say I didn't warn you...] Lots of misinformation has been going around in regard to GroupMail, and the considerations involved in making GroupMail coexist on the same system with BinkleyTerm and ConfMail. I suspect that much of this has nothing to do with GroupMail per se, but rather with emotions and personal feelings about the developers of GroupMail. I won't even attempt to speak to those, but I can at least give you some solid information on how to implement GroupMail on a system that is already successfully running BinkleyTerm and confmail. This information is going to be presented more or less in "cookbook" format. I am going to make a few assumptions to start with... that you are not a "top star" for any conference, that you're not going to feed GroupMail conferences to any non-MSDOS systems that can't run the GroupMail software, and that you're not going to try and convert any GroupMail conference to Echomail or vise-versa. If any of these assumptions don't apply to you, read on anyway, I'll cover one of the exceptions later, and the rest of the information will still be useful to you. This is NOT a substitute for the GroupMail documentation. Read it, too! Also, please count on this information containing at least one glaring error and at least a couple of things that could have been done more easily in some other way. I don't claim to be perfect. But I would like to know of any errors that you do find. Here are the changes you will need to make to your system: 1) CONFIG.SYS - Group requires some new environment variables to be set. If you haven't already done so, you can reserve extra space for environment variables by inserting the following line into your CONFIG.SYS file: FidoNews 6-08 Page 2 20 Feb 1989 shell=command.com /p /e:512 2) AUTOEXEC.BAT - Here is where you add some lines to set the new environment variables that will be used by GroupMail: SET GROUP=C:\GROUP SET GRPHOLD=C:\GRPHOLD SET SEADOG=C:\OPUS If you want your GroupMail message areas on a different drive, change the drivespec for the GROUP variable. If you are going to hold GroupMail bundles for pickup by other nodes, and want those on a different drive, change the drivespec for the GRPHOLD variable. The SEADOG variable should point to the directory that you normally run BinkleyTerm from. 3) BBS.BAT - Your batch file that runs Binkley, ConfMail, etc. Here are the changes you need to make: a) If you test for the existence of mail bundles in your net files area before running ConfMail Import, either delete these tests (you don't really need them anyway) or add tests for the GroupMail bundles you expect to receive. GroupMail bundles are named with the area name (up to eight characters) plus an unpredictable three-character extension. So, for example, if you are expecting to receive GroupMail bundles for the COOKING area, you could test for files named COOKING.* (or COOKING.???) in your net files area. I again emphasize that such tests are normally not necessary, but some people like to use them to shave a few seconds off of batch file processing time. b) your line that calls ConfMail Import should *NOT* include the -M option, but *SHOULD* include the -K option. I use the following line: confmail import areas.bbs -K -N -F confmail.out Now a bit of explanation... if you really want to use the -M option, you can probably do so as long as you are not converting any GroupMail bundles to echomail prior to passing them downstream. I suggest removing the -M option now (if you have been using it) because sooner or later you may wish to convert a GroupMail conference to echomail, and it won't work if -M is set. The -K option will automatically kill all the null file attach messages that your GroupMail feed generates. If you don't mind skipping through all the null file attach messages when you read your netmail (you WILL mind eventually), leave out the -K. c) You should place the following line immediately AFTER your call to ConfMail Import, BEFORE you do anything else: GROUP IN /L This does two things... first, it unpacks any GroupMail bundles FidoNews 6-08 Page 3 20 Feb 1989 you may have received, and second, it scans your netmail area for any GroupMail messages that need to be readdressed to your uplink. That is why it needs to be run AFTER ConfMail Import... if you run it BEFORE ConfMail Import, any messages you've received from your downstream nodes may not get properly forwarded to the Top Star via your GroupMail feeds. And you need to run Group In BEFORE running ReMapper, oMMM, or any other program that may change the headers of those messages. So play it safe, and run Group In right AFTER ConfMail Import. By the way, the /L tells GROUP to relink the message threads. It does basically the same thing for GroupMail conferences that ReplyLnk (or ConfMail Maint in older versions of ConfMail) does for your echomail conferences. d) Just prior to calling oMMM, you should place the following line: GROUP OUT This will check all your GroupMail areas for new messages, and send out anything you have waiting. Now, if you have read the GroupMail documentation, you may be a little confused at this point, since the docs tell you to run GROUP on certain schedules (GROUP OUT in the evening before your mail hours, and GROUP IN in the morning after all mail has been received). But keep in mind that the folks writing the documentation are using SEADOG, which runs on schedules. You probably aren't running schedules in that way. If by chance you do run ConfMail Import only at certain specified times, just do GROUP IN immediately afterward. But, if like most of us, you run ConfMail Import every time mail is received, you should run GROUP IN immediately afterward. If you then do a ConfMail Export, you should run GROUP OUT prior to calling oMMM. GROUP runs very fast (faster than ConfMail when tossing messages, in my opinion) so you needn't worry about it consuming an inordinate amount of time while executing on your system. 4) AREAS.BBS - There are two important considerations here. First, if you are using a BAD_MSGS area, GET RID OF IT NOW!!!! This is *EXTREMELY* important. If you don't do this, some or all of the GroupMail messages originating on your system (or on systems that you feed) will be tossed to the BAD_MSGS area by ConfMail, and will never leave your system. Second, make sure you don't have any echo area names that duplicate GroupMail areas, for the same reason (ConfMail will toss any messages that are supposed to go to your uplinks to those areas instead. The exception to this is if you're converting a GroupMail conference to Echomail, but right now we're assuming you aren't doing that, remember?). Of course, someone will say that if you are VERY careful about how you write your batch file, you can get around these problems. That may be true (although I have my doubts!), but FidoNews 6-08 Page 4 20 Feb 1989 in any event I don't feel like giving a short course in writing batch files here. I'm simply taking the safe road by saying "don't do these things." 5) CONFIG.DOG - You need one of these, even though the GroupMail documentation says that a Mail.Sys file will do (it won't, at least not with GroupMail versions through 2.04). Fortunately, a Config.Dog file is simple to make... you just use any text editor. Mine looks like this: name Jack Decker node 1:154/8 aka 77:1011/8 aka 8:70/8 mail C:\MSG\NET files C:\FILE\NET "Name" is the name of the Sysop, "Node" is your primary address, "Aka" lines contain any other addresses you use (in the same net or in other nets), "Mail" is the path to your netmail area, and "Files" is the path to your incoming net files area (which is what GROUP can't find if you only have a Mail.Sys file). 6) OMMM.CTL (or ROUTE.CTL or whatever you call it on your system). Be sure to put a poll statement in for each system you pick up GroupMail from (unless you are using some other method for doing polls, or your feed is calling you). 7) DELIVER.GRP - You need this file if you are feeding GroupMail to any other BinkleyTerm systems, or any other system that can't generate File Update Requests. Note that future versions of BinkleyTerm will supposedly include the capability to do File Update Requests, but present versions of Binkley do not. DELIVER.GRP is simply a list of systems that are to receive any given GroupMail area from you. I quote from SEA Technical Memorandum #0302: "The group mail conferencing system is, by design, a pickup system instead of a delivery system. If at all possible, it should be used as such, because that is how group mail avoids the bulk of the technical problems with echomail. "However, at least one popular network mailer is not capable of properly negotiating a file update request, which is the mechanism by which group mail functions. Until that can be rectified, GROUP requires some sort of delivery mechanism in order to link such systems into group mail. "If a file named 'DELIVER.GRP' is placed in the SEAdog directory, then GROUP 2.03 will use it as a delivery list, and create file attach messages for each new group mail archive as it is posted by GROUP PACK (for a top star) or GROUP IN (by a middle star). The format of the DELIVER.GRP file will look very familiar to those acquainted with echomail. FidoNews 6-08 Page 5 20 Feb 1989 "The DELIVER.GRP file is a normal ASCII text file. Each line begins with the name of a group conference, with the remainder of the line being a list of network addresses to which it should be delivered. A conference may be listed more than once, in which case it is addative. "For example, a possible DELIVER.GRP file might be: BLATZ 520/1015 107/528 GNORF 107/528 "By adding support of a delivery mechanism, we open the door to all the troubles echomail is heir to. However, the door is open only a tiny crack at this time. The single biggest problem with a delivery system is that of faulty topologies that cause duplicate messages. This is largely avoided from the start because all duplicate group mail archives have the same name. The remaining opportunities for duplicate messages to be generated are avoided because GROUP 2.03 refrains from unpacking any group mail archive that is older than the 'update marker' for that conference." [end quote] Two notes about DELIVER.GRP... first, you DON'T put the node number of YOUR feed in it, only of those systems that are fed BY YOU (this differs from an AREAS.BBS file, which must contain the node number of your feed and of those system that you feed). Second, if you aren't feeding a particular GroupMail conference to anyone else, it doesn't have to be listed at all. 8) OKFILE.LST - Your "requestable files" list for BinkleyTerm. Add the following line: C:\GRPHOLD\*.* (or whatever path you specified for your GRPHOLD directory in the SET command in AUTOEXEC.BAT). I'm assuming that you already have such a list. If not, you'll also need to uncomment the following line in your Binkley.Cfg file: Okfile c:\opus\okfile.lst (of course you should change the path if the subdirectory you're running Binkley out of is not called OPUS). This should allow other systems to obtain any GroupMail areas that you carry on your system. 9) \GROUP\ORIGIN - A file called "Origin" that sits in your GROUP directory. For starters, this can be the same as the first line of your "AREAS.BBS" file up to the exclamation point. You can use custom origin lines for individual conferences by creating a file called "Origin" in individual Group areas, in the same manner in which you create custom FidoNews 6-08 Page 6 20 Feb 1989 origin lines for individual message areas using ConfMail. See the GroupMail documentation for more information. 10) System files. You'll need to provide your BBS program and/or message reader/editor with the paths to your GROUP mail areas. Ditto with your message cleanup routine (that calls RENUM or some other message renumberer). This will vary from system to system, but should not be too difficult to figure out. 11) ARCE.COM - This one threw me at first, and is the one drawback I found in GroupMail. GroupMail wants to use either ARC.EXE or ARCE.COM when unpacking mail, and any other filename just won't do. I've been running PAK10 (and/or another popular program which shall remain nameless) to extract mail archives and had to scrounge through my piles of floppies to find a copy of ARCE.COM. If you are a Top Star for any conference, you'll also have to have either ARC.EXE or ARCA.COM. I wish these filenames weren't hardcoded in the GroupMail program, because I use PAK10 to move echomail around (with the help of a program I wrote called PAKIT101.ARC, which lets "consenting Sysops" use any of the "big three" methods of file compression for their mail archives), and could at least use PAK.EXE to extract GroupMail bundles. I guess it just bugs me that GroupMail won't let you use anything other than the most inefficient method of file compression around. If anything hinders the acceptance of GroupMail, this will be it, because some folks will see this as an effort of SEA to force people to use ARC. (Sorry, Thom, I like GroupMail but I don't care much for ARC, or I should say, ARC's "crunching" method of compression, which is rather inefficient by today's standards. What can I say?). 12) GROUP.EXE - The central program of GroupMail, and the one that does most of the work for you. If you've set up echomail conferences in the past, you'll appreciate the ease with which GROUP takes care of many of the little details of adding or deleting conferences for you. For example, it creates all necessary subdirectories for you, creates and maintains the AREAS.DOG file for you, etc. Now, if you are not a Top Star, you can basically get by using only three basic GroupMail commands (quoted from the GroupMail documentation): GROUP ADD ; This is the command you use to add a new conference. Suppose, for example, that you would like to get the BLATZ conference from 520/542. You would type: GROUP ADD BLATZ Gzorniblatz forum ;520/542 GROUP will take care of the details, like creating the proper directories and updating your AREAS.DOG file. If you run a BBS and you want the conference to be available on your system you will need to add the directory to your FidoNews 6-08 Page 7 20 Feb 1989 message areas. The message directory that GROUP creates will (by default, see later) be a subdirectory of the GROUP subdirectory, or in this case it would be "GROUP\BLATZ". If you are running a mailer other than SEAdog, then you may need to add the directory to your areas list also. In any event, DO NOT delete the AREAS.DOG file, as that is used by GROUP to keep track of your conferences. If you want to import group mail into a BBS that uses a different message base format, you'll need to do a bit more work. See the section on this below. [You might imply from the above that you should add GroupMail areas to your AREAS.BBS file. That is NOT the case, however, unless you are converting a GroupMail conference to echomail, which we're assuming that you're not doing right now!] GROUP DEL . . . This is used to remove one or more conferences. For example, if you wanted to remove the BLATZ conference you would type: GROUP DEL BLATZ If you wanted to remove both the BLATZ conference and the GNORF conference, you would type: GROUP DEL BLATZ GNORF Again, GROUP will take care of the housekeeping details, such as deleting any messages and removing the subdirectory. GROUP EDIT ; This is used to change an existing conference. For example, if you wanted to change your uplink on the BLATZ conference to 440/1, you would type: GROUP EDIT BLATZ Gzorniblatz forum ;440/1 As always, GROUP takes care of any housekeeping details. [end of quoted material] Since Binkley can't do File Update Requests, you do NOT use the GROUP ASK command. We've already covered the use of GROUP IN and GROUP OUT in the batch file. You don't use GROUP PACK unless you're a top star for a conference. I don't know why FidoNews 6-08 Page 8 20 Feb 1989 you'd want to use GROUP KILL, but I've not yet found a reason to do so (it looks like a somewhat dangerous command!) There are several option switches that you can use to modify how GROUP works, and most are described in the GROUP documentation. The one that you will probably want to use is the /R switch: /R Retention; This tells GROUP that any group mail archives that you are holding (if you are a star) should be deleted after days (default is 30 days). For example, you would use "/R5" to retain archives for five days. For example, if you wanted to add the BLATZ conference with yourself as a middle star retaining group mail archives for three days, you would type: GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /r3 Also, because Binkley cannot generate File Update Requests, you'll want to use the /X switch when adding new conferences, as described in SEA Technical Memorandum #0302: /X In ADD or EDIT only. This switch indicates that the designated conference should not be requested. The GROUP ASK command will not generate an update request for any conference that carries this switch. This is intended mainly for use with conferences which are delivered or which are obtained via a GROUP GET (see above). The bottom line is that when you add a new GroupMail conference, your GROUP ADD line will most likely appear something like this: GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /X /r7 (assuming you want to retain conference archives for seven days in this case). If you are a leaf node (that is, you don't hold a particular conference for anyone else to pick up), omit the asterisk and the /r7 in the above line. In this case, the GroupMail bundle will be deleted after it has been tossed. The command line would then look like this: GROUP ADD BLATZ Gzorniblatz forum ;520/542 /X When you use the GROUP EDIT command, it should be in exactly the same format as the GROUP ADD command. In other words, if you are adding switches, you must also re-enter all of the original switches. The word EDIT simply tells Group that you are modifying the particulars of an existing conference, rather than creating a new one. FidoNews 6-08 Page 9 20 Feb 1989 EXCEPTIONS AND SPECIAL CIRCUMSTANCES The GroupMail manual tells you how to import GroupMail into non-compatible message base formats (such as QuickBBS or TBBS). In this case you use the /N flag in your GROUP ADD statement. Since most such systems don't use ConfMail, this type of setup is a bit beyond our discussion. I would only caution you to be careful about the sequence in which you run you mail import routine and GROUP IN. You may have to run your import routine twice... once to toss incoming mail, then GROUP IN to toss incoming GroupMail bundles to the netmail area (and to readdress any GroupMail messages destined for your uplinks), and once more to import any GroupMail messages tossed to your netmail area by GROUP. This is just guessing on my part, since I don't have any actual experience with such systems. However, a similar technique is used to convert GroupMail to Echomail. You might want to do this if you are receiving a GroupMail conference and want to pass it on to another system that cannot run the GroupMail software. Now, I would suggest that you DON'T do this unless absolutely necessary. If it's just a case of one of the nodes you feed objecting to having to put up the GroupMail software (although they are perfectly capable of doing so), I would invite them to seek a feed elsewhere. Converting a conference from GroupMail to Echomail introduces several possible headaches, not the least of which is that you could be the source of duplicate messages entering the conference. On the other hand, it's not something that's terribly difficult to do if you have to. SEA Technical Memorandum #0303 describes the process, but in my opinion makes the process unnecessarily complicated. So, I will give a couple of examples specifically for BinkleyTerm/ConfMail users. The assumption here is that you are a middle star that is receiving the conference in question as GroupMail, and feeding it to some other nodes as GroupMail while feeding still other nodes as Echomail. Your GROUP ADD line would be the same as usual, with the addition of the /N switch... for example: GROUP ADD BLATZ Gzorniblatz forum ;* 520/542 /N /X /r7 If you are not sending the conference to any other nodes AS GROUPMAIL, you can omit the asterisk and the "/r7" switch. Next, you ADD this area to your AREAS.BBS file, just like you would any normal echo. On your system, you will treat this conference as an echomail area rather than a GroupMail area. The /N option that you used in your GROUP ADD statement causes GROUP to add an "AREA:" field and a "SEEN-BY:" field listing the address of the uplink to any conference that you're converting to echomail. FidoNews 6-08 Page 10 20 Feb 1989 In your batch file, you will probably want to run ConfMail Import (WITH the -M option), THEN Group In, and THEN a second run of ConfMail Import (WITHOUT the -M option). This will make sure that any GroupMail received from your downstream nodes gets properly readdressed to your uplinks, and that any Group conferences that GroupMail tosses to your netmail area get properly tossed (by ConfMail) to the Echomail area you've set up for that conference. For example: confmail import areas.bbs -M -N -F confmail.out group in /L confmail import areas.bbs -K -N -F confmail.out The only other items you have to worry about are how the area is defined in your DELIVER.GRP and AREAS.BBS files. As usual, your DELIVER.GRP file should contain ONLY a list of nodes receiving the conference from you AS GROUPMAIL. Your AREAS.BBS entry for the conference in question should contain a list of the nodes receiving the conference from you AS ECHOMAIL, plus YOUR FEED of the conference. The reason for including your feed is so that any messages entered on your system, or sent to you by your downstream links, will be exported to your upstream feed. You may wonder what will happen to an echomail message sent upstream in such a manner to your GroupMail feed. If he is running that area strictly as GroupMail, the message will be tossed into his netmail area (so long as he does not have a BAD_MSGS area... this is why you CANNOT use a BAD_MSGS area with GroupMail!!!), where (hopefully) GROUP IN will find it and readdress it to his uplink, and so on. If he is also operating the area as both echomail and GroupMail, the message will get tossed into the echo area on his system, and then exported to his upstream feed, and so on. Anyway, that's all there is to it... BUT again I ask, "do you REALLY want to convert echomail to GroupMail?" If you are only feeding one or two nodes that cannot accept GroupMail, there may be a better way: SENDING GROUPMAIL TO NON-MSDOS SYSTEMS The following information should be considered HIGHLY experimental. If it works for you, GREAT! If it doesn't... well, you can always convert your GroupMail conferences to echomail. Let's say that you're feeding a point system that's running on a Commodore Amiga (coincidentally, this is what Steve Palm, a point operator off of my system is using). He has a version of ConfMail and BinkleyTerm that's been ported to the Amiga, as well as a message reader/editor, but there is no way he can run the GroupMail software. But, he is a leaf node. That means he doesn't have to worry about forwarding the conference to anyone else. All he needs FidoNews 6-08 Page 11 20 Feb 1989 to be able to do is to read the messages he receives, and send replies. We already know (from the above discussion) that if he creates an echo area with the same name as a GroupMail area on my system, and puts my node in his AREAS.BBS list, that any messages he enters in that area will be exported to my system, where GROUP IN will find them and readdress them to my feed for the conference. So as long as he can send me messages with the proper AREA tag (which will be automatically affixed when ConfMail exports the message from the echo area he's created), he will be able to enter messages in a GroupMail conference. So, if he can figure out some way to process an incoming GroupMail bundle (so that he can read incoming messages), I can just put his node in my DELIVER.GRP file and treat him like any other GroupMail delivery point (which means I don't HAVE to convert the GroupMail conference to Echomail!) The question is, can he unpack a GroupMail bundle? Well, it turns out that there IS a way this can be done. Once you unARC a GroupMail bundle, the extracted mail packet has roughly the same format as an Echomail packet, except that it's addressed to -1/0. At least, it's close enough that ConfMail will unpack and toss it if it thinks it's running on node -1/0 So, in his CONFIG.DOG file, Steve inserts the address -1/0 as an AKA address. Then, in his batch file, he has to put a command to look for and unARC any GroupMail bundles he might receive. For example, if he's getting COOKING and SHORTWAV from me, he'd put in the following lines (note these are MS-DOS batch file lines for illustrative purposes only, not what Steve is actually using on his Amiga): PKXARC \FILE\NET\COOKING.* DEL \FILE\NET\COOKING.* PKXARC \FILE\NET\SHORTWAV.* DEL \FILE\NET\SHORTWAV.* CONFMAIL IMPORT AREAS.BBS -N -A PKXARC ConfMail will find the bundles (addressed to -1/0, but the AKA takes care of that) and unpack them. Next... and this is important... he must do a CONFMAIL EXPORT using an alternate AREAS.BBS format file that contains the following: Origin Line ! Sysop Name \MSG\COOKING COOKING -1/0 \MSG\SHORTWAV SHORTWAV -1/0 Why are we exporting to -1/0? Well, since GroupMail uses that address, I thought I would, too... actually, we could export to ANY phony node, but the idea is to make ConfMail do an export operation on the newly-imported GroupMail messages. Why? Well, keep in mind that GroupMail messages don't have an origin or SEEN-BY lines. Thus, if we simply allow them to be rescanned in the normal manner, we've created an instant dupe loop, since they will all get sent back to the source. So, we FidoNews 6-08 Page 12 20 Feb 1989 do a "dummy" export operation in order to reset the "high water mark" past the last new message that we have just received in the area. This may create an unwanted ".OUT" file for -1/0, but we can always delete that as the next operation in the batch file So, the complete batch file segment would look something like this: PKXARC \FILE\NET\COOKING.* DEL \FILE\NET\COOKING.* PKXARC \FILE\NET\SHORTWAV.* DEL \FILE\NET\SHORTWAV.* CONFMAIL IMPORT AREAS.BBS -N -A PKXARC CONFMAIL EXPORT ALTAREAS.BBS {options} DEL \OUTBOUND\FFFF0000.OUT ...where ALTAREAS.BBS is the alternate AREAS.BBS with the dummy -1/0 net/node numbers, and FFFF0000.OUT is the name of the mail packet (for -1/0) created by the dummy export operation. Of course, when messages are entered using the message reader/editor, we have to run ConfMail Export using the "real" AREAS.BBS file that contains the same entries, but with the real net/node numbers for the GroupMail feed(s) from which the conferences are received: Origin Line ! Sysop Name \MSG\COOKING COOKING 154/8 \MSG\SHORTWAV SHORTWAV 154/8 Now, all of the above will work BUT there is one MAJOR problem. It turns out that while each GroupMail bundle has a unique filename, two or more GroupMail bundles for the same conference can contain .PKT files that have exactly the SAME names. Thus, there is a very good chance that the above batch file segment would fail whenever more than one mail bundle is received for the SAME GroupMail area in the same transmission (it would most likely stop and ask the user whether to overwrite the the .PKT file from the first mail bundle with the .PKT file from the second... or on some systems, it might just go ahead and overwrite the file without asking, an even less desirable situation!). On an MSDOS machine, you could use a FOR-DO loop in the batch file to unarc each GroupMail bundle and then have ConfMail toss (import) the contents of that mail bundle before unarcing and tossing the next GroupMail bundle (but then, on an MSDOS machine you could just run the GroupMail software). There are probably ways to accomplish the same thing on other systems, but the actual method would depend on the commands available in the batch file language, and/or the availability of external utilities that might aid in the process. Or, you could just run the batch file manually (when an operator is present to watch and resolve any such conflicts that might occur)... that might be the most expiditious method at present for point system operators. Note to the developers of GroupMail: It would sure be nice if future versions did not FidoNews 6-08 Page 13 20 Feb 1989 create duplicate .PKT names within different mail bundles for the same GroupMail conference. The method I've shown for preventing the imported GroupMail messages from being rescanned back to the GroupMail feed is not real elegant, and begs for a simple utility that would either a) reset the "high water mark" (the number of the last message scanned by ConfMail Export) to that of the highest message in the area, or b) append an Origin line and SEEN-BY lines to any messages that don't already have them in the specified area, and place the net/node number of the feed for the area in all messages currently in that area. Such a utility could be run every time messages have been tossed to the specified area, and would eliminate the need for the dummy ConfMail Export operation. Yet another (better) option would be to forget the alternate AREAS.BBS file and the dummy ConfMail Export option, but instead use only the regular AREAS.BBS file with NO net/node number following the Group conference area names, so that messages in Group areas would NEVER be exported by ConfMail. Then use a separate utility that would search through Group conference areas for locally-originated messages (messages containing the node's primary net/node number in the FROM field of the message header) and move those TO the netmail area, at the same time readdressing them to the feed for the GroupMail conference and flagging them as Kill/Sent. Such a utility would be relatively easy to create, and would allow non-MSDOS systems to handle GroupMail in a way that more closely resembles the way GroupMail is supposed to operate (that is, a locally-entered message disappears from your BBS until such time as it comes back as part of a GroupMail packet). But, at this point, the fact that a non-MSDOS system can import and process GroupMail is a bit akin to the dancing bear... the wonder is not how well it's done, but that it can be done at all. I hope that these hints prove helpful to you in setting up GroupMail on BinkleyTerm/ConfMail and other types of systems. Please let me know if you find any glaring errors in the above information, or if you can add anything that might simplify the process or make it more understandable. Jack Decker (Fidonet 1:154/8, LCRnet 77:1011/8, NetWork 8:70/8) ----------------------------------------------------------------- FidoNews 6-08 Page 14 20 Feb 1989 What's Happening at SEA? SEAdog 4.50 added many new capabilities and features, and some of them required more data from the node list than we were getting. So we've upgraded XlatList to support those features. Along the way we added some other things people have asked for. First, we expanded the OZONE statement. You may be aware of the earlier form: ozone 1:107 which would import the data for net 107 of zone 1 into your node list. That still works, of course, but now you can also say: ozone 1:all which will import ALL of zone 1 into your node list. This defeats the purpose of zones to some extent, but many people felt a need for it. Speaking of zones: When zones were first designed, there was only the one network, with no hint that other networks would ever form and want to exchange network mail. Hence, the zone concept asumes one central authority to assign zone numbers, oversee zone gates, and so on. As we all know, that isn't quite the case today. To address the current world of multiple independent networks (pun unintentional), Jim Nutt came up with the idea of domains, domain addressing, and domain gates. We wholeheartedly endorse Jim's domain concept, and we support it in SEAdog 4.50 and in XlatList. SEAdog 4.50 contains the mechanisms for turning a domain address into the appropriate extended address via your local domain gate, but you still have to get the domain address from somewhere. Of course, you could just remember it and type it in as needed, but we wanted to find an easier way. We turned to XlatList for the answer. XlatList 2.90 implements a new command, "DOMAIN". This works like the older PUBLIST command, except that the list is designated as being part of a domain. Here's how it works: Suppose you're node 520/1015 in AlterNet, and you'd like to be able to send mail to people in FidoNet. Net 107, in particular, has several people in it you send mail to regularly, but you'd like to be able to reach the rest should the mood strike you. A system near you (let's say 520/16, for example) has volunteered to be your domain gate into FidoNet. In your CONFIG.DOG file you would put the statements: node 520/1015@AlterNet FidoNews 6-08 Page 15 20 Feb 1989 domain FidoNet 520/16 That tells SEAdog what to do. Now in your XLATLIST.CTL file you put: node 520/1015@AlterNet domain AlterNet anetlist anetdiff domain FidoNet nodelist nodediff ozone 1:107 What does this do? o The NODE statement tells XlatList who you are, including what domain you are in. o The first DOMAIN statement pulls in the node list data for AlterNet. Since that's your own domain, it works just like a PUBLIST statement. o The second DOMAIN statement pulls in the node list data for FidoNet. Since this is NOT your own domain, then the data won't appear in your NODELIST.BBS unless you say otherwise. Instead, it's used to create interdomain address entries in your FIDOUSER.LST user index. o The OZONE statement says otherwise, telling XlatList that net 107 in zone 1 should be incorporated into your NODELIST.BBS just as if they were in your own domain and zone. So what happens now? o Say you enter a message to Karl Wong, who is in net 107. Since you have the data for net 107 ready to hand, it goes as normal network mail. o Say you enter a message to Vince Hartman, who is in net 199 in FidoNet. SEAdog will pick his address out of your FIDOUSER.LST and, finding it to be an interdomain address, ruote it via your FidoNet gateway at 520/16. What does all this get you? o Direct access to the systems you normally deal with, and o The ability to send mail to any system anywhere in the world WITHOUT having to carry around megabytes of data on systems you never call. XlatList 2.90 also adds support for the new SEAdog routing class capability. Systems with high speed modems are predefined by XlatList as being in routing class "F" (for Fast), and you can define your own routing classes based on node list comments. For FidoNews 6-08 Page 16 20 Feb 1989 example, if you wanted everyone with a "CM" flag to be in class C, everyone with "XP" to be in class X, and everyone with "MO" to be in class "M", you can make it happen by putting these statements in your XLATLIST.CTL file: class CM C class XP X class MO M This let's you use routing commands like: Send-to class-C to say "send mail to anyone with a CM flag." Our intent was to do away with the need for RouteGen, while still giving you the flexibility and routing control you've come to expect. We think we've succeeded. Files mentioned this week: XLATRGEN.ARC XlatList 2.90, and RouteGen XLATRGEN.ARC may be downloaded from our technical support bulletin board at (201) 473-1991, or may be file-requested from either 520/1015@AlterNet or 1:107/1015@FidoNet. Next week: A sample SEAdog script ----------------------------------------------------------------- FidoNews 6-08 Page 17 20 Feb 1989 Gordon T. Gattone, moderator 18/8 The Watson Echo Conference The WATSON board is a modem that has many additional capabilities such as the ability to record speech on a hard drive and to interact with its callers via touch tones. According to the manufacturer, Natural Microsystems in Natick, MA there have been over 25,000 of them sold. The new WATSON echo is an attempt to bring together those of us who program WATSON and VIS (Voice Information Systems) sequences. Natural Microsystems has agreed to participate and in fact, has allocated funds for equipment purchases to dedicate to the echo. The echo is available from 18/8, 151/1000, 151/100, and 151/2 so far. With so many WATSON modems out there, I would expect the growth rate to be rather rapid. Please contact me at 18/8 if you have any questions or would like a feed. ----------------------------------------------------------------- FidoNews 6-08 Page 18 20 Feb 1989 ================================================================= COLUMNS ================================================================= The Old Frog's Almanac - Part the Three (and last) I've explained, in previous columns, how I came to develop the system which I chose to call The Old Frog's Almanac. What I haven't told you is perhaps the most important factor: I am having a BALL! Every morning, when I check my morning mail, I find myself scanning HDCONF, TELIX, DBASE and other conferences to see what's left after Sirius gets through....and every time I come across a new thread - one which shows real potential - I find myself adding it to the Sirius/EGREP system, and The Almanac grows a tad bit larger...I have, to put things in perspective, accumulated approximately 3.5 MEGS of archived topical extracts, all in the space of five weeks. There seems to be a compulsion within to initiate more and more files, and eat up more and more disk space, just to provide my users with a massive amount of USEFUL information.....let's face it - no matter how many message areas your system carries, there isn't a user born who can possibly keep up with the unbridled flood of information....providing a painless and exciting means by which those thousands of messages can continue to provide value to the users is proving to be FUN. How addictive can this system be? Let's put it this way....my SEAdog batch file, which once stood at a contented 28K, now exceeds 100K; it now processes and maintains over 200 specific topical files, and more are added daily. God knows what will happen when another 200 topics are added...(now, if someone would show me a way to compile the sucker, I'd die happy:-)) I thought I would close this series by offering you a partial list of the files now available on The Almanac - while the 50 or so files represent but 20% of those now extracted and maintained without operator intervention, they are more than enough to give you a clear idea of the scope of the system. - BBS-related Extracts (MEADOW & PNW_MEADOW) 95% of the information contained in these files is extracted from MEADOW....It's reassuring to think that a sysop having a problem with LASTUSER.BBS can request specific files which contain ONLY messages related to LASTUSER.BBS for any given month, without having to wade through the SEA vrs. PKWare wars, or the arguments about PAK's latest version :-) BMDM*.PAK Opus/BiModem Extracts, 02/89 EGRD*.PAK ECHOGUARD Extracts, 02/89 EMBD*.PAK OECC/Embedded Commands MEADOW Extracts, 01/89 JMDM*.PAK JMODEM MEADOW Extracts, 01/89 LUSR*.PAK LASTUSER.BBS Extracts, 01/89 MCHK*.PAK MAILCHECKING Extracts, 01/89 MODM*.PAK MODEM SETUP Extracts, 01/89 FidoNews 6-08 Page 19 20 Feb 1989 NORG*.PAK Opus/NoOrigin Extracts, 02/89 ODOS*.PAK Opus - DoubleDOS Extracts, 02/89 ODV*.PAK Opus & DesqView, 02/89 OKFL*.PAK OFILE Extracts, 01/89 OKFL*.PAK OFILE Extracts, 02/89 OMMM*.PAK OMMM Extracts, 01/89 OMMM*.PAK OMMM Extracts, 02/89 OPXP*.PAK Opus Express Extracts, 01/89 OPXP*.PAK Opus Express Extracts, 02/89 OREG*.PAK REGISTER Extracts, 01/89 OREG*.PAK REGISTER Extracts, 02/89 OTWR*.PAK Opus - TradeWars Extracts, 01/89 OTWR*.PAK Opus - TradeWars Extracts, 02/89 OWIN*.PAK Opus/Windows Extracts, 02/89 OZMD*.PAK Opus & ZModem, 02/89 PRIV*.PAK PRIV File Extracts, 02/89 PSIG*.PAK PC-SIG CDROM, 02/89 RASM*.PAK RASMAM, 02/89 STCK*.PAK STACK Extracts (MEADOW) 02/89 XLAX*.PAK NODELIST Processing, 02/89 - DeskTop Publishing Extracts APM*.PAK PAGEMAKER, 02/89 DPUB*.PAK DeskTop Publishing extracts, February 1989 DQ&A*.PAK DPUB-Q&A, 02/89 FONT*.PAK FONTS, 02/89 GEM*.PAK GEM, 02/89 GLYP*.PAK GLYPHIX Font Mgr., 02/89 LOGI*.PAK DPUB-LOGITECH Mouse, 02/89 LPTR*.PAK LASER PRINTERS, 02/89 PBIT*.PAK Publish It! Extracts, 02/89 PFSF*.PAK PFS FIRST PUBLISER, 02/89 PIRC*.PAK Pirated ClipArt Extracts, 02/89 PSCR*.PAK PostScript Extracts, 02/89 TOPS*.PAK TOPS, 02/89 VENT*.PAK VENTURA, 02/89 - Hard Drives-related Extracts (HDCONF) HDCONF has always been a rich source for technical information, and the Almanac's extracts reflect that in spades...in addition to the files listed below, I also carry a file specific to each Seagate and Miniscribe drive discussed in the conference.... ADAP*.PAK Adaptec Controller Extracts, 02/89 BKUP*.PAK BACKUP UTIL'S, 02/89 BUER*.PAK Bulk Erasure, 01/89 CDCW*.PAK CDC Wren Drives, 01/89 CMOS*.PAK CMOS, 02/89 CORE*.PAK CORETEST, 02/89 CPMQ*.PAK Compaq Drives, 02/89 D33*.PAK DOS 3.3 Extracts, 02/89 ESDI*.PAK ESDI Drives/Controllers, 02/89 FAT*.PAK FAT Extracts, 02/89 FLPY*.PAK Floppy Drive-related Extracts, 02/89 FUJT*.PAK FUJITSU Drives, 02/89 FidoNews 6-08 Page 20 20 Feb 1989 HD*.PAK Hard Drive Conference extracts, 02/89 INLV*.PAK INTERLEAVE, 02/89 MAXT*.PAK MAXTOR Hard Drives, 02/89 MCRP*.PAK MICROPOLIS HD Extracts, 02/89 MIHD*.PAK MicroScience Drives, 02/89 MITS*.PAK Mitsubishi Drives, 02/89 MSHD*.PAK MicroScience Drives, 02/89 OPTI*.PAK Omptimizing/Optimizers, 02/89 PARK*.PAK HD PARK Extracts, 02/89 PERS*.PAK PERSTOR Controller, 02/89 PRIM*.PAK Priam Drives, 02/89 RLL*.PAK RLL, 02/89 RODI*.PAK RODIME Drives, 02/89 SCSI*.PAK SCSI Drives/Controllers, 02/89 SDCH*.PAK Static Discharge extracts, 02/89 SPIN*.PAK SpinRite HD Management, 02/89 SQHD*.PAK Syquest Drives, 02/89 TAPE*.PAK Tape Backup Systems, 01/89 TDHD*.PAK Tandon Drive Extracts, 02/89 THD*.PAK Tandy Hard Drive Extracts, 01/89 TOSH*.PAK Toshiba Drives, 02/89 VRTX*.PAK Vertex Drives, 01/89 WDHC*.PAK Western Digital Controllers, 02/89 OPTN*.PAK OPTUNE, 02/89 VIRU*.PAK VIRUS, 02/89 Just one last reminder....the asterisk in the filenames above represents a four-digit number, in the format "mmyy" - ergo requesting TDHD*.PAK will get you one complete file (TDHD0189.PAK) now, and one partial file (TDHD0289.PAK) - Should you request it next January, it'll get you twelve files - one for each month. (A complete list of all Almanac files is available as ALMANAC.LST - the system I use is available as ALMANAC.PAK, which includes the morning's updated ALMANAC.LST) Ain't life GRAND? ----------------------------------------------------------------- FidoNews 6-08 Page 21 20 Feb 1989 ================================================================= LATEST VERSIONS ================================================================= GMAIL 1.10 The first verison of GMail, a QuickBBS Group Mail processor has been released, and is available from 1:266/15, or 7:520/911. GMail is a fully functional Group Mail processor, with the ability to import and export directly to/from the QuickBBS message base, as well as functioning as a top or mid-level star. GMail is also fast, on the development system, a 12MHZ AT, with a 28ms HD, it imports almost 3 messages per second. The release archive is available as GMAIL110.ARC, and is file-requestable of downloadable from 7:520/911, or 1:266/15. A support conference, with the name of GMAIL, is also available from the same system. ----------------------------------------------------------------- FidoNews 6-08 Page 22 20 Feb 1989 Latest Software Versions Bulletin Board Software Name Version Name Version Name Version Fido 12K* Opus 1.03b TBBS 2.1 QuickBBS 2.03 TPBoard 5.0 TComm/TCommNet 3.2 Lynx 1.10 Phoenix 1.3 RBBS 1.71C Network Node List Other Mailers Version Utilities Version Utilities Version Dutchie 2.90C* EditNL 4.00 ARC 5.32 SEAdog 4.50* MakeNL 2.12 ARCmail 2.0* BinkleyTerm 2.00 Prune 1.40 ConfMail 4.00 D'Bridge 1.10 XlatList 2.90* TPB Editor 1.21 FrontDoor 2.0 XlaxNode 2.31 TCOMMail 2.0 PRENM 1.40 XlaxDiff 2.31 TMail 8901* ParseList 1.30 UFGATE 1.02* GROUP 2.04* EMM 1.40 MSGED 1.96 * 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 6-08 Page 23 20 Feb 1989 ================================================================= NOTICES ================================================================= The Interrupt Stack 19 May 1989 Start of EuroCon III at Eindhoven, The Netherlands 24 Aug 1989 Voyager 2 passes Neptune. 24 Aug 1989 FidoCon '89 starts at the Holiday Inn in San Jose, California. Trade show, seminars, etc. Contact 1/89 for info. 5 Oct 1989 20th 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 6-08 Page 24 20 Feb 1989 ================================================================= REPORTS ================================================================= IFNA Treasurer's Report January, 1989 Steve Bonine 115/777 IFNA Treasurer's report for January, 1989 RECIEPTS & DEPOSITS Membership fees 150.00 FidoCon '88 1200.00 TOTAL RECEIPTS $1350.00 DISBURSEMENTS Postage 12.65 Professional services (Marc Rubin) 34.00 Bank charges 17.40 TOTAL DISBURSEMENTS 63.79 EXCESS RECEIPTS OVER DISBURSEMENTS 1286.21 ADD BEGINNING BALANCE 6082.72 BALANCE IN ACCOUNT 7368.93 Note: The $1200 item is a payment from the FidoCon 88 sponsors. I have received no financial statement from this group which details any of their expenditures. This is my last monthly IFNA treasurer's report, as I will resign as IFNA treasurer at the Board meeting on February 17-19. Until February 20, full IFNA financial data will be available for file- request from 115/777 using the magic filename of IFNA$. After that date, requests for information should be submitted to the new treasurer. ----------------------------------------------------------------- FidoNews 6-08 Page 25 20 Feb 1989 OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION Hal DuPrie 1:101/106 Chairman of the Board Bob Rudolph 1:261/628 President Matt Whelan 3:3/1 Vice President Ray Gwinn 1:109/639 Vice President - Technical Coordinator David Garrett 1:103/501 Secretary Steve Bonine 1:115/777 Treasurer IFNA BOARD OF DIRECTORS DIVISION AT-LARGE 10 Courtney Harris 1:102/732? Don Daniels 1:107/210 11 Bill Allbritten 1:11/301 Hal DuPrie 1:101/106 12 Bill Bolton 3:711/403 Mark Grennan 1:147/1 13 Rick Siegel 1:107/27 Steve Bonine 1:115/777 14 Ken Kaplan 1:100/22 Ted Polczyinski 1:154/5 15 Larry Kayser 1:104/739? Matt Whelan 3:3/1 16 Ivan Schaffel 1:141/390 Robert Rudolph 1:261/628 17 Rob Barker 1:138/34 Steve Jordan 1:102/2871 18 Christopher Baker 1:135/14 Bob Swift 1:140/24 19 David Drexler 1:19/1 Larry Wall 1:15/18 2 Henk Wevers 2:500/1 David Melnik 1:107/233 ----------------------------------------------------------------- FidoNews 6-08 Page 26 20 Feb 1989 __ The World's First / \ BBS Network /|oo \ * FidoNet * (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / Fido \ _//|| _\ / (________) (_/(_|(____/ (tm) Membership for the International FidoNet Association Membership in IFNA is open to any individual or organization that pays a specified annual membership fee. IFNA serves the international FidoNet-compatible electronic mail community to increase worldwide communications. Member Name _______________________________ Date _______________ Address _________________________________________________________ City ____________________________________________________________ State ________________________________ Zip _____________________ Country _________________________________________________________ Home Phone (Voice) ______________________________________________ Work Phone (Voice) ______________________________________________ Zone:Net/Node Number ____________________________________________ BBS Name ________________________________________________________ BBS Phone Number ________________________________________________ Baud Rates Supported ____________________________________________ Board Restrictions ______________________________________________ Your Special Interests __________________________________________ _________________________________________________________________ _________________________________________________________________ In what areas would you be willing to help in FidoNet? __________ _________________________________________________________________ _________________________________________________________________ Send this membership form and a check or money order for $25 in US Funds to: International FidoNet Association PO Box 41143 St Louis, Missouri 63141 USA Thank you for your membership! Your participation will help to insure the future of FidoNet. Please NOTE that IFNA is a general not-for-profit organization and Articles of Association and By-Laws were adopted by the membership in January 1987. The second elected Board of Directors was filled in August 1988. The IFNA Echomail Conference has been established on FidoNet to assist the Board. We welcome your input to this Conference. -----------------------------------------------------------------