OS/2 Shareware BBS: 2 BBS

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

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / sqshp111.lzh / squish.doc < prev next >

Wrap

Text File | 1994-11-01 | 292KB | 7,380 lines

Squish Version 1.11 Reference Manual Created November 1st, 1994 Documentation produced by Scott Dudley, with Don Dawson Copyright 1990, 1994 by Lanius Corporation. All rights reserved. Maximus and Squish are trademarks of Lanius Corporation. TABLE OF CONTENTS LICENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Contact Information . . . . . . . . . . . . . . . . . . 3 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 4 About Squish . . . . . . . . . . . . . . . . . . . . . . 4 Features . . . . . . . . . . . . . . . . . . . . . . . . 4 System Requirements . . . . . . . . . . . . . . . . . . 7 Squish, Money and You . . . . . . . . . . . . . . . . . 8 Ordering Information . . . . . . . . . . . . . . . . . . 9 NETWORK PRIMER . . . . . . . . . . . . . . . . . . . . . . . 10 The Basics . . . . . . . . . . . . . . . . . . . . . . . 10 The Outside World . . . . . . . . . . . . . . . . . . . 11 Is There an Echo In Here? . . . . . . . . . . . . . . . 13 INSTALLATION . . . . . . . . . . . . . . . . . . . . . . . . 15 Assumptions . . . . . . . . . . . . . . . . . . . . . . 15 16-bit or 32-bit? SQ386 and SQ386P . . . . . . . . . . . 16 Quick Installation . . . . . . . . . . . . . . . . . . . 18 Modifying CONFIG.SYS . . . . . . . . . . . . . . . 20 Customizing SQUISH.CFG . . . . . . . . . . . . . . 21 Configuring NETMAIL and BAD_MSGS . . . . . . . 24 Configuring EchoMail areas . . . . . . . . . . . . 26 Declaring Areas in SQUISH.CFG . . . . . . . . 26 Declaring Areas in AREAS.BBS . . . . . . . . . 27 EchoMail Areas . . . . . . . . . . . . . . . . . . 28 Elementary Routing . . . . . . . . . . . . . . . . . . . 29 The Send Command . . . . . . . . . . . . . . . . . 30 The Route Command . . . . . . . . . . . . . . . . . 31 Wildcards . . . . . . . . . . . . . . . . . . . . . 32 The All and World Wildcards . . . . . . . . . 32 Address Abbreviations . . . . . . . . . . . . 34 Examples . . . . . . . . . . . . . . . . . . . . . 35 Batch Files . . . . . . . . . . . . . . . . . . . . . . 38 Configuring your Mailer . . . . . . . . . . . . . . 38 Configuring your BBS . . . . . . . . . . . . . . . 40 OPERATION . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Squish Command Line Parameters and Syntax . . . . . . . 42 Command Line Switches . . . . . . . . . . . . . . . . . 47 Running Squish in Multipass Mode . . . . . . . . . . . . 50 SQ386 Usage Notes . . . . . . . . . . . . . . . . . . . 52 AREAS.BBS REFERENCE . . . . . . . . . . . . . . . . . . . . . 53 SQUISH.CFG REFERENCE . . . . . . . . . . . . . . . . . . . . 54 Configuration Options . . . . . . . . . . . . . . . . . 54 Area Definitions . . . . . . . . . . . . . . . . . . . . 78 Area Types . . . . . . . . . . . . . . . . . . . . 78 Area Tags and Paths . . . . . . . . . . . . . . . . 78 Flags . . . . . . . . . . . . . . . . . . . . . . . 79 Split Area Definitions . . . . . . . . . . . . . . 82 ARCHIVERS AND MESSAGE COMPRESSION . . . . . . . . . . . . . . 83 ROUTING . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Generic Routing Commands . . . . . . . . . . . . . . . . 85 Schedules . . . . . . . . . . . . . . . . . . . . . . . 88 BinkleyTerm Routing Commands . . . . . . . . . . . . . . 91 Dynamic Routing (FrontDoor) . . . . . . . . . . . . . . 93 SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 94 MULTIZONE OPERATION . . . . . . . . . . . . . . . . . . . . . 96 POINTS (4D, FAKENETS AND BOSSNODES) . . . . . . . . . . . . . 98 Fakenet Points . . . . . . . . . . . . . . . . . . . . . 98 4D Points . . . . . . . . . . . . . . . . . . . . . . . 98 Remapping . . . . . . . . . . . . . . . . . . . . . . . 99 USING SQUISH-FORMAT MESSAGE AREAS . . . . . . . . . . . . . . 100 BROADCAST MODIFY/DELETE . . . . . . . . . . . . . . . . . . . 104 SQUISH-FORMAT MESSAGE UTILITIES . . . . . . . . . . . . . . . 106 SQPACK: Weekly maintenance . . . . . . . . . . . . . . 106 SQCONV: Conversion between *.MSG and *.SQ? . . . . . . 107 SQSET: Control for message deletion . . . . . . . . . . 109 SQINFO: Diagnostics . . . . . . . . . . . . . . . . . . 110 SQREIDX: Repair (minor) . . . . . . . . . . . . . . . . 111 SQFIX: Repair (major) . . . . . . . . . . . . . . . . . 112 SQFIX32: High-capacity version of SQFIX . . . . . . . . 113 SSTAT: Statistics generation . . . . . . . . . . . . . 114 APPENDIX A - Errorlevels . . . . . . . . . . . . . . . . . . 116 APPENDIX B - Problem Reporting . . . . . . . . . . . . . . . 117 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . 118 INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 LICENCE (C) Copyright 1989, 1994 by Lanius Corporation. All rights reserved. COMMERCIAL DISTRIBUTION AND/OR USE PROHIBITED WITHOUT WRITTEN CONSENT FROM LANIUS CORPORATION. Noncommercial distribution and/or use is permitted under the following terms: 1) You may copy and distribute verbatim copies of the Squish documentation and executable code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy a valid copyright notice "Copyright 1989, 1994 by Lanius Corporation"; keep intact the notices on all files that refer to this Licence Agreement and to the absence of any warranty; PROVIDE UNMODIFIED COPIES OF THE DOCUMENTATION AS PROVIDED WITH THE PROGRAM; and give any other recipients of the Squish program a copy of this Licence Agreement along with the program. You may charge a distribution fee for the physical act of transferring a copy, but no more than is necessary to recover your actual costs incurred in the transfer. 2) Mere aggregation of another unrelated program with this program and documentation (or derivative works) on a volume of a storage or distribution medium does not bring the other program under the scope of these terms. 3) You may not copy, sublicense, distribute or transfer Squish and its associated documentation except as expressly provided under this Licence Agreement. Any attempt otherwise to copy, sublicense, distribute or transfer Squish is void and your rights to use the program under this Licence agreement shall be automatically terminated. However, parties who have received computer software programs from you with this Licence Agreement will not have their licences terminated so long as such parties remain in full compliance, and notify Lanius Corporation of their intention to comply with this Agreement. 4) You may not incorporate all or part of Squish (including related utilities) into a program which is not completely free for all users. If you wish to distribute Squish in this manner, you must obtain written permission from Lanius Corporation. Squish v1.11 Reference Manual - Page 1 5) The privileges granted above apply only to noncommercial users of the Squish software. You are a NONCOMMERCIAL user only if you are running Squish as a private individual with no "sponsors", "backers", and only if your BBS is not making (or helping to make) a profit. You are a COMMERCIAL user if you make a profit from running your BBS. You are also a COMMERCIAL user if your BBS is being run by (or for) a corporation, government, company, foundation, or any other organization. You are also a COMMERCIAL user if your system is used to advertise for such a commercial organization for the purposes of making a profit. This licence only governs NONCOMMERCIAL users. If you are a COMMERCIAL user, you are not licensed to use or distribute this software without the prior written consent of Lanius Corporation. If you wish to run Squish as a commercial user, please see the section of the program documentation entitled "Ordering Information". 6) This licence may be revoked by Lanius Corporation without prior notice. NO WARRANTY WE PROVIDE ABSOLUTELY NO WARRANTY. EXCEPT WHEN OTHERWISE STATED IN WRITING, LANIUS CORPORATION AND/OR OTHER PARTIES PROVIDE SQUISH "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF SQUISH, AND THE ACCURACY OF ITS ASSOCIATED DOCUMENTATION, IS WITH YOU. SHOULD SQUISH OR ITS ASSOCIATED DOCUMENTATION PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT WILL LANIUS CORPORATION BE RESPONSIBLE IN ANY WAY FOR THE BEHAVIOUR OF MODIFIED VERSIONS OF SQUISH. IN NO EVENT WILL LANIUS CORPORATION AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE SQUISH AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY Squish v1.11 Reference Manual - Page 2 OTHER PROGRAMS) SQUISH, EVEN IF LANIUS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY. Contact Information You can contact Lanius Corporation at any of the addresses listed below: FidoNet: Scott Dudley @ 1:249/106 Internet: sales@lanius.com (commercial inquiries) tech@lanius.com (technical support) CompuServe: >INTERNET:sales@lanius.com (commercial inquiries) >INTERNET:tech@lanius.com (technical support) BBS: +1-613-389-8315 (V.32bis) FAX: +1-613-634-3058 Surface mail: Lanius Corporation 777 Downing St. Kingston, Ont. Canada K7M 5N3 Lanius Corporation can also be reached through the FidoNet EchoMail conferences called MUFFIN (Maximus support) and TUB (Squish support). Electronic correspondence is strongly preferred and the use of surface mail is discouraged. If you must send paper mail (and expect to receive a reply), please enclose a self-addressed, stamped envelope. Users outside of Canada should include an international postal reply coupon instead of a stamp. NONCOMMERCIAL USERS SHOULD NOT ATTEMPT TO CONTACT LANIUS CORPORATION BY TELEPHONE. WE ARE NOT ABLE TO PROVIDE VOICE SUPPORT FOR NON-PAYING CUSTOMERS. Please feel free to contact Lanius Corporation at any time to share your comments about this software and/or licensing policies. Our thanks go to the Free Software Foundation for most of the wording of this licence. Squish v1.11 Reference Manual - Page 3 INTRODUCTION About Squish Squish is a multi-featured, FidoNet-compatible EchoMail processor. Squish incorporates most of the common EchoMail functions into one integrated package, including tossing, scanning, packing, point remapping and topic linking. Although Squish was designed to be used with Maximus 2.0 or above, Squish is compatible with other software which supports either the Squish or the *.MSG message base standards. Squish is not merely a "giveaway" utility; rather, Squish is a full- featured conference manager, making it highly competitive with most stand-alone packages on the market today. To install Squish, your first task is to PRINT OUT AND READ THIS DOCUMENT. At the very least, you should print the section on installation. The "Quick Installation" section can guide you through the standard installation procedure. Features Some of the features in Squish version 1.1 include: * One-pass tossing and scanning, with full support for "passthru" areas. Outbound messages can be built directly from the inbound *.PKT files, without needing to stop over in the message areas. * A 32-bit "industrial-strength" version of Squish is available (under both DOS and OS/2) for systems which carry many areas and which have large numbers of downlinks. * Support for "feature DLLs" under OS/2. Third-party developers can write dynamic link libraries which perform actions while Squish is tossing or packing mail. * Support for MSGID-based message linking and dupe checking. * Internal support for both BinkleyTerm and FrontDoor-style routing. * Squish supports both the standard *.MSG format and the proprietary, flat-file *.SQ? format on an area-by-area basis. * Superior multi-zone operation. Primary addresses can be selected on an area-by-area basis, as can SEEN-Bys and Squish v1.11 Reference Manual - Page 4 numerous other features. It's now easily possible (and practical!) to use a single configuration file for multiple, unrelated FidoNet-technology networks. * True support for BinkleyTerm and InterMail "busy flags". Instead of remaining blocked while the mailer is transmitting to another node (and therefore holding up processing), packets are simply queued for later use. All processing is performed in a separate working directory, and packets are only transferred to the mailer's outbound area as necessary. Since Squish stays out of the way of other mail-handling tasks, Squish offers a significant performance advantage over other mail processors. * Areas can be defined in AREAS.BBS for compatibility with other programs, but areas can also be defined in the main Squish configuration file. * Support for all archiving and dearchiving programs, past and future, through the use of a flexible archiver control file. * Verbose binary statistical information (optional). Squish provides enough information for external utilities to provide a 100% accurate billing report for NECs or hubs, based on mail volume. * Point support, running as either a bossnode or a point, for both 4D and "fakenet" points. * Support for the "2+" 4D packet header proposal, including zone and point numbers. * "Point directory" support for BinkleyTerm 2.50 and above. Squish is the first publicly-available program to support the Binkley point directories both conveniently and efficiently. * Squish also features a built-in node remapper and message linker for BinkleyTerm-style systems. The remapper is not limited to points; it also supports wildcards and soundex name matching. The message linker supports both *.MSG and *.SQ? areas, so no external reply linker is required. * Squish can optionally swap to XMS, EMS or disk when running external programs. Squish can therefore be used in many tight-memory situations, since Squish will only occupy 3K of memory when swapped out. (DOS only.) Squish v1.11 Reference Manual - Page 5 * Squish runs under OS/2 in protected mode, in addition to running under DOS in real mode. The OS/2 version of Squish includes a special serialization feature to allow Squish to be run conveniently in a multi-line environment. Squish v1.11 Reference Manual - Page 6 System Requirements Although Squish was designed to be as generic as possible, the following system configuration is required as a minimum: * An IBM PC, XT, AT or PS/2, or a 100% compatible. To run the 32-bit version of Squish, an 80386SX, 80386DX, 80486SX, 80486DX, Pentium, or compatible processor is required. * A hard drive, with at least two megabytes of free space for the installation, plus space to hold the inbound packet files, local message areas, and generated packets. * Software supporting either the *.MSG or *.SQ? message formats. * A front-end which is compatible with either BinkleyTerm or FrontDoor. In addition, Squish-DOS requires MS/PC-DOS 3.0 or above, and Squish-OS/2 requires OS/2 (IBM or MS) 1.2 or above. If you wish to handle compressed mail, Squish will also require an external archiving program. Squish v1.11 Reference Manual - Page 7 Squish, Money and You In general, Squish is a freeware program for noncommercial users only. If you are a noncommercial user and you abide by the terms given in the licence, there is NO CHARGE for running Squish. NONCOMMERCIAL USERS ARE STILL WELCOME TO RUN SQUISH WITHOUT PAYING A CENT. Unlike other software, this program has no crippled features, extra bells'n'whistles or "registration incentives". There is one simple difference between the commercial and noncommercial versions of Squish: the commercial version entitles you to legally use Squish in a commercial environment. If you are a COMMERCIAL USER as defined in point 5) of the licence above, you must obtain a licence before using Squish. Please see ORDER.FRM for more information. If you did not receive a copy of the order form with this document, contact the author at one of the addresses listed in the licence for more information. If you are a NONCOMMERCIAL user as defined in the licence above, you are welcome to use Squish for free. However, Squish is an extremely large and complex program, and simply maintaining the existing code is consuming a large amount of time. Donations of any value (or even just a postcard) will be gladly accepted. However, noncommercial donations are on a VOLUNTARY basis and are NOT REQUIRED. However, please read the program licence carefully, since additional restrictions or qualifications may apply to you. Squish v1.11 Reference Manual - Page 8 Ordering Information Please see the ORDER.FRM file (included in the Squish distribution package) for information on ordering a copy of Squish for commercial use. Squish v1.11 Reference Manual - Page 9 NETWORK PRIMER This section is intended as a primer for SysOps who are new to FidoNet or a FidoNet Technology Network (FTN). This section covers many of the terms and concepts which are required for everyday FidoNet operations. Those who are familiar with EchoMail and mail routing should feel free to skip on to the next section, entitled "Installation". The Basics The term "FidoNet" refers to an amateur electronic mail network, run collectively by a group of system operators. In the beginning, FidoNet started out as a simple system for exchanging private messages between different bulletin boards. Since then, FidoNet has grown into a full-fledged electronic mail and conferencing network which has members in most countries of the world. FidoNet itself is organized into a numerical hierarchy of "zones", "regions", "nets", "nodes" and "points". Each member of FidoNet, individually known as a "node", can be uniquely identified by that system's zone, net, node and point numbers. To define each term: Zones are wide geographical areas, usually covering one or more continents. At the time of writing, FidoNet currently has six zones: zone 1 (North America), zone 2 (Europe), zone 3 (Oceania), zone 4 (South America), zone 5 (Africa) and zone 6 (Asia). Nets cover a much smaller area than zones; a net usually encompasses a large city and the surrounding area. There are usually many nets within each zone, each of which represents a small geographical area within that zone. Nodes are individual systems. Most nodes consist of bulletin board systems, although a few nodes are devoted exclusively to handling mail. If you wish to become a member of FidoNet and you are running a BBS, this is probably where you will start. Points are users on an individual system. Normally, points do not run full-time systems, since they simply send and receive mail through their "bossnodes" (the nodes where the points pick up their mail). As the size of the network grows, points are becoming increasingly popular. If you do not wish to run a full- time system, this is probably where you'll start. Squish v1.11 Reference Manual - Page 10 These four terms can be combined to give a "network address" which identifies any one node in the network. The format of a FidoNet address is as follows: zone:net/node[.point] For example, given a user in zone 1, in net 249, with a node number of 106, and a point number of 2, that user's full address would be '1:249/106.2'. The point number is optional, so both 1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2. This mode of addressing is sometimes referred to as "4D" or four- dimensional, since it includes the four basic elements of a network address. The Outside World Like other electronic mail systems, it's possible to enter a private message on a FidoNet system and have that message be delivered to its final destination in a short period of time. FidoNet systems "talk" with each other over telephone lines, using one or more sophisticated handshaking protocols. To get a message (known in this context as "NetMail") from system "A" to system "B", the following sequence of events has to occur: * The message is created. Most Fido-compatible software packages can be used to generate a private message to a user on another node. The destination address is entered, using the standard 4D addressing scheme. * The on-disk message is then converted to packet (or *.PKT) form. If you are running BinkleyTerm, this will be performed by Squish after a user logs off. If you are running FrontDoor or a similar mailer type, this will be performed by the mailer itself on startup, or while your mailer is connected to other systems. There are four reasons for converting a message into a packet: 1) The packet structure is much more flexible than the local message structure. All of the fields (such as the To:, From: and Subject: fields) in a packet are variable length, whereas the fields in stored messages are fixed-length. 2) Packets are the "compatibility layer". Since all systems convert messages to the *.PKT format before sending them to another system, there are few Squish v1.11 Reference Manual - Page 11 compatibility problems. This means that systems can store their local message bases in different formats, but still be able to exchange messages easily. In addition, more than one message can be stored in a single packet. Sometimes hundreds (or even thousands) of messages can be stored in a single packet. 3) Messages in a packet can have a different address from the packet itself. The packet itself has a destination (the system where you'll be sending that packet directly to), but each message has an individual destination address. This is useful, for example, when a long-distance call is required to connect with certain parts of the network. The message's final destination always stays the same, but by sending the packet to someone who is local to you (and then having that someone send it to another local system, and so on), costs can be controlled quite effectively. Since the interim destination of a packet does not need to be the same as the final destination of the message, routing of messages via the lowest-cost route can be performed. 4) Packets can be given a "flavour". A "flavour" (or a behaviour characteristic) helps your system decide what to do with an individual message. For example, the "hold" flavour instructs your system to hold the message and wait for the destination system to call and pick it up. Other flavours include "crash" (send a message directly to the destination), "direct" (same as crash), and "normal" (wait for later routing commands). Packets always have an extension of *.PKT. (Qualifier: if you are running a BinkleyTerm system, they may have an extension of *.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley always changes them to *.PKT files before they are sent to another system.) * After the packet is created, it can be optionally archived using a file compression utility. Compression is useful when transferring large volumes of mail or sending to long- distance sites, since compressing mail saves both time and money. * The system which created the message then tries to call the destination system. Obviously, if both systems are fairly busy, this may take a while. Messages are sent back and forth between systems through the use of mailers, also known as "front ends". Mailers call out to deliver waiting mail, Squish v1.11 Reference Manual - Page 12 handle incoming messages and files, and in general, supervise the entire file transfer. * After the two mailers connect (using one of several FidoNet protocols), waiting mail and files are transferred between the two systems. * After the transfer completes, the receiving system then tries to import the message with Squish (or any other mail processor). If the packet was compressed by the sender, it will be decompressed. The *.PKT files will then be imported (otherwise known as "tossed") into the local message base, ready for the recipient to read. Although transferring NetMail can involve much more than just what is given above, this should give you a grasp on NetMail fundamentals. Is There an Echo In Here? In the beginning, FidoNet consisted solely of nodes exchanging NetMail. The only way to get a message from "here" to "there" was to send a private NetMail message. However, a technology called "EchoMail" was developed in late 1985; EchoMail is analogous to a public message area or conference, but EchoMail areas (sometimes known as "echoes") are shared among several other systems. EchoMail is organized into different groups of echoes, each with a different topic. For example, the topics of FidoNet echoes range from Maximus Support to deep-sea fishing and many more special-interest groups. To facilitate topic-oriented EchoMail, each echo must given a tag (or area name). This tag is used to uniquely identify that EchoMail area when transferring messages with other systems. (It does not matter what you call the echo on YOUR system, as long as you are using the same tag as everyone else.) Area tags are one word only, although they can include periods and underscores. To start receiving an echo area, you need to know the tag of that area. For example, the area tag for the echo dealing with hardware and other technical issues is "TECH". EchoMail messages are normally public, and they are entered in a message area just like a normal message. EchoMail messages also look like normal, locally-entered messages, but with some special control information at the bottom of each message. After an EchoMail message is saved, an EchoMail utility (such as Squish) is invoked to "scan" that message out to the rest of the Squish v1.11 Reference Manual - Page 13 network. Unlike NetMail, EchoMail areas have an electronic topology. Some echoes are very large, and as such, the cost to directly send a message to each system which carried that echo would be prohibitive. Instead, each system carrying that echo only transfers EchoMail messages to neighbouring systems. (The neighbour you receive an echo from is also known as your "feed".) EchoMail messages get sent from the originating system to its neighbours, and from those systems to their neighbours, and so on. Despite this "hoppity-hop" method of transferring messages, EchoMail is fairly quick; it can often take less than three days for a message to travel from the USA to Australia and back. Just like NetMail, echoes are sent to other systems in packets. EchoMail messages are almost always compressed, since most of the popular echoes have a daily throughput anywhere from 20 to 200 messages per day. Squish handles EchoMail automatically, just like NetMail. However, you have to tell Squish the names of the areas that you wish to carry, in addition to who your "neighbours" are for each echo. (Information on doing this is covered in greater detail in the installation section.) There is much more to both NetMail and EchoMail than mentioned above; however, you should now be comfortable enough with FidoNet terminology to start installing Squish. Squish v1.11 Reference Manual - Page 14 INSTALLATION Assumptions Before proceeding any further, you should already have a FidoNet- compatible front end installed, in addition to a software package which reads either *.MSG or *.SQ? format message areas. In addition, you should have a set of working batch files for your system. This installation guide only covers the bare essentials, and it glosses over what is required to run Squish as an EchoMail "leaf node" (a system which only transfers mail with one other system). Before reading this section, you should be at least somewhat familiar with network terminology and operations; if not, read over the prior section entitled "NETWORK PRIMER". A minimal knowledge of batch files is helpful. The quick installation also assumes that you will be using the *.MSG format for storing messages. If you wish to use the Squish format, please see the section entitled "USING SQUISH-FORMAT MESSAGE AREAS". This installation procedure does not deal with any advanced topics, so most of the command examples have been simplified to make the installation process easier. For full descriptions of each command, please consult the reference material contained later in this manual. Squish v1.11 Reference Manual - Page 15 16-bit or 32-bit? SQ386 and SQ386P The main Squish executable currently comes in four flavours. You may want to use a different version of Squish depending on your operating system and computer type. The examples in this documentation assume that "SQUISH.EXE" is the name of the Squish executable being used. The DOS distribution includes both SQUISH.EXE and SQ386.EXE: SQUISH is the 16-bit version of Squish that runs on all computers. SQUISH requires at least an 8088 processor. SQUISH can address up to 640 kilobytes of memory. SQ386 is the 32-bit, DOS-extended version of Squish. SQ386 requires at least an 80386 processor. (SQ386 is optimized to run the fastest on an 80486, but it will still work on an 80386.) SQ386 can address up to 4 gigabytes of memory. SQ386 usually runs faster than SQUISH. The OS/2 distribution includes both SQUISHP.EXE and SQ386P.EXE: SQUISHP is the 16-bit version of Squish that runs under all versions of OS/2. SQUISHP requires at least an 80286 processor. SQUISHP can address up to 16 megabytes of memory. SQ386P is the 32-bit version of Squish that requires OS/2 2.0 or above. SQ386P requires at least an 80386 processor. (SQ386P is optimized to run the fastest on an 80486, but it will still work on an 80386.) SQ386P can address up to 512 megabytes of memory. SQ386P usually runs faster than SQUISHP. All versions of Squish support the same basic feature set, but the 32-bit versions have some extra options (such as larger buffer settings) that allow for faster execution. SQUISH, SQUISHP and SQ386P are native applications that run without extra support from the operating system. SQ386 is a DOS-extended application that requires a DOS extender to operate. The DOS distribution of Squish includes a copy of Squish v1.11 Reference Manual - Page 16 the DOS/4GW DOS extender. While this DOS extender should work with other operating environments (such as Windows, DESQview, and the OS/2 DOS box), not all combinations have been thoroughly tested. Running SQ386 may not be a simple "plug-and-play" exercise. DOS extenders are kludges to get around the limitations of DOS, but this means that they may not be compatible with all environments. For example, DOS-extended applications may not work properly on a non-dedicated DOS fileserver. DOS-extended applications may also steal system interrupts for longer than the usual amount of time, possibly causing errors if another task is performing an upload or download while SQ386 is running. These are limitations of the DOS extender, and from the point of view of the application developer, very little that can be done about it. DOS extenders are rickety by nature, and they may not be able to coexist with certain hardware or software configurations. WHILE SQ386 WAS TESTED AS THOROUGHLY AS POSSIBLE, THERE IS NO GUARANTEE THAT IT WILL WORK PROPERLY IN ALL ENVIRONMENTS. IF SQ386 DOES NOT WORK FOR YOU, GO BACK TO USING THE STANDARD SQUISH EXECUTABLE. While we welcome problem reports regarding SQ386, remember that it may not be possible to make SQ386 work for you. For more information on using SQ386, please see the section entitled "SQ386 Usage Notes". Squish v1.11 Reference Manual - Page 17 Quick Installation After reading the installation section at least once, you should decompress all of the Squish files from the distribution archive into a separate directory. You can place Squish anywhere you desire, although all of the examples in this manual use C:\Squish as the base directory. After everything has been decompressed, you will need to load an ASCII text editor to modify the Squish configuration files. Any plain text editor will do, including Qedit, DOS 5.0's EDIT, any word processor in "non-document" mode, or even EDLIN. The four main Squish configuration files are: SQUISH.CFG This is the main configuration file. Information about your system is kept in here, including your system addresses, passwords, run-time options, and (optionally) EchoMail area definitions. Squish will first look for a "SQUISH" environment variable. If found, it will try to use the named file as the Squish configuration file. Otherwise, Squish will look for a file called SQUISH.CFG in the current directory. ROUTE.CFG This is the control file used for mail routing and schedules. This file is used for both FrontDoor and BinkleyTerm-style systems, although it plays only a minimal role when used with FD. COMPRESS.CFG This holds information about all of the archiving programs on your system. Squish uses this information to automatically identify the type of incoming archives, and it uses the commands within to add to and extract from archives. This file is compatible with the compression configuration file used by Maximus 2.0 or above. AREAS.BBS (optional) AREAS.BBS has historically been used to define EchoMail conference information, including the name of the conference, where to store the local message base, where to send the messages to, and so on. Squish fully supports the AREAS.BBS format; however, Squish also supports message area Squish v1.11 Reference Manual - Page 18 definition in SQUISH.CFG. For flexibility, areas can be declared in both AREAS.BBS and SQUISH.CFG, which provides for complete compatibility with all existing software. Squish v1.11 Reference Manual - Page 19 Modifying CONFIG.SYS This section applies only to DOS users. OS/2 users can skip this step and go on to the next section, "Customizing SQUISH.CFG". Before modifying the Squish configuration files, you must first make sure that your system has been configured properly. Squish is a disk-intensive program, and it keeps a number of files open at the same time. To make sure that your system is set up to allow this, use an ASCII text editor to edit C:\CONFIG.SYS. Inside CONFIG.SYS, there should be a line which reads 'FILES=n', where 'n' is a number from 8 through 255. If this line does not exist, it should be added. For Squish, you must make sure that 'n' is no less than 30. If you are running a multitasking system, even more file handles (50 or 60) may be necessary. Having more than 30 file handles is allowable, but having less than 30 will certainly cause problems. After you have changed your FILES statement, save CONFIG.SYS. Since CONFIG.SYS is only read once when the computer starts up, you must reboot to make sure that your changes are recognized by the operating system. WARNING! IF YOU INTEND TO USE SQUISH-FORMAT MESSAGE AREAS IN A MULTITASKING OR NETWORK ENVIRONMENT, YOU *MUST* INSTALL SHARE.EXE! Squish uses SHARE for file and record locking, and if two programs are accessing the flat-file Squish format without SHARE loaded, message base corruption will occur. To install SHARE.EXE, either add this line: INSTALL=C:\DOS\SHARE.EXE to your CONFIG.SYS, or add the following line: SHARE to the end of your AUTOEXEC.BAT. Both methods have the same effect. (Note: DOS 5.0 users must install SHARE by the CONFIG.SYS method.) Squish v1.11 Reference Manual - Page 20 Customizing SQUISH.CFG After modifying CONFIG.SYS and rebooting your machine, you can now start configuring Squish itself. For starters, SQUISH.CFG needs to be modified to suit your system. Although you will see many options in the configuration file, only a few need to be modified to get a minimal Squish system up and running. When performing a new installation, most of the options in SQUISH.CFG should be left alone, since the defaults are acceptable in most cases. However, you will need to modify the following keywords: Address This keyword must be modified to match your system's actual network address. If you are already a member of FidoNet or some other network, include your full 4D address here, including your zone, net and node number. If you do not have a node number, set your address to "1:-1/-1" until you receive an official address. If you are running a point system, please see the SQUISH.CFG reference for more information on configuring Squish for use in a point environment. NetFile This keyword tells Squish where to find inbound files. This is commonly referred to as a "NetFile path" or an "inbound directory", since this is where your front end places inbound *.PKT files and compressed archives. AreasBBS This keyword points Squish to the location of an AREAS.BBS file. This file is optional, so if you do NOT have any software which uses an AREAS.BBS, this statement can be commented out. If you are new to FidoNet, please see the section entitled "Configuring EchoMail Areas" to decide which format is best for you. ArcmailAttach If you are running FrontDoor, InterMail, D'Bridge, or any other front-end which requires a "NetMail attach message" to send files, then this keyword should be enabled. Otherwise, if you are running BinkleyTerm or any other program that uses the "outbound area" concept, this statement should be commented out (disabled). Squish v1.11 Reference Manual - Page 21 Compress The "Compress" keyword specifies the location of the archiver configuration file. If you wish to put COMPRESS.CFG somewhere else (or if you wish to use a compatible COMPRESS.CFG, as used by Maximus), you can specify an alternate path and filename here. Otherwise, this option should be left alone. Routing The "Routing" keyword gives the location of your routing control file. If you are using the default configuration, you can leave this as is. Outbound This keyword specifies a directory to use for building packets and file attaches. This keyword is required for both FrontDoor and Binkley-style systems. In a Binkley environment, this should be the "root name" of the BinkleyTerm outbound area. In a FrontDoor environment, this will be the base directory used for building packets and compressed mail archives. No directory extensions should be given for this keyword. For multi-zone systems, Binkley adds an extension to the base directory (to separate the mail for each zone). However, Squish will add the OUTBOUND.### zone extensions AUTOMATICALLY, you should just specify the path (without an extension). Squish will also create a private work area (with a .SQ extension) for both Binkley and FrontDoor-style systems. LogFile The LogFile keyword specifies the path and filename of the Squish log file. This log file uses a Binkley and Maximus- compatible log format. Origin The Origin keyword is only required if you are not using AREAS.BBS. (AREAS.BBS includes a default origin line, so you can skip this keyword if you are using AREAS.BBS.) Squish needs a default origin line to place at the end of messages, just in case a message being scanned did not already contain one. Generally, this line should contain Squish v1.11 Reference Manual - Page 22 the name of your system, your location, and your phone number. The text in your origin line text should be no more than 60 characters (letters/numbers) long. For a normal system, the above changes should be enough to get your system up and running. Later, once your system is running reliably, the control files can be modified to suit your personal preferences. Squish v1.11 Reference Manual - Page 23 Configuring NETMAIL and BAD_MSGS After customizing the main configuration file, you need to declare at least three messages areas. For starters, a NetMail area is required. This is where private messages addressed to specific users on other systems are stored. Squish requires at least one netmail area. Secondly, a bad messages area is also required, since Squish needs a place to store invalid messages. Netmail areas are declared by placing a 'NetArea' line in SQUISH.CFG. A sample NetArea declaration might look like this: NetArea NETMAIL C:\Max\Msg\Net 'NetArea' is the area type. This tells Squish that the area contains netmail. The next part of the line is a one-word 'area tag', which is simply a short form for the area name. In the case above, 'NETMAIL' is the area tag. All areas must be given a unique area tag, but aside from that, the area tag you give to a NetMail area (whether it be 'NETMAIL' or 'WOMBAT') is of little importance. Finally, the last item in the line is the path to the area itself. For *.MSG format areas, this should be a separate directory on your hard drive. Squish will create nonexistent directories when importing messages, so you do not have to create the directory right away. * Tip for advanced users: A Squish-format netmail area can be used instead of *.MSG. For more information, see the documentation for 'NetArea' in the SQUISH.CFG reference. Next, an area to hold bad messages must be created. This area will be used to store insecure messages, messages destined for unknown areas, and other messages that Squish cannot process. The format for a 'BadArea' line is very similar to that of netmail areas: BadArea BAD_MSGS C:\Max\Msg\Bad 'BadArea' is the area type, and it tells Squish that the area will be used to hold bad messages. WARNING! If you are using MsgTrack or some other message-bouncing utility, ensure that each program has its own "bad messages" area. Otherwise, Squish will erroneously attempt to toss bounced messages. Squish v1.11 Reference Manual - Page 24 The next part of the line is the area tag, which has the same restrictions as the tag for netmail areas. 'BAD_MSGS" is suggested for the area tag, but any other single word will do. As with netmail areas, the last part of the line contains the path to your bad messages directory. Again, the bad messages area defaults to the *.MSG format, so this should be the name of a separate directory on your hard drive. Finally, an area for storing duplicate messages is also required. This area will be used to store messages that were erroneously sent to your system more than once. The format for a 'DupeArea' line is similar to that of netmail and bad message areas: DupeArea DUPES C:\Max\Msg\Dupes 'DUPES' is the suggested area tag for the dupes area. Squish v1.11 Reference Manual - Page 25 Configuring EchoMail areas After creating the definitions for both NETMAIL and BAD_MSGS, the next task is to define one or more EchoMail areas. Squish supports two different methods of declaring echoes; the best method for you depends on your system configuration. First of all, EchoMail areas can be declared in SQUISH.CFG. The format for defining echoes is almost identical to the formats for NETMAIL and BAD_MSGS, so it's easy to remember. In addition, several Squish-specific flags can only be used in SQUISH.CFG. Secondly, areas can also be declared in AREAS.BBS. This file is the "standard" for EchoMail area definitions, and many other programs support AREAS.BBS. The format of AREAS.BBS is less flexible than the format of SQUISH.CFG, so several Squish- specific options are not available when using AREAS.BBS. However, if you are converting from another program and already have an AREAS.BBS, this is probably the wisest option. * Tip for advanced users: Squish can handle areas defined in both SQUISH.CFG and AREAS.BBS. You can even declare one area in both places, if you need compatibility with other programs and also Squish-specific features. For more details, please see the EchoArea portion of the SQUISH.CFG reference. Declaring Areas in SQUISH.CFG If you have decided to declare your EchoMail areas in SQUISH.CFG, then read on. Otherwise, skip ahead to "Elementary Routing". Remember, if you are not using AREAS.BBS to define your echoes, you must enable the 'Origin' statement in SQUISH.CFG. (See the "Customizing SQUISH.CFG" section for more details.) Defining an EchoMail area in SQUISH.CFG is similar to defining netmail and bad message areas. A sample echo definition might look like this: EchoArea MUFFIN E:\Msg\Muffin 1:123/456 'EchoArea' tells Squish that the area we are defining is an EchoMail area. 'MUFFIN' is the tag for this area. Unlike the tags defined for NetMail and bad message areas, the tag that you specify for EchoMail areas is important, since the tag is used as the area name when sending EchoMail to other systems. Area tags are Squish v1.11 Reference Manual - Page 26 usually short, and spaces are not allowed. You must ensure that your system is using the same echo tag as your feed, so it's best to call your feed and get the required tag information in advance. 'E:\Msg\Muffin' is the path to the EchoMail area. By default, echoes use the *.MSG format, so a separate directory is required for each echo. If this directory does not exist, Squish will create it automatically. Finally, '1:123/456' is the address of the system from which you receive the echo. This tells Squish that it's okay to accept mail from that address, and it also tells Squish to send locally- entered messages to that system. As many addresses can be listed as desired, with a space between each address. If you are a leaf node, you'll only need to list the address of your feed. Full 4- dimensional addresses (zone, net, node and point) are acceptable. In addition, a number of special flags can follow the addresses. These flags can be used for many purposes, including declaring the area to be Squish format, defining a primary address, or declaring an area as 'passthru'. For more information, please see the EchoArea portion of the SQUISH.CFG reference. Any number of EchoMail areas can be defined, limited by available memory. However, each area must be defined on a separate line in the configuration file. Declaring Areas in AREAS.BBS If you have already defined your EchoMail areas in SQUISH.CFG, then skip ahead to "Elementary Routing". Otherwise, read on. AREAS.BBS is the de facto standard for defining EchoMail areas, so you'll have the highest degree of compatibility if you declare your areas using this method. AREAS.BBS contains two separate components: a default origin line, and also a number of echo definitions. Default Origin Line The very first line of AREAS.BBS is interpreted in a special manner. The line should have the following format: <default_origin>! <sysop_name> Squish v1.11 Reference Manual - Page 27 <default_origin> is the default origin line to use for all of your echoes. Normally, this should include your system name, location, and phone number, or anything else that will fit in under 60 characters. <sysop_name> should be your name. For historic purposes, this should be separated from the default origin line by an exclamation point. Squish does not use the name you specify here, but it should be included for compatibility with other programs. For example, the first line in AREAS.BBS might look like this: MyBBS * Anytown, Anystate * (123) 456-7890! Joe SysOp In this example, the default origin line would be "MyBBS * Anytown, Anystate * (123) 456-7890", and the SysOp name would be "Joe SysOp". EchoMail Areas Following the default origin line can be any number of EchoMail areas. All echoes must each be defined on a separate line, using the following format: <path> <tag> <nodes> <path> is the name of the directory in which the *.MSG files are to be kept. As with other *.MSG-type areas, each echo should have its own separate directory. If the directory does not exist, it will be automatically created. <tag> specifies the area tag for this area. <nodes> is a list of zero or more nodes to which will be sending the specified echo to you. Normally, for a leaf node, you will only be sending the echo to one place: to your feed. All of the addresses go after the area tag, with at least one space between each address. For example, the following line could be used as an entry for the MUFFIN echo: C:\MAX\MSG\MUFFIN MUFFIN 1:123/999 888 777 Squish v1.11 Reference Manual - Page 28 Elementary Routing After you have configured the EchoMail areas available on your system, your attention should be turned to mail routing. In Squish, routing is based on the idea of schedules and control files. A schedule is simply a set of routing commands which can be performed as a single unit. Schedules can be run either all day, during certain times of the day only, or on manual request. Most nodes will only need one schedule, since the majority of systems use the same set of routing commands 24 hours a day. Commands in ROUTE.CFG have three purposes: * Firstly, routing can direct NetMail from one system to another. (Normally, EchoMail is not routed.) For example, routing commands could redirect all NetMail destined for 1:123/456 to 1:987/654. If 1:987/654 is a local call, but 1:123/456 is not, then it's obviously useful to send mail via the system which is local to you. For ArcmailAttach systems, this feature is usually handled by your mailer. * Secondly, routing can control whether or not mail is compressed. When sending large volumes of EchoMail, external programs such as ARC and ZIP can be used to compress mail packets. This reduces the amount of time it takes to transmit mail, which in turn reduces long-distance phone charges. * Finally, routing also controls the 'flavour' of outbound mail. All outbound mail has a flavour (or priority) which controls when the mail gets sent. By default, Squish creates all outbound packets with a "normal" flavour. However, the routing commands can be used to change this flavour to "crash" (send this mail immediately), "direct" (a synonym for crash), or "hold" (do not call out; hold mail for pick-up). The flavour of messages can also be changed by your mailer (depending on when phone rates are the cheapest, for example), but ROUTE.CFG is used to assign a default flavour to each outbound packet. In general, ROUTE.CFG starts off with a section of global routing commands (which are run every time Squish scans the netmail area), followed by a set of zero or more schedules. The commands within the global section and each schedule all use the same format; the only difference is when the commands are executed. No matter what, commands in the global section of the routing control file are ALWAYS executed. Even when explicitly running a different schedule, the global commands are still run first. Squish v1.11 Reference Manual - Page 29 Therefore, the global section should contain commands that you want to run every time that Squish is executed. Everything between the first line of ROUTE.CFG and the first 'Sched' statement is considered to be a global command and is treated accordingly. Since most nodes will not require schedules, only basic routing information is described here. Most nodes will have all of their routing commands in the global section of the routing file, which is what this quick installation describes. Routing commands in ROUTE.CFG are executed from top to bottom in sequence. In other words, if you place a certain routing command before another, you can be assured that Squish will process each command in the order you specified. By default, unless routing commands are used for a given node, mail will be sent directly to that node, uncompressed, using the normal message flavour. However, various routing commands can be used to modify this behaviour. The Send Command The most basic form of routing is the 'Send' command. This command instructs Squish to compress mail for the specified nodes, and to give the resulting mail a flavour. The Send command does NOT perform any readdressing; it simply modifies the flavour and compression of the mail, without changing that mail's destination. The format for the Send command is as follows: Send <flavour> <node> [<nodes>...] <flavour> specifies the flavour to use for the resulting compressed mail archive. Valid flavours are normal, crash, hold and direct. Following the flavour comes a list of one or more nodes. Squish will search for normal-flavoured, uncompressed mail destined to any of the specified nodes, and compress and flavour that mail accordingly. For example, given the following command: Send Crash 1:123/456 Squish would take all normal-flavoured packets for 123/456, compress them using the default archiver, and send the compressed mail archive to 123/456 using the crash flavour. Squish v1.11 Reference Manual - Page 30 You can specify more than one node for a Send command, but Squish behaves exactly as if each node were in a separate Send command of its own. If you wish to route mail for one system through another, then the Route command must be used instead. In other words, the following command: Send Crash 123/456 234/567 345/678 is completely identical to this: Send Crash 123/456 Send Crash 234/567 Send Crash 345/678 Both of these commands would compress normal-flavoured packets for 123/456, 234/567 and 345/678, give the compressed mail the crash flavour, and send the resulting archives to 123/456, 234/567 and 345/678 (respectively). If you are using an ArcmailAttach mailer, then the 'Send' command is probably the only one you'll need. Dynamic routing is performed by your mailer, so the only reason for using ROUTE.CFG is to compress and flavour mail, which is exactly what the Send keyword does. The Route Command The Route command is similar to the Send command; however, Route can be used to change the destination address of mail (otherwise known as routing that mail), whereas Send only sends mail directly to its destination. The Route command is normally NOT required for systems using the ArcmailAttach keyword. If you are running an ArcmailAttach mailer, most messages will be routed on- the-fly, so you can safely skip this section. The format of the Route command is as follows: Route <flavour> <target> [<nodes>...] As with the Send command, <flavour> specifies the message flavour to give the resulting archive. Valid flavours are normal, crash, direct, and hold. <target> specifies the address of the routing target. Mail for all of the other nodes will be packaged up, given the specified flavour, and sent to this address. In other words, this is where all of the routed mail will be sent. In addition, mail addressed to the target itself will also be flavoured and sent accordingly. Squish v1.11 Reference Manual - Page 31 Make sure that you have the permission of the target node before routing mail through his/her system. <nodes> is the optional list of network addresses for which Squish should readdress mail. Squish will look for normal- flavoured, uncompressed packets for these nodes, and then route them through the specified target. For example, the following route command: Route Crash 123/456 234/567 345/678 would take mail for 123/456, 234/567 and 345/678, compress it using the default archiver, and send it all to 123/456 using the crash flavour. Note the difference between Route and Send: whereas Send will send the mail to each node individually, Route will send all of the mail to the first node specified. The difference between Route and Send is a fundamental concept in Squish routing. Wildcards The Route and the Send commands provide the framework for a very flexible routing system. However, the Route and Send commands are often not enough to accomplish a particular task. For example, to route mail for all nodes in net 123 through another node, is it necessary to explicitly give the node number for each system? Fortunately, the answer is no. The All and World Wildcards In both SQUISH.CFG and ROUTE.CFG, Squish supports a form of wildcards. These wildcards can be used to specify a particular node or range of nodes for a particular routing command. The most basic form of wildcard is 'All'. 'All' can be used in place of a zone, net, node or point number, and it instructs Squish to process mail for all nodes which match the rest of the address. For example, given the following command: Send Crash 106/All Squish would then scan for normal packets destined to any node in net 106, compress the packet, give it the crash flavour, and send the resulting archive directly to its destination. Squish v1.11 Reference Manual - Page 32 Wildcards can also be used with the 'Route' command. To use the same example, but to have all of net 106's mail routed through one node, the following could be used: Route Crash 106/123 106/All As above, this would compress normal-flavoured packets for nodes in net 106, and give the resulting archives the crash flavour. However, all of the archives would be sent to 106/123, where they could be handled by routing commands on 106/123's system. Squish also supports zone wildcards. For example, the following command: Route Crash 2:123/456 2:All would take mail for all addresses in zone 2, compress it, and send it all through 2:123/456. Finally, the 'World' wildcard can be used to specify all uncompressed and normal-flavoured packets, no matter where they are addressed. This is typically useful for "clean-up" situations and for taking care of mail that has no applicable routing commands. 'World' is equivalent to 'All:All'. For example, the following command: Route Crash 1:987/654 World would cause all remaining, normal-flavoured mail to be compressed and sent to 987/654. As before, all of these wildcards can be used for both the Send and Route commands, in addition to most of the other commands in ROUTE.CFG and SQUISH.CFG. IMPORTANT NOTE FOR ARCMAILATTACH SYSTEMS: By default, Squish leaves outbound packets in an uncompressed form. However, ArcmailAttach mailers only recognize compressed archives, so you MUST ensure that all packets that Squish creates are compressed. To do this, you must add the following statement to the end of your ROUTE.CFG: Send Normal World This instructs Squish to archive all remaining packets, and to give the resulting archives a normal flavour. This makes sure that your mailer can see all of the packets that Squish generates, even if you have not added specific routing commands for an individual node. Squish v1.11 Reference Manual - Page 33 Address Abbreviations Although full 4D addresses can be specified almost everywhere, Squish also permits several shortcuts to save on typing. When Squish encounters a node number, it will save a copy of that address. Later, if Squish comes across an incomplete address, it will use that saved copy to fill in missing information. Squish can use short forms to handle zone and net numbers; however, a node number must always be specified. For example, the following Route command: Route Crash 1:12/34 1:12/45 1:23/45 2:23/56 2:23/67 2:34/67 could be rewritten as follows: Route Crash 1:12/34 45 23/45 2:23/56 67 34/67 which has the same effect. In this case, Squish assumes zone 1 and net 12 when it comes to the lone "45", based on the previous address. The "23/45" address is also assumed to be in zone 1, again because of the earlier zone 1 address. The "2:23/56" is used to start a new set of zone and net defaults, so the full address is required. As with "45, the "67" assumes the zone and net numbers of the last address. Finally, a zone number of 2 is assumed for the last address because of the earlier "2:". Squish v1.11 Reference Manual - Page 34 Examples This section contains several simple routing files, including comments, which should demonstrate the uses of the various routing commands. In ROUTE.CFG, comment lines start with either a semi-colon (;) or a percent sign (%). (Everything on the line following either of those characters will be ignored.) Example 1: Simple ArcmailAttach routing % Sample routing file #1. This example demonstrates a minimal % system configuration. This type of routing file is the most % useful when using the ArcmailAttach keyword: since all % routing is performed by your mailer, the only purpose for % ROUTE.CFG is to tell Squish which messages to compress. % % This routing file simply compresses all mail and sends it % to the mail's final destination. (However, these messages % can be routed by your mailer using dynamic routing.) Send Normal World % The above statement tells Squish to take mail for everyone % (ie. 'World'), place it into an archive, and give it the normal % flavour. Unless you have a special configuration, this is all % of the routing that you have to do for ArcmailAttach systems. Example 2: Simple BinkleyTerm Routing % Sample routing file #2. This example demonstrates a minimal % system configuration for a BinkleyTerm mailer. This example % assumes several things: % % 1) You will be connecting with another node on a fairly % frequent basis, and you'll be routing most of your % long-distance netmail through this system. (Most % Net Echo Coordinators are willing to route netmail % for little or no charge, but you should ask before % doing so.) % % 2) You want to send mail directly to nodes in your own % net. Since those nodes are local to your system, sending % netmail directly is usually much faster. % % 3) You may also be sending netmail to selected long-distance Squish v1.11 Reference Manual - Page 35 % nodes, and you want EchoMail for those systems to be sent % directly, as opposed to being sent through your local % coordinator. % % This example also uses a fictitious network address of % 123/456. Obviously, your own net and node number should % be substituted for this address, or -1/-1 if you have no % network address. % The first command instructs Squish to send netmail directly % to all systems in net 123. Mail will be archived, given % the "crash" flavour, and sent directly to its destination. % % Most of your mail will probably be to and from local systems, % so sending it directly is usually the best route. Send Crash 1:123/All % The next command also tells Squish to send mail directly % to nodes 111/222, 222/333 and 333/444. These addresses % are presumably long-distance nodes with which you talk % frequently, and you therefore want to send your % NetMail directly, as opposed to routing it. If you % do not communicate with any long-distance nodes, this % command can be commented out. % % However, if you are running any EchoMail conferences of % your own, and you are feeding the conference to other nodes % from your system, you should include the addresses of those % nodes here. It is considered to be impolite and against % FidoNet policy to route unsolicited EchoMail through % other systems, so you should usually send EchoMail % directly. All of the routing commands apply to both % NetMail and EchoMail, so you should make sure that you have % added the appropriate commands to deal with systems that % receive EchoMail from you. Send Crash 1:111/222 333/444 555/666 % The third and last command tells Squish to send mail for % everywhere else to 1:123/3, which is presumably your area % coordinator. % % Notice how this statement is positioned below all of the % other routing commands. Since Route and Send only operate % on uncompressed packets with a normal flavour, this command % ignores mail which has been processed by the two other % commands; it will only route mail which has not been already % processed. % Squish v1.11 Reference Manual - Page 36 % However, if this command was mistakenly placed above the % other two commands, you would find that ALL of your mail % was being sent to 123/3 regardless. Since the mail % is archived and changed to a crash flavour by this % command, the following Send commands would not find any % mail to process, which was probably not your original % intent. Route Crash 1:123/3 World Squish v1.11 Reference Manual - Page 37 Batch Files After adding the appropriate routing commands, the final step in the installation is to modify the batch files for your mailer and your BBS. At a bare minimum, Squish must be run in two different situations: 1) After receiving mail. When your mailer receives mail from another system, Squish needs to be executed to decompress the mail and import it into your own message base. Optionally, Squish can also scan out or export mail at the same time, if you are sending an echo to someone else. 2) After entering messages locally. When a message is entered, either through a BBS or an external editor, Squish must be called to export the locally-entered messages. There are several variations on this theme (after entering EchoMail, after entering NetMail, or both), but the same general process is followed for each variation. Configuring your Mailer First of all, your mailer must be configured to either run an external program when mail has been received, or else to drop back to the calling batch file with an errorlevel. If you do not know how errorlevels work, you should refer to the Maximus Operations Manual for a hand-holding tutorial. Section eight of the Maximus installation covers errorlevels and batch files. This gives a general overview of concepts and terminology, which will be helpful when setting up Squish. Assuming that you have batch file basics covered, the first step is to find out which errorlevel your mailer uses when mail is received. For BinkleyTerm, this errorlevel is specified by the 'E2' and 'E3' flags in your BINKLEY.EVT configuration file. For FrontDoor, this errorlevel is specified in the Mailer / Errorlevels / ReceivedMail option in SETUP.EXE. For other systems, please consult your mailer's documentation. The next step is to invoke Squish when the specified errorlevel is found. Assuming that your mailer exits with an errorlevel of 100 after receiving mail, the following should be placed in your batch file, immediately after running your mailer: :Loop bt unattended ; Other commands here if errorlevel 100 goto SquishIn ; Toss messages if errorlevel 96 goto BBS ; Call a BBS program Squish v1.11 Reference Manual - Page 38 if errorlevel 48 goto BBS ; Call a BBS program ... and so on ... Only the lines labelled ':Loop' and 'SquishIn' are required by Squish itself. The other lines should have be added so that your BBS is run for human callers; they are not mandatory for Squish's operation, and the errorlevels may be different (depending on which BBS package you run). The errorlevel procedure is the same for FrontDoor, except that 'fd' should be substituted for 'bt unattended'. Please consult your mailer's documentation to learn how to start up a different type of mailer. The ':Loop' label should be placed just before your mailer's command-line. After tossing and scanning mail, Squish will jump back up to this label and restart your mailer. The 'if errorlevel 100' statement checks for the "received mail" errorlevel, and if found, it jumps to the part of the batch file which starts up Squish. Keep in mind that all errorlevels must be given in DESCENDING ORDER. When interpreting each 'if errorlevel' statement, the operating system performs a check to see if the current errorlevel is GREATER THAN OR EQUAL TO the specified errorlevel. To ensure that each line is executed only when you want it to, all of the errorlevels have to be in descending order. After adding the check for receiving mail, you should now create the portion of the batch file which actually invokes Squish. Near the end of your batch file, but before any final 'exit' or ':end' statements, add the following: :SquishIn cd\Squish squish in out squash link cd\Bink goto Loop This does five things: 1) The ':SquishIn' label is referenced by the earlier 'if errorlevel' statement. This is where your batch file will jump to if mail is received. 2) The 'cd\Squish' changes the current directory to \Squish, Squish v1.11 Reference Manual - Page 39 which is presumably where SQUISH.EXE and its associated configuration files are kept. 3) The 'squish in out squash link' command starts Squish in one-pass mode. This command will cause Squish to check for incoming mail, decompress it, toss it to the local message bases, scan it out to other nodes (if necessary), pack messages and create ARCmail attaches in your netmail area, and finally, to link reply chains. For more information on Squish's command-line parameters, please see the section entitled "Squish Command Line Parameters and Syntax". 4) The 'cd\Bink' command tells DOS to change back to your mailer's directory. (If you are running FrontDoor, this will probably be 'cd\FD' or something similar.) Unless this line is included, your mailer may not operate properly after Squish runs. 5) The 'goto Loop' command causes your batch file to loop back to the top again, and to restart your mailer. Unless this command is included, Squish would simply drop back to the operating system, or possibly execute other unwanted commands in your batch file. To make sure that this looping works, ensure that there's a ':Loop' label right above the line that calls your mailer. (See above for more details.) Configuring your BBS After making the above modifications, Squish should be fully operational when receiving mail. The only other modification you need to make are to your BBS's or off-line reader's batch files. The procedure is similar: determine which errorlevel is used when mail is entered, and jump to the appropriate portion of the batch file. For example, Maximus uses the following errorlevels: Errorlevel 12: Caller entered EchoMail (and maybe NetMail) Errorlevel 11: Caller entered NetMail (but not EchoMail) Others: Caller entered neither NetMail nor EchoMail The two separate cases -- NetMail/EchoMail, and NetMail only -- must be treated differently. When EchoMail is entered (and possibly NetMail as well), the echoes must be scanned for messages to export, and the netmail area must be packed (or scanned for ARCmail attaches). However, when only NetMail is entered, only the packing/scanning needs to be performed. What follows is a simple batch file which demonstrates how to implement Squish on a Maximus system. This assumes that you have Squish v1.11 Reference Manual - Page 40 configured Max's "Log EchoMail" feature and that it points to the file C:\MAX\ECHOTOSS.LOG. max -p%1 -b%2 -t%3 ; Other parameters here if errorlevel 12 goto SquishOut if errorlevel 11 goto SquishSquash if errorlevel 5 goto Recycle ... and so forth ... As before, only the 'SquishOut' and 'SquishSquash' lines are required by Squish. After taking care of the other errorlevels, you should insert the following two sections in your BBS's batch file: :SquishOut cd\Squish ; Chg to Squish dir. squish out squash -fc:\max\echotoss.log ; Export messages del c:\max\echotoss.log goto End :SquishSquash cd\Squish squish squash ; Pack msgs and do ArcAttaches goto End The section marked ':SquishOut' invokes Squish and instructs it to scan the EchoMail areas listed in ECHOTOSS.LOG. If your BBS program or off-line reader is not capable of generating an ECHOTOSS.LOG, then simply omit the '-fc:\max\echotoss.log'. Omitting that command-line option will cause Squish to scan all EchoMail areas every time it is run, which is usually much slower than using ECHOTOSS.LOG for scanning. (Please see the section entitled "Squish Command Line Parameters and Syntax" for information on the format of ECHOTOSS.LOG.) After exporting messages, the 'squash' portion of the command line tells Squish to pack netmail messages, create ARCmail attaches, and execute the commands in ROUTE.CFG. The ':SquishSquash' portion of the batch file does the same thing, except that it skips scanning the EchoMail areas, and simply runs Squish in a mode which packs netmail messages and executes ROUTE.CFG. This concludes the Squish installation procedure. If you have followed all of these steps, you should have a working version of Squish that tosses, scans, packs, links, slices and dices. For advanced tricks and tips on operating Squish, please read through the rest of this manual at your leisure. Squish v1.11 Reference Manual - Page 41 OPERATION Squish Command Line Parameters and Syntax Squish operates in several modes, all of which are controllable from the command line. The command line itself is broken down into a series of "actions" and "switches". Actions are single words which control Squish's processing modes, such as tossing and scanning messages. Switches are used to modify the behaviour of those modes, such as only scanning certain areas, not displaying any output, and so on. The format of the command line is as follows: SQUISH <switches> <mode> Modes <mode> consists of one or more of the following keywords: IN Toss (import) messages. This option causes Squish to check for packets and compressed mail archives in all of the NetFile directories, and to import any messages that it finds. OUT Scan (export) messages. This option causes Squish to scan all EchoMail areas for new messages. If Squish finds a new message, that message will be exported to all of the nodes listed in that area's definition. Squish uses the SEEN-BYs to keep track of which nodes the message has already been sent to, so the message may not be exported to all of the nodes listed. If both the IN and OUT actions are specified on the same command line, Squish will function in "single pass" mode. "Single pass" means that Squish will both toss and scan messages at the same time (which yields higher performance). Single pass mode is especially useful for systems running many "passthru" areas, since messages will be written directly to the output *.PKT files, as opposed to making a temporary stop in a message area. Consequently, using passthru message areas in multipass mode is MUCH slower than using passthru areas in single-pass mode. However, you should ONLY use the "IN" parameter when there are messages to be tossed. When running with "IN" and "OUT", Squish will only scan those areas to which messages are being tossed. Therefore, when you Squish v1.11 Reference Manual - Page 42 wish to only scan messages, the `IN' parameter should NOT be specified. When the OUT command is specified alone, Squish will scan all EchoMail areas on the system. When used in conjunction with the IN command, Squish will scan messages as it tosses. In addition, if Squish detects that unsent messages exist in an EchoMail area, Squish will invoke a full scan of that area before tossing to it. SQUASH For a BinkleyTerm system, the SQUASH command packs messages from the NetMail areas, scans the outbound areas, performs mail routing, and compresses packets. For a FrontDoor-style system, the SQUASH command compresses packets, scans the NetMail area, creates ARCmail attach messages, and optionally kills any orphaned archives. If the SQUASH command is specified on the same command line as IN and OUT, the single pass MaxMsgs mode can also be used to limit outbound packet sizes. LINK Relink reply chains. The LINK command will read all messages in an EchoMail area and create reply links for each message (based on the subject fields). Relinking allows other software to perform "threaded reading" on message bases, which is an easy and convenient way of viewing messages. When combined with the IN and OUT commands, only those areas which received messages will be linked. By default, the LINK command only processes EchoMail areas. However, by using the "-f" parameter to specify one explicit area, a link can be forced for any type of area. (For example, "squish link -fNETMAIL" will force the NetMail area to be linked.) RESCAN Rescan one or more EchoMail areas. The RESCAN command provides a convenient way to rescan EchoMail areas from the command line, instead of fiddling with 1.MSG and other system files. Unlike the other modes, RESCAN cannot be combined with other switches or actions. The format for the RESCAN command is: SQUISH RESCAN <echo_or_tosslog> <node> Squish v1.11 Reference Manual - Page 43 <echo_or_tosslog> is either the tag of an EchoMail area, or the name of an ECHOTOSS.LOG-format file (containing a list of area tags). <node> specifies the node number for which the specified EchoMail areas should be rescanned. After processing the command line, Squish will immediately rescan ALL of the messages in the specified areas. The SEEN-BYs will not be updated in the on-disk message base, the high water mark will be left untouched, and the messages will not be sent to anyone except the listed node. This command was designed for NECs and other EchoMail hubs who wish to rescan entire message bases for nodes who have just connected to a particular echo. Warning! If you wish to specify command line switches in conjunction with the RESCAN command, those switches must precede the rescan command on the command line. In other words, to leave all packets in the OUTBOUND.SQ area, use `SQUISH -L RESCAN AREANAME NET/NODE'. GET This command instructs Squish to request a file from a node given on the command line. THIS COMMAND IS NOT SUPPORTED FOR ARCMAILATTACH SYSTEMS. The format of the GET command is shown below: SQUISH GET <filename>[!<pwd>] [FROM] <node> [flavour] <filename> is the name of the file to be requested. The filename can contain wildcards. <pwd> can be used to specify the password for a password-protected file. A single exclamation mark must separate the filename and password. The optional literal "FROM" can be used to make the Squish command line more readable. <node> specifies the node number to which the file request should be sent. <flavour> specifies the optional flavour of the request. It can be one of CRASH, DIRECT, HOLD, or NORMAL (the default). Squish v1.11 Reference Manual - Page 44 Examples: SQUISH GET FILES FROM 249/106 CRASH Request "files" from 249/106 using a "crash" priority. SQUISH GET TEST.ZIP!MYPWD 2:254/1 Get "test.zip" from 2:254/1 using a password of "mypwd". UPDATE This command instructs Squish to perform an update request for the node given on the command line. THIS COMMAND IS NOT SUPPORTED FOR ARCMAILATTACH SYSTEM. The format of the UPDATE command is shown below: SQUISH UPDATE <filespec>[!pwd] [FROM] <node> [flavour] The command-line syntax of the UPDATE command is identical to that of the GET command. However, this command instructs Squish to perform an update request instead of a simple file request. In addition, a fully-qualified pathname must be provided, instead of just a filename. SEND This command instructs Squish to send a file to a node given on the command line. THIS COMMAND IS NOT SUPPORTED FOR ARCMAILATTACH SYSTEMS. The format of the SEND command is shown below: SQUISH SEND [^|#]<filename> [to] <address> [flavour] <filename> gives the name of the file that is to be transmitted to the remote system. If a "#" is placed in front of the filename to send, the file will be truncated after it is sent. If a "^" is placed in front of the filename to send, Squish will delete the file after it is sent. IMPORTANT NOTE FOR OS/2 AND 4DOS USERS: Since the "^" character has special significance on the OS/2 and 4DOS command lines, one must enclose the entire filename (including the "^") in quotes. Squish v1.11 Reference Manual - Page 45 Examples: SQUISH SEND C:\CONFIG.SYS TO 249/1 CRASH Send c:\config.sys to 249/1 using a priority of CRASH. SQUISH SEND "^E:\Max\Max.Exe" to 106/114 Hold Send e:\max\max.exe to 106/114 using a priority of HOLD. The file will be deleted after it is sent. SQUISH SEND #e:\*.* 273/703 Send all of the files in the root directory of E: to 273/703, using a priority of NORMAL. The files will be truncated after they are sent. POLL This command instructs Squish to poll a specified node. The format of the POLL command is as follows: SQUISH POLL <address> [flavour] <address> is the node which is to be polled. Examples: SQUISH POLL 1:249/106 Crash Generate a crash poll to 1:249/106. SQUISH POLL 2:253/68 Generates a normal poll to 2:253/68. With the exception of RESCAN, SEND, GET, UPDATE and POLL, all of these modes can be specified at the same time for optimum performance. The command "SQUISH IN OUT SQUASH LINK" instructs Squish to toss and scan messages in single pass mode, to pack messages from the NetMail area, to route and compress packets, and to relink reply chains. Certain combinations of the Squish command line parameters are useful only in certain situations. Namely, the "IN" command must only be used when there are packets to be tossed, so care must be taken to use "IN" only when necessary. Squish v1.11 Reference Manual - Page 46 The following command lines are recommended for various situations: After receiving EchoMail or NetMail from another system: SQUISH IN OUT SQUASH LINK (with an optional -fECHOTOSS.LOG) After EchoMail and/or NetMail has been entered locally: SQUISH OUT SQUASH LINK (with an optional -fECHOTOSS.LOG) After NetMail has been entered locally: SQUISH SQUASH Command Line Switches In addition to <mode>, Squish accepts any of the following command line switches: -a<file> The -a switch instructs Squish to use the specified AREAS.BBS-like file, overriding the filename specified in SQUISH.CFG. -c<file> The -c switch instructs Squish to use a configuration file with the specified path and filename, as opposed to looking for SQUISH.CFG in the current directory. This switch will override the config name specified by the SQUISH environment variable (if any). -f<file> The -f switch specifies the name of an ECHOTOSS.LOG- type file which contains a list of echo tags to process. When used in conjunction with the IN command, Squish will create a log of all non-passthru echoes that received messages during the current session. When used in conjunction with the OUT or LINK commands, Squish will only process echoes listed in the ECHOTOSS.LOG file. Although the -f switch was designed to be used with a tosslog filename, it can also specify the name of a single EchoMail area to be processed. For example, "SQUISH OUT -fMUFFIN" would instruct Squish to scan the MUFFIN echo for new messages. WARNING! Squish will never delete ECHOTOSS.LOG. When tossing, Squish will simply append to the log you specify (to fully supporting multi-line systems). It is assumed that your batch files will delete Squish v1.11 Reference Manual - Page 47 ECHOTOSS.LOG after performing all necessary processing; this must always be done, or else ECHOTOSS.LOG will grow and grow after each successive invocation of Squish. -l The -l switch (BinkleyTerm systems only) instructs Squish to leave *.OUT packets in the OUTBOUND.SQ holding area. Before Squish terminates, it normally moves all unrouted packets from OUTBOUND.SQ to the proper zoned outbound area. However, if you are running Squish in a multipass environment, you may wish to leave the packets in the OUTBOUND.SQ area between passes to shield the packets from other programs on multitasking or multi-line systems. -n<file> The -n switch instructs Squish to use a different log file for the current run only. This switch overrides the LogFile keyword in SQUISH.CFG. -o The -o switch (BinkleyTerm systems only) instructs Squish NOT to pack messages in the NetMail area when performing a SQUASH command. Squish will still scan the outbound area and archive packets, but no NetMail messages will be processed. If you need to run an external utility over your NetMail area (such as a message tracker or readdresser), this option will allow you to use MaxMsgs with a one-pass IN OUT SQUASH command line. Squish can be run with IN OUT SQUASH and the -o switch, and then your external utility can be run, followed by a separate SQUISH SQUASH without the -o switch. -q The -q switch enables "quiet mode". Quiet mode suppresses most of the information displayed while a packet is tossing, although Squish will still display the name and origination addresses for each packet. Although this option makes the Squish screen display less informative, the -q makes Squish run slightly faster. -s<sched> The -s switch instructs Squish to process the specified schedule when performing the SQUASH command. If no schedule is specified, Squish will execute the global commands, plus any schedule which is within the current time period. If an explicit schedule is specified on the command line, only that schedule and the global commands will be executed. -t The -t switch toggles the status of Squish's secure Squish v1.11 Reference Manual - Page 48 mode. In other words, if you have `Secure' turned ON in SQUISH.CFG, using -t will temporarily turn OFF Secure more. Likewise, if you have Secure turned OFF in SQUISH.CFG, using -t will temporarily turn ON secure mode. -u The -u switch toggles the use of the TossBadMsgs keyword. If TossBadMsgs is enabled in SQUISH.CFG, this switch will disable TossBadMsgs processing. If TossBadMsgs is not enabled in SQUISH.CFG, this switch will enable TossBadMsgs processing. -v The -v switch toggles the use of "Statistics Mode". If "Statistics" is turned ON in the configuration file, this switch will temporarily disable statistics mode. Similarly, if "Statistics" is turned OFF in the configuration file, -v will temporarily turn it back on. This switch can be used to create statistics information only when mail is received from a certain node. -z The -z switch instructs Squish to scan non-passthru areas only. Normally, when Squish is invoked with the OUT command, it will scan all of the areas defined in SQUISH.CFG and/or AREAS.BBS. However, if you normally do not keep any messages in your passthru areas, this switch will cause Squish to skip those areas and marginally speed up processing. Squish v1.11 Reference Manual - Page 49 Running Squish in Multipass Mode The easiest and most efficient way to run Squish is in "single pass" mode, meaning that Squish will toss, scan, and pack messages all at the same time. However, Squish can also be run in multipass mode, meaning that tossing, scanning and packing can be separated into two or three different passes. Some of the reasons for using multipass mode are: * Decreased memory requirements. When running in single pass mode, Squish needs enough memory to buffer the packet being tossed, to hold the incoming messages, and buffers for outbound messages. When running in multipass mode, Squish only needs to keep one part of the message in memory at a time, thereby reducing memory requirements of the DOS version by 60K or more. * Some preprocessing utilities may need to be run between passes. For example, several utilities may need to be run over the message bases after a message has been tossed, but before that message is scanned out to other systems. Multipass mode allows for this type of external utility. The key to multipass mode is the use of ECHOTOSS.LOG. The -f switch should be used to keep a log of tossed messages, such that Squish scans and links only those areas which received messages. Invoking Squish in multipass mode is usually done in the following manner: SQUISH IN -fECHOTOSS.LOG rem * Other external utilities here SQUISH OUT -fECHOTOSS.LOG rem * Other external utilities here SQUISH SQUASH rem * Other external utilities here SQUISH LINK -fECHOTOSS.LOG del ECHOTOSS.LOG Depending on your processing requirements, you may wish to run two passes at the same time (such as SQUASH and LINK, or IN and OUT), but the general format remains the same. Squish will be Squish v1.11 Reference Manual - Page 50 somewhat slower when running in multipass mode, especially when the IN and OUT passes are separated. However, this method of operation allows for flexibility and allows other external utilities to be inserted into the tossing/scanning process. Squish v1.11 Reference Manual - Page 51 SQ386 Usage Notes The 32-bit DOS version of Squish uses the DOS/4GW extender from Rational Systems, Inc. This file is included in the Squish distribution as DOS4GW.EXE. The DOS extender is automatically loaded whenever SQ386.EXE is run. DOS4GW.EXE must be in the same directory as SQ386.EXE, and it must be on your path. To operate properly, SQ386 requires either an XMS or a DPMI memory driver: Under DOS, this means that you should have HIMEM.SYS installed, or an equivalent DOS memory manager (such as QEMM or 386^MAX). Under OS/2 or Windows, nothing needs to be done. Both OS/2 and Windows act as DPMI hosts. The 32-bit version of Squish is also memory-hungry. While SQ386 does not require much conventional memory, A MINIMUM OF TWO MEGABYTES OF XMS/DPMI MEMORY IS REQUIRED. In general, SQ386's performance will increase as you give it more memory. For more information on the 32-bit version of Squish, please see the installation subsection titled, "16-bit or 32-bit? SQ386 and SQ386P". Squish v1.11 Reference Manual - Page 52 AREAS.BBS REFERENCE Squish supports the definition of EchoMail areas in the standard AREAS.BBS file. However, this format was designed for use with older systems, and as such, it does not support many of the new features that Squish offers. Regardless, some users may find it advantageous to declare areas in AREAS.BBS for compatibility reasons. The first line of AREAS.BBS is always your default origin line; this text will be added to messages which do not already have an origin line. After the text of the origin line, you should place an exclamation mark, followed by your name. Squish does not use the SysOp name, but other programs may require it. For example, the first line in AREAS.BBS might look like this: BBS Name * City, Provice/State !SysOp Name Following the default origin line should be one or more EchoMail area definitions. An EchoMail area definition has the following format: [#][$]<path> <tag> [nodes...] Both the '#' and '$' characters are optional. If a '#' is placed before the path, that area will be treated as a passthru area. (For more information on passthru areas, please see the section entitled "Area Definitions" in the SQUISH.CFG reference.) If a '$' is placed before the path, that area will be treated as a Squish (*.SQ?) format message area. (For more information, please see the section entitled "USING SQUISH-FORMAT MESSAGE AREAS".) Both the '#' and '$' characters should come immediately before the first character of the area's path. No spaces are permitted. <path> should specify the path of the EchoMail area. For a *.MSG area, this should be the name of directory in which the *.MSG files are kept. For a Squish (*.SQ?) area, this should specify the path and root filename of the message area. <tag> should be the one-word area tag to be used for that area. [nodes] is the optional list of nodes to whom you send that echo. For examples, please see the distribution copy of AREAS.BBS. Squish v1.11 Reference Manual - Page 53 SQUISH.CFG REFERENCE SQUISH.CFG is the main Squish configuration file. SQUISH.CFG controls most aspects of Squish's operation, including the message areas it uses, the directories where it places files, and even how to remap messages addressed to certain users. SQUISH.CFG is divided into two logical sections: firstly, there is the main configuration section. This section contains information about your system and everything else that Squish needs to know. Secondly, there is an optional area configuration section. This part of the configuration file allows you to define NetMail, EchoMail, dupe storage and bad message areas for your system. SQUISH.CFG is an ASCII file, so it can be edited using a text editor (or a word processor in non-document mode). Lines which begin with a semicolon (;) are treated as comments and are ignored. Configuration Options This section describes all of the commands and options available in the system information section of SQUISH.CFG. For information on defining EchoMail, NetMail, bad message or dupe storage areas, please see the next section. The following is an alphabetical listing of keywords in SQUISH.CFG. Descriptions are given for all keywords, and examples are given where appropriate. AddMode (BinkleyTerm systems only) The AddMode keyword enables the "add mode" functionality of the outbound directory manager. Add mode causes new file attaches to be merged into existing attaches of different flavours. When add mode is turned on, Squish will perform some special processing before creating a file attach. Instead of simply creating an attach with the specified flavour, it will first scan the outbound directory to see if any other attaches exist for the same node. If a non- normal-flavoured attach is found, add mode will cause Squish to add the current file to that attach, regardless of the flavour specified for the "Route" or "Send" commands. This verb is useful in many situations, such as when a node goes down for a short period of time. With add mode turned on, simply change the flavour of the existing attaches in the outbound area to "hold". When Squish scans out more Squish v1.11 Reference Manual - Page 54 mail for that node, it will notice the hold attach and it will hold all new mail as well. This means that no modifications to your routing control files are necessary, even if you are using "Route Crash" or "Send Crash" for that particular node. By default, with add mode disabled, Squish will simply use the given flavour, without attempting to check for other existing attaches. Address <node> [<node>...] The Address keyword defines one or more network addresses used by your system. The first address specified in SQUISH.CFG is considered to be your "primary address", and this address will be used for all outbound mail (unless told otherwise -- see the documentation on the EchoArea keyword in the "Area Definitions" section of the SQUISH.CFG reference). Squish handles full 4D addresses and is capable of running as either a bossnode or a point. For a normal network node, only one address statement is required. Your primary address should be declared in this format: Address 1:123/456 where "1:123/456" is your full network address, including zone number. For fakenet points, two addresses are required. The first address declared in SQUISH.CFG should be your fakenet address, and the second address should be your full 4D point address. Both addresses must include the proper zone number. For example, a fakenet point at 1:123/456.1 (using a fakenet of 12345) might use the following set of address statements: Address 1:12345/1 Address 1:123/456.1 In addition, fakenet points must also use the "PointNet" verb, below. For 4D points, only one address is required. This address should be your full 4D point address, and it should be declared as the first address in your configuration file. Squish v1.11 Reference Manual - Page 55 For example, a 4D point of 1:123/456 might use the following address statement: Address 1:123/456.1 However, to use 4D points, all of your software must be able to handle 4D addresses, and your mailer and EchoMail processors must compliant with the "2+" packet type. After you have defined your primary address, any number of AKA (Also-Known-As) addresses may be listed. These addresses will not be used for outgoing mail, but Squish will use these AKAs to determine whether or not a packet is destined for your system. Any number of AKAs may be specified, up to the limit of available memory. AddToSeen <node> [<node>...] The AddToSeen keyword globally adds a node number to the SEEN-BYs of all EchoMail areas which are processed by your system. The AddToSeen keyword specifies one or more two- dimensional address (net/node only) which are to be added. This keyword adds these addresses to ALL echoes, so it should be only used in special situations. By default, your primary address is added to the SEEN-BYs for all areas. For information on changing your primary address, or for adding to the SEEN-BYs on an area-by-area basis, please see the "Flags" section of the SQUISH.CFG reference. ArcmailAttach The ArcmailAttach keyword informs Squish that your mailer requires "ARCmail file attaches" to transmit EchoMail to other systems. Mailers such as FrontDoor, D'Bridge, and InterMail require this keyword, whereas others (such as BinkleyTerm) do not. If you are not running any of the above pieces of software, please consult your mailer's documentation to determine whether or not it requires ARCmail attaches. When this keyword is enabled, Squish operates differently in several ways: * Packing of the NetMail area is disabled. Mailers which require ARCmail attaches perform dynamic packing on their own, so this portion of the Squish code is automatically disabled. Squish v1.11 Reference Manual - Page 56 * ARCmail attach messages will be generated for outbound EchoMail. This support is internal to Squish, so no external utilities are required. * Most of the routing code for the SQUISH SQUASH command is disabled. Again, since ARCmail attach mailers perform dynamic routing, these features are not required. * Squish will only write packets to the OUTBOUND.SQ area, and it will disable the use of BinkleyTerm-style "zoned outbound directories". * Squish will enable 4D point support, since most ARCmail attach mailers are capable of handling 4D points. By default, ARCmail attach support is disabled. This means that: * Squish will perform packing of the NetMail area. Squish will gateroute messages, handle file attaches, file requests and update requests, in addition to the optional deletion and truncation of attached files. Messages will be packed from all areas declared using the 'NetArea' keyword. * Squish will perform static routing and packing in the outbound areas. If the BinkPoint verb is implemented, Squish will enable support for 4D points on a BinkleyTerm-style system. * Squish will directly process BinkleyTerm-style zoned outbound directories and enable full support for all commands in ROUTE.CFG. Unless the ArcmailAttach verb is set correctly, Squish may produce unpredictable and unreliable results on your system. Make sure that this verb is set appropriately before running Squish. AreasBBS <filespec> The AreasBBS keyword specifies the path and name of a ConfMail-compatible AREAS.BBS file, which is one way of defining EchoMail areas. Please see the section entitled "AREAS.BBS REFERENCE" for more information on using this command. Note: the '-a' command-line switch can also be used to override the filename given for this command. Squish v1.11 Reference Manual - Page 57 BatchUnarc The BatchUnarc keyword instructs Squish to decompress all compressed mail bundles at the same time. By default, Squish will decompress one mail bundle, toss all of the packets in it, decompress the next bundle, toss those packets, and so on. Although this method makes efficient use of disk space, there is a slight chance that messages may get out-of-order, depending on the order in which the compressed mail archives arrived on your system. The BatchUnarc keyword instructs Squish to decompress all of the compressed mail archives at once, and to then toss the *.PKT files. Squish always sorts packets by date before tossing, so this ensures that messages will not get out of order. BinkPoint (BinkleyTerm systems only) The BinkPoint keyword enables the BinkleyTerm 2.50+ point directory support. When this keyword is enabled, Squish will turn on full 4D address support, and Squish can then communicate freely with 4D points running BinkleyTerm. If you are using 4D points with Binkley 2.50 or above, BOTH the boss and the point must have this keyword enabled. Buffers <type> or Buffers <writebuf> <outbuf> <msgbuf> The Buffers keyword can be used to limit Squish's memory usage. Two different forms of the keyword can be used: With "Buffers <type>": <type> is any of "Small", "Medium" or "Large". These types are just short-hand for certain predefined buffer sizes. (See below for more information.) With "Buffers <writebuf> <outbuf> <msgbuf>": <writebuf> controls the amount of memory used to buffer writes to disk. (This parameter does not provide for much of a speed increase beyond 16k.) <outbuf> controls the amount of memory used to buffer messages for various nodes. This parameter controls how often Squish has to stop tossing and place packets in the outbound area. For systems which forward mail Squish v1.11 Reference Manual - Page 58 to many nodes, this parameter will have a significant impact on processing speed. <msgbuf> controls the maximum message size that Squish is able to process, for either inbound or outbound mail. Under the 16-bit versions of Squish, this parameter is limited to 63K. The defaults for the 16-bit versions of Squish (SQUISH and SQUISHP) are: BUFFERS writebuf outbuf msgbuf Small 16k 16k 16k Medium 26k 40k 32k Large 57k 57k 63k The defaults for the 32-bit versions of Squish (SQ386 and SQ386P) are: BUFFERS writebuf outbuf msgbuf Small 64k 64k 64k Medium 76k 128k 128k Large 128k 512k 256k The buffer sizes shown for "Small" are the lowest values that can be specified. In addition, buffer sizes for the 16-bit versions of Squish cannot be larger than 63K. Note that the small, medium and large buffer sizes have changed from Squish 1.01. To use the same buffer sizes as the "large" mode of Squish 1.01, use: Buffers 57 57 16 If no "Buffers" statement is specified, Squish will use the LARGE setting for writebuf and outbound and the MEDIUM setting for msgbuf. Keep in mind that while reducing the level of buffering will provide the DOS versions of Squish with more memory, reducing the buffer sizes will also have an impact on speed. If you want Squish to run as fast as possible, use large buffer values. If you want Squish to run in as little memory as possible, use small buffers. If you want a compromise, try using medium buffers. Other tips for reducing memory usage: Squish v1.11 Reference Manual - Page 59 * Disable the "Statistics" keyword. Keeping statistics almost doubles Squish's memory requirements for storing AREAS.BBS information. * Reduce the "MaxAttach" and "MaxPkt" settings. A value of 64 for each setting works for most systems. * Reduce the "Duplicates" setting. However, since this impairs Squish's ability to identify duplicate messages, doing so is not recommended. * Run SQUISH SQUASH in a separate pass from SQUISH IN OUT. If memory is really tight, run everything in its own separate pass. (See the section entitled "Running Squish in Multipass Mode" in the OPERATION section for more information.) BusyFlags The BusyFlags keyword enables "busy flag" support for BinkleyTerm and InterMail systems. This option is required when using more than one copy of your mailer with the same outbound area; the busy flags provide for file locking, which prevent collisions when two different nodes attempt to send mail at the same time. Squish has full support for the busy flag mechanism. To further help throughput, Squish also performs most of its operations in a separate holding directory, outside of the main zoned outbound directories. Files are only transferred to the outbound directories as necessary, which minimizes the "down time" for any given node. In addition, if Squish attempts to send mail to a node which is busy due to mailer activity on another line, the packet will be simply queued for later use, as opposed to waiting for that node to become free again. Unlike other mail processors, this means that Squish never has to wait because of mail activity occurring on other lines of a multi-line system, which makes Squish the ideal choice for a multi-line installation. If ArcmailAttach mode is enabled, Squish uses a busy flag format that is compatible with InterMail (and certain other ArcmailAttach mailers). If ArcmailAttach mode is not enabled, Squish uses BinkleyTerm-style busy flags. Squish v1.11 Reference Manual - Page 60 When using BinkleyTerm, make sure to turn on busy flag support by enabling the "Flags" directory and setting a non- zero task number. CheckZones The CheckZones keyword instructs Squish to check the zone numbers on all incoming packets. This option is enabled in the default configuration file; however, it may cause problems in secure mode with older, non-zone-aware systems. Commenting out this option tells Squish not to check the zone number when performing security checks on inbound packets, which may help if you have to deal with such older software. Compress <filespec> The Compress keyword gives the path and filename of the compression configuration file. Squish can use almost any external program to compress mail, including ARC, PKArc, PKZip, LHarc (both 1.xx and 2.xx), ZOO, PAK, ARJ, and more. Squish's compression support is completely user-definable, so new archivers can be added to the configuration file with ease. For more information, please see the documentation on the "Pack" and "DefaultPacker" keywords, and also the section entitled "ARCHIVES AND MESSAGE COMPRESSION". DefaultPacker <packer> The DefaultPacker keyword instructs Squish to use <packer> as the default packer for compressed mail. <packer> must be the name of a packer defined in the compression configuration file. NOTE! The official standard for compressed mail in FidoNet is the version 5 ARC format. Unless you have a good reason for changing the default, ARC should be left as the default packer. Packer types can be changed on a node-by-node basis through the "Pack" verb, so DefaultPacker should only be used when necessary. DupeCheck [<type>...] The DupeCheck keyword controls the dupe-checking algorithm used by Squish: <type> can be either or both of "Header" or "MSGID". "Header" instructs Squish to check the message header to determine whether or not a message is a dupe. Squish will Squish v1.11 Reference Manual - Page 61 hash the "To", "From" and "Subject" fields into a 32-bit identifier. It will append the message date to this, resulting in a 64-bit duplicate identifier. "MSGID" instructs Squish to check the MSGID kludge to determine whether or not a message is a dupe. Squish will hash the text of the MSGID "address" field into a 32-bit identifier. It will append the MSGID serial number to this, resulting in a 64-bit duplicate identifier. If only one of the above settings is enabled, Squish will only use that method when determining whether or not a message is a dupe. However, if both MSGID and Header are specified, Squish will perform both checks. If EITHER the MSGID or the header is duplicated, Squish will declare the message to be a dupe. DupeLongHeader This keyword instructs Squish to use the entire "Subject:" line when determining whether or not a message is a duplicate. Without this option, Squish will only check the first 24 characters of the subject line. Duplicates <number> The Duplicates keyword instructs Squish to keep up to <number> duplicate message IDs for each message area. By default, Squish stores the IDs of the past 1000 messages. Unlike other mail processors, Squish uses a highly-accurate 64-bit duplicate identifier, so increasing <number> will NOT significantly increase the chances of a duplicate message being falsely detected. Feature <name> (OS/2 only) Feature32 <name> (OS/2 only) The Feature and Feature32 keywords instruct Squish to load a third-party DLL file. <name> should be the root name of the file to load, without the ".DLL" suffix. The Feature keyword should only be used with 16-bit DLLs. The Feature32 keyword should only be used with 32-bit DLLs. (By convention, the name of the feature DLL will include a "32" if it is a 32-bit DLL.) See the Squish Developers Kit (to be made available shortly after the release of Squish 1.1) for information on writing feature DLLs. Squish v1.11 Reference Manual - Page 62 ForwardFrom [FILE] <node> [<nodes>...] The ForwardFrom keyword tells Squish that the forwarding of in-transit NetMail messages is allowed, as long as the messages originated FROM any of the specified nodes. If the "FILE" keyword is added before the first node number, Squish will also properly forward in-transit files. Any number of nodes may be listed, and wildcards may be used. NOTE! The ForwardFrom verb allows the specified nodes to forward messages ANYWHERE. If you have your routing set up to crash all messages to their destinations, this should only be enabled for systems that you trust. For a more conservative approach, see the ForwardTo keyword. ForwardTo [FILE] <node> [<nodes>...] The ForwardTo keyword tells Squish that the forwarding of in-transit NetMail messages is allowed, as long as the messages are destined TO any of the specified nodes. If the "FILE" keyword is added before the first node number, Squish will also properly forward in-transit files. Any number of nodes may be listed, and wildcards may be used. This option is appropriate for most systems, since it allows anyone to forward mail to the specified systems, but to those systems only. Unlike ForwardFrom, this means that you have control over where the messages end up, as opposed to the person who sent the message. GateRoute <flavour> <gate> <node> [<nodes>...] [EXCEPT <node> [<nodes>...]] The GateRoute keyword causes Squish to perform gaterouting on NetMail messages addressed to the specified gate or any of the following nodes. Squish follows the FTS-0001 standard for gaterouting, so the messages produced by this command should be acceptable to SEAdog and other non-zone- aware mailers. Gaterouting will only be performed on NetMail messages with a flavour of normal. Messages marked as crash or hold will never be gaterouted; instead, they will be classified as direct interzone messages and will be treated accordingly. <flavour> specifies the flavour to which messages will be converted after gaterouting has taken place. The gaterouted flavour should usually be normal (so that other commands in ROUTE.CFG can compress and route the mail normally), but you can specify an alternate flavour if you so desire. Squish v1.11 Reference Manual - Page 63 <gate> specifies the address of the system to which messages should be gaterouted. This should be the address of an official network zonegate. <node> and <nodes> specify the list of nodes for which gaterouting is to be performed, including wildcards. All NetMail messages which are addressed to these nodes will be gaterouted through the specified gate system. (EchoMail should NEVER be gaterouted.) Optionally, a list of exceptions can be given for each zonegate. Simply add the 'EXCEPT' keyword to the GateRoute line, and for the current GateRoute keyword, Squish will ignore all messages addressed to those nodes. Wildcards are also supported for gaterouting exceptions. For example, to gateroute all messages going from zone 1 to zone 2, with the exception of messages destined for 2:123/456, the following gateroute statement could be used: GateRoute 1:1/2 2:All Except 2:123/456 In zone 1 of FidoNet, the standard set of gaterouting statements for other zones looks like this: GateRoute 1:1/2 2:All GateRoute 1:1/3 3:All GateRoute 1:1/4 4:All GateRoute 1:1/5 5:All GateRoute 1:1/6 6:All Include <filename> This keyword instructs Squish to read in another file as part of the standard SQUISH.CFG processing. The contents of <filename> will be processed just as if they were placed directly in SQUISH.CFG. Include files can be nested, but no more than 16 levels of nesting are supported. KillBlank The KillBlank verb instructs Squish to delete blank NetMail messages. Blank netmail messages are commonly generated by ARCmail attach systems, manual file requests, file attaches, and update requests. By definition, a "blank message" is a message which consists only of a message header, kludge lines and blank lines. Squish v1.11 Reference Manual - Page 64 KillDupes The KillDupes verb instructs Squish to delete duplicate messages as they are received, as opposed to placing the dupes in the DUPES message area. If you are encountering a large number of dupes and you already know where the problem is, this keyword can then be enabled to delete the dupes as they are tossed. However, having a copy of the dupes tossed into the DUPES area is instrumental to determining which system originated the duplicate messages, so this keyword should not be used for normal operation. KillIntransit The KillIntransit verb instructs Squish to delete in-transit NetMail messages. Normally, Squish leaves in-transit messages in the NetMail area for review by the SysOp, but this keyword will cause Squish to delete in-transit messages as soon as they have been packed up and sent to their destination. KillIntransitFile (non-ArcmailAttach systems only) The KillIntransitFile verb instructs Squish to delete in- transmit files. Squish will add a "delete-after-sending" flag when writing the *.?LO file for the forwarded file. This option is only valid for non-ArcmailAttach systems. LinkMsgid The LinkMsgid keyword instructs Squish to perform reply linking on the basis of MSGID and REPLY keywords. This style of linking ensures that the "read original" and "read reply" fields in the message header always point to the correct message. However, MSGID-based linking requires more memory than the default subject-based reply linking. LogFile <filespec> The LogFile keyword instructs Squish to keep a log of message information in the specified file. The log file is Maximus and Binkley-compatible, so it's safe to keep all three logs inside one file. The Squish log file includes information on archives, packet headers, areas which received mail, the amount of mail that was sent from your system, and to whom. The log file provides one way of obtaining EchoMail statistics; the other way is through analysis of the binary statistics file. For Squish v1.11 Reference Manual - Page 65 more information on binary statistics, please see the "Statistics" keyword. LogLevel <number> The LogLevel keyword instructs Squish to include only a certain subset of messages in the log file. <number> must be a log level number from 0 to 6. (The default log level is 6.) The types of lines logged for each log level are shown below: Level Flags 0 ! 1 !+ 2 !+* 3 !+*- 4 !+*-# 5 !+*-#: 6 !+*-#: (and a space) MaxArchive <k> When used in conjunction with MaxMsgs, this keyword helps to control the maximum size of archive files that Squish generates. <k> specifies the approximate size, in kilobytes, of the largest ARCmail file that Squish should create. The MaxArchive value controls Squish's selection of archive files when compressing messages. With MaxArchive set to 'x', Squish will not ADD any packets to archives which exceed a size of 'x' kilobytes. Instead, it will create a new archive for the same node, assuming that all of the *.MO0 to *.MO9 filename extensions have not been used. If all *.??0 through *.??9 have been used, Squish will add packets to the *.??9 archive, regardless of its size, to ensure that packets remain in order. This keyword does not provide a strict upper limit on the size of archives, but it does help to control archive size. For example, assume that a value of "MaxArchive 100" is used, and assume that a 99k file already exists. This file is less than 100k, so Squish will add more mail to that archive. Depending on your MaxMsgs setting, the mail to be added could range from a few kilobytes to a few megabytes. Squish v1.11 Reference Manual - Page 66 However, a relatively low value for MaxMsgs (100-200) allows Squish to control the size of generated archives within 50-75k of the value specified by MaxArchive. MaxAttach <number> (ArcmailAttach systems only) The MaxAttach keyword specifies the maximum number of ARCmail attach messages which can be in your NetMail directory at any given time. For internal reasons, Squish needs to know how many attaches you'll have concurrently. The default, 256, is more than enough for most systems. However, if you transfer an extremely large volume of mail with an ArcmailAttach mailer, you may need to increase this to 512 attaches or more. MaxMsgs <msgs> The MaxMsgs keyword instructs Squish to create a new set of outbound packets after processing every <msg> messages. The MaxMsgs keyword is useful in NEC situations, especially when a large volume of mail is processed at the same time. This verb helps to limit the size of packets that Squish generates, by making it taking a break from tossing and scanning after sending every <msgs> messages, and to then go and archive the packets generated so far. This keyword is completely automatic when running in single pass mode; as long as IN, OUT and SQUASH are specified on the command line, Squish will interleave the tossing, scanning and packing automatically. However, when running Squish in multipass mode, some batch file modifications are required. For multipass mode, after Squish finishes scanning every <msgs> messages, it will stop execution and exit with an errorlevel of 5. This errorlevel should be trapped by your batch file, and SQUISH SQUASH should be called at that point. After packing the NetMail area, your batch file should call SQUISH IN OUT again. For example, the following batch file segment could be used to run Squish in multipass mode: :TossIt rem * Perform the main toss/scan cycle SQUISH IN OUT -fECHOTOSS.LOG if errorlevel 5 goto PackIt goto DoneToss :PackIt Squish v1.11 Reference Manual - Page 67 rem * If we got here, it's because we exceeded MaxMsgs. rem * We use -o, since we do not want to pack the netmail rem * area right now. SQUISH SQUASH -o goto TossIt :DoneToss rem * Now, perform a full pack to take care of remaining rem * archives, and also to handle any in-transit NetMail. SQUISH SQUASH When using the MaxMsgs keyword, Squish will create a file called MAX_MSGS.DAT in the current directory. This file is used to maintain information that is required between passes, such as the current location in the packet file and information about the packet itself. MaxPkt <num> The MaxPkt keyword informs Squish that there may be up to <num> packets queued in the OUTBOUND.SQ directory. For internal reasons, Squish needs to know the maximum number of packets that you'll be keeping in OUTBOUND.SQ. MaxPkt defaults to 256 packets, which should be more than enough for most systems. Unless you run a very busy system, you will not need to use this keyword. NetFile [NoPkt] [NoArc] [NoEcho] <path> The NetFile keyword specifies the path to one of your inbound directories. When tossing mail, Squish will look in all of the NetFile directories you specify in the configuration file, and it will attempt to toss from each one. If the 'NoPkt' modifier is added before the directory name, Squish will never toss plain *.PKT files from that directory. If the 'NoArc' modifier is added before the directory name, Squish will never toss compressed mail files from that directory. If the 'NoEcho' modifier is added before the directory name, Squish will never toss EchoMail messages from that directory. NOTE! The NoEcho modifier cannot be used if "BatchUnarc" is enabled. Squish must be able to toss one Squish v1.11 Reference Manual - Page 68 incoming archive at a time to properly apply NoEcho processing. These modifiers can be used in conjunction with BinkleyTerm's three-tiered inbound areas to make your system slightly more secure. Nuke (ArcmailAttach systems only) The Nuke keyword instructs Squish to delete any orphaned compressed mail files in the OUTBOUND.SQ directory. Before performing a SQUISH SQUASH, Squish will scan the NetMail area for ARCmail attach messages. It will then scan OUTBOUND.SQ and delete any compressed mail file for which there is no attach. WARNING! This keyword is dangerous, since Squish will delete compressed mail bundles if an ARCmail attach message is accidentally deleted. Most systems do NOT require this keyword. If your mailer supports the ^aFLAGS kludge for truncating files, this is not necessary. As of this writing, the only mailers which is known to require the Nuke keyword is D'Bridge. Some users have also reported that the Fido mailer also requires this keyword. NoSoundex The NoSoundex keyword instructs Squish to disable the automatic "Soundex" feature for remapping point mail. In certain cases, the Soundex feature may incorrectly map the name of a point, so this keyword can be used to ensure that Squish uses exact name matching when processing remapped mail. NoStomp The NoStomp keyword instructs Squish to leave packet headers alone when routing mail with the "Route" keyword in SQUISH.CFG. (Packet stomping is normally required to ensure that the packet is addressed properly, including the packet password and destination address.) Squish v1.11 Reference Manual - Page 69 OldArcmailExts This keyword instructs Squish to use the old file extension format when creating compressed mail archives. Normally, Squish creates files with extensions of .MO?, .TU?, .WE?, and so on. If OldArcmailExts is enabled, Squish will use the .MO? extension only, for compatibility with older systems such as Opus 1.03. Origin <text> The Origin keyword specifies a default origin line to use for EchoMail messages. If no origin can be found in the body of a message which was originated locally, Squish will use this text as the default origin line. If you are using AREAS.BBS, this keyword is not required. The AREAS.BBS format includes a default origin line, and that origin will override the one given in SQUISH.CFG. Outbound <path> [zone] This keyword is required for both ArcmailAttach and BinkleyTerm systems. When running Binkley, this keyword gives the path to the base outbound directory. Specify only the base path of your outbound directory, such as "D:\Bt\Outbound". If you are using a BinkleyTerm system, Squish will add the zoned directory extensions automatically, so only one outbound path needs to be declared for most systems. If a particular outbound directory does not exist, Squish will create it on the fly. Squish also creates a directory with an extension of .SQ for both BinkleyTerm and ArcmailAttach systems. This is used by Squish as a temporary work directory for packets. With the optional [zone] parameter, Squish supports BinkleyTerm's domain outbound directories, using zone-based domain resolution. The first "Outbound" keyword in SQUISH.CFG must not contain a zone number. This keyword will be used as the default outbound directory for your primary domain. After the first default "Outbound" keyword, any number of domain-specific "Outbound" keywords can follow. The [zone] parameter instructs Squish that mail for the given zone Squish v1.11 Reference Manual - Page 70 belongs to a different domain and should be placed into a different directory. For example, given the following definitions: Outbound \squish\outbound Outbound \squish\alternet 7 Outbound \squish\foonet 123 Mail for zone 7 will be placed into \squish\alternet, since the zone number matches the second "Outbound" keyword. Mail for zone 123 will be placed into \squish\foonet, since the zone number matches the third "Outbound" keyword. Mail for your primary zone number will be placed into \squish\outbound. The zone number does not match any of the zone-specific outbound directories, so the mail goes into the default directory. Mail for zone 9 will be automatically placed into \squish\outbound.009. The zone number does not match any of the zone-specific outbound directories, so it goes into a zoned version of the default directory. Pack <packer> <node> [<nodes>...] The Pack keyword instructs Squish to use the specified mail compression program when compressing mail for the listed nodes. By default, if a node is not listed after any Pack keywords, Squish will use the compressor defined with the DefaultPacker keyword. If no default packer is declared, Squish will simply use the first packer listed in SQUISH.CFG. Since the FidoNet standard for mail compression is ARC, you are urged not to change the default. Instead, the Pack keyword can be used to change the compression method on a node-by-node basis. <packer> specifies the name of a packer, as specified in COMPRESS.CFG. Please see the section entitled "ARCHIVERS AND MESSAGE COMPRESSION" for information on COMPRESS.CFG. <node> and <nodes> specify the nodes for which this packer should be used. Any number of nodes may be listed here, including wildcards. When packing mail for any of the nodes listed after a particular packer, Squish will attempt to run that packer using the information given in COMPRESS.CFG. Squish v1.11 Reference Manual - Page 71 You can specify as many nodes as you like, and you can also use as many packers and Pack lines as desired. When unpacking compressed archives, Squish will determine the archive type automatically, again using the information given in COMPRESS.CFG. WARNING! Squish will not attempt to convert archives from one type to another. Before changing the compression type for a certain node, make sure that no other compressed mail archives are waiting to be sent to that system. If there was, Squish would attempt to add a packet to that archive using the wrong archiver, which would certainly cause problems. Password <node> <password> The Password keyword allows passwords to be assigned to individual systems. For more information on using passwords, please see the section entitled "SECURITY". <node> should specify a single node address. No wildcards are permitted. <password> is the case-insensitive password to use for the specified node. Passwords must be eight characters or fewer, with no spaces allowed. PointNet <net> PointNet specifies the "fakenet" number to use for non-4D points. The fakenet point scheme was designed to work with systems which were unable to support true points, such as BinkleyTerm 2.40 and lower. When this keyword is used on the bossnode system, it causes the specified net number to be stripped from the SEEN-BYs for messages being exported to non-point systems. The fakenet number will also be used on the bossnode for remapping point addresses. If used on a point system, this keyword ensures that the right address is used on the point's origin line, if Squish is actually forced to add an origin line to a message. NOTE! The point software should be responsible for placing the correct origin line in messages generated by that point. Squish will use the correct address if Squish itself inserts the origin, but Squish will never modify an existing origin line. Squish v1.11 Reference Manual - Page 72 QuietArc The QuietArc keyword instructs Squish to suppress the screen output of external compression utilities. This option makes the screen look tidier, but it does not make any functional changes. Remap <node> <name> (non-ArcmailAttach systems only) The Remap keyword is used to readdress mail with specified addresses in the "To:" field. Unlike other mail processors, Squish's remapping facility is a full node remapper. Messages can be remapped anywhere, from a point across the street to another system across the world. <node> specifies the network address of the system for which mail is to be remapped. This address must be EXPLICIT; if you are remapping mail to a 4D point, then you must specify the address in a 4D format. If you are remapping mail to a fakenet point, you must specify the node's fakenet address. <name> should be the name to check for in the "To:" field of inbound messages. When a NetMail message arrives that is destined for your system, Squish will scan the "To:" field for all of the names listed in Remap statements. If it finds a match, it will readdress the mail to the appropriate address and write the message back to disk. The <name> field has two special features: * Name wildcards. By placing a "*" at the end of a name, Squish will automatically remap messages which begin with that text. For example, using a remap name of "Jes*" would remap messages which were to "Jesse Hollington", "Jesse", and so forth. * Soundex support. If Squish cannot find an exact match, it will perform a soundex compare of both the "To:" field and the Remap names. If a misspelled match is found, the message will still be readdressed (and noted in the log). To disable Soundex support, see the "NoSoundex" keyword. Remap statements are processed in sequential order, from top to bottom. Therefore, if you wish to have a "clean up" statement to remap messages which were not caught by other Remap statements, include the command "Remap <node> *" after all other Remap statements. This will cause Squish to remap all remaining messages to the specified address, even if it Squish v1.11 Reference Manual - Page 73 could not find a match using any of the other Remap statements. Routing <filespec> This keyword specifies the location of the routing configuration file. By default, Squish will look for ROUTE.CFG in the current directory. SaveControlInfo (Squish message areas only) When this keyword is enabled (as it is in the default configuration file), Squish will preserve SEEN-BY and path information in *.SQ?-style message areas. If this keyword is commented out, Squish will strip SEEN-BY information from *.SQ? areas (when running in single pass mode ONLY). If you are really tight on disk space, stripping the SEEN- BYs is one way to reduce disk requirements. As long as you are running in one-pass mode, the *.SQ? format is safe to use without having SEEN-BYs written to the local message base. However, Squish will always write SEEN-BY information for *.MSG areas, as it will for *.SQ? areas when running in multipass mode. Secure The Secure keyword enables Squish's packet security features. For more information, please see the section entitled "SECURITY". Statistics [filename] The Statistics keyword turns on a binary statistics file, SQUISH.STT, which is used to hold extremely verbose statistics information about inbound and outbound messages. The Squish statistics file includes enough information to create a 100% accurate billing report for NECs and other EchoMail hubs. A minimal program (SSTAT) is included to parse this statistics file and display a billing report. [filename], if specified, overrides the default filename for the statistics file. For example, to instruct Squish to place the statistics file in d:\squish\squish.stt, the following keyword should be used: Statistics d:\squish\squish.stt Squish v1.11 Reference Manual - Page 74 Note that the "Statistics" keyword will approximately double the memory requirements for reading the SQUISH.CFG and AREAS.BBS files. StripAttributes [node [node...] [EXCEPT node [node...]]]] The StripAttributes keyword instructs Squish to strip the crash, hold and direct bits from incoming messages. This keyword is enabled in the default configuration file, since it prevents other systems from overriding your routing by sending a crash-flavoured message through your system. However, some systems run "power points" which have file attach privileges, so this keyword may need to be disabled to give full control of the system to the points (and everyone else). If no [node] parameter is specified, Squish will strip attributes from all incoming mail by default. If nodes are specified, Squish will strip attributes on incoming mail from those nodes only. In addition, the EXCEPT keyword can be used to exclude certain nodes from StripAttributes processing. For example, the following line: StripAttributes 1:All 2:All EXCEPT 1:123/456 instructs Squish to strip attributes from all messages from zone 1 and zone 2, except those which originate from 1:123/456. Swap [filespec] (DOS version only) The Swap keyword instructs Squish to swap itself out of memory before calling external archiving programs. If you are running Squish in a restricted environment, swapping can save 200K of conventional memory (or more). By default, Squish will first try to swap itself to XMS and then EMS. If unsuccessful, Squish will try to swap itself to disk. When swapping to disk, Squish will use a default swap filename of __SQUISH.~~~ in the current directory. However, if you wish to specify an alternate path and filename (such as a file on a RAMdisk), you can do so here. THIS KEYWORD MUST SPECIFY A FILENAME, NOT JUST A PATH! Squish v1.11 Reference Manual - Page 75 TinySeenBys <node> [<nodes>...] [EXCEPT <nodes>...] The TinySeenBys keyword instructs Squish to strip down the SEEN-BYs to a bare minimum when exporting or scanning messages to the specified nodes. The SEEN-BYs in the messages sent to those nodes will contain only the addresses of those systems which are listed for the EchoMail area in question. Any number of nodes may be specified, and wildcards can be used. The "EXCEPT" keyword can be used to except certain nodes from tiny SEEN-BY processing. For example, the following line TinySeenbys 1:249/All 1:12/All Except 1:12/12 instructs Squish to generate tiny SEEN-BYs for all nodes in nets 249 and 12, with the exception of node 12/12. TossBadMsgs Uncommenting the TossBadMsgs keyword indicates that it's safe to toss messages from your BAD_MSGS area. Normally, when Squish finds a message with an unknown area tag, or if it finds an insecure message, Squish will place that message in the BAD_MSGS area. However, if the message later becomes valid (such as when the SysOp adds an EchoArea definition for a previously-unknown area), Squish can automatically toss messages from that area. This feature can save you from manually moving dozens of misdirected messages. Note that the -u command-line parameter can be used to toggle this mode. Track <filespec> The Track keyword specifies a filename to use as a separate log for in-transit NetMail. If this keyword is enabled, Squish will log the To:, From: and Subject: lines of all in- transit netmail, in addition to the messages' origination and destination addresses. This keyword is useful for determining exactly who is forwarding messages through your system, and where the final destinations of those messages were. In addition, Squish will also place a note in the log if an AREA: line was found in the forwarded message, which indicates that the message in question was a routed EchoMail message. Squish v1.11 Reference Manual - Page 76 WARNING! This keyword must point to a separate log file. You cannot use the same log for both Track and LogFile. ZoneGate <target> <node> [<nodes>...] The ZoneGate keyword is used to strip the SEEN-BYs on messages destined for other zones. According to the FidoNet Technical Standards Committee, SEEN-BYs should be stripped whenever a message crosses a zone boundary. The procedure of stripping the SEEN-BYs on such a message is called "zonegating". <target> specifies the node for which you are zonegating mail. All EchoMail messages destined to this node will have their SEEN-BYs stripped. <node> and <nodes> specify one or more nodes to add to the SEEN-BYs of the zonegated messages, AFTER the original SEEN- BYs have been stripped. These addresses should be two- dimensional (net and node only), since there are no provisions for zone or point numbers in SEEN-BYs. WARNING! Unlike other mail processors, Squish does not automatically add any addresses to the SEEN-BYs of zonegated messages. As a bare minimum, you should add your own address and the address of the zonegate. For example, to zonegate messages from 1:123/456 to 2:987/654, the following ZoneGate line might be used: ZoneGate 2:987/654 123/456 987/654 Notice that both our address (123/456) and the zonegate's address (987/654) were included in the <nodes> section of the command. Failing to add both of these nodes may cause dupes. Squish v1.11 Reference Manual - Page 77 Area Definitions Squish supports a flexible method for defining message areas in the Squish configuration file. The same mechanism is used for defining EchoMail, NetMail, BAD_MSGS and duplicate message areas. The general format of an area declaration is: <type> <tag> <path> [flags] [nodes] Area Types <type> specifies the type of area to define. A type must be specified for all areas. This type should be one of the following keywords: NetArea This area is defined as a NetMail area. For BinkleyTerm systems, Squish will pack messages from all NetAreas specified. For ArcmailAttach systems, Squish will use the first NetArea declared for creating ARCmail file attaches. EchoArea This area is defined as an EchoMail area. Messages can be tossed to and scanned from this area using the standard Squish commands. BadArea This area is defined as a "bad messages" (or BAD_MSGS) area. This will be used to store messages with security violations, messages for unknown areas, and other messages for which Squish could not find a proper home. DupeArea This area is defined as a duplicate message area. If Squish receives duplicate messages from another system (and if KillDupes is NOT enabled), those messages will be placed into this area for review by the SysOp. Area Tags and Paths <tag> specifies a short, one-word area tag (name) to use for the area being defined. For EchoMail areas, this tag should be the name of the echo. For other area types, such as NetAreas and BadAreas, any unique tag can be used. <path> specifies the directory and/or filename to use for this message area. If using the *.MSG format, the name of a separate directory should be given for each area. If using the Squish format (*.SQ?), a path and root filename (up to eight characters Squish v1.11 Reference Manual - Page 78 with no extension) should be given. Squish will automatically create areas which do not exist. WARNING! The <tag> and <path> fields in AREAS.BBS are "reversed", meaning that the path comes before the tag. If you are used to defining areas in AREAS.BBS, make sure that you use the proper order when defining areas in SQUISH.CFG (tag and then path). Flags [flags] specifies an optional set of flags and options. A flag consists of a single dash followed by a letter, plus an optional modifier. The flags currently supported by Squish are: -f This flag tells Squish that the area is stored in FTS-0001 (*.MSG) format. *.MSG is the default storage format, so this flag usually is not required. When the *.MSG format is being used, the name of the *.MSG directory should be given for <path>. -h This flag tells Squish to ensure that all incoming messages have the PRIVATE bit enabled. This is useful for NetMail areas or other area types where confidential information may be exchanged. -p<node> This flag specifies an alternate primary address for the current area. <node> should be a full 4D address, including zone and point numbers (if appropriate). Using an alternate primary address will affect Squish's operation in the following ways: * The alternate address will be added to the SEEN-BYs for the specified area, as opposed to adding the first address declared in SQUISH.CFG. * The alternate address will be added to the ^aPATH line instead of your normal address. * The alternate address will be used when creating packets with messages from the specified area. Squish v1.11 Reference Manual - Page 79 This flag permits "clean" multi-zone operation with only one configuration file, even when using a diverse range of addresses and message areas. -s This flag strips the private bit from all messages which are tossed to this area. Unlike other EchoMail processors, handling of private messages can be controlled on an area-by-area basis. -u<node> This flag instructs Squish to accept broadcast modify/delete messages from the node in question. See the section entitled "BROADCAST MODIFY/DELETE" for more information. -x<node> This flag instructs Squish NOT to accept any inbound messages in this echo from the specified address. This flag can be used to make a certain node "read only" for one area, since messages coming from that node will trigger a security violation and be placed in BAD_MSGS. -0 (That's a zero, not the letter "o".) This flag tells Squish that the current area is a "passthru" area. This means that messages from this area do not stay on your system; they are simply scanned out to the other systems listed for this area and then deleted. If you are running Squish in single pass mode, messages will be scanned directly from the inbound *.PKT files and will never touch your message areas. -+<node> This flag adds a node to the SEEN-BYs for the current area only. <node> should be a two- dimensional address (net/node only). Note! If you are using an alternate primary address, that address will be added to the SEEN- BYs automatically. -$ This flag tells Squish that the area is stored in the Squish (*.SQ?) format. When using this flag, <path> should specify the full path and root filename of the Squish area. (A root filename is the path and the first eight characters of a DOS filename, with no extensions permitted.) -$d<num> This flag specifies that no more than <num> days Squish v1.11 Reference Manual - Page 80 worth of messages should be kept in a Squish-style area. This causes SQPACK to delete all messages which are more than <num> days old. NOTE! Unlike -$m, this flag does NOT cause Squish to purge messages on the fly. If you choose to delete message by date, you must run SQPACK once a day. Otherwise, if you choose to delete by message number, you can allow Squish to renumber and purge the area as it tosses. -$m<msgs> This flag specifies the maximum number of messages to keep in a Squish-style area. Normally, Squish leaves the maximum message counter alone in a *.SQ? area. However, if Squish has to create the area for one reason or another, the maximum message counter will be set to a value of <msgs> messages. Using the -$m switch also implicitly activates the -$ switch. -$s<msgs> This flag specifies the number of messages to skip killing <msgs> messages at the beginning of a Squish-style area. This flag must be used in conjunction with the -$m flag. See the section entitled "USING SQUISH-FORMAT MESSAGE AREAS" for more details. Squish v1.11 Reference Manual - Page 81 Split Area Definitions Squish allows EchoMail areas to be defined in SQUISH.CFG, AREAS.BBS, and it even allows area definitions to be split between both. Such splitting is necessary, especially if you want to use Squish-specific features and also wish to remain compatible with the AREAS.BBS file format. When declaring a split area in either SQUISH.CFG or AREAS.BBS, Squish will check to see if that area exists in the list of existing areas. If it does, Squish will simply add to that area's definition, as opposed to creating a new logical area. Nodes and flags specified in one file will be automatically applied to the other; in other words, the following two definitions: AREAS.BBS: $C:\Msg\Magic XXYZY 1:123/456 789 SQUISH.CFG: EchoArea XXYZY C:\Msg\Magic -$ -p1:234/567 would be equivalent to the following definition in SQUISH.CFG only: EchoArea XXYZY C:\Msg\Magic -$ -p1:234/567 1:123/456 789 Declaring areas using this method enables all of the new Squish features, but it also allows for compatibility with utilities which use AREAS.BBS for node information, including Areafix and many others. Squish v1.11 Reference Manual - Page 82 ARCHIVERS AND MESSAGE COMPRESSION Through the use of external file archiving utilities, Squish is capable of compressing mail that it sends to other systems. If you are using the Send and Route keywords in ROUTE.CFG, Squish will automatically compress mail for the specified nodes. Instead of sending *.PKT files, Squish will then send *.MO?, *.TU?, *.WE?, *.TH?, *.FR?, *.SA? and *.SU? files. (The last part of the file extension will be a single digit; this digit is incremented after creating each archive, which ensures that compressed mail files do not get overwritten once an archive arrives at its destination.) In addition, Squish allows you to define a separate compression program for individual nodes. Some of the systems you connect with may wish to use ARC, while others may elect to use ZIP and LZH. The Pack and DefaultPacker statements in SQUISH.CFG can be used to select different archivers for each node. However, Squish takes a new approach to message compression. Instead of hardcoding support for all of the archivers currently available, Squish uses a "compression configuration file". Using such a file allows Squish to support as many archive types as possible. The flexibility of this file even allows Squish to use archiving programs which have not been invented at the time of this writing. In SQUISH.CFG, the Compress keyword controls the location of the compression configuration file. As distributed, COMPRESS.CFG comes configured for use with ARC, ZIP, PAK, ZOO, ARJ, LHarc 1.13 and LHarc 2.xx. However, new programs can be added to Squish's repertoire on a moment's notice. COMPRESS.CFG is divided into a number of entries, one per archiver. (As many archivers can be defined as you like, memory limiting.) Each entry in COMPRESS.CFG looks like this: Archiver <name> Extension <ext> Ident <pos>,<hexstr> Add <cmd> Extract <cmd> View <cmd> End Archiver The "Archiver" keyword starts off the definition of an archiving program. <name> specifies the short-form name of the archiver; this short form should be a single word, since Squish uses it to select compression types with the Pack statement in SQUISH.CFG. Squish v1.11 Reference Manual - Page 83 <ext> is the file extension normally used by the specified archiver. At present, this information is not used by Squish, but it may be used by other programs which share the same COMPRESS.CFG file. Next comes the Ident keyword: the information provided by this keyword allows Squish to identify archives of unknown types. Most archiving programs place a special signature at the beginning of a compressed file, so when Squish encounters such a file, these special signatures are used to determine how to unpack the archive. The <pos> number tells Squish where to look for the archiver's signature. If <pos> is greater than or equal to zero, it is interpreted as an offset from the start of the file, with the first byte being offset 0, the second byte being offset 1, and so on. If <pos> is negative, Squish will interpret it as an offset from the END of the file, with -2 being the last byte in the file, -3 being the second-last byte in the file, and so on. <hexstr> is an ASCII representation of the archiver's signature. Every byte in the archiver's signature should be converted to hexadecimal, and then entered into the compression configuration entered as two hexadecimal digits. Since most archivers use special control characters in their signatures, entering the signatures directly is not possible. However, by representing each byte as two hexadecimal digits in the range 0-9 and A-F, even the simplest of editors can read the compression configuration file. The Add keyword specifies the command which should be used to add files to the specified type of archive. Similarly, the Extract and View keywords specify the commands to use for extracting from and viewing archives (respectively). Before executing the archiver, Squish will make two special translations: all occurrences of the string "%a" will be changed to the name of the archive being processed. Similarly, all occurrences of the string "%f" will be changed to the name of the file(s) to be added or extracted. These tokens allow the utmost in flexibility when handling multiple archiving programs. The "End Archiver" keyword signifies the end of an archiver definition. Each "Archiver" keyword must be followed by an "End Archiver" keyword later in the file. In addition, if Squish encounters a line prefixed with the "DOS" or the "OS2" keywords, it will only parse that line when running under the indicated operating system. This allows different archiving programs to be used under DOS and OS/2. Squish v1.11 Reference Manual - Page 84 ROUTING Squish includes a complete routing control system for both BinkleyTerm and ArcmailAttach mailers. Squish is capable of generating ARCmail attach messages for systems with dynamic routing, and it also includes a full complement of commands for handling static routing. All of Squish's routing is performed via the ROUTE.CFG file. Whether you are using dynamic (ArcmailAttach) or static (Binkley) packing, all of the Squish routing commands must be placed in this file. As distributed, all of the commands in your routing control file are executed every time a SQUISH SQUASH is performed. However, Squish's routing system can be used to implement "schedules", which cause certain routing commands to be performed at certain times. (Schedules can be run on the basis of the time of day, or they can be simply run on demand.) Commands which are to be always run, regardless of schedules, must be placed in the "global section", or before the first "Sched" statement in ROUTE.CFG. The only difference between schedules and the global section is when the commands are performed; otherwise, after Squish has started processing a section of the control file (whether it be the global section or a schedule), all routing commands are treated the same. Generic Routing Commands Several routing commands apply to both static and dynamic packing. Namely, all of following commands can be used equally well on both BinkleyTerm and ArcmailAttach systems: Send <flavour> [NoArc] <node> [<nodes>...] The Send command scans for uncompressed mail with a normal flavour, compresses it, and changes the mail's flavour. The Send command changes the attributes of the mail, but it never changes the mail's destination address. (If you wish to change the destination address, please see "Route", below.) <flavour> specifies the flavour to use for the resulting compressed mail file. Squish will assign this flavour to the compressed mail archive after archiving all of the packets for this node. Squish v1.11 Reference Manual - Page 85 The optional NoArc modifier stops Squish from archiving the packet that is created for the specified system. Squish will simply change all normal-flavoured packets to the specified flavour, placing all of the original packets into one large packet file. The command "Send <flavour> NoArc <node>" has the same net effect as "Change Normal <flavour> <node>". This modifier apples to BinkleyTerm systems only. <node> and <nodes> are simply a list of nodes to which mail should be sent. Squish will expand all node number wildcards and process all normal-flavoured packets for those nodes. In the BinkleyTerm outbound area, using Send (without the NoArc modifier) has the following result: xxxxyyyy.OUT --> xxxxyyyy.MO? + xxxxyyyy.?LO With the NoArc modifier, the result will be as follows: xxxxyyyy.OUT --> xxxxyyyy.?UT Route <flavour> [NoArc] [File] <target> [<nodes>...] The Route command scans for uncompressed mail with a normal flavour, compresses it, changes the mail's flavour, and (unlike Send) readdresses the mail. The Route command scans for mail addressed to any of the specified nodes, but readdresses that mail to the target. In other words, Route scans for uncompressed mail destined to <nodes>, archives the mail, and finally sends it to <target>. <flavour> specifies the flavour to use for the resulting compressed file. The NoArc modifier (optional) stops Squish from archiving the resulting mail. Squish will simply combine all of the specified packets into one, give it the appropriate flavour, and send it to the target without any form of compression. This modifier applies to BinkleyTerm systems only. WARNING! The NoArc modifier causes all 4D zone and point information to be lost! Only net and node numbers will be maintained for mail routed with the NoArc keyword. The File modifier (optional) instructs Squish to route file attaches in addition to messages. By default, all file attaches are sent to the specified destination, regardless of flavour. However, if the File modifier is used, Squish will also scan for and route file attaches. This modifier applies to BinkleyTerm systems only. Squish v1.11 Reference Manual - Page 86 <target> is the address of the system which will receive the routed packets. Make sure that you have made prior arrangements with the target to route your mail, since it's discourteous to route mail through someone else's system without asking permission. Wildcards should not be used when specifying the target address. <nodes> are the addresses for which mail will be routed. All of the normal-flavoured mail for these addresses will be packaged up and sent to the target. In the BinkleyTerm outbound area, using Route (without any modifiers) has the following result: xxxxyyyy.OUT --> XXXXYYYY.MO? + XXXXYYYY.?LO When using the NoArc modifier, the Route command has the following result: xxxxyyyy.OUT --> XXXXYYYY.?UT The File modifier causes the following changes to take place, in addition to the above: xxxxyyyy.FLO --> XXXXYYYY.?LO Define <token> <text> The Define token is used to provide a short-form for routing commands. The Define command acts as a macro facility, since it causes all further occurrences of <token> to be replaced by <text>. As an example, the Define command is useful if there is a common set of nodes for which different routing commands must be applied over and over again. Given the following Define statement: Define Hub300 300 301 302 303 304 305 306 Squish would translate the word "Hub300" to "300 301 302 303 304 305 306" wherever that word occurred later in the file. If the following route command were given: Route Crash 1:123/300 Hub300 all of the mail for nodes 300 through 306 would be routed through 1:123/300. However, replacements will only take place when the defined <token> is surrounded by whitespace or punctuation. Squish v1.11 Reference Manual - Page 87 Dos <cmd> The Dos command can be used to pass the name of an external command to the operating system. The command will simply be run via the default command processor (normally COMMAND.COM for DOS, or CMD.EXE for OS/2). Schedules Squish supports the concept of "schedules", which are routing commands that can be run at different times of the day. Squish also supports a section of global routing commands which are always run. The "Sched" statement in ROUTE.CFG is used to begin a schedule. All routing commands which precede the first Sched statement are in the "global section", and they are always run when a SQUISH SQUASH is performed. Squish will execute statements inside a schedule up to the next Sched statement, or until the end of the file is reached. The format of the Sched statement is as follows: Sched <tag> [day] [start] [end] <tag> is a one-word identifier for this schedule. If you wish to explicitly execute this schedule on demand, then this tag must be specified on the command line through the -s command-line switch. Otherwise, the name given to each schedule is irrelevant. <day> instructs Squish to execute the schedule on certain days of the week. To always execute a schedule, use the word "All". To execute a schedule on weekends only, use the word "WkEnd". To have it executed only on weekdays, use "WkDay". To execute the schedule on a particular day of the week, use the words "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" or "Sun". To execute the schedule on more than one day of the week, use the "|" (pipe) character to string together two or more of the above words. For example, "Tue|Wed|Fri" would cause the schedule to be run only on Tuesdays, Wednesdays and Fridays. <start> specifies the starting time for the schedule, specified in 24-hour format (hours:minutes). The schedule will only be executed if the current time is equal to or greater than the time specified. <end> specifies the ending time for the schedule, specified in 24-hour format. The schedule will only be executed if the current time is equal to or less than the time specified. Squish v1.11 Reference Manual - Page 88 WARNING FOR EX-QMAIL USERS! IF YOU WILL BE RUNNING A SCHEDULE BY THE COMMAND LINE, <tag> IS THE ONLY REQUIRED PARAMETER! When Squish is scanning through ROUTE.CFG, it will automatically execute any schedules which fall within the specified time frame, regardless of those schedules' tags. This means that ALL schedules with a date/time of "All 00:00 23:59" will be executed. Unless you want to run all of your schedules each time a SQUISH SQUASH is performed, only use the date and time for schedules which actually need to be run at different times. Example For example, the following ROUTE.CFG segment has a set of global routing commands which are run all the time, a set of commands which are run in the morning, and a set which are run in the afternoon/evening: ; GLOBAL COMMANDS ; Always route mail for net 123. Route Crash 1:123/1 123/All ; Route mail for my NC to the right place. Route Crash 1:222/0 1 ; MORNING COMMANDS Sched Morning All 00:00 11:59 ; Convert previously-held mail to crash for nodes in zone 2 Change Hold Crash 2:All Send Crash 2:All ; AFTERNOON/EVENING COMMANDS Sched Afternoon All 12:00 23:59 ; Convert crash zone 2 mail back to hold Change Crash Hold 2:All ; Now send all new zone 2 mail as hold Send Hold 2:All ; COMMANDS RUN ON DEMAND Squish v1.11 Reference Manual - Page 89 Sched PollNEC Poll Crash 1:222/2 When run in the morning, Squish would handle routing for nets 123 and 222, in addition to sending crashmail to all zone 2 systems. When run in the afternoon, Squish would still handle routing for nets 123 and 222, but it would send mail to zone 2 systems as hold. When run with the command line switch "-sPollNEC", Squish would generate a crash poll to node 222/2. Squish v1.11 Reference Manual - Page 90 BinkleyTerm Routing Commands The following commands can only be used on a BinkleyTerm-style system. These commands directly modify the outbound directories, so there are no equivalent commands for ArcmailAttach systems. Leave <node> [<nodes>...] The Leave command modifies outbound mail so that it will not be sent by BinkleyTerm. Squish will rename both *.?UT and *.?LO to an extension which is not recognized by BinkleyTerm, thereby preventing the mail from being sent or picked up. Leaving mail is useful for mail hubs and NECs, since it stops all mail from being given to the specified nodes. If your system has a crucial polling window and you want to stop others from receiving mail when they call in, the Leave command can be used to make that mail inaccessible. To convert mail back to its original form after using "Leave", see the documentation for the Unleave command. As many nodes can be specified for the Leave command as necessary. Wildcards are permitted. In the BinkleyTerm outbound area, using Leave has the following result: xxxxyyyy.?UT --> xxxxyyyy.N?T xxxxyyyy.?LO --> xxxxyyyy.N?O Unleave <node> [<nodes>...] The Unleave command undoes all of the changes which were made by the Leave command. Mail which was left for the specified nodes will be converted back to its original flavour, such that the mail can once again be sent or picked up. As many nodes can be specified for the Unleave command as necessary. Wildcards are permitted. In the BinkleyTerm outbound area, using Unleave has the following result: xxxxyyyy.N?T --> xxxxyyyy.?UT xxxxyyyy.?LO --> xxxxyyyy.N?O Squish v1.11 Reference Manual - Page 91 Change <from_flavour> <to_flavour> <node> [<nodes>...] The Change command is used to change the flavour of existing packets and file attaches. <from_flavour> specifies the flavour to convert FROM. Only mail of this flavour will be converted. Valid flavours are crash, hold, direct and normal. <to_flavour> specifies the flavour to convert TO. All types of mail with a <from_flavour> will be converted to the <to_flavour>. Valid flavours are crash, hold, direct and normal. <node> and <nodes> specify the nodes for which mail should be converted. Squish will process mail which are addressed to these nodes only, and apply the specified conversions. In the BinkleyTerm outbound area, using Change has the following result: xxxxyyyy.?UT --> xxxxyyyy.?UT xxxxyyyy.?LO --> xxxxyyyy.?LO Poll <flavour> <node> [<nodes>...] The Poll command is used to generate a poll to another system, even if there is no other mail waiting for that node. <flavour> specifies the flavour to use when creating the poll. Valid flavours are normal, crash, hold, and direct. <node> and <nodes> specify the node numbers which should be polled. Wildcards are NOT permitted. In the BinkleyTerm outbound area, using Poll has the following result: Create: xxxxyyyy.?LO HostRoute <flavour> [File] [NoArc] <node> [<nodes>...] HostRoute is similar to the Route and Send commands, except that HostRoute will route normal-flavoured mail to each node's net host, as opposed to routing it all through a central hub. (In other words, mail for 123/456 will be routed through 123/0, just as mail for 678/901 will be routed through 678/0.) Squish v1.11 Reference Manual - Page 92 <flavour> specifies the flavour to use when creating the routed packets. The File modifier instructs Squish to route files in addition to messages. In general, the HostRouting of files is discouraged. The NoArc modifier stops Squish from archiving the resulting packets. Messages will be sent to the net hosts in an uncompressed form. <node> and <nodes> specify the nodes for which routing will take place. Wildcards are permitted. In the BinkleyTerm outbound area, using HostRoute has the following result: xxxxyyyy.OUT --> xxxx0000.?UT The File modifier causes the following changes to take place, in addition to the above: xxxxyyyy.FLO --> xxxx0000.?LO Dynamic Routing (FrontDoor) Squish has only minimal support for dynamic routing, since dynamic routing is always performed by your mailer. The Route command CAN be used to route mail, but using your mailer to perform all routing is recommended. All schedules for an ArcmailAttach mailer should end with the command "Send Normal World". This command compresses all remaining mail and gives it a flavour of normal. Since ArcmailAttach mailers only recognize compressed mail, this command is required to ensure that all mail is properly sent. Squish v1.11 Reference Manual - Page 93 SECURITY In most environments, EchoMail security is not a problem. However, in some instances, other systems may attempt to inject unwanted mail into normal EchoMail areas. Squish provides two forms of protection against this: * "Secure mode". When the "Secure" keyword is added to SQUISH.CFG, Squish will check the origination addresses of all incoming packets, and it will only toss messages from systems which are listed in the "<nodes>" section of your area definitions. In other words, unless you have added the address 123/456 to the definition for a particular echo, that node will not be able to send messages in that echo to your system. Secure mode provides protection against unlisted systems "crashing" messages into an EchoMail area through your system. If messages cannot be tossed due to a security violation, they will be placed in your BAD_MSGS area. * Packet passwords. Although secure mode protects against most unwanted packets, other systems may try to send you mail using the address of another node. Squish protects against this by allowing packet passwords to be used; by using Password statements in SQUISH.CFG, you can declare a password for nodes that you regularly connect with. Passwords are "bidirectional", meaning that the same password is used for both sending and receiving mail. The packet password must be the same for both sides of the link. In other words, if node 123/456 wants to use the password "qwerty" for node 234/567, the configuration file on 123/456 must look like this: Password 234/567 Qwerty and the configuration file on 234/567 must look like this: Password 123/456 Qwerty In either case, the intent is to list the password to use when sending mail to the other system. When creating packets for that system, Squish will insert the specified password into the packet. In addition, when tossing packets from that system, Squish will check to make sure that the password is the same as the one listed in your configuration file. If the two passwords do not match, the incident will be noted in the log, and the packet will be renamed to *.BAD and will not be tossed. Squish v1.11 Reference Manual - Page 94 * Multiple NetFile paths. Squish supports multiple NetFile paths with varying attributes in SQUISH.CFG. When used with a mailer which allows different inbound directories to be declared for passworded and non-passworded systems, the modifiers for the NetFile keyword (such as NoArc and NoPkt) can be used to stop Squish from tossing certain types of mail from certain systems. This helps prevent so-called "ARCmail bombs" from being decompressed and filling up all of your disk space. * Receive-only nodes. The -x<node> flag can be used with an EchoArea definition to stop Squish from tossing messages from a certain node in a certain echo. This allows an echo to be sent to a system, but it stops that system from sending any messages back into the echo. If all of these security features are enabled, Squish becomes a very secure and rigid mail processor. Most of these features will not be necessary for day-to-day operation, but they will become extremely useful when trying to stop unwanted mail from entering your system. Squish v1.11 Reference Manual - Page 95 MULTIZONE OPERATION Squish was designed especially for use on a multizone system. In addition to full zone and point support, Squish can use an alternate primary addresses for each individual message area on your system. Squish can control the SEEN-BYs on an area-by-area basis, generate packets with proper 4D addressing information, and more. The first key to multizone operation is the -p flag in SQUISH.CFG. This flag allows an alternate primary address to be selected for each individual message area. Squish will use the alternate address when adding to the ^aPATH line, SEEN-BYs and the message origin. In addition, the origination address in outbound packets will also use your alternate address for that area. To use the -p flag, simply place that flag and your alternate primary address before all the addresses of the systems that you feed. For example, to declare an alternate primary address of 89:487/106, in an area called "IMEX.R82" (which you receive from 89:487/0), the following line should be used in SQUISH.CFG: EchoArea IMEX.R82 C:\Msg\ImexR82 -p89:487/106 89:487/0 The alternate primary address also changes your default address for the area definition, so the following would have the same effect: EchoArea IMEX.R82 C:\Msg\ImexR82 -p89:487/106 0 Squish can support an unlimited number of alternate primary addresses, as long as you use the proper -p flag for each area. The -p flag is not required for areas which use your primary address (the first address declared in SQUISH.CFG), since Squish will use your first address by default. Squish is also capable of adding node numbers to the SEEN-BYs for one area only. In a manner similar to using alternate primary addresses, simply add a -+<node> flag for each area and for each node that you wish to add. (Your alternate primary address will be added automatically, so you do not need to worry about adding it as well.) For example, if you wanted to add the nodes 487/2 and 487/3 to messages passing through your system in the ABC echo, using an alternate address of 89:487/106, the following declaration in SQUISH.CFG would do the job: EchoArea ABC C:\Msg\ABC -p89:487/106 -+487/2 -+3 487/0 Squish v1.11 Reference Manual - Page 96 Finally, you should make sure that you have declared all of your alternate primary addresses using the Address keyword in SQUISH.CFG. Otherwise, Squish will not realize that messages for your alternate address are really for your system, and it will try to forward them as in-transit netmail. That's all there is to it! No secondary configuration files, and more importantly, no kludges are required. Squish provides transparent support for multizone systems, with a minimum amount of hassle and with no speed drawbacks. Squish v1.11 Reference Manual - Page 97 POINTS (4D, FAKENETS AND BOSSNODES) Squish incorporates full support for 4D and fakenet points, both as a point itself and as the managing bossnode. Bossnodes can also transparently support both types of points, still using the same configuration file. Fakenet Points In the early days of FidoNet, support for true points was minimal or nonexistent. As a workaround, instead of giving true 4D addresses to a system's points, a dummy net number was created. In turn, the node numbers in that net would actually represent points of the bossnode. Since this dummy net/node combination was a simple net/node address (with no point numbers), adapting existing software was no problem. This net number would be used for internal communication between the bossnode and the points. For example, if 123/456 were using a dummy net number of 14122, the fakenet version of the address 123/456.1 would be 14122/1. When using the fakenet scheme, it is vitally important to ensure that fakenet numbers do not "escape" out into the rest of the net. Since many systems could theoretically be using the same dummy network number, the fakenet addresses are usually stripped or converted by the boss system before messages are sent to the rest of the network. Squish supports fakenet points through the use of the "PointNet" keyword in SQUISH.CFG. Simply specify which dummy net you are using, and Squish will automatically handle the details of stripping and adding SEEN-BYs. NOTE! As the boss of a fakenet system, you should make sure to use the actual fakenet number whenever you refer to one of your points. Since Squish supports both 4D and fakenet points in the same configuration, you must be careful to use the correct address. In other words, if you have a fakenet point at 123/456.1, with a fakenet address of 14122/1, you must ensure that your control files and AREAS.BBS always refer to this point as 14122/1. 4D addresses can only be used when dealing with true 4D points. 4D Points Squish supports true 4D points in addition to fakenet points. However, to use 4D points, both the bossnode and the point must be running 4D-capable tossers, scanners and mailers. As of this writing, the only 4D mailers in common use are FrontDoor, InterMail, D'Bridge, and BinkleyTerm 2.50+. 4D tossers and scanners include Squish, TosScan, Imail and others. Unless all Squish v1.11 Reference Manual - Page 98 of your software supports 4D addressing and the "2+" packet header proposal, you will not be able to use 4D points. Squish supports 4D points in an extremely simple manner; just use the 4D point address like a normal address. Squish will automatically handle the tossing and scanning of messages from 4D points, and there is no need to remap addresses. SEEN-BYs are ignored when sending messages to 4D points, since SEEN-BY lines are only two-dimensional. As with fakenet points, make sure that you always use the 4D address when referring to 4D points. If you attempt to mix and match 4D and fakenet addresses for the same node, Squish may not work the way you intended it to. IF YOU USE *.MSG FORMAT MESSAGE AREAS AND WISH TO SUPPORT 4D POINTS, SINGLE-PASS MODE MUST ALWAYS BE USED. *.MSG areas cannot hold the origination and destination point numbers that Squish requires for 4D operation. However, Squish can use 4D points with *.MSG areas, as long as "SQUISH IN OUT" is always used. Squish message areas contain proper zone and point operation, so 4D points can be used with both the single-pass and multipass modes. Remapping Squish includes a built-in node remapper. This remapper readdresses inbound netmail based on the "To:" field, and it also remaps outbound netmail by changing the fakenet back to a 4D address, if applicable. When specifying point numbers in the remapper, make sure that you specify either a 4D or a fakenet address, as appropriate. Again, since Squish supports both 4D and fakenet points in the same configuration, you must make sure to use ONLY fakenet addresses for fakenet points, and ONLY 4D addresses for 4D points. For more information on the remapper, please see the "Remap" keyword in the SQUISH.CFG reference. Squish v1.11 Reference Manual - Page 99 USING SQUISH-FORMAT MESSAGE AREAS In addition to the FidoNet standard *.MSG format, Squish also supports the proprietary, flat-file *.SQ? message base. This message base was designed from the ground up to be fast, reliable and small. Some of the key features of the Squish message format are: * Flat-file message areas. A separate message database per message area. Using a separate message file for each area still provides for quick access, but if disaster should happen (such as a message base crash), only one area will be damaged. * Maintainability. The Squish format utilizes a customized circular file structure. For the most part, Squish message areas are completely self-maintaining. If a message is deleted in a Squish message base, the space left by that message can be reused when more messages are written to the area. Squish attempts to fill the message base in an optimal manner, so "packing" is not as important as it is with other message base types. Depending on the volume of mail you process, Squish areas may only need to be packed once a week! Squish areas are also renumbered on the fly, so an external renumbering utility is not required. Finally, the Squish file format also allows for a "maximum message limit" to be set for any given area. This limit will be used to automatically purge old messages as new ones are written to the message base, which eliminates the need for an external message deletion utility. A separate set of message numbers is maintained for each message area, which eliminates the "messages in this area are numbered 89,216 through 90,784" eyesore of other message formats. * Reliability. The Squish format was designed to make message recovery an easy task, even in the event of a total message base crash. The SQFIX utility can be used to fix a damaged Squish area with no user intervention. SQFIX has a high success rate; in most cases, not a single message will be lost! * Speed. Since Squish uses a flat-file message base, it is much faster than the FTS-0001 *.MSG format. Based on preliminary testing, Squish is also faster at tossing messages than QECHO 2.66 and several other utilities which use the Hudson message format. Squish v1.11 Reference Manual - Page 100 * Size. Messages are stored in the equivalent of a random- access file with a record length of 1 byte, so no "blocks" are necessary. Unlike the Hudson format, Squish stores messages directly after one another with no padding. When the SEEN-BY information is turned off, Squish message bases are consistently smaller than the equivalent Hudson-format message base. * Multitasking and LAN awareness. Squish was designed from the ground up to be compatible with multitasking and network systems. Multiple programs, such as Squish and Maximus, can access the same message base at the same time with no danger of corruption. * Flexible structure. Squish areas have built-in support for full 4D origination and destination addresses, date-of- creation and date-of-arrival binary timestamps, and more. In addition, ^A kludge lines are stored in a separate logical record before the message body, providing a unified way for developers to access message control information. Even with all of these advanced features, the Squish format is easy to use. Squish format areas can be declared in both SQUISH.CFG and AREAS.BBS, although the maximum message limit can only be set in SQUISH.CFG for compatibility reasons. On disk, Squish message bases are stored using two files per message area. To name a Squish area, you must specify a path and a "root filename". A root filename is the base part of a filename, eight characters or fewer, with no extension. Squish will then add the appropriate extensions to access the message data and index files. The Squish message format itself only requires two files per message area: areaname.SQD This file is used to store the message data. Information about the area, the number of messages, message headers, the message body, and the linked lists are all stored in this file. areaname.SQI This file is used to store the message index. This contains a copy of the "To:" field in the message header, and it allows the Squish format to be accessed quickly in a non-linear fashion. The above are the only required files for a Squish-format area. Squish v1.11 Reference Manual - Page 101 However, other programs create files with similar extensions, such as: areaname.SQB This file is used by the Squish tosser to store duplicate message information. areaname.SQL This file is used by Maximus to store lastread pointer information. This file is an array of UMSGID numbers, using the user's lastread_ptr field as the index. areaname.SQO This file is used by the Squish tosser to provide a custom origin line for the given area. If an .SQO file is present for a given message area, the first line in the file will be used as the origin line for messages in that area, overriding the "Origin" setting in SQUISH.CFG. Squish will automatically add the "* Origin" prefix and the trailing "(zone:net/node)" text. For more information on the Squish file format, see the Squish Developer's Kit, to be released shortly after Squish 1.1 is made available. To declare a Squish-format area in AREAS.BBS, simply add a "$" character to the beginning of the path. In other words, to convert the following to a Squish-format area: E:\MSG\ASDF ASDF 249/99 simply add a "$" at the beginning to make it look like this: $E:\MSG\ASDF ASDF 249/99 For an area declared in SQUISH.CFG, simply add a "-$" flag to the area definition. In other words, given the following definition for a *.MSG area: EchoArea ASDF E:\MSG\ASDF 249/99 a "-$" should be inserted to convert the area to the Squish format, like this: EchoArea ASDF E:\MSG\ASDF -$ 249/99 To add a maximum message limit to a Squish area, the "-$m" flag can be used in SQUISH.CFG. For example, to limit the ASDF area to 100 messages, the following definition could be used: EchoArea ASDF E:\MSG\ASDF -$m100 249/99 Squish v1.11 Reference Manual - Page 102 When using the above definition, Squish will automatically purge messages such that no more than 100 messages are in the area at once time. A limit on the maximum age of messages can also be set using the -$d flag. However, purging messages by date is only performed when SQPACK is run, so Squish will not perform date deletion when tossing messages. For more information on the -$, -$d and -$m flags, please see the SQUISH.CFG reference. In terms of usage, Squish will automatically create nonexistent areas, so you do not have to worry about creating them manually. Squish treats *.SQ? areas just like *.MSG areas in all respects, including direct tossing and scanning. However, Squish areas can be accessed much faster than their *.MSG counterparts, and Squish areas will also use less disk space. Once you have tossed messages to a Squish-format message base, those messages can be accessed with any program which supports the Squish format. If you are using the -$m flag, Squish areas are mostly self- maintaining. However, small "holes" can creep into the message base over time, even with the circular file format. For this reason, the SQPACK program can be run at predefined intervals to pack and compress message bases. Also, if you are using the -$d option, SQPACK must be run to delete old, expired message. For information on installing SQPACK, please continue reading in the next section, entitled "SQUISH-FORMAT MESSAGE UTILITIES". Squish v1.11 Reference Manual - Page 103 BROADCAST MODIFY/DELETE Squish 1.10 introduces support for broadcast message deletion and modification. This feature allows users on remote systems to write an EchoMail message, and even after the message has been sent to a remote system, it allows the user to amend or delete the message on all of the systems which carry that conference. First, broadcast messages are currently only supported in Squish message areas. While the concept of broadcast messages could be easily applied to other area types, Squish needs to maintain a database of MSGID values for broadcast message processing. In the interests of speed, Squish currently does not maintain this information for *.MSG areas. Note that the broadcast feature also relies on the Squish .SQB file to store information on messages being tossed. The dupe file must also be large enough (as defined by the "Duplicates" keyword) to store information for all of the messages in the area. THE BROADCAST FEATURE ONLY WORKS ON MESSAGES THAT WERE ORIGINALLY TOSSED TO A SQUISH AREA BY SQUISH 1.10 OR ABOVE. The broadcast feature must be enabled on an area-by-area basis, using the "-u<node>" flag for each EchoArea definition. <node> specifies the address of a trusted uplink which is allowed to submit update/delete requests. (The actual origin of the update/delete message is not important. However, Squish will only process update/delete messages if it receives them from the node specified by -u.) For example, the following definition sends PVT_ECHO to both 249/106 and 107, but it only accepts update/delete messages that it receives from 249/106. Note that 249/106 is specified twice; it is listed once in the scan list, and it is listed once for the -u flag. EchoArea PVT_ECHO \path\pvt_echo -$ 1:249/106 107 -u106 An automatic update/delete message has the same format as a normal message in an EchoMail area, except that it contains an "Area Control Update" kludge in the following format: ^aACUPDATE: MODIFY <addr> <serial> or ^aACUPDATE: DELETE <addr> <serial> Squish v1.11 Reference Manual - Page 104 For either format of the command, Squish will scan the area for a message containing a MSGID kludge of the format "MSGID: <addr> <serial>". When processing an ACUPDATE MODIFY, if the message containing that MSGID is found, it will be replaced in its entirety by the update message. The old message will retain its original message number. Note that Squish will strip the "ACUPDATE" line from the modified message before writing it to disk. When processing an ACUPDATE DELETE, if the message containing that MSGID is found, that message will be deleted. The contents of the ACUPDATE message are ignored. Note that all ACUPDATE processing is performed during "SQUISH OUT" phase. If an ACUPDATE message passes the "-u" security check, the ACUPDATE message (in its original form) will be scanned out to all of the nodes before the ACUPDATE operation takes place. In other words, ACUPDATE acts as a broadcast message to all nodes listed for an area. The modification/deletion is performed by each node that receives the message; the messages which are consequently modified are NOT transmitted to other nodes. All remote modify/delete transactions are noted in the Squish log file. Squish v1.11 Reference Manual - Page 105 SQUISH-FORMAT MESSAGE UTILITIES In addition to the main tosser/scanner/packer, the Squish package includes several utility programs designed to help users of Squish-format message bases. SQPACK: Weekly maintenance The SQPACK program is used to "pack" Squish-format message areas. Over the course of time, small holes can develop in Squish message areas, so SQPACK can be used to recover this wasted space. If you are using the -$m flags on your areas, you probably will not need to run SQPACK more than once a week. However, if you are killing messages by age (through the -$d flag), you'll need to run SQPACK whenever you wish to delete messages. The command-line format for SQPACK is as follows: SQPACK <filespec> <filespec> should specify the name and path of a Squish-format message data file. Wildcards are allowed. For example, to pack the message in the file D:\MSG\MUFFIN.SQD, the following command should be issued: SQPACK D:\MSG\MUFFIN.SQD In addition, if there are a number of message areas in the D:\MSG directory, the following command could be given to pack all of those areas: SQPACK D:\MSG\*.SQD When SQPACK finishes processing all of the selected areas, it will print out a short statistics report detailing how much space was used before, how much space is used now, and a percentage savings. This percentage can guide you when figuring out how often to run SQPACK. Note to Maximus users In addition to the name of a Squish data file, SQPACK can also accept the name of a Max 2.00 AREA.DAT file. If you enter "SQPACK D:\MAX\AREA.DAT", SQPACK will automatically pack all of the Squish-format areas defined in AREA.DAT. Squish v1.11 Reference Manual - Page 106 SQCONV: Conversion between *.MSG and *.SQ? The SQCONV utility is used to convert message areas between the *.MSG and Squish message formats. SQCONV is normally run from the OS prompt, and it can only be run on one area at a time. SQCONV uses the following command-line format: SQCONV <from_path> <from_type> <to_path> <to_type> <zone> <from_path> specifies the directory or root filename of the area that you wish to convert. <from_type> specifies the type of the <from_path> area. Valid types are either "*.MSG" or "Squish". <to_path> specifies the directory or root filename for the area to be created. <to_type> specifies the type of the <to_path> area. Valid types are either "*.MSG" or "Squish". <zone> specifies your default zone number. Since *.MSG format messages do not always have zone numbers available, you must tell SQCONV which default zone number is used in that area. For example, to convert a *.MSG area in C:\MAX\MSG\LOCAL to a Squish area called C:\MAX\MSG\PRIVATE.SQ?, the following command line would be used: SQCONV C:\Max\Msg\Local *.MSG C:\Max\Msg\Private Squish 1 The above assumes that you are in zone 1; for other zones, simply substitute your default zone number for the "1". To convert an area back from Squish format to *.MSG, the following could be used: SQCONV C:\Msg\Sqarea Squish C:\Msg\Msg_Area *.MSG 1 Also, please note that both Squish and *.MSG areas can have the same name. Since *.MSG messages are placed inside a separate directory, and Squish areas are placed in *.SQ? files in the directory above, the following command is perfectly acceptable: SQCONV C:\Msg\Local *.MSG C:\Msg\Local Squish 1 Squish v1.11 Reference Manual - Page 107 The above command would convert all of the messages in C:\Msg\Local\*.MSG and place those messages in the files called C:\Msg\Local.SQ?. WARNING! You must exercise caution when converting a Squish area back to the *.MSG format. Since SEEN-BYs are not updated in Squish EchoMail messages, converting a Squish area to *.MSG may cause messages in that area to be rescanned. You should make sure that the high water marker is properly set when converting a Squish area back to *.MSG. (Converting *.MSG areas to Squish is not a problem, since Squish will never scan a converted Squish-format message.) Squish v1.11 Reference Manual - Page 108 SQSET: Control for message deletion The SQSET utility is used to manually update the "maximum message limit" and "protected messages" for a given message area. These limits can be set automatically in SQUISH.CFG using the -$m and -$s flags in SQUISH.CFG, but some users may prefer to set these limits from the OS prompt. The command-line format of SQSET is as follows: SQSET <area> [<max_msgs> [<skip_msgs>] [<days_to_keep>]] <area> specifies the path and root filename of a Squish-format message area. <max_msgs> specifies the maximum number of messages to keep in this area at one time. The next time a message is written to this area, Squish will automatically delete and renumber messages such that there are no more than <max_msgs> in the area. If this parameter is omitted, Squish will simply display the current settings for <max_msgs> and <skip_msgs>. <skip_msgs> specifies the number of messages to skip at the beginning of the area, before starting to automatically delete messages. When <skip_msgs> is used, <max_msgs> must also be specified. When Squish is deleting old messages, this command causes it to only start deleting after the first <skip_msgs> messages. This is useful for keeping "posting rules" as the first message in each area, or for keeping a certain number of messages for an indefinite length of time. <days_to_keep> specifies the maximum age of messages in this area. Any messages which are more than <days_to_keep> days old will be deleted during the next SQPACK run. Squish v1.11 Reference Manual - Page 109 SQINFO: Diagnostics SQINFO is a diagnostics and information utility for Squish-format message areas. SQINFO will walk through both the chain of message frames and also the chain of free frames, displaying information about each message and reporting any errors it comes across. SQINFO can be used to quickly diagnose problems in a Squish-format message area. This program is not required for normal use, so it can be deleted if disk space is at a premium. SQINFO is primarily of interest for third-party utility authors who are writing *.SQ?-compatible programs. The command line format of SQINFO is as follows: SQINFO <area> [-q] [-b] [-e] <area> is the path and root filename of a Squish-format message area. -q is the optional "quick" switch. Instead of displaying a verbose report on each message, SQINFO will simply list the location of each message. SQINFO will still check for and notify the user of errors, since this option simply disables most screen output. -b is the optional "bug-find" switch. When in this mode, SQINFO will display nothing except the area name. SQINFO will still check for errors, but it will not tell you where the error occurred. This mode is useful when checking a large number of areas for problems; simply run "SQINFO <area> -b" over all message areas, and then rerun SQINFO (without the -b) on areas which have problems. -e is the optional "errorlevel" switch. When in this mode, SQINFO will operate as in "bugfind" mode, but it is also geared for batch operation. SQINFO will not prompt the user to press a key, and it will return an errorlevel based on the condition of the base. If the message area is okay, SQINFO returns an errorlevel of 0. If the message area is damaged, SQINFO will return an errorlevel of 1. The -q, -b and -e options are mutually exclusive. Only one of the above switches can be specified on the command line. Squish v1.11 Reference Manual - Page 110 SQREIDX: Repair (minor) SQREIDX is an indexing utility for Squish-format message areas. This utility can be used to correct simple indexing problems, but it is not required for normal use. If more than just the index is damaged (as reported by SQINFO), SQFIX should be used instead. The command-line format of SQREIDX is: SQREIDX <area> <area> should be the path and root filename of the Squish-format message area with the grunged index. SQREIDX will recreate the index for <area> by walking through the message chains in the data file, and then by rewriting the original index. If the index is not the only problem with the area, the full-fledged SQFIX should be used instead. Squish v1.11 Reference Manual - Page 111 SQFIX: Repair (major) SQFIX is a full-fledged restoration utility for Squish-format message areas. Even when run on a heavily-damaged area, SQFIX can recover all of the messages which were not individually damaged. SQFIX is completely automated and requires no operator assistance. The command-line format for SQFIX is: SQFIX <area> <area> is the path and root filename of the message area to be fixed. Squish will automatically restore a damaged fixed area. If the area can be fixed, the old data files will be renamed to <areaname>.XXD and <areaname>.XXI. Squish v1.11 Reference Manual - Page 112 SQFIX32: High-capacity version of SQFIX SQFIX32 is a 32-bit version of SQFIX. SQFIX32 comes in both DOS and OS/2 versions. While the 16-bit version of SQFIX is limited to areas of roughly 5400 messages in size, SQFIX32 can rebuild message areas of almost any size. SQFIX32 has the same command-line format as the regular SQFIX. However, the same restrictions that apply to the 32-bit versions of Squish also apply to SQFIX32. Namely: - To run the DOS version (SQFIX32.EXE), you must be running a 386 or higher processor. SQFIX32.EXE requires the DOS4GW.EXE DOS extender. - To run the OS/2 version (SQFIX32P.EXE), you must be running OS/2 2.0 or above. Please see the section entitled "16-bit or 32-bit? SQ386 and SQ386P" for more information on running 32-bit programs. Squish v1.11 Reference Manual - Page 113 SSTAT: Statistics generation If the Statistics option is enabled in the Squish configuration file, Squish will create a binary statistics log. This log contains a great deal of information, but not in a human-readable format. The SSTAT utility included with Squish is very minimal, but it does provide useful information. SSTAT is more of a billing report generator than an analysis utility; unless you are scanning mail to someone else, SSTAT will not produce any output. However, if your system does scan mail to more than one system, SSTAT is capable of producing a 100% accurate billing report for each system, based on the volume of mail sent to each node that you feed. SSTAT works from a configuration file called SSTAT.CFG. This file must be in the current directory when SSTAT is run, as must SQUISH.STT (the statistics log produced by Squish). SSTAT.CFG is a free-format configuration file, similar in nature to SQUISH.CFG and ROUTE.CFG. At the current time, SSTAT only handles the following two keywords: Track <node> [<nodes>...] This keyword causes SSTAT to track mail for the specified nodes. <node> can be a full-fledged address, including zone, net, node and point number. SSTAT will track all mail which is addressed to that node. Wildcards may NOT be used. Area <tag> [<tag>...] This keyword causes SSTAT to track mail for the specified area tags only. SSTAT will only report mail for the specified areas, and these areas will be the only ones included as part of the billing reports. A sample SSTAT.CFG is included in the distribution archive. After you have customized SSTAT.CFG, let Squish run for a while, and then run SSTAT. If all goes well, and if you are scanning mail to at least one other node, SSTAT should produce a highly- detailed report describing all of the message activity on your system. SSTAT performs two sets of calculations: one set is based on the number of messages sent to each node, while the other is based on the quantity of bytes sent to each node. In most cases, the number representing the quantity of bytes sent is usually more reflective of long-distance telephone charges. Squish v1.11 Reference Manual - Page 114 At the end of the report, SSTAT will include an overall summary with percentage totals, suitable for use in a cost-sharing arrangement. SSTAT uses a sophisticated algorithm for determining the TRUE cost of messages, but in short, the billing scheme works like this: 1) For each area listed in SSTAT.CFG, SSTAT will determine the total quantity of mail (whether that be bytes or messages) that you received in the area. Squish will divide this number by the total quantity of mail received in ALL areas listed in SSTAT.CFG. The result of the division is a percentage for the area; this percentage represents the area as a portion of your total inbound mail. In other words, if you multiply your long-distance charges by this percentage, the result will represent how much it cost to bring in the specified area. 2) For each area listed in SSTAT.CFG, and for each node listed within each area, SSTAT will calculate the total quantity of mail sent to that node for that area. SSTAT will then divide this by the total quantity of mail sent to all nodes within that area. The result of this division represents the percentage of mail (within that area) which is being consumed by the node in question. 3) For each node in each area, the percentage determined in step 2) is then multiplied by the percentage determined in step 1) for that area. This figure now represents the actual percentage that this node must pay for receiving the mail in that area. 4) The percentages for each node are then added up for each area, which represents the percentage total as shown at the end of the billing report. This percentage represents the actual amount that this node should pay for any long- distance charges in a cost-sharing system. Squish v1.11 Reference Manual - Page 115 APPENDIX A - Errorlevels Squish will set one of several errorlevels after termination. The errorlevels currently supported by Squish are: Erl Action 0 No tossing or scanning took place. 1 Error. Squish encountered some sort of fatal error and had to abort. 2 Sent EchoMail. This means that Squish exported one or more EchoMail messages. (This errorlevel is only used when performing "SQUISH OUT" as part of a multipass operation.) 3 Tossed NetMail only. This means that Squish tossed one or more packets, but only NetMail was received. 4 Tossed EchoMail and/or NetMail. This means that Squish tossed one or more packets containing EchoMail (and possibly NetMail). 5 MaxMsgs was reached. This means that Squish reached the MaxMsgs limit when processing mail in a multipass environment. This means that SQUISH SQUASH should be invoked, followed by another round of exporting. With the exception of errorlevel 1, higher errorlevel numbers will take precedence. In other words, if EchoMail and/or NetMail was tossed, but MaxMsgs was also reached, Squish will exit with an errorlevel of 5. Squish v1.11 Reference Manual - Page 116 APPENDIX B - Problem Reporting If you discover a problem in the Squish software package, you are encouraged to report the problem to the author. Problem reports can be placed in the TUB or MUFFIN echomail areas (for Squish and Maximus, respectively). If the problem is urgent, you can also send a NetMail message to the author at 1:249/106. If you encounter a "trap" error with the 32-bit DOS version (or any of the OS/2 versions), information from the register dump should be included when submitting a problem report. Under OS/2 1.x, the screen will be presented right away and will start with a "TRAP 000D". Under OS/2 2.0, you will get a "A program in this session encountered an error" pop-up screen. Cursor down to the "register dump" option and write down the information in the register dump window. Under SQ386, the extender will display "Trap 000d" and the registers will be simply dumped to the console. In all cases, the most important registers to write down are CS and IP (or CS and EIP). If possible, the register values for AX, BX, CX, DX, SI and DI are also helpful. (The 32-bit equivalents are EAX, EBX, ECX, EDX, ESI and EDI.) In addition, you should include any other files needed to recreate the problem, such as SQUISH.CFG, AREAS.BBS, ROUTE.CFG, and any relevant packets or message bases. Squish v1.11 Reference Manual - Page 117 GLOSSARY *.MSG The message format originally used by Fido, also used as the FidoNet standard for local message storage The *.MSG system requires a separate directory for each message area, and a separate file for each message. This makes the *.MSG format inefficient, in terms of both disk space and time. For compatibility reasons, Squish uses the *.MSG format by default. *.SQ? The message format originally used by Maximus. *.SQ? (or "Squish format") uses two files per area; a .SQI file contains a message index, and the other contains the message headers and text. *.PKT The "transport layer" for FidoNet-compatible messages. Packets are used when transferring messages between two different FidoNet systems. Since all systems use the same type of packet, *.PKT can be used to transfer messages between systems which use unlike message bases (such as *.MSG and the QuickBBS/Hudson format). See also "2+" and "StoneAge". 2+ A new, backwards-compatible form of *.PKT files. The original packet design had no allowances for zone and point information; the 2+ packet format corrects this shortcoming. Squish creates 2+ packets by default, but it can also handle StoneAge packets. See also "*.PKT" and "StoneAge". 4D A term used to refer to a full FidoNet address. An address in the form "zone:net/node.point" is called 4D because it allows for four-dimensional addressing. Squish v1.11 Reference Manual - Page 118 archiver An archiver is a program used to compress files. Archivers are very useful in a FidoNet environment, since compressing mail can reduce its size by up to 80%. ARCmail ARCmail refers to both a program from System Enhancement Associates and to a mail compression format. Mail which is compressed using the ARC archiver is referred to as "ARCmail". Similarly, mail compressed with ZIP is called "ZIPmail", mail compressed with LHarc is referred to as "LZHmail", and so on. ArcmailAttach An ArcmailAttach system is a mailer which requires "file attaches" to send compress mail bundles. ArcmailAttach is not specific to the ARCmail compression method; it simply means that a different method is used for creating compressed mail bundles. Mailers such as FrontDoor, InterMail, D'Bridge and Dutchie require the "ArcmailAttach" keyword in SQUISH.CFG. AREAS.BBS A ConfMail-compatible file containing a list of message directories, addresses, and area tags. Squish can use AREAS.BBS, but areas must be declared in SQUISH.CFG to use some of Squish's advanced features. busy flag A semaphore file used in the BinkleyTerm outbound area. Busy flags are used to ensure that two programs do not access the same file at the same time, when running in a multitasking or a network environment. crash A message flavour. Crash means that a message should be sent directly to its destination, with no routing implied. Crash usually implies "send it NOW". Squish v1.11 Reference Manual - Page 119 direct A message flavour. Direct is identical to crash in all respects, except that the message will be governed by your mailer's event schedule. downlink A downlink is a system that receives mail from your system. For example, if 1:1/1 sends mail to 1:1/2 and 1:1/3: 1:1/2 and 1:1/3 are downlinks of 1:1/1. 1:1/1 is the feed for 1:1/2 and 1:1/3. duplicate messages (dupes) A second copy of an EchoMail message. When problems crop up in EchoMail topology, copies of old messages occasionally get dumped into the system. Squish usually detects and stops most duplicate messages. EchoMail A message conferencing system originally devised by Jeff Rush. Squish fully supports the EchoMail format. errorlevel An errorlevel is a number set by a DOS or OS/2 program when that program terminates. This number can be later checked for in a batch or command file, and various actions can be taken based on that number. FD An acronym for the FrontDoor front-end mailer. feed A "feed" is the system which sends you mail for a particular EchoMail area. flavour A 'flavour' (or the American "flavor") is also known as a priority. Flavours can be used to override other routing commands and to explicitly send mail directly to a given node. For more information, see the glossary entries for "hold", "normal", "crash" and "direct". Also see the Squish v1.11 Reference Manual - Page 120 "Leave", "Unleave", "Send" and "Route" commands in the ROUTE.CFG reference. front end A synonym for "mailer". FTS-0001 A document describing the base level of FidoNet compatibility. "FTS" is an acronym for "FidoNet Technical Standard". Squish is compliant with FTS-0001. hold A message flavour indicating that the message in question should be placed on hold for pick-up. host-routed Host-routed means that the messages in question will be sent to the network host (net/0), as opposed to being sent directly to the destination. Squish can optionally perform host routing. leaf node A system which only communicates with one other system when sending and receiving EchoMail. Leaf nodes do not forward EchoMail to other systems. mailer A FidoNet-compatible program which answers the phone and interacts with other systems, which includes transferring files, messages, and system information. Common mailers include BinkleyTerm, FrontDoor and D'Bridge. maximum message limit In Squish-format message areas, a limit can be set on the maximum number of messages to allow in a given area. Once this limit is exceeded, messages will be purged from the beginning of the message area until the message count falls below the maximum. Squish v1.11 Reference Manual - Page 121 net network As part of a 4D network address, a "net" is a small geographical area, usually encompassing a large city and the surrounding area. NetMail NetMail is a direct, point-to-point transfer of private messages. NetMail is analogous to "Email". node As part of a 4D network address, a "node" is a single system or computer within a net. normal A message priority. Normal-flavoured messages can be routed, but if no routing is applied, a normal message will be sent directly to its destination. origin line A control line near the bottom of an EchoMail message. The origin line identifies the origination point of a message. Most origin lines have the following form: * Origin: name (address) where "name" is a brief description of the system, and "address" is a full 4D network address. outbound areas (outbound directories) A set of directories used for storing outbound mail. BinkleyTerm and Opus are the only common mailers which use outbound areas. point As part of a 4D network address, a "point" normally represents a single-user system that connects with a full- fledged network node to receive mail. Squish v1.11 Reference Manual - Page 122 remap Remapping is the process of readdressing inbound messages based on the name in the "To:" field. For example, messages are commonly remapped for points, since the point number may be occasionally omitted when specifying a system address. SEEN-BY A control line at the bottom of an EchoMail message. SEEN- BYs are used to determine which systems have already been sent a particular message. SHARE.EXE A DOS program used to enable file locking. SHARE must be loaded if you wish to use Squish-format message areas in a multitasking environment. SHARE is only required for DOS systems. StoneAge A term applied to the original *.PKT design. StoneAge packets do not support zone or point information. See also "2+" and "*.PKT". tear line A control line at the bottom of an EchoMail message. A tear line is used to end the message body, and it usually contains a short, product-specific banner. A tear line begins with three dashes, such as "--- Squish v1.10". wildcards Squish uses wildcards to specify multiple nodes for routing commands. For more information, please see the section entitled "Wildcards". zone In a 4D network address, a "zone" is a wide geographical area, usually covering one continent or more. Squish v1.11 Reference Manual - Page 123 zonegate A zonegate is a system which sends EchoMail to more than one zone. Squish is capable of acting as a zonegate. Squish v1.11 Reference Manual - Page 124 INDEX .MO? . . . . . . . . . 70, 83 99, 101, 118, 122, -$ . . . . . . 80-82, 102-104 123 -$m . . 81, 102, 103, 106, 109 Address . . . . . . . . . . 21 -$s . . . . . . . . . 81, 109 alternate primary -+ . . . . . . . . . . 80, 96 address . 79, 80, 96 -0 . . . . . . . . . . . . 80 ARC . . . 29, 61, 71, 83, 119 -a . . . . . . . . . . 47, 57 archive . . 18, 30-33, 35, 48, -c . . . . . . . . . . . . 47 66, 67, 69, 72, -f . . . . . . 43, 47, 50, 79 83-85, 114 -l . . . . . . . . . . 44, 48 archiver . 5, 22, 30, 32, 72, -o . . . . . . . . . . 48, 68 83, 84, 119 -p . . . . . . . . 41, 79, 96 ARCmail . 40, 41, 43, 56, 57, -q . . . . . . . . . 48, 110 64, 66, 67, 69, 78, -s . . . . . . . . 48, 80, 88 85, 95, 119 -x . . . . . . . . . . 80, 95 ARCmail bombs . . . . . . . 95 -z . . . . . . . . . . . . 49 area tag 13, 24, 25, 28, 53, *.?LO . . . . . . . . . 65, 91 76, 78 *.?UT . . . . . . . . . . . 91 Areafix . . . . . . . . . . 82 *.BAD . . . . . . . . . . . 94 AREAS.BBS . 5, 18, 19, 21, 22, *.FR? . . . . . . . . . . . 83 26-28, 47, 49, 53, *.MO? . . . . . . . . . . . 83 57, 60, 70, 75, 79, *.MSG . . 4, 5, 7, 15, 24, 25, 82, 98, 101, 102, 27, 28, 53, 74, 78, 117, 119 79, 99, 100, 102, AreasBBS . . . . . . . 21, 57 103, 104, 107, 108, ARJ . . . . . . . . . . 61, 83 118 AUTOEXEC.BAT . . . . . . . 20 *.OUT . . . . . . . . . 12, 48 BAD_MSGS . 24-26, 76, 78, 80, *.PKT . 4, 11-13, 21, 42, 58, 94 68, 80, 83, 118, batch file . . . . 38-41, 67 123 BINKLEY.EVT . . . . . . . . 38 *.SA? . . . . . . . . . . . 83 BinkleyTerm . 4, 5, 7, 11, 12, *.SQ? . . 4, 5, 7, 15, 53, 74, 18, 21, 22, 35, 38, 78, 80, 81, 100, 43, 48, 54, 56-58, 103, 107, 110, 118 60, 61, 69, 70, 72, *.SQD . . . . . . . . . . 106 78, 85-87, 91, 92, *.SU? . . . . . . . . . . . 83 93, 98, 119, 121, *.TH? . . . . . . . . . . . 83 122 *.TU? . . . . . . . . . . . 83 BinkleyTerm 2.50 . 5, 58, 98 *.WE? . . . . . . . . . . . 83 bossnode . 5, 11, 55, 72, 98 ^aFLAGS . . . . . . . . . . 69 busy flag . . . . 60, 61, 119 ^aPATH . . . . . . . . 79, 96 Change . . . . . . 86, 89, 92 <areaname>.XXD . . . . . 112 comment . . . . . . . . . . 35 <areaname>.XXI . . . . . 112 Compress . . . . . . . . . 22 <areaname>.XXI. . . . . . 112 COMPRESS.CFG 18, 22, 71, 72, 1.MSG . . . . . . . . . . . 43 83, 84 2+ . . . 5, 56, 99, 118, 123 CONFIG.SYS . . . . 20, 21, 46 4D 5, 11, 21, 34, 55-58, 72, ConfMail . . . . . . 57, 119 73, 79, 86, 96, 98, crash . . . 12, 29-34, 36, 37, Squish v1.11 Reference Manual - Page 125 44-46, 55, 63, 75, host-routed . . . . . . . 121 87, 89, 90, 92, HostRoute . . . . . . . 92, 93 100, 119, 120 Imail . . . . . . . . . . . 98 D'Bridge 21, 56, 69, 98, 119, InterMail . 5, 21, 56, 60, 98, 121 119 decompress . . 18, 38, 40, 58 label . . . . . . . . . 39, 40 direct 12, 29-31, 44, 63, 75, LAN . . . . . . . . . . . 101 92, 103, 120, 122 LHarc . . . . . . 61, 83, 119 Dos . . . . . . . . . . . . 88 link . 4, 39, 40, 43, 46, 47, dupe . . . 4, 54, 61, 62, 104 50, 94 DUPES . . . . 25, 65, 77, 120 mailer 5, 11, 29, 31, 33, 35, duplicate 25, 60, 62, 65, 78, 38-40, 56, 60, 67, 102, 120 69, 93, 95, 119, dynamic packing . . . . 56, 85 120, 121 dynamic routing . 31, 35, 57, mailers . 12, 13, 33, 56, 57, 85, 93 60, 63, 69, 85, 93, ECHOTOSS.LOG 41, 44, 47, 48, 98, 119, 121, 122 50 MAX_MSGS.DAT . . . . . . . 68 errorlevel . 38-41, 67, 110, maximum message 116, 120 limit100-102, 109, EXCEPT 1, 2, 39, 41, 44, 64, 121 75, 76, 92, 104, Maximus . 1, 3, 4, 13, 18, 22, 110, 120 38, 40, 65, 101, exceptions . . . . . . . . 64 102, 106, 117, 118 fakenet 5, 55, 72, 73, 98, 99 multi-line . . 6, 47, 48, 60 FD . . . . . 18, 39, 40, 120 multi-zone . . . . 4, 22, 80 feed 14, 27, 28, 96, 114, 120 multipass 42, 48, 50, 51, 60, FidoNet . 3-5, 10, 11, 13-15, 67, 74, 99, 116 21, 36, 61, 64, 71, name wildcards . . . . . . 73 77, 98, 100, 118, NEC . . . . . . . . . . . . 67 119, 121 net . . . 10, 11, 21, 24, 27, file attaches 22, 54, 56, 57, 32-36, 44, 56, 72, 64, 78, 86, 92, 119 77, 80, 86, 89, 92, file requests . . . . . 57, 64 93, 98, 102, 114, flavour 12, 29-33, 35-37, 44, 118, 121, 122 54, 55, 63, 85, 86, NetMail . . . 11, 13, 14, 21, 91-93, 119-121 24-26, 29, 35, 36, front end . . . . 15, 21, 121 38, 40, 41, 43, FrontDoor . 4, 7, 11, 18, 21, 46-48, 54, 56, 57, 22, 38-40, 43, 56, 63-65, 67-69, 73, 93, 98, 119, 120, 76, 78, 79, 97, 99, 121 116, 117, 122 FTS-0001 . . 63, 79, 100, 121 NoArc . . . 68, 86, 87, 93, 95 gateroute . . . . . 57, 63, 64 node . 5, 10, 11, 15, 21, 27, gaterouting . . . . . . 63, 64 28, 30, 31, 32-36, global section 29, 30, 85, 88 43-46, 49, 54-56, hold . 7, 12, 24, 29-31, 44, 60, 61, 63, 64, 66, 46, 50, 54, 55, 63, 71-73, 75, 76, 77, 74, 75, 89, 90, 92, 79, 80, 82, 83, 85, 99, 120, 121 86, 90-96, 98, 99, Squish v1.11 Reference Manual - Page 126 102, 104, 105, 114, RESCAN . . . . . . 43, 44, 46 115, 118, 120-122 root filename . . 53, 78, 80, NoPkt . . . . . . . . . 68, 95 101, 107, 109-112 normal 12, 13, 23, 29-33, 35, ROUTE.CFG . 18, 29-33, 35, 41, 36, 44, 46, 54, 55, 57, 63, 74, 83, 85, 63, 65, 79, 85-87, 88, 89, 114, 117, 92-94, 99, 104, 121 110, 111, 120, 122 Define . 10, 18, 26, 54, Opus 1.03 . . . . . . . . . 70 78, 83, 87 origin line . 22, 23, 27, 28, Leave . 22, 44, 48, 69, 53, 70, 72, 102, 91, 121 122 Poll . . . . . 46, 90, 92 OS/2 4, 6, 7, 16, 17, 20, 45, Route 12, 18, 29-37, 41, 52, 62, 84, 88, 46, 54, 55, 57, 63, 113, 117, 120 69, 74, 83, 85-89, OUT . 2, 4, 5, 10, 12, 13, 21, 92, 93, 114, 117, 29, 36, 38-43, 121, 31, 32, 83, 46-51, 54, 58, 60, 86, 87 61, 67, 74, 75, 80, Sched 30, 48, 85, 88-90 86, 87, 93, 98, 99, Send . 30-32, 36, 37, 54, 105, 106, 116 83, 85 outbound area . 5, 21, 22, 48, Unleave . . . . 91, 121 54, 58, 60, 86, 87, routing . . 4, 10, 12, 18, 22, 91-93, 119 26, 27, 29, 30, outbound directories 57, 60, 31-33, 35, 36, 38, 70, 71, 91, 122 43, 55, 57, 63, 69, OUTBOUND.### . . . . . . . 22 74, 75, 85, 87-93, OUTBOUND.SQ . 44, 48, 57, 68, 119-123 69 scan . . . 13, 32, 38, 40-43, packet . 5, 7, 11-13, 29, 32, 46-50, 54, 67, 69, 43, 48, 50, 56, 60, 73, 86, 104, 105, 65, 68, 69, 72, 74, 108, 114 86, 94, 99, 118 schedule 29, 48, 85, 88, 89, PAK . . . . . . . . . . 61, 83 120 passthru . 4, 27, 42, 47, 49, SEAdog . . . . . . . . . . 63 53, 80 secure mode . . . . 49, 61, 94 point . . 4, 5, 8, 10, 11, 17, security 61, 72, 74, 78, 80, 21, 27, 28, 32, 94, 95, 105 55-58, 65, 67, 69, SEEN-BY . 74, 76, 99, 101, 123 72, 73, 77, 79, 86, semaphore . . . . . . . . 119 96, 98, 99, 114, SHARE.EXE . . . . . . 20, 123 118, 122, 123 single pass . 42, 43, 46, 50, point directory . . . . . . 5 67, 74, 80 primary address . 27, 55, 56, soundex . . . . . . 5, 69, 73 79, 80, 96 split area . . . . . . . . 82 private messages 10, 24, 80, SQFIX . . . . . . 100, 111-113 122 SQINFO . . . . . . . 110, 111 quiet mode . . . . . . . . 48 SQPACK . . 81, 103, 106, 109 remapper . . . . . 5, 73, 99 SQREIDX . . . . . . . . . 111 reply chains . . . 40, 43, 46 SQSET . . . . . . . . . . 109 Squish v1.11 Reference Manual - Page 127 SQUASH 39-41, 43, 46-48, 50, Origin . . 22, 23, 26-28, 57, 60, 67, 68, 69, 53, 70, 72, 96, 85, 88, 89, 116 102, 104, 122 SQUISH . 1-9, 11, 13-22, 24, Outbound . 4, 5, 21, 22, 26-36, 38, 39, 29, 33, 43, 44, 48, 40-50, 52-121, 123, 50, 54, 55, 57-60, 124 67-71, 74, 86, 87, SQUISH.CFG 18-21, 24, 26, 27, 91-93, 96, 99, 119, 32, 33, 47, 48, 49, 122 53-56, 64, 69-71, Pack . . . . . 61, 71, 72 75, 79, 82, 83, Password 44, 45, 69, 72, 94-99, 101-103, 94 109, 114, 117, 119 PointNet . . . 55, 72, 98 AddMode . . . . . . . 54 QuietArc . . . . . . . 73 Address . . . . . 55, 97 Remap . 54, 73, 74, 99, AddToSeen . . . . . . 56 123 ArcmailAttach . 21, 29, SaveControlInfo . . . 74 31, 33, 35, 44, 45, Secure . 48, 49, 61, 69, 56, 57, 60, 65, 67, 74, 94, 95 69, 70, 73, 78, 85, Statistics . 49, 60, 65, 91, 93, 119 66, 74, 75, 106, BadArea . . . . . 24, 78 114 BatchUnarc . . . . 58, 68 StripAttributes . . . 75 BinkPoint . . . . 57, 58 Swap . . . . . . . 5, 75 Buffers . . . . . . . 58 TinySeenBys . . . . . 76 BusyFlags . . . . . . 60 TossBadMsgs . . . 49, 76 CheckZones . . . . . . 61 ZoneGate . . 64, 77, 124 Compress . . . 22, 61, 83 SSTAT . . . . . . 74, 114, 115 DefaultPacker . 61, 71, Track . 42, 76, 77, 114 83, 61 SSTAT.CFG . . . . . . 114, 115 DupeArea . . . . . 25, 78 StoneAge . . . . . . 118, 123 Duplicates . 60, 62, 104 tag . . 13, 24-28, 44, 53, 76, EchoArea 26, 27, 55, 76, 78, 79, 88, 89, 114 78, 82, 95, 96, tear line . . . . . . . . 123 102, 104 toss 24, 38, 40, 42, 46, 50, ForwardFrom . . . . . 63 58, 67, 68, 76, 94 ForwardTo . . . . . . 63 TosScan . . . . . . . . . . 98 GateRoute . . 57, 63, 64 update requests . . . . 57, 64 KillBlank . . . . . . 64 wildcard . . . . . . . 32, 33 KillDupes . . . . 65, 78 World 10, 11, 32, 33, 35, 37, KillIntransit . . . . 65 73, 93 LogFile . 22, 48, 65, 77 ZIP . . . . . 29, 45, 83, 119 MaxAttach . . . . 60, 67 zone . 4, 5, 10, 11, 21, 22, MaxMsgs . 43, 48, 66-68, 27, 32-34, 55, 61, 116 63, 64, 70, 71, 75, MaxPkt . . . . . . 60, 68 77, 79, 80, 86, 89, NetArea . . . 24, 57, 78 90, 96, 99, 102, NetFile . 21, 42, 68, 95 107, 114, 118, 123, Nuke . . . . . . . . . 69 124 OldArcmailExts . . . . 70 Squish v1.11 Reference Manual - Page 128 zoned outbound directories . 57, 60 zonegating . . . . . . . . 77 ZOO . . . . . . . . . . 61, 83 Squish v1.11 Reference Manual - Page 129