synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / modem.madness / SMMRBBS / NOSN101.ZIP / NOSNAIL.DOC < prev next >

Wrap

Text File | 1992-12-25 | 40.5 KB | 1,123 lines

NoSnail - Netmail for RBBS-PC │ Release 1.00 │ December 25, 1992 (c) Copyright Eddie Rowe 1992 All Rights Reserved Eddie Rowe P.O. Box 434 Ruston, LA 71273 │ BBS: (318)-255-4710 (v.32bis) │ Fidonet: 1:380/14 │ Internet: Eddie_Rowe@f14.n380.z1.fidonet.org │ CServe: >INTERNET:Eddie_Rowe@f14.n380.z1.fidonet.org │ Revisions to this document are annontated in this │ fashion. Table of Contents Copyright and License 1 Warranty 1 What is NoSnail? 1 Software Requirements 2 Hardware Requirements 3 Acknowledgments 3 Installation 3 Addressing Kludge 8 Operation 8 Maintenance 9 Multitasking Environments 10 Security Considerations 10 Software References 11 NoSnail Development 11 Newbees to Fidonet 12 Bug Reports 13 Future Enhancements 13 Fidonet Technical Standards Committee 13 History of NoSnail 13 NoSnail 1.00 Page 1 COPYRIGHT AND LICENSE NoSnail - Netmail for RBBS-PC is (c) copyright 1992 by Eddie Rowe You are hereby granted a limited license to use, copy and distribute NoSnail - Netmail for RBBS-PC on the following conditions: 1. You may use this program for any non-commercial or commercial purpose. 2. You may copy and distribute as many copies of this program, provided you do not charge money for the program. A small fee (for copying, handling, mailing, and the disk containing the copy) is allowed, but this amount shall NOT exceed your real costs. 3. The program and documentation shall NOT be modified in any way. While permission is granted for the conversion of the distribution archive to one's favorite archiving format, files shall NOT be added or deleted from said archive. WARRANTY No warranty of any kind is offered on NoSnail - Netmail for RBBS-PC. Furthermore, you use this program AT YOUR OWN RISK. Under no circumstances shall the author be liable for damage this software may inflict upon you or your property - either by itself or with your help. WHAT IS NOSNAIL - NETMAIL FOR RBBS-PC? NoSnail allows sysops to give their users access to routed outbound netmail (or indiscriminate access to continuous outbound netmail - which is NOT recommended.) Routed netmail is netmail which is moved along existing echomail paths instead of being sent directly to the destination system by placing a special phone call. The end goal of routed netmail is to encourage participants in echos to reduce non-topical conversations and thereby reduce the costs of moving echomail. Think about this: One routed netmail message will pass through a half-dozen nodes, whereas an off-topic echomail message will pass through perhaps hundreds of nodes! SOFTWARE REQUIREMENTS RBBS-PC NoSnail has been tested with RBBS-PC 17.4 with the Maple NoSnail 1.00 Page 2 merges. (Most recent version as of this date is 08-31-92) Please note that there is NO SUPPORT for the carbon copy feature of RBBS 17.4 - I don't need it and apparently no one else does either since I have not received any mail regarding it. FIDONET TECHNOLOGY MAILER │ NoSnail should work alongside ANY FTS-0001 compatable │ mailer. As I only run BinkleyTerm, I do not have any │ personal experience with others. NoSnail has been tested │ alongside D'Bridge, Frontdoor and Intermail. NoSnail is │ capable of writing messages directly to the Outbound area │ according to FTS-0001 specifications or to a netmail │ directory in the *.MSG format. ECHOMAIL/NETMAIL TOSSER NoSnail ONLY handles OUTgoing netmail messages. In order to process INcoming netmail you will need additional software. There are a number pieces of software which │ may be used to accomplish this. MsgToss, OverMail, and │ RBBSMail are the three known packages which support RBBS │ and Fidonet echomail/netmail. PACKER/ROUTER │ NoSnail's job is to export the mail from the RBBS-PC │ style message base and get it into a more compatible │ format. After NoSnail processes the mail, the mail needs │ to be bundled up for your echomail host. The goal is NOT │ to send each message directly to its final destination, │ but to let the message move along echomail channels. │ Some mailer packages have routing built into the mailer │ and there are control files which determine how this │ takes place - it is up to you to determine where your │ mailer sends the netmail created by NoSnail. PLEASE do │ NOT blindly run NoSnail if routing mail is new to you! │ In the past I have used oMMM faithfully to do this task, │ but recently I installed a bare bones Squish setup since │ it supports Binkley's 4D points. My Squish setup is │ enclosed for your convience. PREFERENCES I personally find both BinkleyTerm and RBBSMail to have the same spirit about them as RBBS-PC. In addition to this, both of these authors are BIG supporters of the Standards set forth by the Fidonet Technical Standards Committee. Authors such as these make it easier to write programs to supplement their work, but the decision is in your court. NoSnail 1.00 Page 3 HARDWARE REQUIREMENTS There should be no hardware requirements in excess of those you are currently operating under with RBBS-PC. To quote Jan Terpstra, "think about that for a while....". ACKNOWLEDGMENTS Tom Jennings - creator of Fidonet The BinkleyTerm Trio - Vince Periello The RBBS-PC community. Bruce Gingery for his aid in my grasping the concept of Big Indian - Little Indian when it comes to programming. Randy Bush for putting on "paper" exactly what authors of Fidonet technology software have implemented and his netmail from around the world in answer to my questions. Participants of NET_DEV echo for their insights. Dennis Dodd for his aid in helping me to understand how to properly use DOS interrupts. (still in amazement) INSTALLATION Step 1 - RBBS-PC SETUP First you need to create an area for users to enter their netmail messages inside RBBS-PC. I HIGHLY recommend the use of NETMAIL as your conference/subboard name for this area for the sake of simplicity. While this area should be configured like your other conferences/subboards, it should NOT necessarily be in your AREAS.BBS control file used by your echomail scanner/tosser - I can say for sure │ that this area should be declared as your XNETMAIL area │ in the RBBSMail 18.2 AREAS.BBS. If you are attempting to use NoSnail with ANY version of RBBS-PC greater than 17.3C, DO NOT ALLOW MULTIPLE MESSAGE HEADERS (i.e. Carbon Copies) in the area you setup for NoSnail!!! If you choose to allow these in your MAIN area, then you MUST setup the NETMAIL area as a Subboard with these DISABLED!!! WARNING: Do NOT use CONFIG on the message base used by NoSnail under ANY circumstances! NoSnail is presently following Jan Terpstra's (RBBSMail) lead in the method in which it marks messages as already exported. The ":" between the minutes and seconds is modified to a "." after exportation.) NoSnail 1.00 Page 4 Step 2 - NOSNAIL.CFG NoSnail's configuration file format is much like that of other Fidonet utilities in that it operates on the keyword format. Lines beginning with a semi-colon are ignored as well as blank lines. You may also have a comment after a configuration option provided there is a │ space & semi-colon between the phrase and your comment. The sample configuration included in the archive shows all the variations on comments which are possible. Valid NOSNAIL.CFG phrases: ADDRESS This is your default Fidonet address. It MUST be in the form of "Zone:Network/Node". Additionally if you are operating as a point, NoSnail will accept a 4D address of "Zone:Network/Node.Point". Note: This parameter is REQUIRED AKA1, AKA2, AKA3, ... AKA9 Since some people have brain seizures when they receive mail from a different network than the one they are a member of, NoSnail provides AKA matching - up to NINE AKAs are supported. Place your additional addresses in the proper "Zone:Net/Node.Point" format. AKAs are matched in order of appearance in NOSNAIL.CFG. NoSnail will automatically use an AKA for a message to a Zone which you have an AKA defined. The NOSNAIL.LOG displays what address (or AKA) was used on each message exported for additional error checking. Note: These parameters are optional. ELVISMODE If there are problems with the exportation of a netmail message (i.e. the user used some ungodly syntax for the address) you can have NoSnail return a copy of the failed message to the sender. NoSnail will attempt to shell out and run MsgForm to bounce the message back to its sender if this parameter is used. Note: This parameter is optional. ERROR EXPLITIVE Since you will eventually tuck NoSnail away in some obscure batch file and not be around when it runs, NoSnail proudly supports the Error Explitive. NoSnail NoSnail 1.00 Page 5 will place this string in front of any error messages - providing colorful feedback even while you are not around! I suggest you don't get too carried away here, or your log file will look very weird. Note: This parameter is REQUIRED FLAVOR │ This controls whether NoSnail will write the netmail │ messages directly to the Outbound area (as with previous │ versions) or to the Netmail directory. │ If you wish to have NoSnail to write messages as *.MSG │ messages to a netmail subdirectory, this parameter should │ be "MSG". If you wish to have NoSnail to write messages directly to the OUTBOUND area for Binkley then you have several options. BinkleyTerm uses the extension of files in its outbound area to determine how it should handle the mail. The PREFERRED extension is "OUT". (These are documented in the BinkleyTerm and OMMM docs.) OUT - Normal ; This means that the netmail has not been processed by any of the mail archiving/routing software. It is my understanding that if you do not run any software on this file that it will be treated as a DUT (described below). I have BinkleyTerm configured on my system to NOT dial out for Normal packets - I HIGHLY recommend you do the same. HUT - Hold ; This means that the netmail will not be sent to the destination system, but instead will hang around until that system calls you. CUT - Continuous Mail ; This means that the netmail will be sent directly to the destination system. WARNING: THIS WILL COST YOU THE EXPENSE OF A PHONE CALL!!! DUT - Direct ; This means that the netmail will be sent directly to the destination system. This extension is used for those systems who do NOT operate a mailer except during Zone Mail Hour. WARNING: Packets with this extension have the potential to COST YOU THE EXPENSE OF A PHONE CALL!!! Note: This parameter is REQUIRED NoSnail 1.00 Page 6 INTL The ^aINTL kludge is documented for inTERzone mail in FTS-0001, but some authors have chosen to rely on the line to properly route all their mail. This option ensures that EVERY netmail message has this control line - regardless of its destination. │ Two of the more widely used software packages in Fidonet │ - SquishMail and QMail - require this line. Thanks to │ netmail I have from Scott Dudley (author of Maximus and │ SquishMail), Squish relys on the INTL line when routing │ mail for any other zone than your default. │ Note: While this parameter is optional, its use is │ STONGLY recommended to ensure the proper routing of your │ netmail on remote systems. KILLSENT │ All *.MSG messages have the LOCAL flag set, and may have │ the PRIVATE flag if the message was privileged within │ RBBS-PC. Usage of this parameter sets the Kill/Sent flag │ on mail exported in the *.MSG format and will result in │ the *.MSG netmail message being deleted after packing by │ your packer. This parameter has NO bearing on packets │ written to the Outbound area, NOR does it have any affect │ on the NETMAIL messages file (NETMAILM.DEF). │ Note: This parameter is optional for *.MSG users MSGBASE This is the RBBS-PC *M.DEF message base which contains your netmail messages. This is the messages file that you created in Step 1 above. (If you followed my suggestion to K.I.S.S. this would be NETMAILM.DEF...) Note: This parameter is REQUIRED NETMAIL │ This is the path to your *.MSG subdirectory. │ THIS LINE MUST _NOT_ END WITH A "\" CHARACTER! │ Note: This parameter is REQUIRED OUTBOUND This is your default outbound area which should correspond to the Zone of your default Fidonet address. THIS LINE MUST _NOT_ END WITH A "\" CHARACTER! │ Note: REQUIRED for those of you using BinkleyTerm. NoSnail 1.00 Page 7 SYSOP This is the name you wish to have swapped for messages sent by "SYSOP". Obviously this should be your PUBLIC NAME, but could be an assumed name - whatever floats your boat. DO NOT PUT YOUR SECRET NAME THAT YOU USE TO LOGON REMOTELY FOR THIS PARAMETER!!! A word of warning here for those with CoSysops. Make sure that none of them have "SYSOP" status in the NETMAIL area or they might be sending message out with YOUR name on them. I don't think this very likely (in fact I deem it almost impossible), but I don't do cosysops myself. Note: This parameter is REQUIRED Step 3 - OUTBOUND DIRECTORIES │ Note: Not relevant for *.MSG operation. You must have an outbound directory for EVERY Zone you will intend to send netmail. In our example here, Zone 1 mail would be placed in the OUTBOUND directory, Zone 2 mail would be placed in the OUTBOUND.002 directory, Zone 8 mail would be placed in the OUTBOUND.008 directory, etc. Undoubtedly you already have the proper directories defined for the Zones you send mail to on a regular basis, but remember that some networks such as Fidonet are so large that there are various additional zones within the network. Note: The OUTBOUND directories for multiple zone support are numbered in HEXIDECIMAL, NOT just plain jane decimal! Step 4 - NOSNAIL PLACEMENT While personally I like to place NoSnail & its config file in the RBBS subdirectory, many are placing NoSnail elsewhere and supplying a full path to the NETMAIL message base (NETMAILM.DEF is you followed my lead). Step 5 - MSGFORM PLACEMENT (optional) If you enabled ElvisMode you need to place a copy of MSGFORM in the directory with NoSnail or the DOS path. Step 6 - HELP FILES Take a look at the included help files that I have created to help MY users properly send netmail to │ destinations unknown. There are provided as an EXAMPLE │ and NOT NECESSARILY what you should have for YOUR users. Persons outside of Fidonet may NOT be able to give their users the okay to send mail to people on Internet, NoSnail 1.00 Page 8 Compuserve, MCIMail, etc. Contact your network coordinator (or Boss Node) for aid in determining this. │ I have learned in recent months that RBBS-NET is a valid │ Internet domain also. Unfortunately the lack of support │ for routed netmail may cause undo economic hardship to │ offer your users the capability to send netmail to │ Internet sites. I successfully sent mail to an RBBS-NET │ site via Internet and it was gated by Richard Couture of │ 8:914/201@rbbsnet which was in keeping with the │ information I had at my disposal. Unfortunately Richard │ is not flying the UUCP flag in the RBBSLIST so he may no │ longer be serving as a gateway. Step 7 - MAIL DOOR SUPPORT (optional) Just about everyone and their brother has jumped on the mail door bandwagon. Be sure to configure your mail door to allow access to this area so that your offline users can enter netmail messages. Actually this is the main reason for this product. It is SO EASY to reply to echomail posts via netmail if the reply is not appropriate for the echo! If you have no idea what a mail door can do for you, I need to talk to you! │ I encourage you to point your users to the OFFLINE QWK │ mail reader - it is FREE and works quite nicely. OFFLINE │ has netmail capabilities built into it and would help │ your users not botch the addressing up. I would │ appreciate hearing about any other QWK readers which │ support netmail in a similar manner as OFFLINE. ADDRESSING KLUDGE │ RBBS-PC currently does not support a method for entering │ netmail addresses. NoSnail makes use of a special kludge │ to allow netmail to be sent. NoSnail uses the FIRST LINE │ of the message's text as the address field. This line │ should begin with "To:" and the address should be │ directly after the kludge. (Personally I prefer to leave │ a couple of spaces after the colon, but NoSnail is happy │ with just one.) The address should be in the form of │ "Zone:Network/Node.Point". Here is an example of what │ should be on FIRST LINE of a message on your system that │ you wish to come to me: │ To: 1:380/14 │ Note: The ADDRESS KLUDGE line is NOT exported with the │ netmail. OPERATION Undoubtedly you will want to enter a message or two and put NoSnail through a test on your system PRIOR to NoSnail 1.00 Page 9 putting it in an obscure batch file to ensure it behaves properly under your setup. I recommend you also botch an address on purpose to see how MsgForm performs if you │ have enabled ElvisMode. D'Bridge, Frontdoor, Intermail │ users may wish to test the security offered in NoSnail │ (refer to the security section below). NoSnail reads its configuration file, looks for new messages in the NETMAIL message base, and exports them out as netmail messages. (Obviously NoSnail also marks the messages as sent to prevent duplicates from being sent.) If NoSnail has problems exporting the message, it will attempt to recover from the error, mark the message as sent, and move on to any additional messages which may exist. (If you have enabled ElvisMode, NoSnail runs MsgToss before moving on to the next message for processing so the sender can be alerted to the problem.) ELVISMODE If you configured NoSnail to operate in ElvisMode, NoSnail will send a message to the user when they botch the netmail address, or when the packet writing process fails (usually this is when the zone of the message is NOT a valid zone - i.e. you do not have an outbound directory for that zone.) NoSnail does this by simply shelling to DOS and calling MSGFORM with the following parameters: MSGFORM /LTR:NOSNAIL.LTR /MSG:%1 /PRI /NET /TO:%2 In place of %1 NoSnail puts the message base name you are using for your NETMAIL area (NETMAILM.DEF right?) and in place of %2 it puts the name found in the FROM field of the message it gagged on. Immediately after running MSGFORM NoSnail deletes the NOSNAIL.LTR file which was written by NoSnail. I only have a copy of MSGFORM 1.1 so I cannot say if it works with prior versions or future versions. If you run into problems LET ME KNOW, and DISABLE this feature by removing/commenting "ElvisMode" from your NOSNAIL.CFG. MAINTENANCE NoSnail does not require any extra maintenance beyond a normal echomail area. Since it follows RBBSMail's lead in the manner of marking messages as exported, virtually ANY message purge utility may be run on the NETMAIL NoSnail 1.00 Page 10 message base to keep it trimmed to a reasonable size - │ just be sure to throw any RBBSMail switches. (Now, say it with me, "DON'T USE CONFIG UNDER ANY CIRCUMSTANCES!") As far as I know, Config and MU-Purge are the only two message base utilities which are guaranteed to cause you grief if used on a message base processed by RBBSMail. These WILL also cause you grief if you run them on the message base maintained by NoSnail!!! Users of RBBSMail will want to make use of RBBSMNT because it is of special value to them (plus it is in the same spirit as RBBSMail). I also have personal experience with Chip Morrow and Doug Wilson's MailFix program - included in the Mail Manager .QWK program distribution archive. Users of MsgToss should not have any problems using MsgToss to purge the NETMAIL message just like they do any other echomail area. You might also consider the Huh? and RTMBP packages to take care of maintanance on your netmail area. Both of these have been praised in the RBBS-PC echo, but I do NOT have any experience with either package. MULTITASKING ENVIRONMENTS There is NO support in NoSnail for those who multitask or operate under network environments other than the message base being opened in SHARED mode. One should always assume this when it comes to running software, but in case you assume the reverse, you are WRONG and cruising for a bruising! 8-) │ I have just finished migrating to DESQview 386 on the │ BBS. I am running NoSnail in the same window that I │ run Binkley and RBBS and have not ran into any │ difficulties as my primary node handles all of the mail │ processing and the other node runs barefoot RBBS. │ BinkleyTerm users should be aware that with this version │ of NoSnail attempts to use the BinkleyTerm .BSY flags. │ Prior writing a packet the outbound area NoSnail attempts │ to look for the existance of a .BSY flag for the node for │ which it is about to write the mail. If found NoSnail │ will NOT write directly to the outbound, but instead will │ write to the *.MSG subdirectory. SECURITY CONSIDERATIONS │ Unfortunately those using D'Bridge/Frontdoor/Intermail │ type mailers have to deal with potential headaches. │ These mailer packages feel the need to meddle in messages NoSnail 1.00 Page 11 │ - something which I object to most seriously. These │ mailers look at the beginning of netmail messages and │ have the potential to handle the mail differently than │ intended -immediate mail, file attaches, etc. Great │ pains have been went to in order to parse messages to │ ensure user cannot enter the special FLAGS lines which │ will cause D'Bridge/Frontdoor/Intermail to dial out to │ drop off netmail instead of routing it. Sysops who run │ D'Bridge/Frontdoor/Intermail may desire to try to break │ NoSnail's security to get a valid FLAGS line past NoSnail │ - this is HIGHLY encouraged. (RBBS-PC's line editor will │ allow you to enter control characters.) │ BinkleyTerm users don't have to worry about such problems │ as BinkleyTerm does not meddle. SOFTWARE REFERENCES Throughout this document I've dropped the names of various pieces of software. These should be readily available to you on major BBSs around the United States and Europe (Hi Jan!). In the event you cannot find them locally I have got them online - I have NO idea if these are the newest versions of these programs. These should all be FREQable and/or downloadable as personal downloads using the NOSNAIL LATEST VERSION scheme. (You can manually log onto my system as the name NOSNAIL LATEST and the password VERSION to access my personal file directory.) If you don't operate in Fidonet never fear! I don't turn down File Requests from anyone - that is about as brain dead as you can get IMHO. If I missed listing any, drop me a note and I'll correct the oversight. No, I don't keep any mailers online. FTS-0001.A15 25k Basic Fidonet Technology Specification HUH200.ZIP 35k HUH? - *M.DEF message base utility MAILFIX.ZIP 12k MAILFIX - *M.DEF message base utility MNT-201.ZIP 46k RBBSMNT - *M.DEF message base utility by Jan Terpstra MSGFRM11.ZIP 40k MSGFORM - need to use ElvisMode OMMM_170.ZIP 91k OMMM - Mail masher of sorts (this is the one I use to route my .OUT netmail packets to my echomail host ) │ RMAIL182.ZIP 99k RBBSMail Echomail processor by Jan Terpstra RTMBP200.ZIP 65k RBBS TURBO MESSAGE BASE PACKER - *M.DEF message base utility │ SQSH_101.ZIP 313k SQUISH echomail/netmail processor NOSNAIL DEVELOPMENT NoSnail has been developed under Digital Research's Superior Disk Operating System (version 6.0) and under Micro$oft's Professional Development System 7.1 (just NoSnail 1.00 Page 12 another fancy name for an overpriced version of Basic). │ Additionally its performance has been tested under │ Quarterdeck's DESQview 2.41 & QEMM 6.02. NEWBEES TO FIDONET If you've made it this far in the documentation and are totally confused with things, DO NOT GIVE UP! This document makes a lot of broad assumptions in regards to the operation of RBBS-PC in a Fidonet technology environment. If you need help I am here to lend a helping hand. (not to mention the outstanding group of people in the RBBS-PC echo) Please refer to the beginning of this document for addressing information. If you insist on sending SnailMail, I would appreciate a │ S.A.S.E. for a reply. Those operating in any other │ domain than Fidonet need to give me a few days and poll │ me for a reply - I strive to answer my personal mail each │ day, but ... I'll be revising this document from time to time to enhance its readability and clarity. The only way I'll know I botched an explanation will be for you to let me know. BUG REPORTS If you experience any difficulty with NoSnail, strip your system of any software which may be resident and potentially causing conflicts. If you ARE able to point the finger at a TSR or device driver, please pass this information on to me so I can document it and attempt to remedy. If the item is a shareware product which would allow you to send me a copy, please do. If not please supply me with complete information as to the name & version of the software and the address & phone number of the author. If you are unable to point the finger at anything on your system, then it is time to let me try to duplicate it here. In order for me to do this I will need the following as a minimum: 1. DOS manufacturer and version 2. Machine type (microprocessor), manufacturer, bios manufacturer & date 3. Environment under which you operate. 4. Copy of your AUTOEXEC.BAT and CONFIG.SYS 5. NOSNAIL.CFG 6. Messages file (NETMAILM.DEF) 7. Outbound packets (if trashed or improper) 8. *.MSG files (if the message was bounced back to you for some reason) 9. Complete details as to what is wrong, how NoSnail 1.00 Page 13 discovered, and attempted futile remedies. Archive the various files into a unique archive which includes your node address as part of the name if you have an address, else dream something up. Be sure to also include a file with the output redirected to a text file also. (i.e. run Nosnail with this command line: "NoSnail > Error.rpt") FUTURE ENHANCEMENTS Many have forwarded ideas for future versions of NoSnail. I have recently purchased a C compiler and will be pursuing a port of my BASIC code to C beginning sometime in early 1993. Fans of NoSnail have often dropped netmail with requests so feel free to share your ideas such as the ones below: │ Add support for DESQview and the DESQview API mail │ boxes Add support for FSC-0045 │ Add support for Continuous mail in some fashion FIDONET TECHNOLOGY STANDARDS COMMITTEE NoSnail adheres to FTS-0001 which is the basic Fidonet standard. If my messages can get past Randy Bush's system, then they should be well within specs in my opinion. (Rest easy...I've looked at the files with a HEX editor until I am blue in the face. The test with Randy's system was just so I sleep better at night. Those of you who like me have used Amax to attempt to send netmail to Europe from North America through the gateway know what happens.) Many sysops have no idea what exactly the FTSC does. I've enclosed a text file (FTSC.DOC) of a message entered in the NET_DEV echo clarifying what exactly the "job" of FTSC is. Rick Moore is current FTSC chair. I think all of us who operate in the realm of Fidonet Technology should become more aware of how things operate on the techie side of the family. HISTORY OF NOSNAIL 1.00 December 25, 1992 Changed addressing from SUBJECT FIELD to LINE ONE of the text of the message - i.e. ADDRESS kludge Corrected ElvisMode problem Corrected MSGID problem NoSnail 1.00 Page 14 Corrected a limitation with paths in NOSNAIL.CFG Support for writing *.MSG messages Support for Binkley's .BSY flags Support for Binkley's 4D Point Sub-directories .57 September 11, 1992 Corrected an error in type two packet as determined by MsgTrack .56 September 11, 1992 (pre-released at FidoCon) Optimized & streamlined code AKAs increased from THREE to NINE NOSNAIL.CFG now operates on keywords Support of FTS-0009's MSGID added for reply linking INTL kludge for INTRAZone mail .55 July 3, 1992 NETMAIL Message Base now opened in SHARED Mode Conversion of ALL CAPS names fields to proper case - no more getting hatemail about the ALL CAPS headers from non-RBBS systems! But will I now get it from those with "nonstandard" names??? 8-) Stripped out support for FSC-0039 proposal - messages are now FTSC-0001 by default Support for up to three AKAs Improved local display for the red-eyed sysop Error Explitive Added Elvis Mode Added (RTS- return to sender with MSGFORM) NoSnail's Log file now a bit more verbose Changed from the QuickBasic 4.5 compiler to the PDS 7.1 compiler - including a 286 machine specific version 0.52ß May 6, 1992 - Maintenance Release Fixed a problem dealing with killed messages which had NoSnail 1.00 Page 15 not been packed yet. This caused NoSnail to appear to be locked up, but which was caught in an infinite loop or caused NoSnail to not be able to export messages after killed messages. No implications on message bases packed regularly as far as I know. Hats off to Ken Humrich, Andrew Hart, Jim Wargula for their aid as this was a VERY difficult to fix since I could not duplicate at first...Ken's message base did the trick for me. Enhanced NoSnail to include its very own logfile so that output from running could be separated from bare necessity information for a logfile. (Plus it is kinda cheasy to redirect output. <grin>) 0.51ß April 27, 1992 - Maintenance release. Fixed incorrect implementation of multiple zone outbound subdirectories. These direcories have to be named in hexidecimal, not decimal as initially implemented. Fixed flaw in logic for creating hexidecimal net/node address from a decimal value when the network or node number get to four digits in length. Enhanced error checking so that errors resulting from messages entered with an incorrect address are hopefully recoverable and processing can continue. (This goes for messages entered with illegal characters in the subject field - ie text, and messages for zones for which no outbound subdirectory exists.) Added a public sysop name field to configuration file so that the sysop's public name is used in the exported netmail message. 0.50ß April 21, 1992 - First public beta released. 0.40ß March 16, 1992 - First in-house beta for users of HOTLine RBBS. 0.00 November 1991 - Idea conceived for NoSnail