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 in Fidoconfig manual.

Table of Contents


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 simply, isn’t it? Enjoy! :-)

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:
    1. 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.
    2. 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 in Fidoconfig manual.


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 define config variable version with value set to hpt version like MAJOR.MINOR.PATHLEVEL, i.e. 1.9.0 or 1.4.1. You may use this variable too for make common config for several hpt versions.

To test config for hpt only you may call tparser tool with parameters -Dmodule=hpt and (if need) -Dversion=1.9.0 (tparser 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 in Fidoconfig manual.


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 in 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 in fidoconfig to make it work) AND which are allowed to be paused (see -pause, -paused, -noautoareapause, -autoareapause in EchoArea in fidoconfig and AutoAreaPause in 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 in 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 in FidoConfig Manual directory like this:

2.5000.117.1.hut
2.5000.117.1.mo0

If SeparateBundles is on and packer in FidoConfig Manual 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:

flavournetmailflow
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 in Fidoconfig manual.


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 in fidoconfig or EchoAreaDefaults in 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 in FidoConfig Manual, 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, LinkMsgBaseDirs.

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.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 in Fidoconfig manual.


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 carbon{Addr|To|From|Kludge|Subj|Text} statements.

See CarbonMove.


3.5.4 CarbonDelete

Syntax:

carbonDelete

Example:

carbonDelete

This statement specifies that selected by previous carbon{Addr|To|From|Kludge|Subj|Text} statement msgs should not be stored into EchoArea.

This statement can be repeated for each different carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 thru the pipe, not temporary file.

This statement can be repeated for each different carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 carbon{Addr|To|From|Kludge|Subj|Text} 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 in Fidoconfig manual.

Appendix A Configuration File Keyword Index

Jump to:   A   B   C   D   E   F   H   I   K   L   M   N   O   P   R   S   T   U  
Index EntrySection

A
AddToSeenAddToSeen
AdvancedAreafixAdvancedAreafix
AdvStatisticsFileAdvStatisticsFile
AfterUnpackAfterUnpack
AllowEmptyPktPwdAllowEmptyPktPwd
AllowPktAddrDifferAllowPktAddrDiffer
AllowRemoteControlAllowRemoteControl
ArcmailSizeArcmailSize
ArcNetmailArcNetmail
AreafixAreafix
AreafixFromPktAreafixFromPkt
AreasFileNameCaseAreasFileNameCase
AreasMaxDupeAgeAreasMaxDupeAge
AutoAreaCreateSubdirsAutoAreaCreateSubdirs
AutoPassiveAutoPassive
AutoPauseAutoPause
AvailListAvailList

B
BeforePackBeforePack
BundleNameStyleBundleNameStyle

C
CarbonAddrCarbonAddr
CarbonAndQuitCarbonAndQuit
CarbonCopyCarbonCopy
CarbonDeleteCarbonDelete
CarbonExcludeFwdFromCarbonExcludeFwdFrom
CarbonExternCarbonExtern
CarbonFromCarbonFrom
CarbonFromAreaCarbonFromArea
CarbonGroupsCarbonGroups
CarbonKeepSbCarbonKeepSb
CarbonKludgeCarbonKludge
CarbonMoveCarbonMove
CarbonOutCarbonOut
CarbonReasonCarbonReason
CarbonRuleCarbonRule
CarbonSubjCarbonSubj
CarbonTextCarbonText
CarbonToCarbonTo

D
DailyBundlesDailyBundles
DefArcmailSizeDefArcmailSize
DenyRescanDenyRescan
DisableKludgeRescannedDisableKludgeRescanned
DisablePIDDisablePID
DisableTIDDisableTID
DupeBaseTypeDupeBaseType
DupeHistoryDirDupeHistoryDir

E
EchoMailFlavourEchoMailFlavour
EchoTossLogEchoTossLog
ExcludePassthroughCarbonExcludePassthroughCarbon

F
FileBoxFileBox
FileBoxAlwaysFileBoxAlways
FileBoxesDirFileBoxesDir
FlavourFlavour
ForwardPktsForwardPkts

H
HptPerlFileHptPerlFile

I
IgnoreCapWordIgnoreCapWord
IgnoreSeenIgnoreSeen
ImportLogImportLog
IntabIntab

K
KeepTrsFilesKeepTrsFiles
KeepTrsMailKeepTrsMail
KludgeAreaNetmailKludgeAreaNetmail

L
LinkBundleNameStyleLinkBundleNameStyle
LinkGrpLinkGrp
LinkMsgBaseDirLinkMsgBaseDir
LinkWithImportLogLinkWithImportLog

M
MinDiskFreeSpaceMinDiskFreeSpace
MsgBaseDirMsgBaseDir

N
NetmailExternNetmailExtern
NetmailFlagNetmailFlag
NetMailFlavourNetMailFlavour
NoProcessBundlesNoProcessBundles
NoRulesNoRules
NotValidFileNameCharsNotValidFileNameChars

O
OriginOrigin
OuttabOuttab

P
PackAkaPackAka
PackNetMailOnScanPackNetMailOnScan
PktSizePktSize
ProcessPktProcessPkt

R
RecodeMsgBaseRecodeMsgBase
ReducedSeenBYReducedSeenBY
RemapRemap
RescanGrpRescanGrp
RescanLimitRescanLimit
RouteRoute
RouteFileRouteFile
RouteMailRouteMail
RulesDirRulesDir

S
SendNotifyMessagesSendNotifyMessages
SeparateBundlesSeparateBundles
SetConsoleTitleSetConsoleTitle
SortEchoListSortEchoList
StatLogStatLog

T
TearLineTearLine
TempInboundTempInbound
TempOutboundTempOutbound
TossingExtTossingExt

U
UnsubscribeOnAreaDeleteUnsubscribeOnAreaDelete