; ; ; ; ; ; ; +-- +--+ - - --- +--- - - ; | | | | | | | | | ; +-+ | | | | | +--+ +--+ ; | | \| | | | | | | ; --+ +--\ +--+ --- ---+ - - ; ; ---------------------------------------------------- ; The Maximus-CBCS Tosser/Scanner/Packer, Version 1.00 ; ---------------------------------------------------- ; ; ; ; ; ; ; ; ; ; The 'Address' keyword specifies the network addresses of your ; system. ; ; ---------------- ; FOR NORMAL NODES ; ---------------- ; ; Your FIRST address should be your primary address. By default, ; this will be used for all outgoing mail. You can specify ; additional addresses after the first, but they will simply ; be used as AKAs. Any number of addresses may be specified, ; limited by available memory. Address 1:103/705 Address 1:3615/51 ; ------------------ ; FOR FAKENET POINTS ; ------------------ ; ; Squish can be used in a Binkley-style "fakenet" configuration. ; However, the format for specifying addresses is slightly different. ; ; The FIRST address specified must be your fakenet address, including ; the zone. ; ; The SECOND address must be your full 4-dimensional network address, ; including your point number. The third and subsequent addresses will ; be treated as AKAs. ; ; Fakenet points must also use the 'Pointnet' verb, later in this ; configuration file. ; ; For a point at 1:123/456.1 (with a fakenet address of 23914/1), the ; following configuration would be used: ; ; Address 1:23914/1 ; Address 1:123/456.1 ; ; ------------- ; FOR 4D POINTS ; ------------- ; ; This feature can only be used if both you and your boss are running ; 4D-aware packers AND 4D mailers. ; ; Most mailers support 4D points, but BinkleyTerm (version 2.40 or ; below) does not. Others, such as FrontDoor, InterMail, D'bridge, and ; BinkleyTerm 2.50+ can handle 4D points correctly. ; ; In addition, you and your boss must be running 4D-compatible ; packers and scanners. Most packers and scanners are NOT fully ; 4D. As of this writing, the most common 4D tossers/scanners/packers ; are TosScan, Imail, GEcho and (of course) Squish. ; ; Unless both you and your boss satisfy all of these requirements, ; you must use a fakenet point instead. ; ; For 4D points, simply include your full 4D address. Any addresses ; after that will simply be considered as AKAs. ; ; For a point at 1:123/456.1, the following configuration would be used: ; ; Address 1:123/456.1 ; The 'NetFile' keyword tells Squish where your mailer places ; received packets and ARCmail packages. You can specify as many ; NetFile paths as you like, and Squish will search each of them ; when invoked with 'SQUISH IN'. ; ; The NetFile keyword has two modifiers: 'NoPkt' and 'NoArc'. The ; 'NoPkt' modifier instructs Squish NOT to toss *.PKT files from ; the specified path. The 'NoArc' modifier instructs Squish NOT ; to toss ARCmail bundles from that path. These modifiers may ; be useful for a tri-level security scheme, such as that which ; is offered by BinkleyTerm. NetFile c:\im\Inbound ;NetFile C:\Inbound\Prot ;NetFile NoArc C:\Inbound\Known ;NetFile NoArc NoPkt C:\Inbound\Unknown ; The 'AreasBBS' keyword tells Squish where to find a standard-format ; AREAS.BBS file. NOTE: using AREAS.BBS is optional! If you ; have no other utilities which use AREAS.BBS, it may be easier ; to comment out this keyword and to use the 'EchoArea' keyword ; to define areas in this configuration file. (See later in ; this file for more details.) AreasBBS n:\im\system\Areas.BBS ; The 'ArcmailAttach' keyword instructs Squish to use ; FroDo/IM/D'bridge-style message handling. This is compatible with ; most other mailers which use an 'attach message' to send archives. ; ; This keyword is NOT required for systems running BinkleyTerm, ; Opus, or any other programs which use an 'outbound directory'. ; ; When this keyword is uncommented, Squish will generate *.MSG ; attach messages instead of Binkley-style *.?LO files. This keyword ; also disables most of the routing commands in ROUTE.CFG. ; ; EVEN IF 'ArcmailAttach' IS ENABLED, YOU MUST STILL USE THE ; "SQUISH SQUASH" COMMAND AND HAVE A VALID ROUTE.CFG! ; ; When ArcmailAttach is defined, the `squash' phase of processing ; will be used to build attach messages, as opposed to scanning ; the outbound area. ROUTE.CFG is still required, but since most ; mailers will perform dynamic routing, its importance is minimal. ; Please see the comments in ROUTE.CFG for information on routing ; and ArcmailAttach systems. ArcmailAttach ; If you're running BinkleyTerm 2.50 or above, the BinkPoint ; keyword can be enabled. BinkPoint enables the Binkley 2.50+ ; "point directories", which allows for full 4D point support. ; If you wish to run 4D points on a Bink system, you must be ; running Binkley 2.50 or greater, and this keyword must be ; enabled. ;BinkPoint ; The 'Compress' keyword gives the name of a compression configuration ; file. Squish's compression is extremely flexible, and support for new ; archiving programs can be added at any time. For most people, the ; default COMPRESS.CFG is all that is required. Compress Compress.Cfg ; The routing control file is used to control Squish's operation during ; the 'Squash' phase of processing. ; ; --> THIS KEYWORD IS ALWAYS REQUIRED, EVEN FOR ARCMAILATTACH SYSTEMS! <-- ; --> PLEASE SEE THE COMMENTS IN ROUTE.CFG FOR DETAILS! <-- Routing n:\im\Route.Cfg ; When not using 'ArcmailAttach', the Outbound keyword tells Squish where ; to find your Binkley-style outbound area. This should always be the ; name of your PRIMARY outbound area, without an extension. Squish ; will dynamically create outbound areas as necessary for other zones, ; so only the primary directory name is required. ; ; If 'ArcmailAttach' is being used, THIS KEYWORD IS STILL REQUIRED! ; In this case, the Outbound directory should point to a scratch ; area which Squish can use to build and store compressed mail packages. Outbound n:\im\Outbound ; The 'LogFile' keyword instructs Squish to keep a log of its activities. ; This log is written using a Max/Bink/Opus-compatible format, so the ; same logfile name can be used for both Max and Squish. LogFile Squish.Log ; The 'Origin' keyword is used to specify a default origin line for ; EchoMail areas. This option is only required if you're NOT using ; an AREAS.BBS, since Squish can normally obtain the origin line ; from that file. ; ; This origin line will be added to local messages which were created ; without an origin or tear line. ; ;Origin No-name BBS - (111) 222-3333 ; The 'Secure' keyword instructs Squish to check the addresses on all ; echomail messages it receives, and causes it to reject unsolicited ; messages. This means that only only those nodes which are listed ; in AREAS.BBS (or your EchoArea lines) will be able to send echomail ; messages to your system. ; ; If a message is received from a system which is not listed for ; a particular message area, the message will be placed in your ; BadArea and noted in the logfile. Secure ; The 'CheckZones' keyword instructs Squish to check the zone number ; on all incoming messages, and to treat different zones as distinct ; entities. ; ; This is normally desired; however, several older software packages ; do not support zones, and as such, Squish may find a 'random' ; zone number in packets it receives from other systems. ; ; If this keyword is commented out, Squish will ignore zone numbers ; when tossing messages. CheckZones ; The 'QuietArc' keyword instructs Squish to suppress the screen output ; of external compression programs. This is useful for reducing screen ; clutter, especially when packing mail for a large number of nodes. ; ; NOTE: this keyword will not suppress the screen output for LHarc 2.xx. ; For whatever reason, the author of LHarc wrote the program in such ; a way that screen output cannot be easily eliminated. ;QuietArc ; The 'Duplicates' keyword defines the number of duplicate message IDs ; that Squish will keep for each individual area. By default, Squish ; keeps 1000 IDs for each area, which should be acceptable for the ; majority of other systems. ; ; Unlike most other software, Squish uses a safe 64-bit ID to identify ; messages as dupes. Due to a few other factors, Squish's advanced ; dupe checking technology almost never identifies messages as false ; duplicates, so raising this number will not adversely impact mail ; reliability. Duplicates 2000 ; The 'KillDupes' keyword instructs Squish to delete duplicate messages ; as they are tossed. This provides for efficient use of disk space ; (if a large packet of dupes is received from your uplink), but it ; leaves the operator with no way to determine the cause of the dupes. ; ; By default, KillDupes is off, and duplicate messages will be placed ; into your DupeArea. KillDupes ; The 'KillIntransit' keyword instructs Squish to delete in-transit ; netmail. This means that netmail NOT addressed to your system will ; be deleted after it is packed. ;KillIntransit ; The 'KillBlank' keyword instructs Squish to delete blank netmail ; messages, or netmail messages which do not have a message body. ; Such messages are generated by some D'bridge systems, in addition ; to manually-generated file requests and file attaches. KillBlank ; The 'Password' keyword is used to specify a password for outgoing ; packets. In addition, if 'Secure' mode is enabled, Squish will ; also check incoming packets for the specified password, and it will ; reject and rename packets with invalid passwords. Passwords are ; case insensitive, and they must be eight characters or less. ; Address Password ; ----------- -------- ;Password 1:249/106.2 Boffo ;Password 1:225/1 Gnarly ; The 'Pointnet' verb is used to support fakenet-style points. This ; keyword must be used by BOTH fakenet bosses and fakenet points. ; Simply specify your pointnet number, and Squish will automatically ; convert pointnet addresses and strip SEEN-BYs as necessary. This ; option is not required if you are a 4D point, or if you are a boss ; and only feed 4D points. If you are a boss which supports BOTH ; 4D and fakenet points, then this keyword is still required. ;Pointnet 12345 ; The 'Track' keyword instructs Squish to keep a log of forwarded netmail ; messages, including the header information (to/from/subject). ; This command in not a replacement for external utilities such as ; MsgTrack, but it can be used as a quick means of finding out who is ; forwarding netmail through your system. ; ; WARNING! This keyword must point to a SEPARATE log file. You cannot ; use the same logfile for both Track and LogFile. Track MsgTrack.Log ; The 'Pack' keyword tells Squish to use the specified compression method ; when compressing mail for the specified nodes. ; ; The first word following 'Pack' must be a valid compression type, as ; specified in COMPESS.CFG. (The compression types supported by ; the distribution version of Squish are ARC, PAK, ZIP, LHARC, LH113, ; ZOO and ARJ. However, more archivers can be easily added when ; they become available.) ; ; Any number of nodes may be specified after the compression type, and ; 'All' may also be used to specify a broad range of systems. If no ; compression type is specified for a given node, then the default ; compression method will be used. (See below.) ; ; NOTE! Older programs, including QMail 1.00, do not support the LHarc 2.xx ; compression format. For this reason, the 'LH113' compression format ; is provided; this instructs LHarc to create archives in compatibility ; mode. If your feeds are running QM 1.00, you must specify the ; LH113 method instead of LHarc. ; ;Pack Zip 1:24906/All 249/102 104 106 108 2:2/1 ;Pack LHarc 1:249/112 116 ;Pack LHarc 2:222/123 500/All ; The 'DefaultPacker' specifies the name of the compression program to ; use for nodes not lisited in any of the 'Pack' statements. ; ; WARNING! The official FidoNet standard for mail compression is ; ARC. Unless you have a very good reason for using a different ; compression method, you should leave this keyword alone to ensure ; maximum compatibility. DefaultPacker Zip ; The 'SaveControlInfo' keyword instructs Squish to keep the SEEN-BY and ; PATH control information inside the message database. This command ; will ONLY be applied to Squish-type areas, and will ONLY be used when ; running in a one-pass "IN OUT" mode. The SEEN-BYs and PATH lines will ; always be retained when running in multi-pass mode. This option ; can be used to save space on your hard drive. SaveControlInfo ; The 'ForwardTo' keyword tells Squish that it has permission to forward ; messages which are destined to the specified nodes. If you add the ; modifier 'File' after 'ForwardTo', then Squish will also forward ; file attaches to the specified nodes as well. ; ; To forward ALL mail passing through your system, simply ; use 'ForwardTo WORLD'. ; ; For ArcmailAttach systems, your mailer handles the routing of files. ; This keyword is not needed for such systems. ;ForwardTo 1:249/0 1 9 106 126 229/414 24906/All ;ForwardTo File 1:249/122 ; The 'ForwardFrom' keyword uses the same syntax as ForwardTo, except it ; it tells Squish to allow messages coming from the specified nodes to ; be forwarded ANYWHERE. When used with the 'File' modifier, this ; command is considerably more dangerous than ForwardTo, since it ; effectively gives the specified nodes a blank cheque, since they ; will have the ability to send large files through your system, ; possibly to a long-distance number. Normally, this option should ; only be used for points or trusted individuals. ; ; For ArcmailAttach systems, your mailer handles the routing of files. ; This keyword is not needed for such systems. ;ForwardFrom 1:24906/All 249/99 ;ForwardFrom File 1:249/108 ; The 'TinySeenbys' verb tells Squish to use "tiny" SEEN-BYs for the ; specified list of nodes. This means that Squish will strip off all ; excess node numbers when exporting a message, and it will only add the ; node numbers of the systems that are defined for each echo area. ; ; This keyword can significantly reduce the size of output packets, ; especially if Squish is processing widely-distributed EchoMail ; areas. ;TinySeenbys 249/199 2:123/456 ; The 'Remap' keyword can be used to automatically forward messages to ; points. If a message arrives on your system which is addressed to one ; of your 'Address' statements, Squish will compare the message's ; "To:" address with each of the names listed below. If a match is ; found, Squish will forward the packet manually, and readdress the ; message to the specified point. ; ; In addition, the '*' character functions as a wildcard, and can be used ; to remap mail which is addressed using only a partial name. ; ; NOTE! If you are using fakenet points, make sure to specify the ; full fakenet address! Similarly, if you are using 4D points, make ; sure that you use the full 4D address. The address you specify doesn't ; have to be a point address, but if you are using a point address, you ; should make sure to specify the correct one. ; ; FOR BOSSES OF FAKENET POINTS ONLY: ; ;Remap 24906/2 Mark Kaye ; Remap messages for Mark Kaye to point 2 ;Remap 24906/3 Kevin Kell ; Remap messages for Kevin Kell to point 3 ;Remap 24906/1 Scott* ; Remap messages starting with 'Scott' to ; ; point 1. ; ; FOR BOSSES OF 4D POINTS ONLY: ; ;Remap .2 Mark Kaye ; Remap messages for Mark Kaye to point 2 ;Remap .3 Kevin Kell ; Remap messages for Kevin Kell to point 3 ;Remap .1 Scott* ; Remap messages starting with 'Scott' to ; ; point 1. ; The 'AddToSeen' keyword instructs Squish to add a particular node number ; to the SEEN-BYs for all echomail areas that your system receives. ; (Note: it is possible to add SEEN-BYs on an area-by-area basis. See ; 'EchoArea' below for more details.) ; ; The node numbers you specify here will be added to each and every ; message that passes through your system. This is usually not required, ; except when changing primary addresses. ;AddToSeen 250/814 820 ; The 'GateRoute' keyword is used to send inter-zone messages through ; the zonegate. Since this is declared in SQUISH.CFG, this will gateroute ; ALL netmail messages going through your system to the specified ; addresses. This command is only useful when NOT using ArcmailAttach. ; ; GateRouting is only required by other brain-dead packers which ; do not properly understand zones. If you're using the low-priority ; netmail routing scheme, it's probably safe to use a normal ; 'Route' command in ROUTE.CFG. However, when sending directly to ; any of the official zonegates, it's best to use the GateRoute method. ; ; After the word 'GateRoute', you must specify a flavour to use for ; the resulting gaterouted package. This will be placed into the ; appropriate .?UT message bundle. ; ; Following the message flavour is the 'host node'. This is where ; all of the gaterouted messages will be sent. ; ; After the host node comes the 'route-to' nodes. You can specify any ; number of nodes after the host, and you can even use the 'All' ; wildcards. ; ; If you wish to except certain nodes from gateroute processing, include ; the word 'Except', followed by any nodes whose mail you do NOT wish ; to gateroute. ; ; The following will work for standard gaterouting within zone 1: ; ;GateRoute Normal 1:1/2 2:All ;GateRoute Normal 1:1/3 3:All ;GateRoute Normal 1:1/4 4:All ;GateRoute Normal 1:1/5 5:All ;GateRoute Normal 1:1/6 6:All ; ; If you were connecting directly with a particular node in zone 2, and ; you did not want that node's mail to be gaterouted, you could use the ; following sample gateroute line: ; ;GateRoute Normal 1:1/2 2:All Except 2:123/456 ; The 'BusyFlags' keyword instructs Squish to use the BinkleyTerm ; *.BSY flags in the outbound area. These flags are a must when ; Squish is running in a multitasking or network environment, since ; they stop Squish and Binkley from trying to access the same ; bundle at the same time. ;BusyFlags ; The 'OldArcmailExts' keyword should be used when communicating with ; older systems, such as Opus 1.03. Early versions of Opus did ; not understand the *.TU?, *.WE?, and other day-of-week extensions ; when performing a WaZOO session, so sending compressed archives ; using the new ARCmail extensions may cause the remote end not ; to unpack mail right away. This keyword instructs Squish to ; use only the .MO? extension. ;OldArcmailExts ; The 'TossBadMsgs' keyword instructs Squish to "toss" messages from ; your BadArea, every time a SQUISH IN is performed. Squish will ; skim all of the message in the area, and it will attempt to toss ; each one. ; ; This feature is extremely useful if you request an area, but forget ; to add the echo to your configuration files. The messages for that ; area would end up in your BadArea; with TossBadMsgs enabled, ; once you add that area to your configuration, messages will be ; tossed from your BadArea just as they would from a .PKT file, ; thereby saving you a lot of manual message moving. ;TossBadMsgs ; The 'BatchUnarc' keyword instructs Squish to decompress all compressed ; mail archives at the same time, and to start tossing the packets after ; all of the archives have been decompressed. ; ; Using BatchUnarc requires slightly more space, but it also prevents ; messages from getting out of order. Squish will toss packets accoring ; to their dates, but if Squish only tossed mail from one archive at ; a time, the dates can get mixed up. If you don't send mail to ; anyone else, you probably don't need to use this. However, if you're ; sending one or more echoes to other systems, using BatchUnarc is ; probably a good idea. ;BatchUnarc ; The 'ZoneGate' command instructs Squish to perform special conversions ; on messages addressed to the 'zonegate node'. When sending an ; echomail conference across zones, SEEN-BYs must be stripped from ; messages, since net/node numbers may be duplicated among different ; zones. ; ; This command provides an FTSC-0004 compliant method to gate conferenes ; between zones. The format for the ZoneGate command is as follows: ; ; ZoneGate ; ; The is the address of the system which you are gating for. All ; echomail messages addressed to this system will have their SEEN-BYs ; stripped. ; ; is a list of nodes which are to be added to the SEEN-BYs, ; after the original set of nodes is stripped. WARNING: Squish does ; NOT automatically add your address or the host's address to ; the SEEN-BYs, so you must include your address and the other system's ; address, at a bare minimum. Other nodes can be added to the SEEN-BYs ; for safety purposes. ; ; NOTE: ZoneGate is a potentially dangerous command. If you do not ; know exactly what you're doing, this command should be avoided. ;ZoneGate 2:253/68 249/106 253/68 ; The 'Statistics' keyword instructs Squish to keep a statistics file, ; based on mail sent and mail received. These statistics are extremely ; verbose, but they are also extremely accurate. An external program ; can be used to read the SQUISH.STA file, and to generate a 100% ; accurate billing report for the specified nodes. ; ;Statistics ; The 'StripAttributes' keyword instructs Squish to strip the message ; flavour attributes (CRASH and HOLD) from incoming netmail messages. ; Stripping these attributes prevents someone from routing a CRASH ; message through your system, and then having your system deliver ; the message as CRASH as well. StripAttributes ; The 'AddMode' keyword instructs Squish to "add" to existing .?LO files. ; Normally, when Squish wants to send a message or file to a particular ; node, it will use the exact flavour specified in the routing control ; file. However, AddMode instructs Squish to check the outbound area ; first, and if a flavoured file attach exists (such as CRASH, HOLD or ; DIRECT), the file will be added to that file attach instead. ; ; This is useful if a specified set of routing commands is normally used, ; but if exceptions must be made. In other words, a node may be marked ; Crash, but if that node goes down for a period of time, it may be ; desirable to keep that node's mail on hold. When AddMode is enabled, ; simply change the flavour of the existing attach to HOLD, and all future ; attaches will also be made as HOLD (regardless of the original flavour), ; until the HOLD file attach is picked up. ;AddMode ; The 'MaxMsgs' keyword instructs Squish to stop scanning after 'x' ; messages have been reached, to pack the resulting packets into an ; archive, and to continue scanning from where it left off. This ; feature can help in situations where disk space is at a premium, ; or where the size of the output .PKT files is to be kept small. ; ; When running in "IN OUT SQUASH" mode, the MaxMsgs feature is ; automatic. However, when the OUT and SQUASH phases are separated, ; some batch file magic is required. Please see the documentaton ; for information on using MaxMsgs in separate passes. ; ; The number after MaxMsgs specifies the number of messages to ; process before taking a break and archiving the output. A number ; of around 100 messages usually yields packets of about 75K in ; size, assuming a normal backbone load. This number can be increased ; or decreased, depending on your processing requirements. ;MaxMsgs 150 ; The Swap keyword (DOS only) instructs Squish to swap itself out to ; XMS/EMS/disk before spawning the compression programs. This frees ; up all but 3k of the memory that Squish normally uses, and it ; allows Squish to be used in tight-memory situations. ; ; By default, Squish will attempt to swap to XMS first followed by ; EMS, and finally, Squish will attempt to swap to disk. If you ; don't specify anything after the 'Swap' keyword, and Squish ; resorts to disk swapping, Squish will write the swap file in ; the current directory. However, if you wish Squish to swap elsewhere ; when it has to resort to disk swapping, you can specifiy a path ; and a filename after the 'Swap' keyword. ; ; WARNING! Some networks may be allergic to the Swap command. If ; you're having trouble getting Squish to run with Swap, try ; turning it off. ; ;Swap D:\Temp\$$SQUISH.SWP ; The 'Nuke' keyword (ArcmailAttach mode only) instructs Squish to ; delete ARCmail bundles for which there is no attach message. This ; keyword is ONLY required when using Max with D'bridge, or some other ; mailer which cannot delete or truncate files as they are sent. ; ; When Squish gets to the SQUASH phase, it will scan all of the messages ; in the netmail directory, and make a note of all file attaches. It ; will then scan the outbound packet directory, and delete any ARCmail ; bundles which do not have attach messages. ; ; THIS COMMAND IS POTENTIALLY DANGEROUS, SO IT SHOULD ONLY BE USED ; IF YOUR MAILER REQUIRES IT! ; ;Nuke ; The 'MaxAttach' keyword is for ArcmailAttach mode ONLY. This option ; instructs Squish to reserve memory for up to netmail attach ; messages. You should have no more than this number of messages in ; your netmail area. Nothing drastic will happen if the number of ; attaches exceeds this, but you may find that duplicate attach ; messages are created if it's too small. The default for MaxAttach is ; 256. Most systems will NOT need to use this keyword. ; ;MaxAttach 256 ; The 'MaxPkt' keyword is used in both ArcmailAttach and ; non-ArcmailAttach modes. This keyword specifies the maximum number ; of packets which can be present in OUTBOUND.SQ at one time. If the ; number of packets exceeds this value, then the excess packets will ; simply be queued for the next run of Squish. The default for MaxPkt ; is 256. Most systems will NOT need to modify this number. ; ;MaxPkt 256 ; The `Buffers' keyword controls Squish's memory usage. By default, ; Squish will use large buffers for processing mail. However, if ; you're running Squish in a memory-restricted environment, you ; can tell Squish to use less memory by specifying one of the ; options below. WARNING! As you decrease the buffer size, Squish ; becomes slower and slower. `Buffers Small' is unsuitable if you're ; forwarding mail to any other nodes; medium buffers should be ; considered the minimum for hubs. Buffers Large ;Buffers Medium ;Buffers Small ; Next are any number of message area definitions. However, as a bare ; minimum, you must have a NetMail area and a bad messages area. ; ; The format of a message area definition is: ; ; [flags] [nodes] ; ; specifies the type of area to define. Valid s are ; NetArea, BadArea, DupeArea and EchoArea. You must have at least ; one NetArea and at least one BadArea. ; ; specifies a short-form "name" for that area. This name is ; used as a quick way of referring to that area; for NetAreas, BadAreas ; and DupeAreas, the only requirement is that the tag must be unique. ; However, for EchoAreas, this tag defines the actual name of the area, ; as used when talking to other systems. In other words, before assigning ; a tag to an echo, you should ask your feed for the name of that echo. ; ; specifies the path to the area. For *.MSG areas, this should ; be the path to the message directory. For Squish areas, ; should be the path and root filename of the Squish area. ; ; [flags] are an optional set of modifiers for each area. A flag is ; a dash followed by a character, plus an optional argument. Flags ; can be used to change the attributes of an area, such as making ; that area "passthru", using the Squish message format for that area, ; and so on. ; ; A brief description of each flag follows, but for more information, ; you should consult the Squish documentation for a full explanation of ; each flag. ; ; -f The '-f' flag selects the FTSC-0001 (*.MSG) ; storage format. *.MSG is the default, so this ; flag normally doesn't need to be used. ; ; -p The '-p' flag selects an alternate primary ; address for the current area only. This ; address will be used in SEEN-BYs, PATH lines, ; and packet headers. ; ; -s The '-s' flag instructs Squish to strip the ; private bit from all messages received in the ; current area. ; ; -x The '-x' flag stops from SENDING mail ; into the specified echo. ; ; -0 The '-0' flag indicates that the current ; area is a passthru area. ; ; -+ The '-+' flag instructs Squish to add ; to the SEEN-BYs for the current area only. ; ; -$ The '-$' flag tells Squish that the specified ; area uses the Squish message format. ; ; -$m The '-$m' flag instructs Squish to keep up ; to a maximum of messages in this ; Squish-format area. Message will be ; deleted by Squish on the fly. ; ; -$s The '-$s' flag instructs Squish to skip the ; first messages when killing up to the ; last '-$m' messages in each area. This ; parameter is only applicable when using ; the -$m flag. ; ; -$d The '-$d' flag instructs Squish to keep up ; to a maximum of days' worth of ; messages in this Squish-format area. Killing ; by date is NOT done on the fly, so SQPACK must ; be run on a regular basis to purge messages. ; Every system must have at least one NetArea. You can declare ; more NetAreas if you like (and Squish will scan all of them when ; packing mail), but all inbound NetMail will be placed into ; this area. NetArea NETMAIL n:\im\mail ; The BadArea is used for placing insecure or grunged messages. Every ; system must have a BadArea. BadArea BAD_MSGS n:\im\Badecho ; The DupeArea is optional. If you have defined a DupeArea, all duplicate ; messages will be placed into this message area. Otherwise, duplicates ; will go into your BadArea. DupeArea DUPES n:\im\Dupes ; Next comes zero or more EchoMail area definitions. IF YOU ARE DECLARING ; YOUR AREAS IN AREAS.BBS, COMMENT OUT ALL 'ECHOAREA' LINES! ; ; The first line defines an EchoMail area called 'TUB', which uses ; the *.MSG format in the C:\Max\Msg\Bath directory. This echo is ; scanned to 1:123/99. ;EchoArea TUB C:\Max\Msg\Tub 1:123/99 ; The second line defines an EchoMail area called 'MUFFIN', which uses ; the Squish format (because of the '-$') in the files called ; C:\Max\Msg\Muffin.Sq?. This echo is also scanned to 1:123/99. ;EchoArea MUFFIN C:\Max\Msg\Muffin -$ 1:123/99 ; As many EchoMail areas can be added as you like. Just make sure to ; add the appropriate flags, including -$ for Squish-format areas, ; and you should be all set. ; ### .