HPT
***

This document describes HPT 1.9, a Fidonet Message Tosser for OS/2,
Windows, BeOS and Unix.

   HPT is based on FIDOCONFIG library, so read documentation of
FIDOCONFIG about location of config file, keywords ideology and about
majority of the keywords, see Fidoconfig Manual (fidoconfig).

1 An Overview on HPT
********************

HPT is a Fidonet message tosser and packer with areafix, written by
Matthias Tichy, 2:2432/645@fidonet.  Now project is being supported by
Husky Development Team.

   Features of HPT:
  1. tossing packets of 2, 2.0 & 2+ types
  2. supporting Msg, Squish and Jam message bases
  3. posting to net & echo areas
  4. areafix (on the fly, from command line, limit for areas...)
  5. autocreate on the fly
  6. forward requests
  7. pause and autopause for links
  8. linking net & echo areas
  9. carbon copy
  10. groups & levels for personal and public access to echo areas
  11. powerful dupe checker
  12. link defaults

   The advantages of HPT are:

  1. Open Source (GPL)
  2. many supported platforms & operating systems
  3. quick bug fixing

   The limitations of HPT is:

  1. OPUS messagebase (type MSG) is limited to 65536 messages, this is
     SMAPI implementation limit;
  2. PKT password is limited to 8 characters, this is PKT 2+ limit.

2 Installation Procedures and Release Notes
*******************************************

This chapter provides you with information that is necessary to
successfully install and use HPT.

   I suppose, that you already has compiled binaries.  If not - read
"Download" or "Compile the Source Code" chapters.

  1. Read FIDOCONFIG documentation about location of config-file and
     majority of the configuration statements.
  2. Copy sample config files to config directory
  3. Edit config files for your purposes
  4. Run 'tparser' from FIDOCONFIG package to test your config (read
     about 'PublicGroup' or 'AccessGrp' if you want to use groups for
     'EchoAreas')
  5. It is simple, isn't it?  Enjoy!  :-)

2.1 Download the Source Code & Binary Files
===========================================

Main page - <http://husky.sourceforge.net/>
Latest win32 binaries - <http://elfy.nv.googlepages.com/>

2.2 Compiling the Source Code
=============================

1.  The smapi and fidoconf packages are required for hpt.

   2.  Put the fidoconfig and smapi packages in the directory where the
other packages of fido linux reside:

/usr/src/packages/
-> smapi/
-> hpt/
-> fidoconfig/

   3.  Compile and install smapi and fidoconf packages.  Use "Makefile"
for dynamic executables and makefile.lnx (or what you need) for static
ones.

   4.  Compile and install hpt:
$ make
$ make install
   You should use the _same_ makefiles in smapi, fidoconf and hpt.

2.3 Support, Contacting the Author, Reporting Bugs, Contributing Code
=====================================================================

There are numerous reasons why you might wish to establish contact with
me, the author of HPT.

  1. You have decided to use HPT on a regular basis.  In this case,
     please do send me an e-mail at the address listed below.  How much
     time I will spend on developing HPT in the future will heavily
     depend on the number of mails I receive from users that tell me
     that they do use HPT.

  2. You have a general questions on how to configure or on how to use a
     certain feature of HPT. In other words, you need support.  In this
     case, you'd best post your question to one of the following echos:

     'FIDOSOFT.HUSKY'
          The international Husky conference.  English is the preferred
          language here.
     'RU.HUSKY'
          This Russian echo covers Husky Project.  I monitor it
          regularly.
     'RU.ECHOPROCESSORS'
          Russian talks about echoprocessors.  I monitor it regularly.

     If you do not have access to any of these echos, you may of course
     also contact me via netmail or e-mail at the addresses listed
     below.

  3. You want to report a bug.  There are two sorts of bugs:

       a. Normal bugs.  You think that a certain function of HPT does
          not work as expected, e.g.  it is producing garbage, or doing
          strange things, or similar.  In this case, either post to the
          echos listed above, or contact me via netmail.  Please do
          supply all information that is necessary to understand your
          problem.

       b. Fatal bugs.  A fatal bug occurs if HPT crashes.  Depending on
          your operating system, the symptom might be a core dump, or a
          SYS 3175, or a general protection fault, or a system lockup,
          or a spontaneous reboot.  I do consider a crash untolerable.
          No matter how stupid things you do, you should not be able to
          crash HPT.

          If you are an experienced user and get core dump, you can send
          me gdb report.  If you have a crash, locate 'core' file that
          has been generated.  Then run $ gdb hpt core, type where.  HPT
          must be compiled with debug information (DEBUG=1 in
          'huskymak.cfg' file).  Then send report to address below.

          If you are running any other binary version (like Windows),
          you will not get a core file on a crash.  Write down as much
          information as you can, try to find a way to reproduce the
          crash and contact me at the addresses below.

  4. You want to contribute to HPT. If you are a programmer and have
     fixed a problem in MsgEd-TE on your own, please submit your changes
     to me.  The preferred way for doing this is to send me a difference
     file in GNU diff format (with -c parameter).  Your work will be
     highly appreciated and honored in an appropriate place.  If you
     want to regularly work on HPT, we also have a CVS server online
     that you can have access to if you like.

     If you want to write a new feature for HPT, please contact me
     beforehand to avoid that we do duplicate work.  Again, I will
     appreciate and honor eny efforts done by you.  Please note that for
     writing a HPT enhancement, you should be familiar with C. Also, HPT
     uses a special indentation style throughout the source code, that I
     would like you to adhere to.

   So here are my addresses if you want to get in contact with me:

   * Fidonet: Max Levenkov  2:5000/117

   * e-mail: sackett@mail.ru

2.4 Credits
===========

Thanks to:

  1. Matthias Tichy (basic code)
  2. Max Levenkov (areafix, group code, carbon copy, code clean up &
     speed up and more)
  3. Tobias Ernst (some features, stable releases, cvs & www support)
  4. Sacha M. Silbe (features, makefiles)
  5. Kolya Nesterov (unpack, post, link)
  6. Fedor Lizunkov (areafix, autocreate reports, group code, JAM code
     in SMAPI)
  7. Serguei Revtov (win32 version support, hptlink, features & good
     patches)
  8. Alexander Vernigora (dupe detection)
  9. Pavel Gulchouk (Perl support, JAM & link hacking)
  10. Alex Semenyaka (netmailExtern, processPkt)
  11. Alex Bronin (win32 patches)
  12. Nikolay Nestyurkin (makefiles)
  13. Lev Serebryakov (new %list)
  14. ...  and all other people (sorry, if I've forget somebody)
   P.S. all this people make bug fixes, so I don't mention it.

3 HPT 1.9 Configuration Reference
*********************************

HPT is based on FIDOCONFIG library, so read documentation of FIDOCONFIG
about location of config file, keywords ideology and about majority of
the keywords, see Fidoconfig Manual (fidoconfig).

3.1 Using config
================

Although HPT uses fidocongig, not all config statements refer to hpt.
Hpt ignores all unused config statements.The Husky Fidonet Software
project concept is to use one config file for all fidonet programs.

3.1.1 Predefined config variables
---------------------------------

In some cases need use different values for one statement in hpt, htick
and/or other husky programs (called "modules").  It solve using config
variable 'module': hpt define the 'module' variable with value 'hpt' and
you may use if-elseif-else-endif conditions statements sequence like as:

     if "[module]"=="hpt"
       Origin   High Portable Tosser at my node
     elseif "[module]"=="htick"
       Origin   High Portable Ticker at my node
     else
       Origin   My node
     endif

   HPT defines a config variable 'version' with the value set to the hpt
version like 'MAJOR.MINOR.PATCHLEVEL', for example '1.9.0' or '1.4.1'.
You may use this variable to make common config for several hpt
versions.

   To test config for hpt only you may call tparser tool with arguments
'-Dmodule=hpt' and (if needed) '-Dversion=1.9.0' (tparser is included
into fidoconfig package) like this:

     tparser -Dmodule=hpt
     tparser -Dmodule=hpt -Dversion=1.9.0

3.1.2 Statements order
----------------------

Common rule for config statements order is: *Define object before using
it!*.

   Examples:
   * define addresses before any link, area and carbon definitions
   * define packers before any link definitions
   * define links before any area and route definitions
   * define links and areas before any carbon definitions

3.2 General Keywords
====================

HPT is based on FIDOCONFIG library, so read documentation of FIDOCONFIG
about location of config file, keywords ideology and about majority of
the keywords, see Fidoconfig Manual (fidoconfig).

3.2.1 AddToSeen
---------------

Syntax:
     'addToSeen <addr> [<addr> ...]'
Example:
     'addToSeen 99/100 99/101'

   Add <addr> to SEEN-BYs.  If <addr> is present or not - it is always
adds.

   This statement can be repeated.

3.2.2 AfterUnpack
-----------------

Syntax:
     'afterUnpack <string>'
Example:
     'afterUnpack pktpack /home/fido/in.tmp/*.pkt'

   This <string> is executed after unpacking arcmail bundle.  You may
process your pkt files in 'tempInbound' directory with external utility.

   This statement cannot be repeated.

3.2.3 AreafixFromPkt
--------------------

Syntax:
     'areafixFromPkt <bool>'
Example:
     'areafixFromPkt'

   Process areafix requests on the fly.  Check "areafix", "areamgr" &
"hpt" keywords in toUserName field.  Request messages don't saves.

   This statement cannot be repeated.

   See RobotNames (fidoconfig).

3.2.4 AreasFileNameCase
-----------------------

Syntax:
     'areasFileNameCase (Lower|Upper)'
Example:
     'areasFileNameCase Upper'

   This statement defines case of filemanes of autocreated areas.
Default is lower case.

   This statement cannot be repeated.

3.2.5 AutoPassive
-----------------

Syntax:
     'autopassive <bool>'
Example:
     'autopassive'

   If this statement is defined HPT will check for old bundles in every
run.  Fileboxes are not checked.  Links, for which there are bundles
that are at least "AutoPause" days old, will be paused.  It
stops exporting echomail for them.  If AutoPause is not defined
or is equal to 0 for a link then AutoPassive is ignored for this link.
If AutoPassive is not defined then AutoPause is ignored for all
links.

   The paused link is unsubscribed from the areas which are passthrough
with no downlinks besides him (see -def in EchoArea (fidoconfig)
to make it work) AND which are allowed to be paused (see -pause,
-paused, -noautoareapause, -autoareapause in
EchoArea (fidoconfig) and AutoAreaPause (fidoconfig)).  An
unsubscribe request is sent to the uplink for those areas.  Note that
this feature is unavailable when using %PAUSE Areafix command.

   By using "hpt pause" command-line parameter instead of defining
AutoPassive in the configuration file, you can do the check for old
bundles and all the rest of the functionality of AutoPassive only once.

   This statement cannot be repeated.

   See also AutoPause and Pause (fidoconfig) sections.

3.2.6 BeforePack
----------------

Syntax:
     'beforePack <string>'
Example:
     'beforePack pktpack /home/fido/out.tmp/*.pkt'

   This <string> is executed before packing pkt files to arcmail
bundles.  You may process your pkt files in 'tempOutbound' directory
with external utility.

   This statement cannot be repeated.

3.2.7 BundleNameStyle
---------------------

Syntax:

     'bundleNameStyle <timeStamp | addrDiff | addrsCRC32 |
     addrDiffAlways | addrsCRC32Always | Amiga>'

Example:

     'bundleNameStyle timeStamp'

   This statement sets a rule for creating names of arcmail bundles:

'timeStamp'
     some kind of random names (current time + some counter).
'addrDiff'
     create name from difference of source and destination addreses.
     Always the same filename for every pair of links.  Automatically
     switches to 'timeStamp' when all alowed extensions have been used.
'addrsCRC32'
     create name from CRC32 of string composed from "hpt", source and
     destination addreses.  Always the same filename for every pair of
     links, very unique.  Automatically switches to 'timeStamp' when all
     alowed extensions have been used.
'addrDiffAlways'
     the same as addrDiff but tries to use lower free numbers of
     extension in case when all higher numbers are already busy.
'addrsCRC32Always'
     the same as addrsCRC32 but tryes to use lower free numbers of
     extension in case when all higher numbers are already busy.
'Amiga'
     Amiga Style Outbound (ASO). Bundles are created in
     outbound (fidoconfig) directory like this:
          2.5000.117.1.hut
          2.5000.117.1.mo0
     If SeparateBundles is 'on' and packer (fidoconfig)
     not defined, pkt is moved to '2.5000.117.1.sep' directory.

     Extensions & prefixes in flo files are created as in
     'addrDiffAlways' algorithm.

   Default value is 'timeStamp'

   This statement cannot be repeated.

   See also LinkBundleNameStyle.

3.2.8 DefArcmailSize
--------------------

Syntax:
     'defarcmailsize <integer>'
Example:
     'defarcmailsize 1024'

   default arcmail size in kb for all links.  500kb if not defined.

   This statement cannot be repeated.

3.2.9 DisableTID
----------------

Syntax:
     'DisableTID <bool>'
Example:
     'DisableTID'

   Don't add TID-line to scanned messages.

   This statement cannot be repeated.

3.2.10 DisablePID
-----------------

Syntax:
     'DisablePID <bool>'
Example:
     'DisablePID'

   Don't add PID-line to generated messages.

   This statement cannot be repeated.

3.2.11 DisableKludgeRescanned
-----------------------------

Syntax:
     'DisableKludgeRescanned <bool>'
Example:
     'DisableKludgeRescanned'

   Don't add kludge RESCANNED to generated messages.

   This statement cannot be repeated.

3.2.12 IgnoreCapWord
--------------------

Syntax:
     'IgnoreCapWord <bool>'
Example:
     'IgnoreCapWord'

   Ignoring Capability Word in pkt files.  If some pkt moved to bad.
This may help, but not recommended.  It is better to change old
software.

   This statement cannot be repeated.

3.2.13 IgnoreSeen
-----------------

Syntax:
     'IgnoreSeen <addr> [<addr> ...]'
Example:
     'IgnoreSeen 99/150'

   Ignore this SEEN-BY & pack mail for link.  But no pack it back if the
mail was from him.

   This statement can be repeated.

3.2.14 KeepTrsFiles
-------------------

Syntax:
     'keepTrsFiles <bool>'
Example:
     'keepTrsFiles'

   Leave transit (routed) files in 'Inbound' directory.  If this
statement is ommitted transit files wouldn't be kept.  Default is "off".

   File route possible with "Att" attribute in message header and file
name in subject line.

   This statement cannot be repeated.

   See RouteFile.

3.2.15 KeepTrsMail
------------------

Syntax:
     'keepTrsMail <bool>'
Example:
     'keepTrsMail'

   Save transit messages in NetmailArea.  If this statement is ommitted
transit messages wouldn't be kept in NetmailArea.  Default is "off".

   This statement cannot be repeated.

3.2.16 KludgeAreaNetmail
------------------------

Syntax:
     'kludgeAreaNetmail <kill | ignore | echomail>'
Example:
     'kludgeAreaNetmail kill'

   Default is "kill"

   If message started with "AREA:NETMAIL" we have three ways:

   1.  kill this kludge.  process message as netmail.  2.  ignore this
kludge.  process message as netmail.  3.  process message as echomail.

   This statement cannot be repeated.

3.2.17 LinkWithImportLog
------------------------

Syntax:
     'linkWithImportLog <yes | no | kill>'
Example:
     'linkWithImportLog yes'

   This statement specifies if the importlog-file should be used to
determine which echomail areas need to be linked.

yes
     importlog-file will be read.  areas which are in importlog, will be
     linked.  the importlog-file will not be erased.
kill
     like yes, but the importlog-file will be killed after using it.
no
     DEFAULT. all areas will be linked.

   This statement cannot be repeated.

3.2.18 NetmailFlag
------------------

Syntax:
     'netmailFlag <file>'
Example:
     'netmailFlag /etc/ftn/flags/netmail'

   Create file-flag after unpacking netmail msg.  This feature can be
used for execute netmail trackers after tossing.

   This file also created after scannig 'NetmailArea' without route
definition.  Scanning is stopped but file-flag created for netmail
tracker.

   This statement cannot be repeated.

3.2.19 NoProcessBundles
-----------------------

Syntax:
     'noProcessBundles <bool>'
Example:
     'noProcessBundles'

   Don't unpack arcmail bundles.

   This statement cannot be repeated.

3.2.20 Origin
-------------

Syntax:
     'origin <string>'
Example:
     'origin mega cool station'

   Add this Origin to hpt messages: post, reports about new areas
created.

   This statement cannot be repeated.

3.2.21 PackNetMailOnScan
------------------------

Syntax:
     'PackNetMailOnScan <bool>'
Example:
     'PackNetMailOnScan off'

   When PackNetMailOnScan is "on" (default) hpt packs netmail when doing
"hpt scan" and netmail area is found in EchoTossLog file.  When it is
"off" hpt leaves netmail area(s) in EchoTossLog file until "hpt pack" is
invoked.

   This statement can be repeated (overrides old setting).

3.2.22 ProcessPkt
-----------------

Syntax:
     'processPkt <string>'
Example:
     'processPkt pktdate'

   The <string> is executed before tossing each pkt file.  You can fix
your pkts using pktdate or any other tool before tossing them.  Note
that pkt file may be renamed depending of 'tossingExt' token value.

   This statement cannot be repeated.

3.2.23 RecodeMsgBase
--------------------

Syntax:
     'recodeMsgBase <bool>'
Example:
     'recodeMsgBase off'
Defaults:
     'recodeMsgBase on'

   This statement specifies if we should recode messages when put/get
them to/from message base.  So you can keep message base in transport
charset and configs/other local files in local one.

   This statement cannot be repeated.

3.2.24 Remap
------------

Syntax:
     'Remap <ToName>,<ToAddress>,<NewAddress>'
Examples:
        * 'Remap Max Levenkov,2:5000/117,2:5000/117.1\n'
        * 'Remap *,2:5000/117,2:5000/117.1'
        * 'Remap Max Levenkov,*,2:5000/117.1'

   Remap mail to other address.  ToName *OR* ToAddress can be replaced
with asterisk to match any value of ToName or ToAddress.  Two asterisks
can't be defined together.  *This statement does not touch TOPT & FMPT
kludges.*

   This statement can be repeated.

3.2.25 Route
------------

Syntax:
     'route <flavour> <routeVia> <target> [<target> ...]'
     'route nopack <target> [<target> ...]'
Example:
     'route crash 2:2433/1245 2:2433/* 2:2432/*'
     'route nopack 2:5020/98*'

   The *route* statement defines a route to destination address namely
the node address via which we send the netmail containing the specific
destination address.

   There are two variants of the statement.  The first one defines a
route to <target>.  The second one with 'nopack' (or 'no-pack') just
after the 'route' keyword tells not to process netmail when its
destination coinsides with an address in <target>.

   *<target>* is one specific destination address or a DOS-style pattern
containing characters *?*  and/or *** and defining a set of destination
addresses.

   *<flavour>* is an instruction to mailer how it should handle the
netmail and it can be one of the following keywords:
   * hold
   * normal
   * crash
   * direct
   * immediate

   If the flavour is 'hold', then the mailer should transfer the mail
during an incoming session only.  So the mail will be placed into
outbound directory and it will wait for an incoming session.  If the
flavour differs from 'hold', then the mail may be transferred both
during an incoming and an outgoing session.  Interpretation of all
flavours except 'hold' depends on the mailer.

   The file extension of the netmail file or the flow file which the
tosser puts into the outbound depends on the flavour:

flavour                           netmail                flow
---------------------------------------------------------------------------
hold                              .hut                   .hlo
normal                            .out                   .flo
crash                             .cut                   .clo
direct                            .dut                   .dlo
immediate                         .iut                   .ilo

   *<routeVia>* defines the node via which the mail will be sent to
destination.  It may take the following values:
   * <address> - mail is routed to destination via this specific
     address.
   * host - when this keyword is used, mail will be transmitted via the
     node whose address is formed from the destination address with node
     and a point numbers equated to zero.
   * hub - this keyword denotes hub-routing, which does not use the hubs
     defined in the nodelist but uses the node address defined by
     formula:

     'via_address = (destination_address / 100) * 100'

     Here '/ 100' denotes integer division discarding the remainder.
     E.g.  a mail to node 2:2433/1245 is sent via 2:2433/1200, but a
     mail to node 2:2433/355 is sent via 2:2433/300 which currently does
     not exist.  BE CAREFUL!
   * boss - this keyword is used when destination system is a point.  If
     the destination address is zone:net/node.point then mail is routed
     via zone:net/node.0
   * no-route (or noroute) - this keyword is a misnomer in a way and in
     fact it means route to destination via itself.

   One may use the second variant of the route statement in the form

   'route <flavour> nopack <target> [<target> ...]'

   Here the <flavour> is ignored.  Such use is deprecated and it is left
for compatibility with old versions.

   There can be several route statements.  They are parsed in the order
they are written until the statement with the target containing the
destination address from the netmail is found.

   *NOTE!* This statement must occur after "link" sections.

3.2.26 RouteFile
----------------

Syntax:
     'routeFile <flavour> <routeVia> <target> [<target> ...]'
     'routeFile nopack <target> [<target> ...]'
Example:
     'routeFile crash 2:2433/1245 2:2433/* 2:2432/*'
     'routeFile nopack 2:5020/98*'

   This statement is the same as the Route statement, but
applies only to messages with file attaches.  Files are routed together
with netmail messages.  If no 'RouteFile' defined, then files will be
not routed at all!

   This statement can be repeated.

3.2.27 RouteMail
----------------

Syntax:
     'routeMail <flavour> <routeVia> <target> [<target> ...]'
     'routeMail nopack <target> [<target> ...]'
Example:
     'routeMail crash 2:2433/1245 2:2433/* 2:2432/*'
     'routeMail nopack 2:5020/98*'

   This statement is the same as the Route statement.

   This statement can be repeated.

3.2.28 SeparateBundles
----------------------

Syntax:
     'SeparateBundles <bool>'
Example:
     'SeparateBundles'

   Move echomail for all links to their own directories.

   This statement cannot be repeated.

3.2.29 SetConsoleTitle
----------------------

Syntax:
     'SetConsoleTitle <bool>'
Example:
     'SetConsoleTitle'

   Set hpt console title while tossing.  (*WIN32 Only!*)

   This statement cannot be repeated.

3.2.30 SortEchoList
-------------------

Syntax:
     'SortEchoList none|name|group|group,name'
Example:
     'SortEchoList name'

   This keyword determines sorting mode for echolist (%LIST, %QUERY,
etc):
'none'
     unsorted (order as presents in config file)
'name'
     sort by name
'group'
     sort by group (-g in echoArea) only
'group,name'
     sort by group and name.

   When sorting is carried out by group, group descriptions (see grpDesc
keyword) are printed before groups' areas.

   By default echolist is sorted by name.

   This statement cannot be repeated.

3.2.31 TearLine
---------------

Syntax:
     'tearline <string>'
Example:
     'tearline We Love HPT! :)'

   Add this tearline to hpt messages (post, reports about new areas
created)

   This statement cannot be repeated.

3.2.32 TossingExt
-----------------

Syntax:
     'TossingExt [<string>]'
Example:
     'TossingExt tos'

   Extension of bundle & packet files will be changed to <string> before
tossing (and before processPkt string executed if set).  That may be
used for preventing of permanent tossing fault because of bad file in
inbound.  Default extension: tos.  'TossingExt' without parameter
disables files renaming in tossing.

   This statement cannot be repeated.

3.3 Files and Paths
===================

HPT is based on FIDOCONFIG library, so read documentation of FIDOCONFIG
about location of config file, keywords ideology and about majority of
the keywords, see Fidoconfig Manual (fidoconfig).

3.3.1 AdvStatisticsFile
-----------------------

Syntax:
     'AdvStatisticsFile <filename>'
Example:
     'AdvStatisticsFile /home/val/fido/log/hpt.sta'

   Define binary statistic file for calculating links and echo traffic.
Parsed by hpt/misc/adv-stat-hpt.pl

3.3.2 AreasMaxDupeAge
---------------------

Syntax:
     'areasMaxDupeAge <integer>'
Example:
     'areasMaxDupeAge 10'

   Set maximum days for storing you hashes in CommonDupeBase.  Default
value is 5.

   For any other dupe base type please use '-DupeHistory' option in
EchoArea (fidoconfig) or EchoAreaDefaults (fidoconfig).

   This statement cannot be repeated.

3.3.3 DupeBaseType
------------------

Syntax:
     'dupeBaseType <TextDupes | HashDupes | HashDupesWMsgId |
     CommonDupeBase>'
Example:
     'dupeBaseType HashDupesWMsgId'

TextDupes
     stores from, to, subj & msgid as text lines.
HashDupes
     stores src32 of from + to + subj + msgid.
HashDupesWMsgId
     same as HashDupes, but stores also msgid as text.
CommonDupeBase
     stores hashes of from + to + subj + areatag + msgid in one file
     (hpt_base.dpa)

   Default is 'HashDupesWMsgId'.

   This statement cannot be repeated.

3.3.4 DupeHistoryDir
--------------------

Syntax:
     'dupeHistoryDir <path>'
Example:
     'dupeHistoryDir /var/spool/fido/dupes'

   This command specifies the path where the dupe history files are
stored.  The format and the names of the dupe-files are not
standardized.

   This statement cannot be repeated.

3.3.5 EchoTossLog
-----------------

Syntax:
     'echotosslog <file>'
Example:
     'echotosslog /var/spool/fido/echotoss.log'

   This statement specifies the file which is filled by a message editor
or "hpt post" with the names of the areas where new netmails or
echomails have been entered.  Each line contains one areaname.  When
"hpt scan" is invoked, only echomail areas listed in this file will be
scanned, when we start "hpt pack" - the same is for netmail areas.  If
area was processed, its name is removed from echotosslog file.  When hpt
has finished processing all listed areas and this file became empty, it
is removed, otherwise kept for futher processing (maybe by other
programs).  If this file is not found - all areas will be scanned
(depending on value of PackNetMailOnScan).  See PackNetMailOnScan,
but if '-f' command line flag specified, scanning will stop.  Filename
after -f is optional.  If it is not set, value of EchoTossLogFile will
be taken from config, and from command line otherwise.  If scanning from
EchoTossLogFile did not make any area scanning, all areas will be
processed (depending on 'scan' or 'pack' mode)

   This statement cannot be repeated.

3.3.6 FileBoxesDir
------------------

Syntax:
     'FileBoxesDir <directory>'
Example:
     'FileBoxesDir ../boxes'

   See FileBoxesDir (fidoconfig), for full description.

3.3.7 HptPerlFile
-----------------

Syntax:
     'hptperlfile <file>'
Example:
     'hptperlfile /etc/ftn/filter.pl'

   This statement specifies the file which contains perl filter
functions.  If not specified, perl support will be switched off.

   This statement cannot be repeated.

3.3.8 ImportLog
---------------

Syntax:
     'importlog <file>'
Example:
     'importlog /var/spool/fido/import.log'

   This statement specifies the file which a tosser fills with the names
of the areas where echomails has been tossed in.

   This statement cannot be repeated.

3.3.9 Intab
-----------

Syntax:
     'intab <file>'
Example:
     'intab /var/spool/fido/recode/outaltkoi8'

   This statement specifies the file which should be used to recode the
characters of the incoming messages from transport to internal charset.
It is useful in russia.  If you do not use this statement no recoding
will be done.

   This statement cannot be repeated.

3.3.10 MinDiskFreeSpace
-----------------------

Syntax:
     'MinDiskFreeSpace <integer>'
Example:
     'MinDiskFreeSpace 10'

   This is the minimum disk free space in MB to run HPT. The following
directories are checked: 'TempInbound', 'MsgBaseDir', 'LinkMsgBaseDir's.

   The default value is 10.

   This statement cannot be repeated.

3.3.11 MsgBaseDir
-----------------

Syntax:
     'msgBaseDir <path>'
Example:
     'msgBaseDir /var/spool/fido/msgb'

   This command specifies the path where msgBases of autocreated areas
are stored.  For example: if an area called 'LINUX.GER' was autocreated
and the msgBaseDir is '/var/spool/fido/msgb' the resulting msgBaseName
is

     /var/spool/fido/msgb/linux.ger.sqd

   If you specify the msgbasedir as PASSTHROUGH, the areas will be
created as passthrough areas.

   This statement cannot be repeated.

   See LinkMsgBaseDir.

3.3.12 NotValidFileNameChars
----------------------------

Syntax:
     'NotValidFileNameChars <string>'
Example:
     'NotValidFileNameChars :;<>=*?\/'

   This characters in message and dupebase filenames will be replaced
with %hex analogs.  If not defined, default string used:
"*/:;<=>?\|%''&+

   This statement cannot be repeated.

3.3.13 Outtab
-------------

Syntax:
     'outtab <file>'
Example:
     'outtab /var/spool/fido/recode/outkoi8alt'

   This statement specifies the file which should be used to recode the
characters of the outgoing messages from internal to transport charset.
It is useful in russia.  If you do not use this statement no recoding
will be done.

   This statement cannot be repeated.

3.3.14 RulesDir
---------------

Syntax:
     'rulesdir <path>'
Example:
     'rulesdir /home/ftn/rules'

   This statement specifies where areafix searches for files with
echoarea rules which are sent to link via netmail when link is
subscribed to areas.  File name is the same as message base file with
trailing ".rul" (and consistently .ru1-.ru9 files with additional
information).  Areaname is used when no message base file is set.  See
also 'NoRules' statement to avoid areafix from sending rules to link.

   This statement cannot be repeated.

3.3.15 StatLog
--------------

Syntax:
     'statlog <file>'
Example:
     'statlog /var/spool/fido/stat.log'

   After tossing (hpt toss), it is checked if there is new personal mail
(netmail or personal echo mail).  If that's true, it is checked if
statlog is defined in config.  If yes, then it is checked if the log
file exists.  If not, then it is created and the number of received
netmails or/and personal echo mails is written to the log file.
Otherwise, if the file exists, the old counter will be read, added to
the new counter and written the actual counter.  The log file looks like
this: netmail: x CC: x Whereas x is the number of mails.  If the log
file exists, one of the two or both lines exist.

   This is for utils, which can show you how many personal mail you got.
The log file is not removed by hpt, only by the util that uses it.  Or
you could write in your toss script something like this: if exist
stat.log type stat.log if exist stat.log del stat.log>nul

   This statement cannot be repeated.

3.3.16 TempInbound
------------------

Syntax:
     'tempinbound <path>'
Example:
     'tempinbound /var/spool/fido/in.tmp'

   This command specifies a path which is used while tossing.  The
incoming packets are unpacked there.

   This statement cannot be repeated.

3.3.17 TempOutbound
-------------------

Syntax:
     'tempoutbound <path>'
Example:
     'tempoutbound /var/spool/fido/out.tmp'

   This command specifies your temporary outbound path.  It is used for
storing outgoing pkt-files before packing.

   This statement cannot be repeated.

3.4 Link Keywords
=================

See AreafixReportsAttr (fidoconfig):: set flags to areafix reports
for the link

   HPT is based on FIDOCONFIG library, so read documentation of
FIDOCONFIG about location of config file, keywords ideology and about
majority of the keywords, see Fidoconfig Manual (fidoconfig).

3.4.1 AdvancedAreafix
---------------------

Syntax:
     'advancedareafix <bool>'
Example:
     'advancedareafix on'

   If this statement is "on" and our system wants to delete an area from
remote config then unsubscribe messages to areafix robot of this link
look like "~areaname".  The area on the remote system will be deleted
from config file, if our system is allowed to delete this area ("allow
area delete" in FastEcho, and LinkGrp must be the same as
EchoArea's '-g <group>' in HPT).

   Our system sends deleting command only for systems with
'AdvancedAreafix' and with UnsubscribeOnAreaDelete set to "on"
and when default uplink ('-def') unsubscribes from an EchoArea or some
link deletes this area by "~areaname" command.  Of course if this link
has the rights to delete this area.

   You may also delete an area yourself by running the following
command:

'hpt afix <your main AKA> ~area'

Here '<your main AKA>' is your main address.  See
address (fidoconfig).

   If 'AdvancedAreafix' for the link is "off" (default), then
unsubscribe command "-areaname" is sent instead of delete command
"~areaname".

   This statement can only be repeated for different links.

3.4.2 AllowEmptyPktPwd
----------------------

Syntax:
     'allowEmptyPktPwd <off|secure|on>'
Example:
     'allowEmptyPktPwd on'

   This flag is useful if you want to generate packet passwords for this
link, but do not want to check the packet passwords that your link sends
to you.  This is sometimes necessary as a workaraound if your link sends
you netmail packets without packet passwords, for example.

   The default state is off.  In this case the incoming packet password
must match the packet password that you defined.  This is the most
secure option.

   If you set this switch to 'secure', packets that do not contain a
packet password and are received in the protected inbound will be
processed.  You can use this if your uplink sometimes sends you packets
without packet passwords, as a workaround until the uplink has fixed his
system.  Still, if you receive packets with _wrong_ packet passwords,
they will be rejected.

   The setting 'on' works like the 'secure' setting, with the difference
that packets without packet passwords are allowed even in the
unprotected inbound directory.  It is not recommended to use this
setting.

   This statement can only be repeated for different links.

3.4.3 AllowPktAddrDiffer
------------------------

Syntax:
     'allowPktAddrDiffer <bool>'
Example:
     'allowPktAddrDiffer on'

   This keyword is useful if your link has more than one addresses, and
therefore the address in PKT header of his areafix request may be
different from the address in MSG header.

   The default state if 'off': in this case such letters won't be
processed by your areafix.  The state 'on' makes areafix ignore this
error.

   This statement can only be repeated for different links.

3.4.4 AllowRemoteControl
------------------------

Syntax:
     'allowRemoteControl <bool>'
Example:
     'allowRemoteControl on'

   If this keyword is 'on' then link can do remote control using
areafix.  Sending command "%from <addr>" (where <addr> is the address of
any link, defined in config) he makes areafix behave as if the message
came from that link.

   You should enable this keyword only for yourself or cosysop, as it
allows changing other links' subscription and settings without knowing
their passwords.

   The default state if 'off': remote control is disabled.

   This statement can only be repeated for different links.

3.4.5 ArcmailSize
-----------------

Syntax:
     'arcmailsize <integer>'
Example:
     'arcmailsize 300'

   Maximum arcmail size in kb for this link.  Default is 500kb.

   This statement can only be repeated for different links.

3.4.6 ArcNetmail
----------------

Syntax:
     'arcnetmail <bool>'
Example:
     'arcnetmail on'

   This keyword is useful if you want to compress netmail for this link
and pack it into arcmail bundles or to filebox like echomail.  A netmail
message will be packed and compressed into a bundle only if its flavour
is equal to 'EchoMailFlavour' for this link.

   The default state if 'off': in this case netmail will be written to
ut-file (i.e.  *.?ut) and will not compressed.

   This statement can only be repeated for different links.

3.4.7 Areafix
-------------

Syntax:
     'areafix <bool>'
Example:
     'areafix off'

   By default areafix is "on".  You can turn off using of areafix by
this link.

   This statement can only be repeated for different links.

3.4.8 AutoAreaCreateSubdirs
---------------------------

Syntax:
     'autoareacreatesubdirs <bool>'
Example:
     'autoareacreatesubdirs on'

   This switch is turned off by default.  When turned off, hpt will
create a flat message base.  This means that a file echo
'FIDOSOFT.HUSKY' would be created in the message base directory with a
base file name of 'fidosoft.husky', like in
'/var/spool/msgbase/fidosoft.husky.sqd' and so on.

   When turned on, a structured message base will be created.  Each dot
in the echo name is treated as directory separator.  Thus,
'FIDOSOFT.HUSKY' would be created with a base name of 'husky' in the
'fidosoft' directory, e.g.  '/var/spool/msgbase/fidosoft/husky.sqd'.

   Please note that this option will _not_ currently work if the
'-dosfile' option is used to create filenames in 8.3 convention.  See
EchoArea (fidoconfig), for more information on the '-dosfile'
option.

3.4.9 AutoPause
---------------

Syntax:
     'autopause <integer>'
Example:
     'autopause 10'

   AutoPause sets the number of days after which HPT will stop exporting
echomail for the link if he has not fetched his echomail for this period
of time.  AutoPassive should be defined for AutoPause to take
effect.

   Technically, if you define "autopause 10" for a link then HPT looks
for 10 (or more) days old files that are listed to be sent for this link
in the .?lo files with '#' or '^' prefixes and reside in the outbound
directory.  If at least one such file exists, exporting echomail for the
link is paused.

   This statement can only be repeated for different links.

   See also AutoPassive and Pause (fidoconfig) sections.

3.4.10 AvailList
----------------

Syntax:
     'AvailList (Full|Unique|UniqueOne)'
Example:
     'AvailList Full'

   This statement specify variant for reply to %avail command for
current link:

* Full        produce full areas list for each uplink with avaiable forward
              subscribe for link
* Unique      like 'Full' but exclude dulicated areas for each next uplink
* UniqueOne   produce one list: all areas from all uplinks without
              duplicates

   Default value is 'AvailList Full'.

   This statement can only be repeated for different links.

3.4.11 DailyBundles
-------------------

Syntax:
     'dailyBundles <bool>'
Example:
     'dailyBundles'

   If DailyBundles is off, hpt will use existing arcmail bundles to add
packets for this link, even if they were created in the previous days.
If DailyBundles is set, a new arcmail bundle for the link will be
started when the new day begins.

   This statement can only be repeated for different links.

3.4.12 DenyRescan
-----------------

Syntax:
     'denyRescan <bool>'
Example:
     'denyRescan'

   Don't allow to rescan areas (via areafix) to your links.

   This token can be applied to one or several area groups (see
'RescanGrp' token for details).

   This statement can only be repeated for different links.

3.4.13 EchoMailFlavour
----------------------

Syntax:
     'echoMailFlavour <hold | normal | crash | direct | immediate>'
Example:
     'echoMailFlavour hold'

   This statement sets the flavour which outgoing echomails for this
link get.  For example set echomailFlavour for points to hold and for
uplink crash.

   This statement can only be repeated for different links.

3.4.14 Flavour
--------------

Syntax:
     'flavour <hold | normal | crash | direct | immediate>'
Example:
     'flavour hold'

   This statement sets the flavours for netmail, echomail and fileechoes
simultaneously.  Note that you can combine this with 'netMailFlavour',
'echoMailFlavour' or 'fileEchoFlavour'; in this case the latest flavour
is applied.

   This statement can only be repeated for different links.

3.4.15 ForwardPkts
------------------

Syntax:
     'forwardPkts <off|secure|on>'
Example:
     'forwardPkts yes'

   If we receive a PKT file that is not addressed to our system, but to
this link of us, this flag controls if the PKT file should be binary
forwarded to this link.  The default behaviour is not to forward the pkt
file, but to remain it to '<filename>.ntu' and leave it in the inbound.
If you specify '<yes>', the file will instead be forwarded to the
destination link (i.E. put into his arcmail bundle).  If you specify
'<secure>', the file will only be forwarded if we have received it in
the secure inbound.  You should specify 'secure' if the destination link
does not check packet passwords.

   PKT forwarding can be useful for tunneling purposes, for instance.
Another example is if you are running two nodes, one IP node at your
company and one PSTN node at your home.  If you want to show both node
numbers at both mailers, the tossers at each node must forward PKT files
that are addressed to the other node, because they themselves cannot
process it (each tosser has a different node number, because the systems
operate on distinct outbound structures and distinct message base
areas).

   This statement can only be repeated for different links.

   WARNING! This statement also enables file forwarding in htick!

3.4.16 FileBox
--------------

Syntax:
     'FileBox <directory>'
Example:
     'FileBox boxes/2.5021.19.1'

   This statement defines directory where outgoing files for link would
be putten instead of putting them in 'Outbound' tree.  See also
'FileBoxAlways' for details.

   Currently hpt can put only echomail into fileBoxes.

   This statement can only be repeated for different links.

3.4.17 FileBoxAlways
--------------------

Syntax:
     'FileBoxAlways <bool>'
Example:
     'FileBoxAlways'

   Pack to link 'FileBox' even if link is not busy.  By default outbound
is used when link is not busy.

   This statement can only be repeated for different links.  Works only
for links which have 'FileBox' or when 'FileBoxesDir' is set.

   See FileBox, FileBoxesDir.

3.4.18 LinkBundleNameStyle
--------------------------

Syntax:
     'linkBundleNameStyle <timeStamp | addrDiff | addrDiffAlways |
     addrsCRC32 | addrsCRC32Always | Amiga>'
Example:
     'linkbundleNameStyle addrDiff'

   This statement sets rule for creating names of arcmail bundles for
link.  It is similar 'BundleNameStyle' keyword.

   See BundleNameStyle.

   This statement can only be repeated for different links.

3.4.19 LinkGrp
--------------

Syntax:
     'LinkGrp <Group name>'
Example:
     'LinkGrp INTERNATIONAL'

   Specifies a group to use for areas auto-created from this link.  Also
link can delete echo areas in his 'LinkGrp' group.

   In this exmaple:

   1) string 'INTERNATIONAL' will be added to a new area record unless
'AutoCreateDefaults' defines implicit group;

   2) links that have no access to group 'INTERNATIONAL' can't forward
requests to uplink with 'LinkGrp INTERNATIONAL';

   3) this link can delete echo areas with '-g INTERNATIONAL' group if
'AdvancedAreafix' is enabled for this link.

   See AdvancedAreafix.

   This statement can only be repeated for different links.

3.4.20 LinkMsgBaseDir
---------------------

Syntax:
     'linkMsgBaseDir <path>'
Example:
     'linkMsgBaseDir /var/spool/fido/msgb'

   Same as 'MsgBaseDir', but you can set it for different links.  *Do
not use it with* 'LinkDefaults'!

   This statement can only be repeated for different links.

   See MsgBaseDir.

3.4.21 NetMailFlavour
---------------------

Syntax:
     'netMailFlavour <hold | normal | crash | direct | immediate>'
Example:
     'netMailFlavour crash'

   This statement sets the flavour for outgoing netmail routed via this
link.

   This statement can only be repeated for different links.

3.4.22 NoRules
--------------

Syntax:
     'norules <bool>'
Example:
     'norules on'

   By default "norules off" i.e.  send rules.

   This statement points to areafix to not send area rules to link when
link is subscribed to area and corresponding file is found in
'RulesDir'.

   This statement can only be repeated for different links.

3.4.23 PackAka
--------------

Syntax:
     'PackAka <addr>'
Example:
     'PackAka 2:4600/220'

   This statement sets the aka to which the echomail and fileechos will
be sent (Pack echomail and fileechos via third link).  The PackAka link
used only in BSO, fileboxes and arcmail filename creation, therefore the
PackAka link may not present in config.

   This feature may be used for simple echomail routing.

   This statement can only be repeated for different links.

3.4.24 PktSize
--------------

Syntax:
     'pktsize <integer>'
Example:
     'pktsize 300'

   Maximum pkt size in kb for this link.  Default - unlimited.

   This statement can only be repeated for different links.

3.4.25 ReducedSeenBY
--------------------

Syntax:
     'ReducedSeenBY <bool>'
Example:
     'ReducedSeenBY on'

   This statement turns on/off reduced seen-by algorithm (FSC-0093)

     RSB algorithm
     -------------
     1) add own system to the PATH.
     2) all area links not contained in the RSB qualify as recipients.
     3) strip RSB addresses not matching an address in the PATH, then
        add own address(es) to the RSB set if not already contained.
     4) add recipients to RSB, sort RSB and forward mail to recipients.

   This statement can only be repeated for different links.

3.4.26 RescanGrp
----------------

Syntax:
     'RescanGrp <string>[,<string>...]'
Example:
     'RescanGrp A,B,C,Local'

   If defined, 'denyRescan' token applies to specified area groups only,
while other area groups are applied with the opposite value.

   Example:

   There are areas with the groups A, B, C and D in config.  The
following table demonstrates how combination of options allows you to
specify different rights for link.

denyRescan off
     All area groups are allowed to rescan.
denyRescan on
     All area groups are denied to rescan.
denyRescan off, rescanGrp A,B
     Area groups A and B are allowed to rescan, while C and D are
     denied.
denyRescan on, rescanGrp A,B
     Area groups A and B are denied to rescan, while C and D are
     allowed.

   This statement can only be repeated for different links.

3.4.27 RescanLimit
------------------

Syntax:
     'RescanLimit <number>'
Example:
     'RescanGrp 100'

   This keyword is used to limit max number of messages sent by %rescan
command.  If it's set to 0 (default), the link is not limited.

   This statement can only be repeated for different links.

3.4.28 SendNotifyMessages
-------------------------

Syntax:
     'sendNotifyMessages <bool>'
Example:
     'sendNotifyMessages on'

   If sendNotifyMessages is true, link will receive notification
messages from areafix about link's requests status, bad posts or
deletion of subscribed area.

   By default is off, i.e.  do not send any notification messages.

   This statement can only be repeated for different links.

3.4.29 UnsubscribeOnAreaDelete
------------------------------

Syntax:
     'unsubscribeOnAreaDelete <bool>'
Example:
     'unsubscribeOnAreaDelete yes'

   If unsubscribeOnAreaDelete is true, link will receive unsubscribe
request ("-area" if AdvancedAreafix is off for the link and
"~area" if it is on) to his areafix when subscribed area is deleted.  An
area may be deleted when default uplink ('-def') unsubscribes from the
area or some link deletes this area by "~area" command (see LinkGrp
for the link that deletes an area must be the same as EchoArea's '-g
<group>').  You may also delete an area yourself by running the
following command:

'hpt afix <your main AKA> ~area'

Here '<your main AKA>' is your main address.  See
address (fidoconfig).

   By default is off, i.e.  do not send unsubscribe request.

   This statement can only be repeated for different links.

3.5 Carbon Copy
===============

HPT is based on FIDOCONFIG library, so read documentation of FIDOCONFIG
about location of config file, keywords ideology and about majority of
the keywords, see Fidoconfig Manual (fidoconfig).

3.5.1 CarbonAddr
----------------

Syntax:
     'carbonAddr <addr>'
Example:
     'carbonAddr 2:5000/100'
     'carbonCopy mail.from.100'

   If an echomail is tossed whose from address field is the same as
<addr>, the echomail is copied to the area specified by the 'carbonCopy'
keyword.

   This statement can be repeated.

3.5.2 CarbonAndQuit
-------------------

Syntax:
     'carbonAndQuit <bool>'
Example:
     'carbonAndQuit'

   By default one message can be processed by Carbon Copy several times.
For example: you set CarbonTo "max" to echoarea MY.MAIL and CarbonSubj
"beer" to echoarea MY.PLEASURE :-) And message to "max" with this
subject line carbons to each 'EchoArea'.

   If you turn on 'CarbonAndQuit' message will be copyed to MY.MAIL
only.

   It is however possible to override this setting, by putting an '*'
before the action:
          CarbonCopy *my.mail
          CarbonMove *my.mail
          CarbonExtern *<command line>

   This '*' does not work for CarbonDelete of course.

   This statement cannot be repeated.

3.5.3 CarbonCopy
----------------

Syntax:
     'carbonCopy <area-tag>'
Example:
     'carbonCopy written.from.points'

   This statement sets the area for the previous
carbon{Addr|To|From|Kludge|Subj|Text} statement.

   If no 'EchoArea' defined to copy, the carbon msgs goes to the
'BadArea'.

   Note: You cannot carbonCopy a message from EchoArea to NetmailArea
and vice versa.

   This statement can be placed after different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statements.

   See CarbonMove.

3.5.4 CarbonDelete
------------------

Syntax:
     'carbonDelete'
Example:
     'carbonDelete'

   This statement specifies that the messages selected by a previous
'carbonAddr' or 'carbonTo' or 'carbonFrom' or 'carbonKludge' or
'carbonSubj' or 'carbonText' statement should not be stored into
'EchoArea'.

   This statement can be repeated for each different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

3.5.5 CarbonExcludeFwdFrom
--------------------------

Syntax:
     'CarbonExcludeFwdFrom <bool>'
Example:
     'CarbonExcludeFwdFrom'

   Don't add to begin of carbon msg text " * Forward from area
<areatag>"

   This statement cannot be repeated.

3.5.6 CarbonExtern
------------------

Syntax:
     'carbonExtern <program name>'
Example:
     'carbonExtern douuedecode'

   This statement specifies external program to run for the previous
'carbonAddr' or 'carbonTo' or 'carbonFrom' or 'carbonKludge' or
'carbonSubj' or 'carbonText' statement.

   If this statement is ommitted and no 'EchoArea' defined for move or
copy, the carbon msgs gets copyed to the 'BadArea'.

   If program name is prepended with '|' sign, hpt tries to pass data
through a pipe, not a temporary file.

   This statement can be repeated for each different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

3.5.7 CarbonFrom
----------------

Syntax:
     'carbonFrom <pattern>'
Example:
          carbonFrom Matthias Tichy
          carbonCopy my.echomail

   If an echomail is tossed whose from-field matched the pattern
<pattern>, the echomail is copied to the area specified by the
'CarbonCopy' keyword or moved to the area specified by the 'CarbonMove'
keyword.  The names must be an exact match.

   You can enclose <string> into quotes ("<string>").

   This statement can be repeated.

3.5.8 CarbonFromArea
--------------------

Syntax:
     'CarbonFromArea <pattern>'
Example:
     'CarbonFromArea Interuser'

   Only messages that are written in this areas will be copied.  Use it
in combination with CarbonRule to prevent that all messages from an area
are copied.

   See CarbonRule.

   Another example:
     CarbonFromArea Interuser
     CarbonRule NOT
     CarbonText " Israel "
     CarbonCopy my.news

   <pattern> is the mask for area name, defined after EchoArea or
NetMailArea.

   This statement can be repeated.

3.5.9 CarbonGroups
------------------

Syntax:
     'carbonGroups <string> [,<string>...]'
Example:
     'carbonGroups Fido, LifeNet'
     'carbonCopy my.echomail'

   With this keyword you can define from which groups messages should be
copied.  It is wise when you use this keyword together with other
selection criteria or else the result will give many messages.

   See CarbonRule.

   This statement can be repeated.

3.5.10 CarbonKeepSb
-------------------

Syntax:
     'carbonKeepSb <bool>'
Example:
     'carbonKeepSb'

   For each CC message SEEN-BY's and PATH fields are killed.  If you set
up 'CarbonKeepSb' then all kludges will be saved.  But you may also set
up '-keepsb' in options of 'EchoArea' where you carbon messages.

   This statement cannot be repeated.

3.5.11 CarbonKludge
-------------------

Syntax:
     'carbonKludge <pattern>'
Example:
     'carbonKludge MSGID: 2:5000/117.'
     'carbonCopy written.by.points'

   If an echomail is tossed which has a kludge line which includes the
substring matches <pattern>, the echomail is copied to the area
specified by the 'CarbonCopy' keyword.

   You can enclose <pattern> into quotes ("<pattern>").
     carbonKludge "REPLY: 2:5000/117 "

   This statement can be repeated.

3.5.12 CarbonMove
-----------------

Syntax:
     'carbonMove <area-tag>'
Example:
     'carbonMove my.echomail'

   This statement sets the area for the previous 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

   If no 'EchoArea' defined to copy (or move), the carbon msgs goes to
the 'BadArea'.

   Note: You cannot carbonMove a message from EchoArea to NetmailArea
and vice versa.

   Unlike 'CarbonCopy' msg gets moved, not copied into this area.

   This statement can be placed after different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statements.

   See CarbonCopy.

3.5.13 CarbonOut
----------------

Syntax:
     'carbonOut <bool>'
Example:
     'carbonOut'

   This statement makes possible carbon your outgoing mail (scanned &
packed).  Don't forget to set carbon rules.

   This statement cannot be repeated.

3.5.14 CarbonReason
-------------------

Syntax:
     'carbonReason <string>'
Example:
     'carbonText msged'
     'carbonReason Found 'msged' in message'
     'carbonCopy my.searches.echo'

   This statement sets the 'reason string' for the previous 'carbonAddr'
or 'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

   This string would be printed after ' * Forwarded ...'  line in
message begining.  That's useful when many carbons are made to single
area.  No reason string is printed if this statement is ommitted.

   This statement can be repeated for each different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

3.5.15 CarbonRule
-----------------

Syntax:
     'carbonRule AND|NOT|OR'
Example:
          carbonGroups fido
          carbonRule AND
          carbonText programming
          carbonCopy my.echomail

   With this keyword you can make it possible to have more than 1
selection criteria for a message.  The default rule is AND. So without
using CarbonRule, all expressions will be AND-ed.  With Carbonrule AND,
the two expressions above and below the AND must be true or else a
message will not be copied.  With Carbonrule you can define how the
expressions are joined together.

   CarbonRule NOT, is in fact AND NOT. So

             CarbonText beatles
             CarbonRule NOT
             CarbonText bugs
             CarbonCopy my.mail

   ...will only copy messages when 'beatles' is in the text AND NOT
'bugs' in the text.

   In general, it is possible to define more than one set of rules for 1
single carbonArea.  For example:
             CarbonText female
             CarbonRule NOT
             CarbonText connector
             CarbonRule OR
             CarbonSubj beer
             CarbonRule AND
             CarbonText drink
             CarbonText holliday
             CarbonCopy my.mail
   Here are two sets of criteria and for all of them there is only 1
carbonarea defined.  After an OR, a new set of expressions start.  The
above example can also be written as:
             CarbonRule NOT
             CarbonText connector
             CarbonRule AND
             CarbonText female
             CarbonRule OR
             CarbonRule AND
             CarbonSubj beer
             CarbonText drink
             CarbonText holliday
             CarbonCopy my.mail

   Messages that have 'female' in the text, but not the word
'connector', will be copied to the my.mail area.

   Also messages with 'beer' in the text AND 'drink' in the text AND
'holliday' in the text, will be copied to the my.mail area.

   A set of expressions is true when they are OR-ed and at least one of
them is true.

   A set of expressions is true when they are AND-ed and ALL of them are
true.  Expressions are evaluated from top to bottom.

   This statement can be repeated.

   A CarbonRule is valid until a next rule is defined of until an
action.  After an action (CarbonCopy, CarbonMove, etc), the CarbonRule
is AND again and new set of expressions starts.

3.5.16 CarbonSubj
-----------------

Syntax:
     'carbonSubj <pattern>'
Example:
     'carbonSubj beer'
     'carbonCopy cc.beer'

   If an echomail is tossed which has a subject line matched <pattern>,
this echomail is copied to the area specified by the 'CarbonCopy'
keyword or moved to the area specified by the 'CarbonMove' keyword.  You
can enclose <pattern> into quotes ("<pattern>").

   This statement can be repeated.

3.5.17 CarbonText
-----------------

Syntax:
     'carbonText <pattern>'
Example:
     'carbonText cool beer'
     'carbonCopy cc.beer'

   If an echomail is tossed which has a kludge line which includes the
substring matches <pattern>, the echomail is copied to the area
specified by the 'CarbonCopy' keyword or moved to the area specified by
the 'CarbonMove' keyword.

   You can enclose <pattern> into quotes ("<pattern>").

   This statement can be repeated.

3.5.18 CarbonTo
---------------

Syntax:
     'carbonTo <pattern>'
Example:
     'carbonTo Max Levenkov'
     'carbonCopy my.echomail'

   If an echomail is tossed whose to-field matched <pattern>, the
echomail is copied to the area specified by the 'CarbonCopy' keyword or
moved to the area specified by the 'CarbonMove' keyword.  The names must
be an exact match.

   You can enclose <pattern> into quotes ("<pattern>").

   This statement can be repeated.

3.5.19 ExcludePassthroughCarbon
-------------------------------

Syntax:
     'excludePassthroughCarbon <bool>'
Example:
     'excludePassthroughCarbon'

   Don't carbon from passthrough areas.

   This statement cannot be repeated.

3.5.20 NetmailExtern
--------------------

Syntax:
     'netmailExtern <program name>'
Example:
     'netmailExtern douuedecode'

   This statement specifies external program to run for the previous
'carbonAddr' or 'carbonTo' or 'carbonFrom' or 'carbonKludge' or
'carbonSubj' or 'carbonText' statement for netmail messages...

   If this statement is ommitted and no 'NetMailArea' defined for move
or copy, the carbon msgs gets copyed to the 'BadArea'.

   If program name is prepended with '|' sign, hpt tries to pass data
thru the pipe, not temporary file.

   This statement can be repeated for each different 'carbonAddr' or
'carbonTo' or 'carbonFrom' or 'carbonKludge' or 'carbonSubj' or
'carbonText' statement.

4 Advanced Concepts in HPT
**************************

This chapter describes how to use some features...  After you have
managed to perform basic functions with HPT, like defining paths &
areas, this chapter will introduce you into some advanced concepts in
HPT that deserve special attention, like how to use several netmail
areas and similar.

4.1 HPT Exit Codes
==================

0 - successful termination
64 - command line usage error
66 - cannot open input (file)
69 - service unavailable [config file not found]
70 - internal software error [not enough memory, etc.]
73 - can't create (user) output file [lockfile]
74 - input/output error
75 - temp failure; user is invited to retry [lockfile used by second copy of hpt]
78 - configuration error

4.2 Renaming Suffixes For Pkt Files
===================================

.tos - hpt crashes on this pkt, report to developers!
.sec - a) pktpwd problem or link not found; b) bundles in unsecure inbound
.acs - could not open pkt
.bad - a) not/wrong pkt; b) bundle unpacking problems
.ntu - not to us
.err - msg tossing problem (couldn't open badArea/couldn't write msg)
.flt - perl filter (process_pkt()) returns bad retcode

4.3 Defining Several Netmail Areas For Several Users
====================================================

If you want receive netmail for one address in first netmail area, and
for second address in second netmail area respectively, you must add '-a
<ourAka>' to netmail area, like this:

Address 2:5000/117
Address 2:90/190
NetmailArea NetMail /home/ml/fido/msgb/netmail -b squish -a 2:5000/117
NetmailArea OtherNetMail /home/ml/fido/msgb/othernetmail -b squish -a 2:90/190

4.4 How Zone Gating works for echomail and what seen-bys is stripped
====================================================================

We have EchoArea with links from zone1 & zone2.  Echo->useAka with
zone2.  Defined by "-a <addr>" or the by the first Echo->address from
config if not defined in EchoArea line.

   Program algorythm:

1.
     check pkt zone address
2.
     split links in to groups: with (pktaddr.zone == linkaddr.zone) and
     (pktaddr.zone != linkaddr.zone)
3.
     send msg to first group of links (their aka adding to seen-bys and
     echo->useAka too if not in seen-bys yet)
4.
     if (pktaddr.zone != echo->useAka.zone) seen-bys cleaned.
5.
     send msg to second group of links (their aka adding to seen-bys and
     echo->useAka too if not in seen-bys yet)
6.
     store msg in msgbase

   Examples:

   a) msg comes from z1.  for z1 links we sending seen-bys with z2
nodes.  but z1 links must clean seen-bys by themselves (this is z2 echo)
or download this echo from z1 link.  after that seen-bys cleaned and msg
forwarded to z2 links.  in the msgbase seen-bys from z2 links only.

   b) msg comes from z2.  forward it to z2 links.  then forward to z1
links.  seen-bys not cleaned: this is z2 echo and z1 links must clean it
by themselves or receive echo from z1 link.  store in msgbase with all
seen-bys from z1 & z2 nodes.

   c) scan works the same: first sending to z2 links, adding to
seen-by's z1 links and export to them.

4.5 Perl support in HPT
=======================

HPT may be compiled with support for calling Perl subs in some parts of
its work.  In this case it also provides API for such subs (Perl hooks).
Perl subs are located in file filter.pl, which usually located in same
directory as HPT's executable file but it's name and location may
changed via 'HptPerlFile' configuration option.  The following Perl
hooks are supported:
1.
     after_unpack - called after unpacking an echomail bundle to
     'TempInbound'
2.
     before_pack - called before packing echomail bundle to one of links
3.
     process_pkt - called before processing pkt, the following variables
     available:
     $pktname - name of pkt,
     $secure - defined if this pkt from secure link
     hook must return "" for normal pkt processing or other string to
     rename pkt to .flt
4.
     pkt_done - called after pkt processing, the following variables
     available:
     $pktname - name of pkt,
     $rc - exit code(0-ok),
     $res - reason(exit code in text form):
          0 - OK ($res undefined),
          1 - Security violation,
          2 - Can't open pkt,
          3 - Bad pkt format,
          4 - Not to us,
          5 - Msg tossing problem
5.
     hpt_exit - called before hpt completely exit if any other Perl hook
     was called during this session.
6.
     route - called just before routing netmail message, the following
     variables availble:
     $addr - message destination address,
     $from - message originating address,
     $toname - destination user name,
     $fromname - originating user name,
     $subject - message subject line,
     $date - message date and time,
     $text - message text,
     $attr - message attributes,
     $route - default route for this message (derermined
          via 'Route' statements in config file (may be empty, this
          means that either no route at all for this message or it will
          be routed via one-to-multi routing(Route normal noroute
          2:5004/73.*)).

     Before return you can set $flavour - to
     hold|normal|crash|direct|immediate for required flavour of message.
     return "" for default routing or address via which this message
     should be sent.  example:

            sub route {
              if ($from eq "2:5004/75.73") return "2:5004/75.0";
              else return "";
            }

     if source address of message is 2:5004/75.73 then route it via
     2:5004/75, otherwise route it using default routing
7.
     scan - called while scanning messages (hpt scan or hpt pack).  The
     following variables available:
     $fromname - originating user name,
     $fromaddr - message originating address,
     $toname - destination user name,
     $toaddr - message destination address (for netmail),
     $area - message area (for echomail),
     $subject - message subject line,
     $date - message date and time,
     $text - message text,
     $attr - message attributes.
     Set $change to update $text, $subject, $fromaddr, $toaddr,
     $fromname, $toname, $attr.  If returns non-empty string (reason),
     the message will not pack to downlinks.
8.
     filter - called for processing every message while tossing.  The
     following variables available:
     $fromname - originating user name,
     $fromaddr - message originating address,
     $toname - destination user name,
     $toaddr - message destination address (for netmail),
     $area - message area (for echomail),
     $subject - message subject line,
     $date - message date and time,
     $text - message text,
     $attr - message attributes,
     $pktfrom - address of originating pkt,
     $secure - defined if the message received from secure link.
     Set $change to update $text, $subject, $fromaddr, $toaddr,
     $fromname, $toname, $attr.  Set $kill for kill message.  If returns
     non-empty string (reason), the message will be moved to badarea.
9.
     tossbad - called when message will be put in badArea.  The
     following variables available:
     $fromname - originating user name,
     $fromaddr - message originating address,
     $toname - destination user name,
     $toaddr - message destination address (for netmail),
     $area - message area (for echomail),
     $subject - message subject line,
     $date - message date and time,
     $text - message text,
     $attr - message attributes,
     $pktfrom - address of originating pkt,
     $reason - reason, why badarea (text string).
     Set $change to update $text, $subject, $fromaddr, $toaddr,
     $fromname, $toname, $attr.  If returns non-empty string (reason)
     for kill the message.

4.6 How remote control using Areafix works
==========================================

You can remotely control and change other links' subscription and
options using Areafix.  Remote control will not give you full access on
your system, but will help you (or your cosysop) with some most common
tasks.

   Some terms first.

   Controlling link is a link that exercise remote control.  He should
be defined in config and should have allowRemoteControl token set to
"on".

   Controlled link is a link whose subscription and options are
controlled.  He should be defined in config too.

   Controlling link is allowed to send "%from <addr>" command to
Areafix, where <addr> is an address of controlled link.  All the next
commands till the end of message or till the next "%from" command will
be executed as if the message came from controlled link.  All the
reports will be sent to controlling link.  There can be as much "%from"
commands in message as you like.  If there was an error while processing
"%from" command (for example, address was not specified in "%from"
command), message processing will be stopped and controlling link will
receive notification message.

   Example of Areafix message:

     %from 2:450/210.1       <-- all next actions will be made with 2:450/210.1
     +ru.husky               <-- subscribe to ru.husky
     %areafixpwd testpwd     <-- change areafix password to 'testpwd'
     %from 2:450/210.5       <-- all next actions will be made with 2:450/210.5
     -bel.sysop              <-- unsubscribe from bel.sysop
     %linked                 <-- send list of linked areas

   As this function allows remote control of other links' subscription
and options without knowing their areafix passwords, you should enable
allowRemoteControl token only for yourself or your cosysop.

HPT is based on FIDOCONFIG library, so read documentation of FIDOCONFIG
about location of config file, keywords ideology and about majority of
the keywords, see Fidoconfig Manual (fidoconfig).

Appendix A Configuration File Keyword Index
*******************************************