;     Configuration file for CleanOut (c) 1995 Klaus Nitsche 2:2461/161
;
;           A utility to keep your Binkley-style outbound clean.
;
;      Please read the documentation to understand how CleanOut works.
;
; -------------------------------------------------------------------------
; Comment lines start with ";" and are ignored by CleanOut.
; Case doesn't matter; you could write
;              OuTbOuNd <blah>
; and CleanOut would still recognize it as a keyword.
; -------------------------------------------------------------------------
;
;
; Name <your_name>
;
; Needed if you want CleanOut to write netmail to lazy pollers.
; Use an underscore (NOT a space) between first and last name.
;
Name Klaus_Nitsche
;
; -------------------------------------------------------------------------
;
; Address <your FTN address>   MANDATORY!
;
; Enter one address for each zone you belong to.  At least one address
; must be specified.
;
;
Address 2:2461/161
Address 246:6104/0
Address 111:222/7
;
; -------------------------------------------------------------------------
;
; NetmailDir <valid directory>
;
; Needed for netmail.  This must be your main netmail folder (with or
; without trailing backslash).
;
NetmailDir d:\bink\netmail
;
; -------------------------------------------------------------------------
;
; KillNetmail (Default: No)
;
; Tells CleanOut to set the "Kill/Sent" Attribute on every outgoing message.
;
KillNetmail No
;
; -------------------------------------------------------------------------
;
; Simulate Yes/No (Default: Yes)
;
; This is the master on/off switch.
; If you specify YES, CleanOut will NOT kill any files.  Use this to test
; CleanOut on your system.  The output will appear as usual and will show
; you the files that CleanOut WOULD have killed if we had been serious here.
;
Simulate Yes
;
; -------------------------------------------------------------------------
;
; LogFile <full drive:path specification> (default: no logging)
;
; If you specify a valid filename here, CleanOut will log all its activity
; to disk.  An existing log file will be appended to.  If you omit the
; path, the log file will be written to the current directory.
;
LogFile cleanout.log
;
; -------------------------------------------------------------------------
;
; LogLevel Mininum/Medium/Heavy       (default: Medium)
;
; If you have activated logging by specifying a log file above, use this
; keyword to indicate how much information should be written to the log
; file.
;
; Minimum will log only the most important information.
; Medium  will log some more information.
; Heavy   will log ALL information including the filenames of all files
;         that are checked.  This will increase the size of your log file
;         considerably.  Use this log level when testing CleanOut.
;
LogLevel Heavy
;
; -------------------------------------------------------------------------
;
; KillArcMail Yes/No (Default: No)
;
; Normally, CleanOut will leave all ArcMail bundles (*.SA?, *.SU? etc.)
; that might be in your outbound alone.
; If you specify YES, it will check if those bundles are listed in one
; of the .?LO files in your outbound directories.  If it doesn't find a
; reference, ArcMail bundles that are NOT referenced get KILLED.
;
; CleanOut understands both *.??[0-9] and *.??[A-Z] naming conventions
; for ArcMail bundles.
;
; There's one exception here.  Even if you specify YES, CleanOut will
; leave ArcMail files with a file size of 0 alone - because your echomail
; processor needs them!  Deleting those files is your echomail processor's
; responsibility.
;
KillArcMail No
;
; -------------------------------------------------------------------------
;
; KillHidSys Yes/No (Default: No)
;
; Indicates whether files with the "Hidden", "System", or "Read-only"
; attribute should be deleted.
;
;
KillHidSys No
;
; -------------------------------------------------------------------------
;
; KillRoot Yes/No (Default: No)
;
; This is an additional security step.  By default, CleanOut will never
; delete files from a root directory (such as C:\ or D:\).  If you DO want
; to specify such a root directory below, you MUST also enable this switch.
;
; This is to keep you "I'll shoot before I ask" guys from deleting your
; system files in C:\ <grin>.
;
KillRoot No
;
; -------------------------------------------------------------------------
;
; NeverKill <filename>
;
; With this keyword, you can specify names of files that CleanOut should
; not delete.  (Note: not full path names, just file names!)  Wildcards
; are not allowed.
;
NeverKill files.bbs
NeverKill descript.ion
;
; -------------------------------------------------------------------------
;
; NukeDays <NrDays>
;
; Instructs CleanOut to kill flow files that are at least as old as <NrDays>.
;
; This will have the effect that files referenced in old flow files will
; get deleted as well (such as old file attaches or ArcMail bundles).
;
; Checking for (and deleting) old flow files is done early during program
; run, so subsequently, other files that were listed in these old flow files
; will also get killed when CleanOut continues (because it doesn't know
; about them since it didn't read the flow file's contents before deleting
; it).
;
; If you specify less than 14 days (this value is hardcoded), you'll get
; a popup window that asks you for a confirmation.  If you don't press 'Y'
; within 20 seconds, CleanOut defaults to killing only those flow files that
; are at least 14 days old.
;
NukeDays 30
;
; -------------------------------------------------------------------------
;
; NukeException <valid FTN address>
;
; Here, you can list downlinks whose old flow files should *not* be nuked,
; even if NUKEDAYS <days> is active.
;
NukeException 111:222/7.10
NukeException 246:6104/1200
NukeException 246:6104/1300
NukeException 2:2461/161.3
;
; -------------------------------------------------------------------------
;
; WarnDays <NrDays>
;
; The previous stage to "NukeDays".  When CleanOut finds a flow file aged
; <NrDays>, it will write a warning message to the corresponding downlink
; that they have still a few days to pick up their stuff before it gets
; nuked from your outbound.  (This does not apply to the nodes listed
; above under "NukeExceptions".)
;
; If you enable this function, don't call CleanOut more than once per day,
; because it would write another warning message to the same downlink in
; each run.
;
WarnDays 20
;
; -------------------------------------------------------------------------
;
; Readdress <from address> <to address> <optional message flavour>
;
; Enables you to send notification messages to another address where there's
; a better chance to reach the recipient.  You must specify two addresses
; per line.
;
; <optional message flavour> can be any combination of the words
;
;           CRASH (make this message a crash mail),
;           KILL  (delete this message after sending),
;           HOLD  (put this message on hold for pickup).
;
Readdress 2:2461/161.2 2:241/1090 Crash Kill
Readdress 246:6104/1300 2:2454/420
;
; -------------------------------------------------------------------------
;
; Outbound <full drive:path specification> (no default)
;
; I'm too lazy to implement an intelligent routine that finds your outbound
; directories on its own and maybe even recognizes domains.  Sorry.
; That means that you have to enter ALL your outbound directories manually.
; (A trailing backslash is not necessary but doesn't hurt either.)
;
; CleanOut does NOT recurse through directories, so you have to enter
; subdirectories as well.  Be sure not to miss a single one!
;
; IT IS EXTREMELY IMPORTANT THAT YOU ENTER **ALL** YOUR OUTBOUND DIRECTORIES!
;
; CleanOut will search these directories for *.?LO files.  It will also check
; if any OTHER file in these directories is referenced in a *.?LO file, and
; if not, zap it.
;
; There are some exceptions.  Files that will NEVER be killed are:
;
; - outgoing uncompressed mail packets (.OUT, .HUT etc.)
; - *.?LO files themselves, of course ;)
; - *.BSY files that signal your mailer is currently in session
;   (actually, on detecting a .BSY file, CleanOut will immediately abort
;   before doing any possible harm)
; - *.REQ files (outgoing file requests)
; - *.#??, *.&??, *.$??, *.-??, *.!??
;   (markers for dial tries, failed connects, etc.)
;
; CleanOut recognizes the additional *.?LO and *.?UT files that Xenia,
; McMail and Portal of Power create.
; The currently known extensions are:
;
; .HLO .DLO .CLO .ILO .SLO .WLO .PLO .FLO
; .HUT .DUT .CUT .IUT .SUT .WUT .PUT .OUT
;
; Got any more info about extra file extensions that your Binkley-style
; mailer creates?  If so:
;
; - DON'T use this program ;)
; - Contact me so I can build the information into CleanOut.
;
Outbound d:\bink\out
Outbound d:\bink\out.0f6
Outbound d:\bink\out.06f
Outbound d:\bink\out.06f\00DE0007.PNT
Outbound d:\bink\out\01F40095.PNT
Outbound d:\bink\out\098C0475.PNT
Outbound d:\bink\out\099D00A1.PNT
Outbound d:\bink\out\09B71F50.PNT
;
; -------------------------------------------------------------------------
;
; ScanAlso <full drive:path specification> (no default)
;
; You can specify a few additional directories here which you want checked
; for files that should be deleted.
; Why?  Simple.  If you use an extra "queue" directory for outgoing files,
; for example (some file tossers support that), or some kind of "private"
; directories for certain downlinks, you can let CleanOut scan those
; directories as well and delete files there that don't show up in any
; *.?LO file in your regular outbound.
;
; CleanOut will NOT look for *.?LO files here - a *.?LO should only occur
; in your regular outbound anyway.
;
ScanAlso d:\bink\out\ATTACH
ScanAlso d:\bink\out\PT
ScanAlso d:\bink\out\TIC
;
;
; [EOF]
