BPQ The BBS

From Digital Traffic System
Jump to: navigation, search

Contents

The BBS

Overview

The BBS is the application most users want to run BPQ for. It is capable of handling bulletins, private messages, and NTS messages. A variety of interfaces is available for users to access their messages.

The following sections explain both the underlying concepts of the BBS and it's configuration. We mainly follow the structure given by the functional blocks for handling messages which are roughly sketched in the diagram below:

               + - - - - - - - - - - - - - - - - - - - - - - -+
               |       +-------------------------+            |
                     +-| logging                 |-+
               |     | +-------------------------+ |          |
    +------+         | +-----+       +-----------+ | +------+     +--------+
    | file |   |     | | Exp |-------|           | | | ISP  | |   | ISP    |
    | sys  |---------|-| Imp | +---+ |           |-|-| gate-|-----| POP3   |
    +------+   |     | +-----+-| f | |           | | | way  | |   | SMTP   |
    -------+     +-+ | +-----+ | o | | m  m      | | +------+     +--------+
           |   | | |-|-| RLI |-| r | | e  a      | |          |
      c  c-|-----| | | +-----+ | w | | s  n      | |
      i    |   | |s| | +-----+ | a |-| s  a      | |          |
      r  c-|-----|t|-|-| B1F |-| r | | a  g      | | +------+     +--------+
      c    |   | |r| | +-----+ | d | | g  e      |-|-| NNTP | |   | news   |
      u  c-|-----|e| | +-----+-| g | | e  m      | | | srvr |-----| reader |
      i    |   | |a|-|-| B2F | +---U |    e      | | +------U |   +--------+
      t  c-|-----|m| | |     |-------|    n      | | +------+     +--------+
      s    |   | |s| | +-----+       |    t      | | | SMTP | |   | email  |
         c-|-----| | | +-----+       |           |-|-| POP3 |-----| client |
    switch |   | | |-|-| CLI |-------|           | | | srvr | |   |        |
    -------+     +-+ | +-----+       +----|------+ | +------U     +--------+
               |                     +----|------+            |
                                     | routing   |
               |                     +----|------U            |
                   +------------+    +----|------+
               |   | user da-   |    | msg store |            |
                   | tabase (U) |    +----|------+
               |   +------------+    +----|------+            |
                                     | housekpng |    BPQ BBS
               |                     +-----------+            |
               + - - - - - - - - - - - - - - - - - - - - - - -+

Web pages, a command line interface, and a graphical user interface (GUI) can be used to access the BBS. These are not shown above as they are not core components for handling messages.

streams and protocols

The streams interface integrates BPQ with the switch. Messages can be forwarded with the RLI, B1F, B2F, and a message export/ import facility. The latter two and the command line interface (CLI) can also be used by users to access their messages.

forwarding

The forwarding facility cares for messages which are destined to other BBS.

internet-like interfaces

The ISP gateway allows to build a gateway between the BBS and the internet mail system similar to the Winlink 2000 approach. Additionally mail (SMTP, POP3) and news (NNTP) services are offered which allow a user to use the BBS with standard email clients.

Note that these interfaces are for user access only and that messages cannot be forwarded through them.

user database

Known BBS users and their properties are stored in the user database. Those components making use of this data are marked with an U in the lower right corner.

message store and housekeeping

All messages are held in the message store and the daily housekeeping process cares for old messages to be removed.

routing engine

The routing engine is responsible to figure out where new messages go to. They are either destined to a local user or going to be forwarded to another BBS using the forwarding facility.

message management

The messages management cares for messages entering or leaving the BBS and thus interfaces with the message routing and the user access components shown on the left and right hand side of the BBS.


Main configuration

The BBS is part of the BPQ standard installation. When there is a new release of BPQ you will find the change log for the BBS at

    http://www.cantab.net/users/john.wiseman/Documents/BBSChangeLog.html

First insert an APPLICATION line for the BBS in the main configuration file bpq32.cfg, e.g.:

    APPLICATION 1,BBS,,DB0NTS,,0

To start BPQ together with the BBS it is best to use the link "Start BPQMail Normal" in the ShortCuts\Normal subdirectory of the BPQ program files folder and it may be a good idea to have a copy of this on your desktop or in the start menu. Right click on the shortcut for an opportunity to do so.

When you start the BBS the first time it is yet not configured and will create a dummy configuration. Click "OK" in the corresponding message box. Then choose the entry named "Main Configuration" under the menu item named "Configuration". The Configuration window has several panes each of which comes with it's own "Save" button. Make sure to click the button on each pane before proceeding to the next one.


Basic Parameters

The "BBS Params" pane contains general information on the BBS.

Two callsigns are known to the BBS: the so-called BBSCALL which is callsign the BBS runs with and the SYSOP callsign used by the person who operates the BBS. You may use the same callsigns for both parameters. If you have a dedicated callsign for the BBS e.g. for unattended operation both callsigns need to be distinguished.

BBS Call, H Route

The callsign of the BBS without SSID. It is used for outbound connections, in message routing headers, and some other places. It does however not necessarily have to be the same as the application callsign defined in bpq32.cfg.

The H route is the hierarchical route of the BBS call for packet radio, e.g. #HES.DEU.EU.

SYSOP Call, msg redirect

Several BBS users may have sysop privileges for the BBS. The SYSOP callsign is the one used by the BPQ console and is thus kind of a master sysop.

The checkbox is to forward messages sent to the BBS callsign to the SYSOP callsign which may be helpful if you use a local message client for both the BBS callsign and the SYSOP callsign.

app nr, streams

The application number is the same as in the APPLICATION statement in the main BPQ configuration and provides the link between the node and the BBS. For each concurrent BBS connection you will need one stream to the node (see above). 10 streams should usually be sufficient.

FBB UI, beacons

This configures announcements of traffic on the packet radio network.

SYSTEM messages

SYSTEM messages are auto generated by the BBS to inform you about important events in the system including the results of the message housekeeping, unroutable messages, new users, and some more. You may choose to send these messages to the SYSOP call instead of the BBS call.

new users

A variety of options are available on how to deal with new users. By default they are required to enter name and home BBS. Additionally their messages are held by default. The checkboxes are to change these defaults. I do not require new users to enter name or home BBS and do not hold their messages.

email params

These parameters are to configure the TCP ports to be used for the SMTP, POP3, and NNTP servers of the BBS (the ones shown on the right side of the overview diagram above). For each server you may choose port number 0 to disable it.

Click the "Save" button to save your data before selecting the next pane.

The "ISP Interface" pane is to configure the ISP gateway shown in the upper right corner of the overview diagram. Most BBS use Winlink 2000 to interface with the internet email system instead.

The housekeeping process runs once a day and removes old messages and logfiles for some notion of "old". The details are configured in the "Housekeeping" pane. For the housekeeping time best choose a value at which you expect not too much load on your system.

The default lifetime for logfiles is 7 days and I recommend to set a larger value e.g. 30 days to be able to trace messages if required. If files are deleted to the Windows Recycle Bin they may be restored later.

Make sure that the checkbox "Send non-delivery notifications for P and T messages" is checked. You will get a notification in case that a message cannot be routed.

As always make sure to click the "Save" button before proceeding to the next pane.


Welcome messages and prompts

The "Welcome messages" pane is to configure the text which is to the upon an inbound connection. The message for new users is for those who log in to the BBS for the first time and it may be a good idea to point them to the online help (H command, see below). For known users the "Normal Users Welcome Message" is used and there is an additional message for users which are configured to be experts. The "Signoff Message" is sent when an interactive user session (one at the CLI, not a forwarding session) is terminated.

A couple of variables are available to make the texts dynamical:

$U, $l

$U is the callsign of the connected station and $l the name associated with the callsign in the user database.

$X, $x, $Z

$X is the number of messages in the BBS for the user regardless of status whereas $x is the number of unread messages for the user. $Z is the local message number of the last message read by the user.

$F

If the user is a BBS $F contains the number of messages to be forwarded to this station.

$L, $N

$L is the local message number of the latest message in the system and $N is the amount of active messages in the system.

$W

results in a carriage return

Generally you should keep all texts as short as possible at least if you are operating on HF with rather small throughput.

Do not use the ">" character in welcome texts as this may confuse the remote side. After you entered your welcome and signoff messages press the "Save" button and proceed to the "Prompts" pane which is very similar to the welcome messages pane and uses the same set of variables. Prompts should always end with the ">" character.

All other remarks made above apply to the prompt texts as well.

Further steps

The message filters pane gives you the option to reject or hold traffic addressed to specific TO and AT parts. A hold message has to be released (unhold) by a sysop first before it is going to be forwarded.

WP stands for White Pages, a phone book like system used in packet radio to exchange user data including name, location, and home BBS. The "WP Update" pane allows you to send your local user data as a bulletin (B) or private message (P) to another station.

Now close the configuration window and choose "Manage users" from the Configuration menu. You will notice that a user for the BBS callsign has already been created automatically. Select this user and check the sysop checkbox. Furthermore add name and location. Then click on the save button.

In order for the new configuration to take effect the BBS needs to be restarted. Select "Close all BPQ32 Programs" in the Window menu of the console to this end.

You can make an info text on your BBS available by creating a file named info.txt in the root directory of the BBS (i.e. the directory named BPQMailChat).

Furthermore you may replace the standard help text of the BBS with your own by providing a file named Help.txt in the root directory of the BBS.


Files overview

Here is a brief overview of files related to the BBS.

Programs

    C:\Program Files\BPQ32
        +- BPQMail.exe                      # BBS program
        |
        +- ShortCuts
            +- Minimized
            |   +- Start BPQMail Minimized  # shortcut BPQ32+BBS minimized
            |
            +- Normal
                +- Start BPQMail Normal     # shortcut BPQ32+BBS normal

User data

    C:\Users\<username>\AppData\Roaming\BPQ32
        |
        +- Logs
        |   +-log_<YYMMDD>_BBS.txt      # BBS log, <YYMMDD> = year,month,day
        |
        +- BPQMailChat
            +- Files                    # optional, downloadable files directory
            +- Mail                     # mail directory
            |   +- m_<nr>.mes           # message file, <nr> = local msg nr
            |
            +- BPQBBSUsers.dat          # user database (binary)
            +- BPQBBSUsers.dat.bak      # user database, backup file
            +- BOQBBSUsers.dat.bak.<nr> # user database, backup file, <nr> = seq. nr.
            |
            +- BPQMail.cfg              # main configuration
            +- BPQMail.cfg.bak          # main config, backup file
            +- BPQMail.cfg.bak.<nr>     # main config, backup file, <nr> = seq. nr.
            |
            +- DIRMES.SYS               # message database (binary)
            +- DIRMES.SYS.bak           # message database, backup file
            +- DIRMES.SYS.bak.<nr>      # message database, backup file, <nr> = seq. nr.
            |
            +- WFBID.SYS                # BID database (binary)
            +- WFBID.SYS.bak            # BID database, backup file
            |
            +- WP.SYS                   # white pages (binary)
            +- WP.SYS.bak               # white pages, backup file
            |
            +- Traffic_<YYMMDD>.txt     # weekly msg statistics, <YYMMDD> = year,month,day
            |
            +- INTRCPT.APS              # optional, NTS intercept file
            |
            +- Help.txt                 # optional, BBS help file
            +- info.txt                 # optional, BBS info file

The BBS at your fingertips

The GUI

Most functions of the BBS are available through the Graphical User Interface (GUI). The BBS main window shows all connected users. The basic structure of the BBS's GUI menu (without the Help entry) is as follows:

    Actions                     Configuration           Windows
    |                           |                       |
    +- Start Forwarding         +- Main Configuration   +- BBS Console (F2)
    +- Logging Options          +- Manage Users         +- Monitor (F4)
    +- Disconnect User          +- Manage Forwarding
    +- Housekeeping             +- Manage Messages
    +- Send Message             +- Manage White Pages
    +- Snd Msg from Clipboard
    +- Rerun Message Routing
    +- Import Messages

All these functions will be described in the respective chapters, e.g. the sections on message forwarding will detail on Actions -> Start Forwarding and Configuration -> Manage Forwarding.


The CLI

Commands to the BBS can be entered with the Command Line Interface (CLI) which can be accessed both via the BBS console window as part of the GUI or via the streams interface. The latter option gives you plenty of ways to access the CLI including the BPQ terminal, telnet terminal access, packet radio connections and many more.

When operating the BBS it is a good idea to always have a CLI window open.

With the BBS console you will be logged into the BBS directly with the SYSOP callsign and with the streams interface the source callsign will be used to access the BBS. Note that there is no timeout at the console contrary to the node idle timeout affective on the streams interface.

In any case the SID (this is the [BPQ-...] string, see the section on forwarding for details) followed by a welcome message and a prompt will be displayed. For both these the most appropriate texts are used depending on wether you are a new user, a known user, or even an expert user.

    [BPQ-1.4.65.3-IHJM$]
    NTS Eastern Area BBS for Europe
    TFC 0 FWD/ 0 DF0NTS
    DF0NTS de DB0NTS>

CLI commands can be abbreviated as long as they are unique, e.g. BYE can be abbreviated with B. Furthermore commands are case insensitive. The following sections contain a detailed description of all available commands and the table below lists the basic commands both in long and abbreviated form:


BYE, B Terminates the BBS session (and disconnects from the node).
IDLETIME n

The idle timeout value in seconds for a BBS connection through the the switch. You will be disconnected after n seconds. The range for the parameter n is 60 to 900.

INFO, I

Prints the BBS info text from the info.txt file or the message "SYSOP has not created an INFO file" if there is none.

HELP, H

Prints the standard help text or your own if a Help.txt file is present.

N

Prints the welcome message (again). Note that this is the N command without any further parameters. "N <value>" sets the user name (see below).

OP [n]

Reads or sets (with the optional parameter n) the output page length. After printing n lines the BBS will pause and ask you to continue (<enter>) or to abort (a) the output. The setting is user specific and is helpful for radio connections.

NODE

This command is available on the streams interface only and returns the user to the node.


Logging

The BBS creates log files on a daily basis and removes them according to your housekeeping configuration. Log file names follow the naming convention log_<YYMMDD>_BBS.txt (<YYMMDD> = year,month,day), e.g. log_151122_BBS.txt for the log file of November 22, 2015.

In the GUI Actions -> Logging options menu you can choose to log BBS traffic (recommended) and TCP traffic.

Here is how typical log file entries look like:

    151122 03:00:07 ?          Msg 8493 Routing Trace To DL4FN Via
    151122 03:00:07 ?          Routing Trace Type P TO DL4FN VIA  Route On (null) (null) (null) (null) (null)
    151122 03:00:07 ?          Routing Trace TO DL4FN Matches BBS DL4FN
    151122 08:13:21 |DL4FN     Incoming Connect from DL4FN
    151122 08:13:21 >DL4FN     [BPQ-1.4.65.3-B2FWIHJM$]
    151122 08:13:21 >DL4FN     NTS Eastern Area BBS for Europe
    151122 08:13:21 >DL4FN     DL4FN de DB0NTS>
    151122 08:13:22 <DL4FN     [AirMail-3.4.034-B2FHIM$]
    151122 08:13:22 <DL4FN     ; DB0NTS de DL4FN
    151122 08:13:22 <DL4FN     FF
    151122 08:13:22 ?DL4FN     B2 From SYSTEM
    151122 08:13:22 ?DL4FN     B2 From - not local User
    151122 08:13:22 ?DL4FN     B2 From Finally SYSTEM
    151122 08:13:22 |          Compressed Message Comp Len 256 Msg Len 369 CRC 8c86
    151122 08:13:22 >DL4FN     FC EM 8493_DB0NTS 369 256 0
    151122 08:13:22 >DL4FN     F> E7
    151122 08:13:22 <DL4FN     FS Y
    151122 08:13:23 <DL4FN     ; DB0NTS de DL4FN
    151122 08:13:23 <DL4FN     FF
    151122 08:13:23 >DL4FN     FQ
    151122 08:13:25 |DL4FN     DL4FN Disconnected

The first two columns contain the date (YYMMDD format) and time (hh:mm:ss format) of the log entry in UTC, respectively. The third column starts with one of the characters |,<,>,? followed by an optional user callsign the log entry is associated with. These characters have the following meaning:

Character Description
|

Informational log entry (the | character resembles the letter I). May optionally be followed by a user callsign.

 ?

Log entry by the routing engine. May optionally be followed by a user callsign.

<

Text received by the user following the < sign during a connection with that user. Binary (compressed) data is not shown.

>

Text sent to the user following the > sign during a connection with that user. Binary (compressed) data is not shown.

The GUI monitor window (F4) shows the same information as the log file except for the two timestamp columns. Therefore it may be helpful to use the tail command on the log file instead (tail for Windows may be obtained through the sourceforge UnixUtils project).

Users

Users are those identities which have connections with the BBS either inbound or outbound. They are identified by a callsign and there are two types of them.

  • stations: radio stations identified by an officially assigned callsign
  • pseudo users: users which are not radio stations and are used to interface with other systems or other special purposes.

The idea of pseudo users may look a bit awkward at first glance. Typical examples are the user RMS used to interface the BBS with the Winlink 2000 system and a user FILE used to export messages to files.

The user database is the repository of all BBS users with the backend store being a binary file (BPQUsers.dat, see above).


Becoming a new user

Users come into existence in two ways:

  • they are created by a sysop using the GUI or
  • they register themselves upon their first connect to the BBS (stations only)

A user can register himself only via the streams interface (shown on the left hand side of the overview diagram) and not via the SMTP/ POP3/ NNTP servers. When a user registers himself by connecting to the BBS for the very first time he will be asked to enter his name, location, and home BBS depending on the settings of the main configuration (see above). Following the creation of a new user a so-called SYSTEM message is generated by the BBS. The date and time of the message are the same the user was created at.

    From: SYSTEM
    To: DL4FN
    Subject: New User OE7FTJ

    New User OE7FTJ Connected to Mailbox on Port 2 Freq 0 Mode 0

In this particular case the new user logged in via the packet radio port of an SCS pactor controller. This is why frequency and mode are not specified.

In the BBS log this is shown as

    150929 22:56:19 ?          Msg 6902 Routing Trace To DL4FN Via
    150929 22:56:19 ?          Routing Trace Type P TO DL4FN VIA  Route On (null) (null) (null) (null) (null)
    150929 22:56:19 ?          Routing Trace TO DL4FN Matches BBS DL4FN
    150929 22:56:19 |OE7FTJ    Incoming Connect from OE7FTJ
    150929 22:56:19 >OE7FTJ    [BPQ-1.4.64.1-B2FWIHJM$]
    150929 22:56:19 >OE7FTJ    NTS Eastern Area BBS for Europe
    I = info, H = help, B = bye
    150929 22:56:19 >OE7FTJ    OE7FTJ de DB0NTS>
    ... ... ...

where message 6902 is the above system message. Note that the welcome message for new users provides some basic help (info, help, bye).

User properties

To set up new or modify the properties of existing users you may either use the CLI which is described below or the much more convenient GUI. Therefore choose "Manage Users" from the "Configuration" menu. All existing users are listed in the upper left of the window. To change an existing user select it from the list. To create a new user enter his callsign in the entry field in the upper left and click "Add user". Then set all parameters and flags as needed and click on "Save". When you are finished just close the user manager window.

The callsign is the primary key of a user and has a maximum length of 6 characters. For stations choose their true callsign and for pseudo users choose something else. It may be a good idea to start names of pseudo users with the "_" character as this will clearly distinguish them from radio callsigns.

The following flags are supported on users:

BBS

This user is a BBS. Messages are forwarded to this user based on the forwarding configuration.

PMS

PMS stands for Personal Mailbox System and refers to mailbox systems implemented by digital mode controllers e.g. the AEA PK-232. Set this flag if the user uses one of these systems to exchange messages with the BBS

Sysop

Grant sysop privileges to the user. These are required to execute certain BBS commands.

Expert

The BBS is less verbose when talking to this user. The Expert user prompt is used instead of the regular prompt and the welcome message is not send on an inbound connection from this user.

Excluded

This user is not allowed to login. To be more precise an inbound connection from this user is terminated immediately and a log entry is generated which reads

151124 20:03:17 |<CALL>  Incoming Connect from <CALL> Rejected by Exclude Flag

where the token <CALL> is replaced with the user's callsign.

You will typically set this flag for pseudo users.

Hold Messages

Messages from this user are put on hold and will not be forwarded until a sysop releases them.

NTS MPS

This user is an NTS Message Pickup Station which is BPQ speech for a Digital Relay Station. This flag is related to message forwarding. Please see the section on forwarding below.

Permit Email

This flag allows the user to access the SMTP/ POP3/ NNTP servers of the BBS and exchange messages using these protocols. The password attribute should also be set then.

Poll RMS for SSIDs

When connecting to a Winlink 2000 RMS the BBS retrieves messages for this user and his callsign extended with the listed SSIDs (if any). The "CMS Pass" has also to be set when Winlink messages are retrieved for a user.

RMS Express User

This user is using the RMS Express software as message client which can retrieve messages for multiple callsigns and the flag temporarily makes the user a B2F BBS for the time of the connection (older versions of BPQ also set the SID pretending to be a WL2K system).

Don't add @winlink.org

When a messaging client specifically designed for use with WL2K (RMS Express, Paclink) sends a message addressed to a callsign it is meant to be for <callsign>@winlink.org. The BPQ BBS is aware of this and appends the @winlink.org part automatically. This flag is to switch off the described automatism for messages addressed to the user in question.

Allow sending Bulls This user is allowed to send bulletins.
Include SYSOP msgs in LM

LM (= list my) is the command a user lists his own messages with. Sysop messages are included in this list if the flag is set. Set this only when the user also has the sysop role.


The following attributes are supported on users:

Name

The name of the user. This is used for WP and may be part of the welcome or signoff message text. Set this to the callsign if you do not know the exact user name.

Password

This password is used to access the builtin SMTP/ POP3/ NNTP servers.

CMS Pass

The WL2K password of the user. This is required if you also have the "poll RMS" flag set which allows the BBS to retrieve your WL2K messages.

QTH

The user's location (used for WP).

ZIP

The zip code of the user's location (used for WP).

Home BBS

The packet radio home BBS of the user. Used for WP and to forward messages for the user to this BBS.


Managing users at the CLI

The main configuration determines wether a new user will be asked for his name and home BBS.

Every user can set a couple of properties for himself which are listed in the table below:

N [name]

Sets your name. Without the parameter the command will print the welcome message.

PASS pwd

Sets the BBS password for your user. This is used for the SMTP/ POP3/ NNTP server interfaces.

Q [qth]

Prints the stored QTH when [qth] is not specified and stores [qth] as the user's QTH otherwise.

HOMEBBS [homebbs]

Prints the user's home BBS when [homebbs] is not specified and sets the value otherwise. [homebbs] has to be given with it's full HA.

CMSPASS [password]

Sets the CMS password used for polling for your Winlink messages. Therefore POLLRMS should also be set (see below). The password is never printed on the screen.

X Toggles Expert mode.

Here is a sample copy of CLI output which shows how to set some of these parameters. The texts right to the prompt are the user input.

    DL4FN de DB0NTS> N Peter
    Hello Peter. Latest Message is 7, Last listed is 0

    DL4FN de DB0NTS> QTH
    QTH is Erbach

    DL4FN de DB0NTS> QTH Erbach/ODW
    QTH is Erbach/ODW

    DL4FN de DB0NTS> HOMEBBS DB0NTS.#HES.DEU.EU
    HomeBBS is DB0NTS.#HES.DEU.EU

    DL4FN de DB0NTS> CMSPASS secret
    CMS Password Set

    DL4FN de DB0NTS> X
    Expert Mode off

Besides that a sysop user (see below for more on sysops) can display and edit a users's properties at the CLI with the EDITUSER command. Access is denied if a non-sysop enters the EDITUSER command (even with his own callsign). Typing EU at the prompt shows the help text for this.

The command "EDITUSER [callsign]" shows the active flags of the user. To add one or more flags append them after the callsign separated by spaces e.g. "EDITUSER DK0DK BBS RMS". To revoke one or more flags prefix them with a minus sign e.g. "EDITUSER DK0DK -BBS". Supported flags are:

BBS BBS user flag
EMAIL email user flag
EXC exclude user flag
EXP expert user flag
HOLD hold messages for this user
PMS PMS user flag
RMS RMS Express user flag
SYSOP sysop user flag

Here is some sample output:

    DF0NTS de DB0NTS> EDITUSER DL4FN
    User Flags: SYSOP BBS
    DF0NTS de DB0NTS> EDITUSER DL4FN EMAIL
    User Flags: SYSOP BBS EMAIL
    DF0NTS de DB0NTS>

The POLLRMS command is used to show and toggle the RMS polling status for your callsign. A sysop can also do this for other users by specifying the user's callsign as the first parameter. The parameters "Enable" and "Disable" are to toggle the RMS polling status.

    DK0DK de DB0NTS> POLLRMS
    RMS Polling for DK0DK disabled

    DK0DK de DB0NTS> POLLRMS DL4FN
    Changing RMS Poll params for another user needs SYSOP status

In the following output a sysop changes the RMS polling status for another user:

    DK0DK de DB0NTS> POLLRMS DL4FN
    Polling for calls DL4FN

    DK0DK de DB0NTS> POLLRMS DL4FN Disable
    RMS Polling for DL4FN disabled
    DK0DK de DB0NTS>

Being BBS sysop

A privileged BBS user is called "sysop" and this is what the sysop user flag (see above) is for. BBS sysop privileges are in particular required for the following actions:

  • change user properties
  • change message status for all messages
  • start message forwarding
  • import messages

Note that BBS sysop privileges are basically unrelated to having sysop privileges on the switch which is why we call them "BBS sysop" privileges.

Whether you are granted BBS sysop privileges depends on both the the sysop user flag and on how the BBS is accessed.

The BBS console is bound to the BBSCALL callsign and will always have sysop privileges even if the sysop flag is not set for the BBSCALL. In all other cases users need the sysop user flag set in order to be granted BBS sysop user privileges.

Local console windows (BPQTerminal and streams windows in the BPQ console) are bound to the NODECALL and are granted BBS sysop privileges if the BBS sysop user flag is set for NODECALL.

Furthermore BBS sysop privileges are granted to users having the BBS user sysop flag set and accessing the BBS through a port connection which already has sysop status on the switch.

BBS users having the BBS user sysop flag set and accessing the BBS through a port connection without sysop status on the switch can acquire BBS sysop privileges by means of one-time passwords (OTP). This prevents from callsigns being spoofed and from fixed passwords being eavesdropped. For such an OTP to be generated the user needs a BBS password being set besides the sysop user flag. The BBS user password is to be entered into the BPQAuth program which generates an OTP to be used with the BBS AUTH command. By clicking the "Copy" button in BPQAuth the complete AUTH command is placed in the clipboard.

    DB0NTS-2} Connected to BBS
    [BPQ-6.0.13.10-B2FWIHJM$]
    NTS Eastern Area BBS for Europe
    TFC 0 FWD/ 0 DL4FN
    DL4FN de DB0NTS> AUTH 637488
    Ok
    DL4FN de DB0NTS>

The following table summarizes the conditions under which BBS sysop user privileges are granted.

BBS access Callsign BBS sysop privileges are granted if...
BBS console BBSCALL always
BPQ console streams window,
BPQTerminal
NODECALL BBS sysop user flag set for NODECALL
port connection WITH
sysop status on switch
any BBS sysop user flag set
port connection WITHOUT
sysop status on switch
any BBS sysop user flag set,
BBS user password set, and
AUTH command with OTP entered

There may be additional options besides accessing the BBS with sysop privileges if you need to remotely administer your BBS. This includes in particular making your BBS accessible over the internet in order to use a remote desktop software (e.g. Teamviewer) or the BPQ web interface. You should be aware that this may come with security vulnerabilities on your internet access point.

Messages

Types, addresses, and status

The BBS handles three types of messages:

type description
P private message
T NTS message
B bulletin

Private messages are destined to a single user at a specific destination BBS. If a private message is received at the BBS it checks wether the recipient is a local user or wether the message is to be forwarded to another BBS.

    sender -P-> BBS -P-> BBS ->...-> dest BBS -P-> user=recipient

NTS messages are destined to a specific BBS typically the state MBO and may be picked up by one of multiple Digital Relay Stations (DRS) to be either delivered to the recipient or handled by a local net. DRS are called Message Pickup Stations (MPS) in BPQ speech.

                                              /-T-> MPS ->...-> recipient
    sender -T-> BBS -T-> BBS ->...-> dest BBS --T-> MPS
                                              \-T-> MPS

Bulletins are destined to multiple BBS and can be read by everyone i.e. every user at every BBS.

                       /--B-> BBS -- user
                      /    ...    \- user
                     /     ...       ...
    sender ->B-> BBS       ...       ...
                     \----B-> BBS -- user
                      \           \- user
                       \--B-> BBS -- user

The following sections focus in particular on T messages whereas bulletins are not discussed in detail.

For P and T messages each BBS needs to decide wether it is the destination BBS itself or if the message needs to be forwarded to a subsequent BBS. Message addresses consist of two parts called the TO and AT parts respectively to facilitate this decision. Both parts are separated by an @ sign: TO@AT. The TO part is to decide wether the message stays at the BBS and which user (P) or MPSs (T) may pick it up and the AT part is to decide which subsequent BBS the message is alternatively to be forwarded to.

Address schemes using the @ character are quite popular and are used for a variety of messaging protocols since the advent of internet email. BPQ uses the following address prefixes for fine-grained control:

NTS:

Some messaging clients can send P messages only. Therefore BPQ converts a private messages addressed to NTS:TO@AT to an NTS message for TO@AT. A private message to NTS:07405@NTSNJ will become an NTS message to 07405@NTSNJ. You may also use the prefix "NTS/" for messages sent from an email client.

RMS:

When a message address is prefixed with RMS: the address is treated as an internet email address and the message will be forwarded via the Winlink 2000 (WL2K) system. A private message addressed to RMS:DL4FN@winlink.org will be considered to be an internet email message for DL4FN@winlink.org to be forwarded via WL2K.

SMTP:

When a message address is prefixed with SMTP: the address is treated as an internet email address and the message will be forwarded via the ISP gateway.

Some status information is needed for the BBS to know wether a message has already been dealt with (forwarded or picked up). In the early days the letters N and Y have been used to this end and over time things have evolved a bit. BPQ uses the following status values (note that N and Y are still there):

status description
N not read
Y read
F forwarded to all BBS/ recipient
K killed
H held
D delivered (NTS messages only)
$ bulletin not forwarded to all BBS yet


Message attributes and the message store

Each message is uniquely identified by it's message id (MID) which is referred to as bulletin id (BID) in BPQ. BIDs are given out by the message senders i.e. the stations bringing messages into the system. They have a maximum length of 12 case sensitive characters. However you should not rely on all systems being aware of this and hence choose all upper case BIDS when creating your own.

The most common way to create BIDS is the scheme [nr]_[callsign] where [nr] is a sequential number and [callsign] is the callsign of the originating station. Examples are 1234_DF0NTS or 4711_WB2FTX.

As the message is moved through the chain of BBS towards the destination BBS each BBS keeps it's own copy and identifies it with a local message number. The local message copy along with it's associated meta data is kept in the message store.

            msg/BID        msg/BID        msg/BID   msg/BID
    sender ---------> BBS ---------> BBS ---------> ... ----> dest BBS
                      local copy     local copy               local copy
                      local msg nr   local msg nr             local msg nr

e.g.

    sender 3906_WB9JSR  BBS        BBS         BBS       dest BBS    MPS
    WB9JSR -----------> W4DNA ---> WB2FTX ---> KW1U ---> DB0NTS ---> DL4FN
                        local      local       local     local
                        nr 966     nr 49447    nr 3572   nr 8386

The local message number is used as the primary message key in BPQ and under certain circumstances the same message (i.e. with the same BID) may exist multiple times in the message store.

The BPQ message store consists of three parts:

  • the BID database (...\BPQMailChat\WFBID.SYS),
  • the message database (...\BPQMailChat\DIRMES.SYS),
  • and the mail directory ...\BPQMailChat\Mail

The BID database is to check for existing BIDs in the system which is needed to decide wether a message is being accepted. Thus the BID database focusses on the physical reception of messages. The BID database is implemented as a binary file consisting of a sequence of datasets, one for each message:

    outline of the BID database
    +----+--------+---+----+
    |type|local nr|BID|date|
    +----+--------+---+----+
    |type|local nr|BID|date|
    +----+--------+---+----+
    | ... ... ... ... ...  |
    | ... ... ... ... ...  |
    +----+--------+---+----+
    |type|local nr|BID|date|
    +----+--------+---+----+

Each dataset contains the message type (B,T,P), the local message number, the message BID, and the date the message entered the system.

Message meta data is stored in the message database which is in particular needed for message forwarding purposes. Contrary to the BID database which has a physical view on messages the message database has a logical view on messages. Like the BID database it is implemented as a binary file consisting of a sequence of datasets, one for each message:

    outline of the message database
    +--------+---+----+------+-------+----------+---------+---+--------+
    |local nr|BID|type|status|subject|timestamps|addresses|BBS|internal|
    +--------+---+----+------+-------+----------+---------+---+--------+
    |local nr|BID|type|status|subject|timestamps|addresses|BBS|internal|
    +--------+---+----+------+-------+----------+---------+---+--------+
    | ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...  |
    | ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...  |
    +--------+---+----+------+-------+----------+---------+---+--------+
    |local nr|BID|type|status|subject|timestamps|addresses|BBS|internal|
    +--------+---+----+------+-------+----------+---------+---+--------+

Besides the local message number, the BID, message type (B,P,T), and the message status (see above) the database also holds the following data:

From

The callsign of the message sender. For WL2K messages this is RMS: and the From Email field is also filled. For system messages this is SYSTEM.

To The TO part of the recipient's address.
From Email

The email address a message was received from. This is used for messages received by email, of course.

Via The AT part of the destination address.
Subject The message subject sometimes also called the message title.
Sent

This timestamp indicates the time the message was initially created. It is inferred from meta data (the first routing header) coming along with the message or set on reception if no such data is available.

Received This timestamp indicates the time the message entered the system.
Last Changed

This timestamp indicates the time the message was last changed. This field is updated in particular when the message is taken by the recipient or forwarded to another BBS.

Size

The message size in bytes which is also the size of the message file. The message size is also used in some forwarding protocols (see below).

BBS The BBS (one or more) a message is to be forwarded to.

For details on how the address fields are used for messages sent and received via WL2K see one of the sections below.

All the above data fields can be set manually in the GUI. Furthermore the message database also holds some internal data which is not available to the sysop:

BBS from The BBS user this message was received from.
B2 flags

B2 is the message forwarding protocol used by WL2K. This field stores wether a message is a B2 message, it has attachments, and is from Paclink, RMS, or RMS Express,

A good example for the different focus of the BID and message databases is a private message with a NTS: address prefix. From the physical point of view the message type is P and this is what is in the BID database. However from a logical point of view this is an NTS message and hence the message type stored in the message database is T.

Finally the mail directory is the last part of the message store and contains the messages as text files. The filename scheme is m_######.mes where ###### is the 6 digit local message number.

WARNING: never edit message files in the mail directory

Using a command line window you can list and show the messages from the mail directory (note that the layout depends on your locale settings and may look different on your machine):

    C:\Users\bpq\AppData\Roaming\BPQ32\BPQMailChat\Mail>dir
    12/11/2015  03:10 PM    <DIR>          .
    12/11/2015  03:10 PM    <DIR>          ..
    10/01/2015  03:00 AM            178 m_006927.mes
    10/01/2015  03:19 AM            142 m_006928.mes
    10/01/2015  05:35 PM            398 m_006929.mes
    ... ... ... ... ... ... ... ... ... ... ... ...
    ... ... ... ... ... ... ... ... ... ... ... ...

    C:\Users\bpq\AppData\Roaming\BPQ32\BPQMailChat\Mail>type m_008386.mes
    R:151119/0312Z 3572@KW1U.#EMA.MA.USA.NOAM BPQ1.4.64
    R:151119/0224z @:WB2FTX.#NNJ.NJ.USA.NOAM [Butler]Z:07405 #:49447
    R:151119/0107Z 966@W4DNA.NC.USA.NOAM BPQ1.4.64


    NR 620 R WB9JSR ARL15 PORT SHELDON MI NOV 19
    DL4FN
    BT
    ARL SIXTY SEVEN 5201 KE8CLV
    NO REPLY TO MSG LEFT
    ON ANSERING MACHINE X 73
    BT
    JOHN WB9JSR
    AR

The top lines starting with R: are the routing headers for the message (see below for more) and the message text starts after an empty line.

Exclusive access to the database files is required to avoid corruption when the message database or the BID database are updated. This is achieved by means of so-called semaphores and the BBS main window shows the number of semaphore clashes i.e. the number of events a potential corruption has been avoided.


The two message formats

From the early days of packet radio on a common format for messages has been used for all types of messages. This packet radio format is designed for traceability which is achieved by routing headers from each BBS giving the date the message was received there and the local message number. The message structure is:

  • The first line contains the subject of the message.
  • followed bye routing header lines until
  • an empty line separates the body.
  • The remaining lines are the message body.

Meta data associated with the message (BID, From, To, At, size) is part of the message transmission protocol. See the section on forwarding protocols below. Here is a sample message:

    S DL4FN
    R:151119/0312Z 3572@KW1U.#EMA.MA.USA.NOAM BPQ1.4.64
    R:151119/0224z @:WB2FTX.#NNJ.NJ.USA.NOAM [Butler]Z:07405 #:49447
    R:151119/0107Z 966@W4DNA.NC.USA.NOAM BPQ1.4.64

    NR 620 R WB9JSR ARL15 PORT SHELDON MI NOV 19
    DL4FN
    BT
    ARL SIXTY SEVEN 5201 KE8CLV
    NO REPLY TO MSG LEFT
    ON ANSERING MACHINE X 73
    BT
    JOHN WB9JSR
    AR

Each BBS the message comes through adds a routing header line at the top of the routing header section. All routing lines start with R: followed by a UTC timestamp in the "YYMMDD/hhmm" format indicating when the message was received. There are two types of headers, one listing the local message number just before the @ sign and the other one after a #: sequence. In the latter format the Z: declaration is for the zip code of the BBS location. The lower most routing line is from the BBS the message was put in the system and holds the time of message creation.

BPQ strips of the subject and stores it in the message database so that the message file starts with the routing headers (if any).

When the Winlink development team abanoned NTS messages, packet radio bulletins, and private packet radio messages from the Winlink software and started focusing on internet email relay they were in need of a suitable message format and introduced the B2 format along with the B2F forwarding protocol (see below) to this end. There is no need for routing headers since messages typically travel a single hop by radio only from the user to the RMS from where on it is routed through the internet.

The B2 format is akin to the internet email (SMTP) format and supports file attachments. It has the following structure:

  • Header lines of the form "Key: value" followed by
  • an empty line separating the headers from the body.
  • The message body which must not be empty and
  • optional file attachments.

The following header fields are supported:

Mid:

The Mid: line always has to be the first header line and holds the message id (the same as the BID).

Date:

The UTC time the message was originated in the "YYYY/MM/DD hh:mm" format.

Type:

The message type. The value "Private" is for messages addressed to end users. There is no value for NTS messages.

From:

The address of the message originator. Starts with SMTP: for internet email addresses.

To:

The recipient's address. A message may have multiple To: lines.

Cc:

Address of a Cc recipient (optional; multiple lines allowed).

Subject: The message subject.
Mbo:

In the WL2K this is the callsign of the originating RMS, "CMBO", or "SMTP".

Body: Number of bytes in the body.
File:

Used for file attachments (optional, multiple lines allowed). Contains the size of the attachment in bytes and the file name.

Here is a sample message:

    MID: IB1PDN3L8YK1
    Date: 2015/10/07 12:27
    Type: Private
    From: DB2HTA
    To: DB0NTS
    Subject: NTS-Nachricht 2
    Mbo: DB2HTA
    Body: 160

    NR 2 TEST R DB2HTA 18 MUENCHEN DEU OCT 10
    KK4IDX
    BT
    TEST MESSAGE X RE YOUR
    NR 10 X RONNIE HORNBACK
    KH7QI NOT KNOWN AT THIS
    LOCATION X 73
    BT
    HERBY DB2HTA

There is a flag in the message database identifying B2 messages. BPQ transparently converts the message formats as needed. Note that when converting from the classical format to B2 the routing headers are lost.


Editing message attributes

The message attributes from the message database listed in the previous section can be edited with the GUI. Therefore choose "Manage Messages" (see above).

Here is what the Manage Messages window roughly looks like:

    +---------------------------------------------------+
    |     +-----+                     +---------------+ |
    | Msg | Msg |   Type   Status     | BBS list      | |
    |     | Lst |                     |               | |
    |     |     |     Filter From     |               | |
    |     |     |       Filter To     |               | |
    |     +-----+      Filter Via     |               | |
    |                                 |               | |
    | From                   Sent     |               | |
    |  BID               Received     |               | |
    |   To           Last Changed     |               | |
    |                        Size     |               | |
    |                                 |               | |
    | Email From                      |               | |
    |        Via                      |               | |
    |    Subject                      |               | |
    |                                 +---------------+ |
    | Edit  Save  SaveTo  Print  Exp                    |
    | Text        File           ort                    |
    +---------------------------------------------------+

To select a message you have two options: either select a single message directly by local message number from the list in the upper left corner or fill in the address filters on the right to the list first. This allows to select messages by the From, To, or Via (AT part) address parts. All filters are ANDed together. The message list will be updated as you type. Then pick a message from the list.

Once a message is selected perform the required updates on the fields of your choice and click on the "Save" button to persist the changes to the message database.

Please note that the message timestamps (Sent, Received, Last Changed) cannot be changed although the GUI indicates differently.

Additionally the following actions are available:

Edit Text

This opens an editor window where you can change the message text. Click on either "Save" or "Cancel" after editing the text and then on "Save". The message size will be updated accordingly.

Save To File

A dialog opens to save the message to a file with the message meta data shown in headers (very much like the B2 format, see below).

Print A printer dialog opens for printing the selected message.
Export

A dialog opens to save the message to a file in standard export format. This allows to import the message into another BPQ or other message software.

The BBS list on the right hand side of the window will be covered in one of the sections below.


Sysop messages

Sysop messages are private messages generated by the BBS itself upon the occurrence of important events. They are destined to the SYSOP callsign from the main configuration and besides that user they can be read by any user having the "Include SYSOP messages in LM" flag set which can be activated for sysop users. The number of unread sysop messages is shown in the BBS main window.

Although the From field for sysop messages reads SYSTEM there is no built-in user or identity with this name in BPQ.

Sysop messages are generated in particular on the following events:

  • the housekeeping has run (optional)
  • a new user registered with the BBS
  • a P or T message turns out to be unroutable (optional)
  • a message was put on hold (various reasons)

For the messages marked as optional it can be configured wether they are to be generated.

The section on housekeeping shows an example of a sysop message.

Housekeeping

The purpose of a BBS is to forward incoming messages towards the destination BBS and to make messages available to local users for pickup. Once a message is forwarded or taken by the user the job is done by the BBS and there is no immediate need to keep the message any further. It may however happen that there is an inquiry to trace a message e.g. from it's sender or that a message is offered for transfer a second time. Therefore it is a good idea to keep messages for a grace period and to remove them from the system then to free the resources. This is done by the housekeeping process.

The housekeeping configuration is part of the BBS main configuration (see above). BPQ always remembers the time of the last housekeeping run (in BPQMail.cfg).

At system startup BPQ checks wether the last housekeeping run is more than a day ago and starts the process if needed. When the BBS is running housekeeping is performed on a daily basis at the time prescribed in the configuration. Furthermore housekeeping runs can be initiated at any time with the GUI (Actions -> Housekeeping).

Roughly speaking housekeeping is done in four steps:

1. BBS log files which are older than the desired age are deleted.

2. A backup copy of the message database is created and all messages with status K (killed) are removed from the database. Furthermore the associated message files are deleted.

3. Messages which exceed their configured lifetime are marked as killed in the message database. Please note that the lifetime of a message is counted from it's creation date and not from the time the message entered the BBS. Furthermore messages the creation date of which is more than 7 days in the future are also killed. When the housekeeping runs again the killed messages will be deleted in step 2.

4. A backup copy of the BID database is created and those BIDs from the database which exceed the configured lifetime are removed. Contrary to the message lifetime the BID lifetime is counted from the date the BID entered the system.

In the configuration you can opt to have a report for each run of the housekeeping process which is generally a good idea. The reports are sent as SYSTEM messages. Here is a sample:

    From: SYSTEM
    To: DL4FN
    Type/Status: PF
    Date/Time: 14-Dec 03:00Z
    Bid: 8975_DB0NTS
    Title: Housekeeping Results

    Killed Messsages Removed 86
    Messages Killed          133
    Live Messages            726
    Total Messages           859
    BIDs Removed             26
    BIDs Left                1841


Routing and Message Management

You are not expected to fully understand this on first reading.


Some background on Message Routing

The route of a message is the path of BBS it takes from the sender to the recipient(s) and routing is the art of knowing the next BBS in the chain. To this end every BBS owns rulesets based on the TO and AT parts of message addresses to determine which messages are to be forwarded to which particular BBS.

We use the term routing for the mechanism to find the next hop a message goes to and the term forwarding for how this is achieved (e.g. by outbound radio links).

Basically there are two routing concepts for BBS around which mainly differ by the point in time the routing decision is made for a message.

Passive routing: The rulesets for different BBS may intersect or even be identical. This is a feature. Inbound messages are put in the message store and marked as pending (status N). When there is a connection with another BBS either inbound or outbound the ruleset for the connected BBS is applied to the pending messages in the store to determine which ones are eligible to be forwarded to this BBS. This concept is for example implemented in Winlink Classic.

Active routing: The rulesets for different BBS should be distinct. This is a feature. Each BBS has a dedicated queue in the message store holding the messages to be forwarded to this particular BBS. All rulesets are applied to an inbound message to determine the unique queue the message is to be put on. Once there is a connection with another BBS either inbound or outbound all messages from it's queue are sent. This concept is implemented by BPQ.

Both concepts come with their pros and cons, of course. Support for DRS is inherent to passively routing BBS whereas it requires additional measures for actively routing BBS. Therefore the MPS user flag (see the section on the user database) has been introduced in BPQ. We will see later that in effect BPQ behaves very much like a passively routing BBS for MPS except that it cannot trigger outbound calls to them.

Routing is based on the address parts of messages. To this end lists of TO and AT address tokens are configured for every BBS. You can find these in the GUI under "Manage Forwarding" and they are part of the BPQMail.cfg config file. Details are discussed in the section on the routing configuration.

BPQ supports routing based on full TO and AT address parts as well as on wildcarded AT matches and wildcarded TO matches for NTS messages.

When a message (or a local copy) is created the message management invokes the routing engine to make the routing decision and puts the message along with it's routing information in the message store. From there it is picked up later on when the message is sent on.

In case the routing rulesets change before a message is transferred to the next hop choose "Rerun Message Routing" from the Actions menu of the GUI to apply the new rulesets to all active messages in the message store.

Be aware that in a real-world scenario (i.e. in every-day life) messages typically path through the forwarding layer before reaching the message management. Thus for a full view on what happens to an inbound message both the forwarding protocol and the message management have to be taken into consideration. See the overview diagram on the BBS above and an example below.

Summing up BPQ is an actively routing BBS making routing decisions on inbound messages.


Message queues and NTS MPS

The aim of the routing process is to assign a message to a single BBS to be forwarded to. If such a BBS can be determined this information is stored in the message database and it is said that the message "is queued" for this BBS. To this end there is a field for each BBS in the message database where a flag is set whether the message is for this BBS. Essentially the message queue is the collection of all pending messages assigned to a BBS.

The important thing about queued pending messages is that they can trigger outbound calls to the BBS.

For NTS messages which are to be forwarded to one of multiple Digital Relay Stations set these users up as BBS and activate the MPS user flag for each of them. When a message comes in it is checked that at least one of the routing rules matches for the message but no routing information is stored in the message database at all! (Note that this is one of the very few exclamation marks in this document).

When an MPS is connected with a forwarding session (see below for details) the routing rules of the MPS are checked against the pending messages to find the NTS messages to be forwarded besides the queued messages for this BBS.

Here is an example with 4 BBS:

  • KW1U is a BBS (not MPS) queueing messages for @KW1U and @NTSMA
  • WB2FTX is a BBS (not MPS) queueing messages for @WB2FTX and @NTSNJ
  • G0DUB is an MPS BBS for NTS messages @NTSGBR and queues personal messages @G0DUB
  • G4KUJ is an MPS BBS for NTS messages @NTSGBR and queues personal messages @G4KUJ

The diagram below is a sketch of the message database where each line represents one message and a routing flag for every BBS (on the right hand side). Queued messages are marked with an "X" and those which may be forwarded to one of the MPS are marked with a ".". The message queue for WB2FTX is highlighted with a vertical box.

                                                            Routing Flags
                 s                                          K  W  G  G
                 t                                          W  B  0  4
             t   a                                          1  2  D  K
     local   y   t                                          U  F  U  U
     msg     p   u                          Destination        T  B  J
     nr      e   s   BID           From     To @AT             X
    +------+---+---+-------------+--------+---------------+------------+
    | 1001 | P | N | 1234_DF0NTS | DF0NTS | KW1U  @KW1U   | X +-+      |
    | 1002 | T | F | 1077_DL4FN  | DL4FN  | 07405 @NTSNJ  |   | |      |
    | 1003 | T | N | 1078_DL4FN  | DL4FN  | 07405 @NTSNJ  |   |X|      |
    | 1004 | P | N | 1235_DF0NTS | DF0NTS | WB2FTX@WB2FTX |   |X|      |
    | 1005 | P | N | 2111_G4KUJ  | G0DUB  | KW1U  @KW1U   | X | |      |
    | 1006 | T | N | 2112_G4KUJ  | G0DUB  | 07405 @NTSNJ  |   |X|      |
    | 1006 | P | N | 1079_DL4FN  | DL4FN  | G0DUB @G0DUB  |   | | X    |
    | 1007 | P | F | 1080_DL4FN  | DL4FN  | G4KUJ @G4KUJ  |   | |      |
    | 1008 | T | N | 3027_KW1U   | KW1U   | G0DUB @NTSGBR |   | | .  . |
    | 1009 | P | N | 3028_KW1U   | KW1U   | G4KUJ @G4KUJ  |   | |    X |
    | 1010 | T | N | 4025_WB2FTX | WB2FTX | G4KUJ @NTSGBR |   | | .  . |
    | 1011 | T | N | 4026_WB2FTX | WB2FTX | G0DUB @NTSGBR |   | | .  . |
    | 1012 | T | F | 2113_G4KUJ  | G4KUJ  | 01742 @NTSMA  |   | |      |
    | 1013 | T | N | 2114_G4KUJ  | G4KUJ  | 01742 @NTSMA  | X | |      |
    | 1014 | T | N | 2115_G4KUJ  | G4KUJ  | 07405 @NTSNJ  |   |X|      |
    | 1015 | P | F | 1236_DF0NTS | DF0NTS | G4KUJ @G4KUJ  |   +-+      |
    +------+---+---+-------------+--------+---------------+------------+
    sketch of the message database                             box = queue
                                                               of WB2FTX

Note that:

  • messages with status F (forwarded) are not queued (e.g. nr 1001)
  • both personal and NTS messages are queued for the non-MPS BBS (e.g. nrs 1003, 1004)
  • for the two MPS only personal messages are queued (nrs 1006, 1009)

Now imagine G4KUJ has a forwarding session with our BBS. Then he gets messages 1009 (type P, queued), 1008, 1010, and 1011 (all type T, routing rule @NTSGBR applies) forwarded.

A list of BBS with pending traffic and the number of messages to be forwarded (both queued and unqueued) to them is displayed by the "FWD QUEUE" command available to sysops only at the command line interface. For the above example the output reads:

    DL4FN de DB0NTS> FWD QUEUE
    G0DUB  4 Msgs
    G4KUJ  4 Msgs
    KW1U   3 Msgs
    WB2FTX 4 Msgs

The structure of the NTSD is roughly as follows:

    +----------+          +----------+          +----------+
    | Area Hub |----------| Area Hub |----------| Area Hub |
    |          |------\ /-|          |------\ /-|          |
    +----------+       /  +----------+       /  +----------+
      | +----------+  / \   | +----------+  / \   | +----------+
      | | Backup   |-/   \--+-| Backup   |-/   \--+-| Backup   |
      | | Area Hub |--------+-| Area Hub |--------+-| Area Hub |
      | +----------+        | +----------+        | +----------+
      |   |                 |   |                 |   |
      |   |                 |   |                 |   |
    +----------+          +----------+          +----------+
    | Regional |          | Regional |          | Regional |    BBS with
    | MBO      |          | MBO      |          | MBO      |    queued
    +----------+          +----------+          +----------+    traffic
     |        |            |        |            |        |
  - -|- - - - | - - - - - -|- - - - | - - - - - -|- - - - | - - - - - -
     |        |            |        |            |        |
  +-----+  +-----+      +-----+  +-----+      +-----+  +-----+  NTS MPS
  | DRS |  | DRS |      | DRS |  | DRS |      | DRS |  | DRS |  with
  |     |  |     |      |     |  |     |      |     |  |     |  unqueued
  +-----+  +-----+      +-----+  +-----+      +-----+  +-----+  traffic
     |        |            |        |            |        |
   local    local        local    local        local    local
   nets     nets         nets     nets         nets     nets

MBOs should always be set up as regular BBS and never as MPS in order to trigger outbound calls on pending traffic. The forwarding scripts can be configured to send the messages to one of several MBOs.

DRS should always be set up as MPS BBS to easily extend the DRS responsible for a set of routing areas (i.e. zip codes).

Before routing

The steps below are performed by the message management when a new (local copy of a) message is created which happens in particular when a message is received from outside e.g. via the streams interface or by importing a message file. Note that these steps do not depend on the message type.

A newly created message may be put on hold for various reasons. A sysop message is send in this case. If a message is held for multiple reasons only the last one is reported. Therefore check messages carefully before un-holding them.

1. BID
1.1 If the message does not come with a BID already a new one is assigned by BPQ: [localMsgNr]_[BBSCALL] where [localMsgNr] is the local message number and [BBSCALL] is the BBS callsign.

1.2 A record in the BID database is created.

2. Meta data
A record in the message database is created and it's fields are populated with the message data. In particular both the received and last changed timestamps are set to the current time.

a) For B2 messages the "message created" timestamp is set to the value supplied in the Date: field of the message header.

b) For B1 messages the routing headers supplied with the message (if any) are parsed.

b1) If more than one routing header of our own BBS is found the message is considered to be potentially looping and is put on hold (status H).

b2) The created timestamp is inferred from the lower-most routing line. The message is put on hold (status H) in case the timestamp is either

  • corrupt
  • more than seven days in the future
  • older than the BID lifetime (default ??? days)
  • older than the max age (typically 30 days).

3. Bad words
Both the message subject and the message body are checked for the occurrence of configured bad words (if any) and the message is held (status H) then.

4. Hold filters
The hold filters (if any) are applied to the To, From, and At address parts and the message is put on hold (status H) if one of them matches.

If the user the message is from is a local user with the "hold messages" flag set the message will also be put on hold.

5. Size check
If the message exceeds the configured size limit it will be put on hold (status H).

For the vast majority of messages everything works smoothly and you will not even notice that steps 1 to 5 have been executed behind the scenes.

6. Routing
Now the message is routed.

Every message is routed in BPQ - no exception.

This means that all inbound messages are passed through the routing engine. Messages for local users are detected by having their message route pointing to BBSCALL. Since your own BBS usually does not have a forwarding script these messages are not sent on but rather stay at the local BBS until they are picked up by someone.


Adressology and the alias table

We have a brief look at addresses, the ingredients for the routing decision and the BPQ alias table before dig into the details of routing personal and NTS messages.

Personal messages - like bulletins - are mainly used on the packet radio network which is based on an international hierarchical addressing scheme (HA = hierarchical address). It is assumed that you are familiar with the basics of this system. Here is an example of a HA and it's parts:

                     AT part
    TO part      routing domain
      |                |
    -----   -----------------------
    KD3QV @ WB2FTX.#NNJ.NJ.USA.NOAM
            ------ ---- -- --- ----
              |     |   |   |   |
             HE4   HE3 HE2 HE1 HE0
             ATBBS
             LMP

As with all address schemes making use of the atsign the token to it's left is called the TO part and the one on the right hand side is called the AT part or the routing domain. The basic idea is that

the TO part is for the messages to stay and the AT part is for the messages to send on.

For personal messages the TO part is typically the callsign of the recipient.

The sub-parts of a HA are called hierarchical elements (HE) and they are numbered from right to left (HE4...HE0). Concatenations of HEs from right to left are called hierarchical routes (HR) e.g. NJ.USA.NOAM. The left-most part (LMP) of a HA is distinguished because it is the callsign of the destination BBS also called the ATBBS. As this term is not really appropriate for NTSD addresses we prefer the term LMP instead.

Message routing in BPQ is configured on a per-BBS basis and each BBS has lists for all three address parts to facilitate routing decisions for personal messages:

TO routing list this list contains TO address parts
AT routing list this list contains LMP address parts (ATBBS)
HR list a list of hierarchical routes (HR)

Thus personal messages are routed on a mixture of callsigns (TO, ATBBS) and geographical information (HR e.g. NJ.USA.NOAM).

NTS messages instead use an addressing scheme based on geographical information alone and flat (i.e. non-hierarchical) routing domains of the form NTSxy. Here xy is the state abbreviation of the recipient's postal address the zip code of which is in the TO part. In Europe (NTSEU) things are little bit different. Here are two sample addresses:

            AT pt                       AT pt
    TO pt   rtng dom            TO pt   rtng dom
      |       |                   |       |
    -----   -----               -----   -----
    07405 @ NTSNJ               DL4FN @ NTSEU
            -----                       -----
              |                           |
             LMP                         LMP

As HA are not used for NTSD there is no need to configure HRs for the routing process. Only the TO and AT routing lists are used.

Use the "Manage Forwarding" window of the BBS GUI to view and configure the TO, AT, and HR lists. The window outline is roughly as follows:

    +---------------------------------------------------------------------------+
    |                                                                           |
    |+--- Global params ---+ +---- Per BBS Parameters -------------------------+|
    ||                     | |                                                 ||
    || Max Size to Send    | |  BBS     TO Calls AT Calls  Times   Conn Script ||
    || Max Size to Recv    | | +------+ +------+ +------+ +------+ +---------+ ||
    || Max Bull Age        | | | (2)  | | (3)  | | (4)  | |      | |         | ||
    ||                     | | +------+ |      | |      | |      | |         | ||
    || Warn if no route  X | | +------+ |      | |      | |      | |         | ||
    || for P or T          | | | (1)  | |      | |      | |      | |         | ||
    ||                     | | |      | |      | |      | |      | |         | ||
    || Use Local Time      | | |      | |      | |      | |      | |         | ||
    ||                     | | +------+ +------+ +------+ +------+ +---------+ ||
    || Aliases             | |                                                 ||
    || +-----------------+ | |  HR (Flood Bulls)        HR (P and Directed B)  ||
    || | (7)             | | | +--------------------+  +---------------------+ ||
    || |                 | | | |                    |  |   (5)               | ||
    || |                 | | | |                    |  |                     | ||
    || |                 | | | |                    |  |                     | ||
    || |                 | | | |                    |  |                     | ||
    || |                 | | | +--------------------+  +---------------------+ ||
    || |                 | | |        +-------------------+                    ||
    || |                 | | | BBS HA | (6)               |                    ||
    || +-----------------+ | |        +-------------------+                    ||
    ||                     | |                                                 ||
    |+---------------------+ +-------------------------------------------------+|
    |                                  Save                                     |
    +---------------------------------------------------------------------------+

Once you select a BBS from the list (1) it is displayed in the selected BBS field (2) and it's TO list (3), AT list (4), and HR list ((5) for personal messages) are shown and can be edited. Every change needs to be saved before making the next change. The BBS HA is used for the routing of bulletins and is not relevant for the routing of personal and NTS messages. However it is recommended to always enter the HA in (6). The remaining per-BBS input fields (Times, Connect Script) are related to forwarding (see below).

The "Global Parameters" pane contains the alias list (7) which is meant to bring non-hierarchical addresses under hierarchical routing, a task which applies almost exclusively to bulletins in the packet radio network. @AMSAT is the classical example for this.

However the alias table is utilized in the routing process of all messages independent of type. So be careful with what you enter there. Entries are of the form "AT:ALIAS" where AT is the part of the message address to match and ALIAS it's alias:

    DF0NTS:DB0NTS
    DF0NTS.#HES.DEU.EU:DB0NTS
    NTSQC:NTSPQ

Applying the alias table to a message address means:

1. Check if one of the left-hand tokens matches with the AT part of the message address. Only full matches are taken into account, no partial matches, no wildcards or whatsoever.

2. If a match is found the alias on the right-hand side is implied as the new AT part for the routing process. The message address itself stays unchanged.

In the above example a message (any type) for @DF0NTS is treated in the routing process as if it were for @DB0NTS and a message that comes with the full HA path @DF0NTS.#HES.DEU.EU is treated as if it were for @DB0NTS as well. This is actually one station with two callsigns.

Use the alias table cautiously because it introduces additional complexity to your setup. It is intended to alias entities which come with two (or more) equivalent names as in the third line of the above example.

The alias table can also be used to introduce virtual routing domains based on routing equivalence classes. We will see how to do this in the section on NTS message routing.


Routing personal messages

Although personal and NTS messages share a couple of steps in the routing process we discuss both message types separately to make things clearer.

The routing decision for each inbound message is shown in the BBS log and we use the following abbreviations for the log entries:

[NR] the local message number
[TO] the TO part of the destination address
[AT] the AT part of the destination address
[HE0]...[HE4] the hierarchical elements of a HA (see above)
[LMP] the left-most part of the AT address part (see above)
[ALIAS] an alias from the alias table
[BBS] a BBS callsign
[LEN] the length of a match

All log messages of the routing engine have the ? character followed by the callsign of the connected BBS the messages are received from which we always show as "CONBBS".

In order to route a message the routing engine performs the steps described below which are formulated as questions (Q P...). We use the token "EOR" (end of routing) to indicate that the routing engine has made it's final decision.

Recall from above that routing of messages is based on BBS having associated lists of TO and AT address parts which may even include wildcards.

P.0 Starting info
When the routing engine is invoked it's initial log message reads:

    ?CONBBS    Msg [NR] Routing Trace To [TO] Via [AT]

P.1 RMS messages
This step cares for the messages which are either addressed TO RMS or are prefixed with "RMS:". The latter ones are internally rewritten as TO RMS with the address after the RMS: prefix moved to the AT part.

Q P.1: Is the TO part of the destination address "RMS"?

  • No: proceed with P.2.
  • Yes: continue

Q P.1.1: Is the AT part of the destination address of the form user@winlink.org where "user" is a local user with the "poll RMS" flag set in the user database?
No: proceed with P.1.2

Yes: If "user" is a BBS the message is queued for it. Otherwise the message stays in the message database without routing information and is waiting to be retrieved by the user. EOR. The log line reads:

    ?CONBBS    Message @ winlink.org, but local RMS user - leave here

Rationale: Because of the "poll RMS" flag the user is known to handle his WL2K traffic via the local BBS. There is thus no need to forward the @winlink.org message for him to a WL2K RMS. It is expected that the user logs in to collect his WL2K messages anyway including the message we just dealt with.

Q P.1.2: Do we have a BBS called "RMS"?
No: proceed with P.3

Yes: The message is queued for the RMS BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace to RMS Matches BBS RMS

Rationale: We are dealing with a message which is either not for a local user with the "poll RMS" flag or which is not for @winlink.org. Therefore the message needs to be forwarded to a WL2K RMS a task usually performed by the BBS named RMS. However messages addressed TO RMS may be dealt with by some other BBS (e.g. a dedicated WL2K RMS which we configured by it's callsign).

P.2 @winlink messages
This step checks if the message is for a @winlink.org address (without using the RMS syntax). This is very similar to the previous step.

Q P.2: Is the destination address of the form user@winlink.org?

  • No: proceed with P.3
  • Yes: continue

Q P.2.1: Is "user" a local user with the "poll RMS" flag set in the user database?
No: proceed with P.2.2

Yes: If "user" is a BBS the message is queued for it. Otherwise the message stays in the message database without routing information and is waiting to be retrieved by the user. EOR. The log line reads:

    ?CONBBS    Routing Trace @ winlink.org, but local RMS user - leave here

Note that this log line is slightly different from the one of P.1.1.

Q P.2.2: Do we have a BBS called "RMS"?
No: The message is considered to be unroutable. EOR. The log line reads:

    ?CONBBS    Routing Trace - @ winlink.org but no BBS RMS

Yes: The message is queued for the RMS BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace @ winlink.org Matches BBS RMS

Rationale: Messages for @winlink.org are bound to the RMS BBS and cannot be routed any other way.

P.3 Alias table
The alias table is applied to the message address.

Q P.3: Is there an entry in the alias table matching the AT part of the message address?
No: proceed with P.4

Yes: For the purpose of routing the AT part of the address is replaced with the alias. The message address itself is not changed in the message database. The log line reads:

    ?CONBBS    Routing Trace Alias Substitution [AT] > [ALIAS]

Now proceed with P.4. Keep in mind that from now on [ALIAS] will always be used instead of [AT].

P.4 Informational log entry
Before the real show starts with P.5 an informational log line is created. No routing decision is made in this step.

A HA is split into it's elements [HE4]...[HE0] if applicable with the left-most part [LMP] being the destination BBS. A log line is written:

    ?CONBBS    Routing Trace Type P TO [TO] VIA [AT] Route On [HE0] [HE1] [HE2] [HE3] [HE4]

Empty HEs are shown as "(null)". BPQ is aware of aliases for countries and continents and knows e.g. that .NA and .NOAM are the same. Furthermore missing continents and the root node WW are added as needed. Note that if an alias was found in the previous step the HEs refer to the alias and not to the real AT address part.

Messages of all types (B,P,T) come through this step so you will notice that a similar log entry also appears for NTS messages.

P.5 Full TO match
Now the core routing process starts. This step checks if one of the BBS takes messages with the TO address part of our message.

Q P.5: Is the TO address part of the message listed in the TO list of one of the BBS?
No: proceed with P.6

Yes: The message is queued for the first BBS found which has the TO part of the address in it's TO list. EOR. The log line reads:

    ?CONBBS    Routing Trace TO [TO] Matches BBS [BBS]

Remark: This is called a "full match" because no wildcards are involved and the TO address part of the message matches exactly with one of the entries in the TO list of one of the BBS.

P.6 Implied AT match
This step checks whether the destination BBS is a local user.

Q P.6: Is the destination BBS of the message known as a local BBS user?
No: proceed with P.7

Yes: The message is queued for the destination BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace [LMP] Matches implied AT [BBS]

Remark: Because no explicit configuration is taken into account in this routing rule it is called "implied AT". It is recommended to not rely on this but rather explicitly list the BBS call in it's AT routing list.

P.7 Full AT match
Now check if one of the BBS takes messages for the destination BBS.

Q P.7: Is the destination BBS of the message listed in the AT routing list of one of the BBS?
No: proceed with P.8

Yes: The message is queued for the first BBS found which has the message destination BBS in it's AT list. See also the remark on P.5 above. The log line reads:

    ?CONBBS    Routing Trace [LMP] Matches AT [BBS]

P.8 Longest HR match
At this point no exact routing match has been found neither for the TO part nor for the destination BBS. Therefore heuristical methods are now applied to find a suitable BBS to forward the message to.

This step looks at the HA of the message and checks whether parts of it match with the HR list entries of a BBS.

Q P.8: Is there a BBS which has a partly matching entry with the message HA in it's HR list?
No: proceed with P.9

Yes: Determine all BBS with partly matching entries in their HR lists. A log line is written for each hit:

    ?CONBBS    Routing Trace HR Matches BBS [BBS] Depth [LEN]

where [LEN] is the number of matching hierarchical address elements. Then pick the first BBS having the longest match (i.e. the most matching address elements) and queue the message for it. EOR. The log line reads:

    ?CONBBS    Routing Trace HR Best Match is [BBS]

Remark: Note that there cannot be a full match of the HA in this step because this case is already covered by P.5 above.

P.9 Wildcarded AT match
The last resort is to find a BBS with a matching wildcard entry in it's AT list. It is not recommended to use this feature for regular routing. Rather use this for default routes to apply when all else failed.

Q P.9: Does one of the BBS have a wildcard AT entry partly matching with the destination BBS of the message?
No: The message is considered to be unroutable. EOR. The log line reads:

    ?CONBBS    Routing Trace - No Match

Additionally a sysop message may be generated (see above).

Yes: A log line is written for each partly matching AT list wildcard entry which is found:

    ?CONBBS    Routing Trace Wildcarded AT Matches  [BBS] Length [LEN]

Here [LEN] is the number of matching characters. The first BBS with the longest match (i.e. the most matching characters) is picked and the message is queued for it. EOR. The log line reads:

    ?CONBBS    Routing Trace Wildcarded AT Best Match is [BBS]


The NTS alias file (INTRCPT.APS)

Before we discuss the routing of NTS messages we briefly introduce the NTS alias file which provides a mechanism to rewrite the AT part of NTS messages and which is involved in the routing of NTS messages.

Contrary to the alias table in the "Manage Forwarding" window the AT address part is changed.

If you want to use this feature place a file named INTRCPT.APS (the filename has been taken over from Winlink Classic) in the ...\BPQMailChat folder.

The alias file contains two colums separated by whitespace (blanks, tabs) the left of which is to find a wildcarded match on either the TO or AT part of the message address and the right of which is to rewrite the AT part. Comments are introduced with "..". Furthermore empty lines are ignored. The file is read on startup and any changes require a restart of the BBS.

This is how the NTS alias file is applied to a message address: The left hand side of the first alias is checked against the TO address part. If they match the AT part of the message address is replaced with the entry from the right column and we are finished. Otherwise the left hand side of the first alias is checked against the LMP. If they match the AT part of the message address is replaced with the entry from the right column and we are finished. If there was no match in this round try the next alias and so on until either there is a match or all aliases have been tried. If there is no match at all the message address stays unmodified.

As the AT match is on the LMP only and the complete AT part is replaced on a match you may loose the if any. Because wildcard matches are permitted (for both the TO match and the AT match) the most specific entries have to be first. Here is a sample file:

    .. INTRCPT.APS file at DB0NTS
    .. assure that messages for local callsigns stay here
    DB0NTS  DB0NTS
    DF0NTS  DB0NTS
    DL4FN   DB0NTS

    .. known users
    DB2HTA  winlink.org
    DK0DK   DB0GV.#HES.DEU.EU
    M1DFO   M1DFO

    .. rewrite UK addresses based on callsign prefixes
    GM0*    NTSGBR
    GB*     NTSGBR
    G0*     NTSGBR
    G1*     NTSGBR
    G2*     NTSGBR
    G3*     NTSGBR
    G4*     NTSGBR
    G5*     NTSGBR
    G6*     NTSGBR
    G7*     NTSGBR
    G8*     NTSGBR
    M0*     NTSGBR
    M1*     NTSGBR
    M6*     NTSGBR

    .. European default
    NTSEU   DB0NTS

Here are a few examples showing the above file in action.

Original address Rewrite Comment
DF0NTS @ NTSEU DF0NTS @ DB0NTS second line, TO match
DB2HTA @ NTSEU DB2HTA @ winlink.org

yes, this works and messages for DB2HTA@winlink.org will be forwarded via WL2K; this type of entry is only reasonable for a callsign in the left column

DK0DK @ NTSEU DK0DK @ DB0GV.#HES.DEU.EU

rewrite to a HA address to facilitate forwarding via packet radio

G0DUB @ NTSEU G0DUB @ NTSGBR wildcard TO match on G0*
DK0DK @ NTSEU DK0DK @ DB0NTS last line, AT match


Routing NTS messages

In this section we use the same abbreviations as above for the discussion of the routing of personal messages. Note that because NTS messages are typically addressed as [zip]@NTSXY the left-most part of the AT address part ([LMP]) is usually the NTS routing domain.

T.0 Starting info
When the routing engine is invoked it's initial log message reads:

    ?CONBBS    Msg [NR] Routing Trace To [TO] Via [AT]

This is excatly the same log entry as for P messages. Note that it shows the original AT part of the message address which may be changed in the next step.

T.1 Apply the NTS alias file
Now the NTS alias file is applied to the message address and the AT part of the address is rewritten in case of a match. The log line for this reads

    ?CONBBS    Routing Trace @[ALIAS] taken from Alias File

where [ALIAS] is the new AT part from the alias file.

T.2 @winlink messages
In this step P.1 and P.2 from above are executed for the message. Although P.1 (message TO RMS) will rarly happen with NTS messages an address of the form CALL@DOMAIN may be rewritten to @winlink.org with the alias file.

Q T.2: Is the destination address of the form user@winlink.org?

  • No: proceed with P.3
  • Yes: continue

Q T.2.1: Is "user" a local user with the "poll RMS" flag set in the user database?
No: proceed with T.2.2

Yes: If "user" is a BBS the message is queued for it. Otherwise the message stays in the message database without routing information and is waiting to be retrieved by the user. EOR. The log line reads:

    ?CONBBS    Routing Trace @ winlink.org, but local RMS user - leave here

Q T.2.2: Do we have a BBS called "RMS"?
No: The message is considered to be unroutable. EOR. The log line reads:

    ?CONBBS    Routing Trace - @ winlink.org but no BBS RMS

Yes: The message is queued for the RMS BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace @ winlink.org Matches BBS RMS

T.3 Alias table
The alias table is applied to the message address. This is the same as P.3.

Q T.3: Is there an entry in the alias table matching the AT part of the message address?
No: proceed with T.4

Yes: For the purpose of routing the AT part of the address is replaced with the alias. The message address itself is not changed in the message database. The log line reads:

    ?CONBBS    Routing Trace Alias Substitution [AT] > [ALIAS]

Now proceed with T.4. Keep in mind that from now on [ALIAS] will always be used instead of [AT].

T.4 Informational log entry
This is the same as P.4. An informational log line is created and no routing decision is made in this step.

A HA is split into it's elements [HE4]...[HE0] if applicable with the left-most part [LMP] being the destination BBS. A log line is written:

    ?CONBBS    Routing Trace Type T TO [TO] VIA [AT] Route On [HE0] [HE1] [HE2] [HE3] [HE4]

For NTS messages typically only [HE0] will show up and the other HEs are reported as "(null)". For more details on HEs see P.4 above.

T.5 TO match (wildcarded and full matches)
It is checked if there is at least one BBS with a (partly) matching entry in it's TO list.

Q T.5.1: Does one of the BBS have a wildcard or full TO entry matching with the TO address part of the message?
No: proceed with T.6

Yes: All BBS are checked even those having the "Send Personal Mail Only" flag set. Those BBS which have an exclusion for the particular TO part (!TO) are left out. A log entry is created for each BBS with a matching TO entry:

    ?CONBBS    Routing Trace NTS Matches TO BBS [TO] Length [LEN]

Here [LEN] is the length of the match in characters. The first BBS with the longest match is picked for the next sub-step.

The TO list of each BBS is checked from top to bottom and the first hit (either wildcarded or full match) is taken for each BBS. Therefore the order of entries in the TO list is of relevance for the routing decision.

Q T.5.2: Is the (first found) BBS with the longest match an NTS MPS?
No: the message is queued for this BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace NTS Best Match is [BBS]

Yes: the message is not queued and no routing information is saved. EOR. The log line reads:

    ?CONBBS    Routing Trace NTS Best Match is [BBS], but NTS MPS Set so not queued

T.6 Full AT match
It is checked if one of the BBS takes messages for the left-most part of the message's AT address part which is typically a NTSxy routing domain. However be aware that even NTS message may come with a HA (e.g. by the alias file).

Q T.6.1: Is the left-most part of the message's AT address part listed in the AT routing list of one of the BBS?
No: proceed with T.7

Yes: All BBS are checked even those which have the "Send Personal Mail Only" flag set. Pick the first BBS with the desired entry in it's AT routing list for the next sub-step.

Q T.6.2: Is the picked BBS an NTS MPS?
No: the message is queued for this BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace NTS [LMP] Matches AT [BBS]

Yes: the message is not queued and no routing information is saved. EOR. The log line reads:

    ?CONBBS    Routing Trace NTS [LMP] Matches AT [BBS], but NTS MPS Set so not queued

T.7 Wildcarded AT match
The last resort is to find a BBS with a matching wildcard entry in it's AT list. As for personal messages it is not recommended to use this feature for regular routing. Rather use this for default routes to apply when all else failed.

Q T.7.1: Does one of the BBS with the "Send Personal Mail Only" flag not set have a wildcard AT entry partly matching with the AT part of the message?
No: The message is considered to be unroutable. EOR. The log line reads:

    ?CONBBS    Routing Trace - No Match

Additionally a sysop message may be generated (see above).

Yes: A log line is written for each partly matching AT list wildcard entry which is found:

    ?CONBBS    Routing Trace Wildcarded AT Matches  [BBS] Length [LEN]

Here [LEN] is the number of matching characters. The first BBS with the longest match (i.e. the most matching characters) is picked for the next sub-step.

Q T.7.2: Is the picked BBS an NTS MPS?
No: the message is queued for this BBS. EOR. The log line reads:

    ?CONBBS    Routing Trace Wildcarded AT Best Match is [BBS]

Yes: the message is not queued and no routing information is saved. EOR. The log line reads:

    ?CONBBS    Routing Trace Wildcarded AT Best Match is [BBS], but NTS Msg and MPS Set so not queued

Remark: Note that this is the only step where the "Send Personal Mail Only" flag for BBS is factored in.

Here are a few examples to show how things typically look like:

  • An NTS message queued for a BBS by TO match (T.5)
    151230 14:44:07 ?KW1U      Msg 9409 Routing Trace To DL4FN Via NTSEU
    151230 14:44:07 ?KW1U      Routing Trace Type T TO DL4FN VIA NTSEU Route On NTSEU (null) (null) (null) (null)
    151230 14:44:07 ?KW1U      Routing Trace NTS Matches TO BBS DL4FN Length 5
    151230 14:44:07 ?KW1U      Routing Trace NTS Best Match is DL4FN
  • NTS alias file (T.1) followed by TO match for MPS (T.5)
    151230 07:19:41 ?DF0NTS    Msg 9407 Routing Trace To G4KUJ Via NTSEU
    151230 07:19:41 ?DF0NTS    Routing Trace @NTSGBR taken from Alias File
    151230 07:19:41 ?DF0NTS    Routing Trace Type T TO G4KUJ VIA NTSGBR Route On NTSGBR (null) (null) (null) (null)
    151230 07:19:41 ?DF0NTS    Routing Trace NTS Matches TO BBS G4KUJ Length 5
    151230 07:19:41 ?DF0NTS    Routing Trace NTS Best Match is G4KUJ, but NTS MPS Set so not queued
  • An NTS message queued for a BBS by AT match (T.6)
    151231 10:48:03 ?DF0NTS    Msg 9453 Routing Trace To 01520 Via NTSMA
    151231 10:48:03 ?DF0NTS    Routing Trace Type T TO 01520 VIA NTSMA Route On NTSMA (null) (null) (null) (null)
    151231 10:48:03 ?DF0NTS    Routing Trace NTS NTSMA Matches AT KW1U
  • NTS alias file (T.1) followed by AT match for MPS (T.6)
    151011 20:20:32 ?DF0NTS    Msg 7306 Routing Trace To G0MRH Via NTSEU
    151011 20:20:32 ?DF0NTS    Routing Trace @NTSGBR taken from Alias File
    151011 20:20:32 ?DF0NTS    Routing Trace Type T TO G0MRH VIA NTSGBR Route On NTSGBR (null) (null) (null) (null)
    151011 20:20:32 ?DF0NTS    Routing Trace NTS NTSGBR Matches AT G0DUB, but NTS MPS Set so not queued


Configuring NTS routing

We restrict ourselves to the setup of NTS routing as things are very similar for personal messages and bulletins are out of scope of this document anyway.

Warning: This section (as the previous ones) describe the many options offered by the BPQ software. When in doubt which option to choose get in contact with your NTSD ADC for advice.

Routing is configured with the "Manage Forwarding" GUI window outlined already in one of the previous sections. First check that the "Warn if no route" flag is set active in the global parameters pane. Remember from the previous section that "Send Personal Mail Only" flag for BBS is rather a "no bulletins please" flag. Leave it unchecked if possible. Furthermore it is recommended to not employ wildcarded AT matching except for very good reasons.

1. Start with your own BBS call and place it both in the TO and AT list of your own BBS. If you are a DRS yourself expand the TO list with your zip codes (see below).

2. Then set up your local users. These are the people logging into the BBS interactively. Set them up as regular users and put their callsigns in the TO list of your own BBS (BBSCALL). For your BBS the lists now look like this:

    BBSCALL     TO List     AT List
    -------------------------------
                BBSCALL     BBSCALL
                LOCAL1
                LOCAL2
                ... ...
                LOCALn

Later we will add more entries to the AT list.

3. Now set up the DRS as BBS users and activate the NTS MPS flag for them. Even if you only have a single DRS I prefer to set the flag because you can easily add additional DRS sharing the same set of zip codes. The only drawback of this approach is that you cannot automatically trigger outbound calls to your DRS. For each BBS the TO list contains in this order

  • the DRS callsign
  • the list of excluded zip codes
  • the list of full zip codes to match
  • the list of wildcarded zip codes to match with the longest strings at the top

In the AT list just put the DRS callsign. This may look like

    DRSCALL     TO List     AT List
    -------------------------------
                DRSCALL     DRSCALL
                !12345
                !12346
                12347
                12348
                142*
                143*
                13*

Excluded zip codes are prefixed with the ! character.

If you have many DRS sharing the same set of zip codes you can also put them in the NTS alias file and alias them to a new routing domain which you then put in the AT List of all the DRS.

Remark: Please note that you cannot put a token into the TO list of both an MPS and a non-MPS BBS. This will confuse BPQ and will end in chaos. If you want to put the same token into several TO lists all the BBS involved have to be MPS.

4. Add all the NTSxy routing domains you are the destination BBS for to your AT list. This ensures that messages sent to your domains and which are for whatever reason not covered by the TO lists of your DRS do not become unroutable. Remember that the TO lists routing (T.5) is performed before the AT list routing (T.6). Your routing list now reads:

    BBSCALL     TO List     AT List
    -------------------------------
                BBSCALL     BBSCALL
                LOCAL1      NTSuv
                LOCAL2      NTXxy
                ... ...     ... ...
                LOCALn

5. Finally we have to care for the remaining some 60 NTSxy routing domains. Set up all the other NTSD BBS as regular BBS users. Do not activate the MPS flag so that traffic for them will be queued and can trigger outbound calls. Also set up those BBS you usually have no links with just in case there will be an inbound call from them in the future.

There are two question to answer:

  • where to send the traffic?
  • how to effectively manage the many NTSxy domains?

When answering the first question you should be aware that whichever BBS outbound messages are queued for any station can be connected to transfer the traffic to. So if you are e.g. in CAN and queue all traffic for EAN to the EAN hub WB2FTX you can use the connect script for WB2FTX to connect to any (of the EAN) BBS and send the EAN traffic there. Details are described in the section on forwarding. Thus from the perspective of outbound calls it does not really matter which BBS outbound messages are queued for as you are free to send them anywhere.

For inbound calls the situation is slightly different. When an inbound call is received from a BBS only the outbound messages queued for this particular BBS are forwarded to it. If you are e.g. in CAN and queue all traffic for EAN to the EAN hub WB2FTX and now receive an inbound call from KW1U your outbound EAN traffic will stay at your BBS. No chance.

So there might be asymmetries in traffic flow depending on who establishes a connection. Basically you have two options to choose the BBS to queue traffic for:

a) Queue traffic for the primary BBS in the geographical target area. In the above examples this means that you queue traffic for EAN for the EAN hub 'FTX. If you prefer a more fine-grained solution queue traffic region-wise to the EAN region BBS.

b) Queue traffic for the BBS in the geographical target area you receive the most inbound calls from to speed up traffic flow at your BBS.

For optimal traffic flow it is recommended to have a look at the BBS logs and rearrange the BBS you queue outbound traffic for as needed. This brings us on to the second question.

There are two options to handle the some 60 NTSD routing domains you may have traffic for:

a) Place all the NTSxy routing domains in the AT routing lists of the choosen BBS.

b) First place the NTSxy routing domains of the NTS region you are in into the AT routing lists of the region BBS just as you did with option a). There still remain some 60 NTSxy domains from 11 regions.

For these use the alias table to establish virtual routing domains based on NTS regions (except for your own) and place the new domains in the AT routing lists of the choosen BBS (instead of the NTSxy).

Your alias table may look like this:

    NTSCT:_1RN
    NTSMA:_1RN
    NTSME:_1RN
    NTSNH:_1RN
    NTSRI:_1RN
    NTSVT:_1RN
    NTSEU:_2RN
    NTSNJ:_2RN
    NTSNY:_2RN
    NTSDE:_3RN
    ... ... ...
    ... ... ...
    NTSWY:_TWN

We started the virtual routing domain names with an underscore to emphasize that they do not exist in message addresses. You can choose any names you like, of course. The alias table is static and will (probably) never change.

Now you only need to handle 11 routing domains which is less error prone than to deal with 60. Remember that the alias table does not change the message address (see T.3) and that the virtual routing domain names will never leave your system. Nobody will ever know about them.

Note that we made Europe a part of 2RN because the EAN hub WB2FTX in NJ is the official target station for European traffic.

Imagine you want to change the BBS you queue 1RN traffic for. With option a) you need to change 6 routing domains whereas you need to change a single one (_1RN) with option b).


Manual routing

The BBS a message was forwarded to is shown in the BBS list of the "Manage Messages" GUI window an outline of which is shown in the section on editing message attributes above.

This window also allows you to put a message into the queue of a BBS by assigning the desired BBS and setting the message status to N.

Although the GUI lets you assign multiple BBS to a single message it is strongly recommended not to do so for personal and NTS messages as this functionality is intended for bulletins and those messages will change status to F only when they have been forwarded to all the assigned BBS.

If you want to manually route messages in order to apply a new routing ruleset to them it is recommended to set up the new ruleset first and then execute "Rerun Message Routing" from the actions menu instead.

User sessions

SID and session types

Historically BBS started with simple command-line interfaces (CLI) intended to be used interactively by a user with a keyboard. CLI are still around and let you read and send messages from a terminal. Later message exchange protocol were developed to forward messages between BBS. Nowadays these protocols are also used in messaging client software for efficient message exchange with a BBS. Five protocols are in use today:

MBL/RLI transfers packet radio messages one by one in plain text
FBB transfers batches of packet radio messages in plain text
BF

transfers batches of packet radio messages in compressed (binary) form; this protocol is also referred to as B0

B1F

more robust protocol to transfer batches of packet radio messages in compressed (binary) form

B2F transfers batches of B2 messages in compressed (binary) form

Details regarding the particular protocols will be discussed in the chapter on forwarding. BBS are expected to be downwards compatible which means e.g. that if a BBS has B1F it is expected to also understand MBL/RLI, FBB and BF. However, you should not rely on this.

All types of users (incl. BBS) can make inbound calls to a BBS whereas outbound calls to other BBS are performed only in order to forward messages to them. When an inbound call is accepted the BBS and the remote side negotiate whether the CLI or one and which of the message exchange protocols are to be used for the particular session. To this end the BBS includes a system identification (SID) together with a welcome text and a prompt in it's initial reply to an inbound connection.

The SID is to tell the remote side the features supported by the BBS including the message protocol preferred for the current session. The SID starts with a [ character followed by the software type and version, a separating dash, the list of supported features, and ends with a ] character. Here are a few examples:

    SID                SID
    start              end
    |                  |
    -                  -
    [BPQ-1.4.65.7-IHJM$]
     ------------ -----
      |            |
     software     software
     and version  features

    [BPQ-1.4.65.7-IHJM$]            BPQ BBS running MBL/RLI
    [FBB-7.00i-AB1FHMRX$]           FBB BBS running B1F
    [WL2K-3.2-B2FWIHJM$]            Winlink 2000 software (always B2F)
    [AirMail-3.4.034-B2FHIM$]       Airmail message client
    [RMS Express-1.3.9.0-B2FHM$]    RMS Express message client (always B2F)

And here is a list of typical BBS features:

I ignore; lines starting with a semicolon are ignored by the BBS
H hierarchical; the software can handle hierarchical addresses
M message ids; the software knows unique ids for messages (MID)
$

bulletin ids; the software knows unique ids for bulletins (BID); this is always the last character of the feature set

J,W these are related to the Winlink 2000 network
A acknowledge; private messages are acknowledged
F FBB message exchange protocol
BF BF message exchange protocol
B1F B1F message exchange protocol
B2F Winlink B2F message exchange protocol
B12F both B1F and B2F

There is no particular feature for the MBL/RLI protocol. Sending a SID without an F means that this protocol is supported.

When the user has received SID, connect text, and prompt he may either directly enter CLI commands to indicate that this is a CLI session or he alternatively sends back his own SID followed by the first protocol command. Note that there is no real negotiation on the protocol to use. When the two SIDs differ with respect to the supported protocols the lower one should be picked. However, you should not rely on all software doing this.

Besides the CLI BPQ supports four different message exchange protocols and the following table shows which functionality they can be used for. Note that inbound connections at the CLI are always used to read the user's messages only even if the user is a BBS.

Session types overview
type messaging
protocol
user inbound BBS
inbound outbound
key-
board
CLI
  • read T and own P
  • send P and T
  • read T and own P
  • send P and T
forwarding send only
(TEXTFORWARDING)
non
inter-
active
MBL/RLI n/a forwarding send/ receive forwarding send/ receive
BF
B1F
B2F with RMS Express
  • receive T and own P
  • send P and T

As can be seen from the table the main distinction is between keyboard sessions at the CLI available to all users includind BBS and forwarding session for BBS only. Although a regular user receives a [...-IHJM$] prompt when logging in implying that the MBL/RLI protocol may be used it can not. Furthermore you will notice a [...-BFIHJM$] SID at the BBS console but nobody can probably talk BF with the keyboard (you can however type in a MBL/RLI SID and commands if you like).

At the CLI you can

  • read all NTS messages which are neither held nor killed
  • read your personal messages (i.e. those with your callsign in the TO address part)
  • send NTS and personal messages.

In a non-interactive session based on one of the message protocols

  • you will receive all messages queued for you
  • if you are an NTS MPS you will also receive all NTS messages matched by one of your routing entries
  • you will receive all your personal messages (even if they are unroutable)
  • you may send any personal or NTS message.


Inbound connections

Inbound connections for use with the CLI or one of the forwarding protocols are always via the streams interface (see the overview diagram at the start of this chapter). Various steps are performed when a connection comes in:

1. User lookup
1.1 The SSID (if any) of the user callsign is stripped off. Only the base callsign is considered a BBS user. Note that the BBS log also shows the original callsign including the SSID. Thus the callsigns DL4FN-1 and DL4FN-15 are both mapped to the same BBS user DL4FN.

1.2 It is checked whether a BBS user with the callsign exists. In case of a new user:

a) A sysop message "New User [USER] Connected to Mailbox..." is generated and the user is created in the BBS user database.

b) If the switch "Hold messages from new users" is set in the main configuration the flag "Hold messages" will be set for the user in the user database.

c) If new users are not forced to enter their name by the main configuration the name field in the user database is filled with the callsign.

1.3 statistics The timestamp for the last connect is updated and the connection counter is incremented in the user database.

2. Checks and log entry
2.1 The user is granted BBS sysop priviliges if he has the sysop flag set and eithers comes in via a TCP connection or has already sysop status on the node (by means of authentication).

2.2 If the user has the "Excluded" flag set in the user database the connection will be terminated. The log line for this reads:

    |[CALL]    Incoming Connect from [USER] Rejected by Exclude Flag

We are finished here. There is no information to the user why the BBS has closed the connection.

For users who are not excluded the log line reads

    |[CALL]    Incoming Connect from [USER]

3. SID and prompt
The SID is generated and sent to the user:

  • an RMS Express user who is not a BBS has B2F
  • a new user has B2F because he may potentially use RMS Express
  • BBS users have what is set for them in the forwarding config
  • all other users have MBL/RLI.

The SID is followed by the welcome text and the prompt:

  • new users get the new users welcome text and the new users prompt
  • expert users get the expert users welcome text and the expert users prompt
  • all others get the standard welcome text and prompt.

4. Changeover
The information sending and receiving stations now change their roles. Either a changeover is forced (e.g. Pactor) or the remote side starts sending when it has received the > character indicating the end of the prompt (e.g. packet radio).

The user then either sends

  • a SID to start a forwarding session or
  • a CLI command to start a CLI session.

As there is no standardized way to negotiate the message exchange protocol to be used when the two SIDs differ BPQ will simply change the protocol according to the needs of the user. You should however not rely on other software being so friendly.


The NTS message lifecycle

The message lifecycle describes by which actions and how messages change status, a process controlled by the message management. Any message status may also be set in the "Manage Messages" window as described above.

With respect to NTS messages the user role model is quite simple and distinguishes between normal users and sysops. Here is what happens for users:

User actions on NTS messages
user action message status
N Y D F H K
list N Y D F n/a
read N Y D F n/a
deliver n/a D D D D D
forward F F n/a
unhold n/a
kill (+) K K K K K n/a
kill (-) n/a

The above table is to be read as follows:

  1. select the column with the original message status shown in the top line
  2. select the row with the action to be performed on the message in the left most column
  3. the new message status is listed where the selected column and row intersect.

Example: If a message with status N is forwarded the new status is F. N/a means that an action is not available for a particular command (and that the message status is thus not changed by the action). For the kill command there are two options:

  • (+): the main configuration allows anybody to kill NTS messages
  • (-): the main configuration allows sysops only to kill NTS messages.

For sysops things are slightly different:

Sysop actions on NTS messages
sysop action message status
N Y D F H K
list N Y D F H K
read N Y D F H K
deliver n/a D D D D D
forward F F n/a
unhold n/a N n/a
kill (+) K K K K K K
kill (-) K K K K K K

Interestingly a new message (N) cannot be directly changed to status Y and subsequently to D (delivered) in order to be marked as being delivered. The only option for a user to get a message to status D is to kill it first if the BBS config allows for this. Furthermore messages which are already forwarded can still be marked as delivered and messages can even be un-killed by being marked as delivered. However, I have learned that "what we have is ok, maybe not great but ok".

The following diagram gives a graphical overview of the NTS message lifecycle. Keep in mind that the behaviour of the kill command depends on the BBS main configuration.

     create                +-+                housekpg/ kill  +-+  housekpg  +-+
    ---------------------->|H|------------------------------->| |----------->| |
                           | |                sysop/ user     |K|            |d|
                           |h|                                | |            |e|
                           |o|                                | |            |l|
     create +-+  unhold    |l| deliver    +-+ housekpg/ kill  |k|            |e|
    ------->| |<-----------|d|----------->| |---------------->|i|            |t|
            |N|  sysop     +-+ user       |D| sysop/ user     |l|            |e|
            | |                           | |                 |l|            |d|
            | |                           |d|                 |e|            | |
            |n|                           |e|  deliver        |d|            +-+
            |e|                           |l|<----------------| |
            |w|                           |i|  user           | |
            | |                           |v|                 | |
            | |                           |r|                 | |
            | |            +-+ deliver    |d|  deliver        | |
            | |            | |----------->| |<-----------+    | |
            | |            |Y| user       +-+  user      |    | |
            | |            | |                           |    | |
            | |            | |                           |    | |
            | |            |r| housekpg/ kill            |    | |
            | |            |e|------------------------------->| |
            | |            |a| sysop/ user               |    | |
            | |            |d|                           |    | |
            | |            | |                           |    | |
            | |            | | forward    +-+            |    | |
            | |            | |----------->|F|------------+    | |
            | |            +-+ BBS        | |                 | |
            | |                           |f|                 | |
            | |                           |w|                 | |
            | |                forward    |d| housekpg/ kill  | |
            | |-------------------------->|d|---------------->| |
            | |                BBS        +-+ sysop/ user     | |
            | |                                               | |
            | |                                               | |
            | |                               housekpg/ kill  | |
            | |---------------------------------------------->| |
            +-+                               sysop/ user     +-+


Messages at the CLI

1. Listing messages
The L command is to list messages. As active BBS usually have lots of active messages various versions of the command are available to give different views on the messages in the system. Furthermore the OP command (see above) may be used for output paging. For regular users messages with status H and K are excluded whereas for sysops messages with all status are shown (see above).

The following table shows the variants of the L command.

L

Lists all messages in the system, newest first. The number of the last message read by each user is stored in the user database. If the latest message number in the system is the same as the number of the last message read by the user the output of the command is "No New Messages".

LR same as L with messages listed in reverse order
L n-m lists messages with local message number in the range from n to m
LR n-m

lists messages with local message number in the range from n to m in reverse order

L n lists message number n
LL n lists the last n messages e.g. LL 3
LM

Lists my messages i.e. those with the user's callsign in the TO address field. If the user is a sysop and has the "Include SYSOP messages in LM" flag set the list will also include system messages.

Ls

where s is a message status (N,Y,D,F,H,K) lists all messages with the given status e.g. LN

Lt

where t is a message type (B,P,T) lists all messages of the given type

Lst

where s is a message status and t a message type lists all messages of the given type and status e.g. LNT to list new NTS messages

L> TO

lists all messages with the parameter TO in the TO address field e.g. L> RMS

L< CALL

lists all messages originating from CALL e.g. "L< DL4FN" to list all messages from this station

L@ DOM

lists all messages for the routing domain DOM e.g. "L@ NTSME" lists all messages which have NTSME in the AT part of their destination address

Email messages from or to CALL@winlink.org are considered to be messages from or to CALL, respectively.

2. Reading messages
To read a message use the R command followed by the local message number e.g. "R 1234". The RM (read my) command is to sequentially read all messages with the user's callsign in the TO address field.

New (N) personal messages change status to Y when read but NTS messages do not.

Note that even an unroutbale message for USER@SOMEWHERE (with no route for @SOMEWHERE) can be read by USER logging in.

3. Sending messages
Messages are sent with the S command:

SB TO @ AT send a bulletin addressed to TO@AT
SC n TO @ AT

Sends a copy of the message with local number n to TO@AT. Besides the copied text of the original message you can also enter additional text. Furthermore the title of the original message prefixed with "Fwd: " is used as the title for the new message. Copied messages are always of type P.

SP TO @ AT send a personal message addressed to TO@AT
SR n

Send a reply to message n. Both the destination address field and the subject are pre-filled. Do not use the SR command for NTS message since this may result in unroutable messages.

ST TO @ AT send an NTS message addressed to TO@AT

After entering the appropriate S command the BBS guides you through the composition of your message. Here are a few examples:

DL4FN de DB0NTS> ST 07405 @ NTSNJ
Enter Title (only):
ATTN WB2FTX - FEB REPORT
Enter Message Text (end with /ex or ctrl/z)
NR 1433 R DL4FN 14 ERBACH ODW MAR 1
DAVE J STRUEBEL WB2FTX
BT
DB0NTS ACTIVITY REPORT FEB 2016
X SENT 944 RCVD 186
TOTAL 1130 X 73
BT
PETER DL4FN

/EX
Message: 11331 Bid:  11331_DB0NTS Size: 155
DL4FN de DB0NTS> L 11331
11331  01-Mar TN     155 07405  @NTSNJ  DL4FN  ATTN WB2FTX - FEB REPORT

DL4FN de DB0NTS> SC 11331 G0DUB @ G0DUB
Enter Message Text (end with /ex or ctrl/z)
FYI see my Feb report below, Greg.
/EX
Message: 11332 Bid:  11332_DB0NTS Size: 216
DL4FN de DB0NTS> R 11332
From: DL4FN
To: G0DUB
Type/Status: PN
Date/Time: 01-Mar 15:45Z
Bid: 11332_DB0NTS
Title: Fwd:ATTN WB2FTX - FEB REPORT

FYI see my Feb report below, Greg.


Original Message:

NR 1433 R DL4FN 14 ERBACH ODW MAR 1
DAVE J STRUEBEL WB2FTX
BT
DB0NTS ACTIVITY REPORT FEB 2016
X SENT 944 RCVD 186
TOTAL 1130 X 73
BT
PETER DL4FN



[End of Message #11332 from DL4FN]
DL4FN de DB0NTS>

3a. Sending messages with the GUI
Messages can also be sent from the GUI by selecting the item "New Message" from the Actions menu of the BBS. However, these messages are always sent from the primary sysop callsign.

4. Delivering messages
An NTS message is either to be taken automatically from the BBS with one of the messaging protocols or manually. In the former case the message status will change to F (forwarded) and in the latter case the message status is manually to be set to D. To mark the message with local message number n as delivered issue the command "D n".

The NTS message lifecycle (see above) shows however that the obvious status transitions N -> Y -> D are not supported and that the message has to be killed first (if supported by the main configuration).

5. Unholding messages
Hold messages are unhold with the UH command the syntax of which is

  • "UH n": unholds message n; multiple message numbers may be supplied (UH n m u v...)
  • "UH ALL": unholds all held messages

6. Killing messages
Messages are killed with the K command. Sysops can kill any message and users are allowed to kill there own messages only. The syntax is:

K n

Kill message number n. A normal user is allowed to kill his own messages (i.e. those addressed to him) only whereas a sysop may kill any message.

KM kill the read messages of the current user
KH kill all hold messages (sysops only)
K> TO kill all messages with TO in the TO address field (sysops only)
K< CALL kill all messages from CALL (sysops only)


Reading Files

The BBS can offer files for the user to display at his terminal. To this end create a directory named "Files" in the BBS main directory (i.e. ...\BPQ32\BPQMailChat\Files) and place your files there. Best restrict yourself to plain text files as non-printable characters may confuse the user's terminal.

The LISTFILES (or FILES for short) command lists the available files and their sizes in bytes whereas the READ command is to read a particular file. For both commands the OP paging command may be helpful.

    DL4FN de DB0NTS> FILES
    file1.txt 7
    file2.txt 13
    sample.txt 24
    DL4FN de DB0NTS> READ sample.txt
    This is a sample file.


    [End of File sample.txt]
    DL4FN de DB0NTS>


Forwarding Protocols

A basic knowledge of the message exchange protocols (also known as forwarding protocols) is essential to understand the options to configure forwarding in BPQ.

In the following examples the station WB2FTX always connects to DB0NTS. For brevity we will leave out the date and time fields of the BBS log excerpts shown

1. MBL/ RLI forwarding
The first wide spread forwarding protocol was developed by W0RLI and has been used in the BBS software of W0RLI and WA7MBL. It is therefore known as RLI or MBL/ RLI forwarding and was the first protocol to introduce SIDs. Messages are transferred in plain text one by one.

The connecting station (WB2FTX in our example) uses the prompt "F>" and the connected station (DB0NTS in our example) uses ">" as it's prompt.

First the SIDs are exchanged and the connected station sends a prompt:

    WB2FTX: {connect}
    DB0NTS: [BPQ-1.4.64.8-IHM$]
            DB0NTS >
    WB2FTX: [WinLink-3.0-HIMR2TU$]
    DB0NTS: >

Now 'FTX starts sending his traffic (if any) with the command "S(B|P|T) TO @ AT < FROM [$MID]" (similar to the command used at the CLI). Depending on the type of message either SB, SP, or ST is used. TO, AT, and FROM are the respective address parts the latter of which may optionally be followed by a dollar sign and the message id (if supported). BPQ checks this command both against it's reject filters and the BID database in case a MID/ BID is supplied and answers with either "OK" to accept or with "NO" to reject the message.

In case the message is rejected 'FTX sends the next S command. If the message is accepted he sends the subject line followed by the routing header lines (if any), a separating empty line, and the message body terminated by either the "/EX" sequence on a single line or the character 0x1A (Ctrl-Z). When the message is received by 'NTS he sends the ">" prompt again.

    WB2FTX: ST DL4FN @ NTSEU < WB9JSR 3906_WB9JSR
    DB0NTS: OK
    WB2FTX: S DL4FN
            R:151119/0224z @:WB2FTX.#NNJ.NJ.USA.NOAM [Butler]Z:07405 #:49447
            R:151119/0107Z 966@W4DNA.NC.USA.NOAM BPQ1.4.64

            NR 620 R WB9JSR ARL15 PORT SHELDON MI NOV 19
            DL4FN
            BT
            ARL SIXTY SEVEN 5201 KE8CLV
            NO REPLY TO MSG LEFT
            ON ANSERING MACHINE X 73
            BT
            JOHN WB9JSR
            AR

            /EX
    DB0NTS: >

When 'FTX is finished sending his traffic he sends his prompt ("F>") and both stations change their roles with 'NTS now issuing the S commands until all traffic is cleared. 'NTS then closes the connection by disconnecting. Thus the connection ends with

    WB2FTX: F>
    DB0NTS: {disconnect}

This protocol is rather simple and can easily be implemented. It involves however a lot of change overs which are critical under poor propagation conditions. This is why later protocols transfer messages in batches.

2. FBB ASCII forwarding
FBB ASCII forwarding is an improvement on the MBL/ RLI protocol by F6FBB with respect to the following aspects:

  • messages are send in batches of (max.) 5 in a row to avoid lengthy change overs
  • both stations alternately send message batches to improve traffic flow in both directions.

However, messages are still exchanged in plain text. The protocol is announced with the letter F in the SID. We will not go into further details as this protocol is not supported by BPQ.

3. BF forwarding (binary compressed version 0)
F6FBB further improved his ASCII (i.e. plain text) forwarding protocol by introducing data compression for the message transfer. The SID includes the letters BF. It all starts with the SID handshake:

    WB2FTX: {connect}
    DB0NTS: [BPQ-1.4.64.8-BFIHM$]
            WB2FTX de DB0NTS>
    WB2FTX: [WinLink-3.0-BFHIMR2TU$]

The connecting station (WB2FTX) continues sending and issues a sequence of up to five so-called proposals. A proposal asks to transfer a message very much like the S line in the MBL/ RLI protocol. Proposals take the form

    FA (B|P|T) FROM AT TO BID size

where FA is the proposal command and "size" is the message size in bytes. The sequence of proposals is terminated with the "F>" command. Here is an example asking to transfer 5 NTS (T) messages:

    WB2FTX: FA T WB9FHP NTSEU DL4FN 63818_WB9FHP 323
            FA T WB9FHP NTSEU DL4FN 63819_WB9FHP 324
            FA T WB9FHP NTSEU DL4FN 63820_WB9FHP 333
            FA T KB1TCE NTSEU G8OJQ 1213_KB1TCE 490
            FA T KW1U NTSEU DL4FN 9961_KW1U 179
            F>

When receiving a sequence of proposals BPQ checks them against it's BID database and against the reject filters. The reply is the command "FS" followed by a sequence of characters one for each proposal:

  • + (or Y): message accepted
  • - (or N): message rejected
  • = (or L): message deferred, the message should be proposed again in the future

After receiving the reply string the messages will be transferred in compressed (binary) form. The compression is based on the so-called YAPP algorithm introduced by WA7MBL. Each compressed message also comes with a checksum (CRC) so that the receiving side can validate that the message was correctly received. So our connection continues by DB0NTS accepting all five messages:

    DB0NTS: FS +++++
    WB2FTX: {sends binary data}

The binary data is not shown in the BPQ BBS log of the sending station but message size and checksum are, e.g.

    |          Compressed Message Comp Len 304 Msg Len 421 CRC b2fb
    |          Compressed Message Comp Len 296 Msg Len 369 CRC 557a
    |          Compressed Message Comp Len 268 Msg Len 334 CRC 7f99
    |          Compressed Message Comp Len 303 Msg Len 378 CRC 3c1a
    |          Compressed Message Comp Len 310 Msg Len 384 CRC 7abb

for sending a batch of five messages.

Furthermore the routing engine (see above) is invoked for each message successfully received. For the first message the BBS log entries at the receiving station might look like this:

    |WB2FTX    Uncompressing Message Comp Len 177 Msg Len 196 CRC 37d
    ?WB2FTX    Msg 12098 Routing Trace To DL4FN Via NTSEU
    ?WB2FTX    Routing Trace @DL4FN taken from Alias File
    ?WB2FTX    Routing Trace Type T TO DL4FN VIA DL4FN Route On DL4FN (null) (null) (null) (null)
    ?WB2FTX    Routing Trace NTS Matches TO BBS DL4FN Length 5
    ?WB2FTX    Routing Trace NTS Best Match is DL4FN

After receiving a batch of messages the receiving station either replies with a sequence of proposals itself or the command "FF" to indicate that there are no pending messages. Both variants (implicitly) acknowledge the successful receipt of all messages.

If the other side does not have any more messages after receiving "FF" it sends "FQ" to terminate the connection. Our sample connection may end like this:

    DB0NTS: FA T DL4FN NTSNE 68465 2009_DL4FN 194
            FA T DL4FN NTSNE 68465 2010_DL4FN 189
            FA T DF0NTS NTSNE 68465 12088_DB0NTS 447
    WB2FTX: FS +++
    DB0NTS: {sends binary data}
    WB2FTX: FF
    DB0NTS: FQ
            {disconnect}

When a checksum error is encountered on receiving a message the receiving station will send the text

    *** Checksum Error

and close the connection immediately.

4. B1F forwarding
B1F forwarding (with the string B1F in the SID) is a slight improvement on the BF forwarding protocol by F6FBB. It has been the standard NTSD protocol for many years.

The "F>" command at the end of a sequence of proposals is now followed by a checksum for the proposals and the FS replies are more fine grained:

  • + (or Y): message accepted
  • - (or N): message already received
  • = (or L): later, already receiving this message
  • H: message accepted but will be held
  • R: message rejected
  • E: syntax error in the proposal line
  •  !offset (or Aoffset): message accepted, send from offset

Offsets allow to resume message transfer at a given offset after a broken connection. In the following example parts of message 10029_WB2FTX have been received in a previous connection. Therefore it is asked to start sending this message again from byte 500 on to save connection time.

    <KW1U      FA T KB1TCE NTSEU DL4FN 1211_KB1TCE 404
    <KW1U      FA T WB9FHP NTSEU DL4FN 63717_WB9FHP 361
    <KW1U      FA T WB9FHP NTSEU DL4FN 63718_WB9FHP 361
    <KW1U      FA T KI0JO NTSEU DL4FN 10029_WB2FTX 1483
    |KW1U      Restart Data found for 10029_WB2FTX - Requesting restart from 500
    <KW1U      FA T KI0JO NTSEU DL4FN 10028_WB2FTX 680
    <KW1U      F> 2B
    >KW1U      FS +++!500+

Here is a complete sample of a B1F session:

    WB2FTX: {connect}
    DB0NTS: [BPQ-1.4.64.8-B1FIHM$]
            WB2FTX de DB0NTS>
    WB2FTX: [WinLink-3.0-B1FHIMR2TU$]
            FA T WB9FHP NTSEU DL4FN 63818_WB9FHP 323
            FA T WB9FHP NTSEU DL4FN 63819_WB9FHP 324
            FA T WB9FHP NTSEU DL4FN 63820_WB9FHP 333
            FA T KB1TCE NTSEU G8OJQ 1213_KB1TCE 490
            FA T KW1U NTSEU DL4FN 9961_KW1U 179
            F> E5
    DB0NTS: FS +++++
    WB2FTX: {sends binary data}
    DB0NTS: FA T DL4FN NTSTN 37641 1983_DL4FN 396
            FA T DL4FN NTSTN 37922 1984_DL4FN 365
            FA T DL4FN NTSNC 28056 1985_DL4FN 360
            FA T DL4FN NTSNC 28730 1986_DL4FN 368
            FA T DL4FN NTSKY 40359 1987_DL4FN 369
            F> 31
    WB2FTX: FS YYYYY
    DB0NTS: {sends binary data}
    WB2FTX: FF
    DB0NTS: FA T DL4FN NTSNE 68465 2009_DL4FN 194
            FA T DL4FN NTSNE 68465 2010_DL4FN 189
            FA T DF0NTS NTSNE 68465 12088_DB0NTS 447
            F> 02
    WB2FTX: FS YYYYY
    DB0NTS: {sends binary data}
    WB2FTX: FF
    DB0NTS: FQ
            {disconnect}

5. B2F forwarding
Although it would have been so easy to transfer internet email including attachments (using RFC-822 and MIME payload) with B1F the Winlink project decided to introduce a new protocol called B2F along with a dedicated message format (B2 messages, see above).

The proposal command in B2F is "FC" and has the standard syntax

    FC EM MID USIZE CSIZE 0

where the literal "EM" is for "encapsulated message" (i.e. a B2 message), MID is the message id, USIZE the uncompressed size and CSIZE the compressed size of the message in bytes. Note that the TO, AT, and FROM fields have been moved inside the message. Therefore BPQ cannot apply the reject filters on the proposal but has to receive the message first. However, when BPQ detects from the SID that the remote station is also a BPQ it uses it's own version of the proposal which is

    FC EM MID USIZE CSIZE FROM ATBBS TO

If there is no ATBBS the callsign of the current connection is used instead. This looks very similar to a B1F proposal and allows BPQ to apply the reject filters immediately. Thus B2F with two BPQs is effectively B1F in disguise.

Furthermore the FS command in B2F only knows the two replies Y (message accepted) and N (message rejected). In particular restarts are not supported.

Besides the protocol commands the BBS log also shows the determination of the sender for outbound messages and the routing engine log entries for received messages. BPQ tries to figure out the full HA address of the sender by taking into account both the home BBS (if configured) for local users and the routing headers inside the message for non-local users. Typical log entries for this look like:

    ?DL4FN     B2 From WA1STU
    ?DL4FN     B2 From - not local User
    ?DL4FN     B2 From Finally WA1STU@W4DNA.#W4DNA.NC.USA.NA

    ?DL4FN     B2 From W4DNA
    ?DL4FN     B2 From - Local User
    ?DL4FN     B2 From Finally W4DNA@DB0NTS

    ?DL4FN     B2 From DF0NTS
    ?DL4FN     B2 From - Local User
    ?DL4FN     B2 From Finally DF0NTS@DB0NTS.#HES.DEU.EU

W4DNA is configured as a local user in DB0NTS to perform outbound calls and it's home BBS is not set. DF0NTS is also a local user and has it's home BBS set to DB0NTS.#HES.DEU.EU.

Here is a sample B2F connection from the BBS logs with a Winlink RMS station. A few lines specific to the Winlink system have been replaced with ellipses.

    <RMS       *** Connected to DB0LJ-10
    <RMS        ... ... ... ...
    <RMS       [WL2K-3.2-B2FWIHJM$]
    <RMS        ... ... ... ...
    <RMS       Wien CMS via DB0LJ-10 >
    >RMS        ... ... ... ...
    >RMS       [BPQ-6.0.12.11-B2FIHJM$]
    >RMS        ... ... ... ...
    ?RMS       B2 From DF0NTS
    ?RMS       B2 From Finally DF0NTS
    |          Compressed Message Comp Len 289 Msg Len 385 CRC 56bb
    ?RMS       B2 From DF0NTS
    ?RMS       B2 From Finally DF0NTS
    |          Compressed Message Comp Len 286 Msg Len 385 CRC e6bc
    ?RMS       B2 From DF0NTS
    ?RMS       B2 From Finally DF0NTS
    |          Compressed Message Comp Len 287 Msg Len 385 CRC 2c9
    ?RMS       B2 From DF0NTS
    ?RMS       B2 From Finally DF0NTS
    |          Compressed Message Comp Len 416 Msg Len 568 CRC 8006
    >RMS       FC EM 12008_DB0NTS 385 289 0
    >RMS       FC EM 12009_DB0NTS 385 286 0
    >RMS       FC EM 12010_DB0NTS 385 287 0
    >RMS       FC EM 12011_DB0NTS 568 416 0
    >RMS       F> 16
    <RMS       FS YYYY
    <RMS       FC EM E4K7ATDWQNSG 1242 803 0
    <RMS       F> 40
    >RMS       FS Y
    |RMS       Uncompressing Message Comp Len 803 Msg Len 1242 CRC 6adb
    ?RMS       B2 Msg To: DL4FN
    ?RMS       Msg 12013 Routing Trace To DL4FN Via
    ?RMS       Routing Trace Type P TO DL4FN VIA  Route On (null) (null) (null) (null) (null)
    ?RMS       Routing Trace TO DL4FN Matches BBS DL4FN
    >RMS       FF
    <RMS       FQ
    |RMS       RMS Disconnected

Although B2F is now the standard protocol in NTSD because of it's support for radio email it has not been designed with NTS messages in mind. The intended use is to bridge the single radio hop between a user station and a Winlink Radio Message Server (RMS) gateway station to transfer personal messages. Therefore the B2 message format does not even specify an NTS message type designator.

BPQ works a great way around all these intricacies and within an ecosystem of BPQ stations NTS messages can safely be moved with B2F. However, when interfacing with other BBS software it is much safer to rely on B1F instead which explicitly specifies type T messages for proposals (FA T ...).

When a message is received with B2F:

1. It is checked whether the destination address starts with "NTS:". In this case the message is considered an NTS message. The message type is set to T.

2. It is checked whether the B2 type of the message is "NTS" (as used e.g. by Airmail) and the message is then considered an NTS message. The message type is set to T.

3. For B2 messages of type T which have the B2 message type set to "Private" the B2 type is changed to "Traffic" instead.

Thus B2 NTS messages can either be of B2 type "Traffic" or "NTS" both of which are preserved in message transfer. NTS messages converted from the packet radio format to B2 will always have "Traffic" as their B2 type.

The routing headers added to a B2 NTS message are made part of it's body.

    TODO: example to follow


Basic forwarding settings

Besides the routing rules we have already discussed above two types of settings are needed to configure message forwarding for a BBS:

  • basic settings including the forwarding protocol to use (this section)
  • the connect script containing instructions how to contact the BBS (next section).

All configuration settings are stored in the BPQMail.cfg file. Message forwarding is configured in the "Manage Forwarding" window which we have already seen above:

    +-----------------------------------------------------------------------+
    |                                                                       |
    |+- Global params -+ +---- Per BBS Parameters -------------------------+|
    ||                 | |                                                 ||
    ||Max Size to Send | |  BBS     TO Calls AT Calls  Times   Conn Script ||
    ||Max Size to Recv | | +------+ +------+ +------+ +------+ +---------+ ||
    ||Max Bull Age     | | | (2)  | |      | |      | | (3)  | |         | ||
    ||                 | | +------+ |      | |      | |      | |         | ||
    ||Warn if no route | | +------+ |      | |      | |      | |         | ||
    ||for P or T       | | | (1)  | |      | |      | |      | |         | ||
    ||                 | | |      | |      | |      | |      | |         | ||
    ||Use Local Time   | | |      | |      | |      | |      | |         | ||
    ||           (4)   | | +------+ +------+ +------+ +------+ +---------+ ||
    ||Aliases          | |                                                 ||
    ||+---------------+| |  HR (Flood Bulls)        HR (P and Directed B)  ||
    |||               || | +--------------------+  +---------------------+ ||
    |||               || | |                    |  |                     | ||
    |||               || | |                    |  |                     | ||
    |||               || | +--------------------+  +---------------------+ ||
    |||               || |                                                 ||
    |||               || | +- - - - - - - - - - - - - - - - - - - - - - -+ ||
    |||               || | |                                             | ||
    ||+---------------+| |    basic BBS settings                           ||
    ||                 | | |                                             | ||
    ||                 | | +- - - - - - - - - - - - - - - - - - - - - - -+ ||
    |+-----------------+ +-------------------------------------------------+|
    |                                Save                                   |
    +-----------------------------------------------------------------------+

To configure the settings for a BBS select it from the list (1) first and it will show up in (2). Forwarding of messages can be restricted to time bands on a per-BBS basis which are entered in the Time field (3). Either local time or UTC may be used depending on whether the checkbox "Use Local Time" (4) is checked. Time bands are of the form hhmm-hhmm where the first group is the start time and second group the end time. Even if you do not plan to use time bands I recommend to enter "0000-2359" in order to have a template for later changes.

Check the box "Enable Forwarding" to trigger forwarding with the BBS by queued traffic each interval seconds. The main reasons for having a forwarding interval are to minimize the overhead (SID exchange, transmit/ receive changeovers etc.) by sending multiple messages in batches and not to constantly occupy the other BBS so that many stations have a chance to connect with it.

Propagation conditions and the amount and frequency of traffic are the main factors to be considered when choosing a forwarding interval. Watch your BBS logs to adjust the value as needed.

Instead of waiting for the next forwarding interval to occur you can also check the box "Send new messages without waiting for poll timer" in order to immediately execute the connect script when a message is queued for the BBS. This approach is reasonable only for fast and reliable connections like TCP and high-speed packet radio. In all other cases it is much better to wait for a few messages to accumulate until forwarding is started.

Check the box "Request Reverse" to initiate forwarding with the BBS each interval seconds. This is also known as polling and does not depend on whether there is pending traffic for the BBS. You also need to have the "Enable Forwarding" box checked and the forwarding interval set for polling to work. The value of the forwarding timer should always be less the value of the polling timer. See below for details.

Polling is prohibited within NTSD but is useful e.g. to check for new Winlink messages in regular intervals.

The list of BBS is scanned through in regular intervals (every 10 seconds) and the following tasks are performed for each BBS:

1. Are time bands configured for this BBS?

  • No: proceed with step 2
  • Yes: continue

1.1 Is the current time covered by one of the time bands?

  • No: we are finished here; there is nothing to do for this BBS
  • Yes: continue

2. Is both "Enable forwarding" checked AND there is a connect script for this BBS?

  • No: we are finished here; there is nothing to do for this BBS
  • Yes: continue

3. Has the forwarding interval timer expired?

  • No: we are finished here; there is nothing to do for this BBS
  • Yes: continue

4. Is there queued traffic for the BBS?

  • Yes: execute the connect script and we are done with this BBS
  • No: continue

Note that only queued traffic triggers the script. NTS messages for an NTS MPS will not do this.

5. Is reverse forwarding enabled for this BBS?

  • No: we are finished here; there is nothing to do for this BBS
  • Yes: continue

5.1 Has the reverse forwarding interval expired?

  • No: we are finished here; there is nothing to do for this BBS
  • Yes: execute the connect script and we are done with this BBS

All this happens behind the scenes and there are no log entries for the above tasks.

Both polling and forwarding based on pending traffic can be used together for the same BBS. Consider the following configuration for the BBS "RMS" to connect with the Winlink system:

  • enable forwarding every 3600 seconds
  • request reverse every 43200 seconds.

Note that the forwarding interval is less than the polling interval as explained above. The first part assures that outbound traffic has to wait for at most one hour until it is send and that multiple messages can be batched together. The second part is to poll for new inbound messages twice a day (43200 seconds are 12 hours) even when there is no outbound traffic.

The option "Send Personal Mail Only" is part of the message routing (see above) and should rather read as "no bulletins for this BBS".

Instead of using the checkboxes the above settings can also be performed by a sysop at the CLI with the FWD command.

FWD [BBS] displays the current settings for the BBS
FWD [BBS] [interval] sets the forwarding interval to [interval] seconds
FWD [BBS] REF [interval] sets the interval for reverse forwarding
FWD [BBS] [+-] [flag]

activates (+) or deactivates (-) an option, flags are: EN(able), RE(verse poll), and SE(nd immediately)

Here are a few examples:

    DF0NTS de DB0NTS> FWD KW1U
    KW1U Fwd Interval 1000 Rev Interval 0 Fwd Enabled, Reverse Poll Disabled, Send Immediately Disabled
    DF0NTS de DB0NTS> FWD RMS +RE
    RMS Fwd Interval 3600 Rev Interval 43200 Fwd Enabled, Reverse Poll Enabled, Send Immediately Disabled
    DF0NTS de DB0NTS>

Configure the forwarding protocol to use with the BBS by checking the appropriate checkboxes in the "basic settings" area according to the following table (+: box checked, -: box unchecked).

Protocol Binary B1 B2
MBL/ RLI -- -- --
BF + -- --
B1F + + --
B2F + -- +
B1F + B2F + + +

Offering B1F and B2F simultaneously is for stations that make inbound connections with both protocols. Not all client software supports this. It is therefore recommended to avoid this and perform some testing when the setting is really needed.

Some of the protocols come with further details to configure.

For MBL/ RLI you can choose whether you want messages to end with either the token "/EX" or the 0x1A (Ctrl-Z) character.

For the FBB protocol family (BF, B1F, B2F) the maximum block size is the maximum amount of data transferred with a single message batch.


Connect scripts

Connect scripts are sequences of commands to connect with a remote BBS to exchange traffic with them. As outbound connections are made through ports the mentioned commands include switch/ port commands to control radios and teletype controllers as well as commands built into the BBS.

Connect script syntax is as follows:

  • each command is on a single line
  • lines starting with either a space, semicolon or hash (#) are comments
  • each command not recognized as a BBS builtin command is passed to the switch.

Names of the builtin commands are chosen not to conflict with those of standard switch/ port commands. In order to call applications from connect scripts never name them as builtin BBS connect script commands.

The first thing that happens when a connect script starts is the allocation of a stream on the switch. The log line for this is

    |[BBS]     Connecting to BBS [BBS]

This is one of the BBS streams from the main configuration and the GUI shows it's BBS callsign (not necessarily the callsign which is connected to, see below). If there is no stream available the log line

    |          No Free Streams for connect to BBS [BBS]

is printed and the show is over. The timer for the forwarding interval is reset and there will be another attempt to execute the script when the timer will have expired.

The connect script expects the other end (e.g. a connected BBS) to close the stream. Use the PASSWORD command if you need sysop privileges on the switch to change node parameters but do not forget to change them back later.

The following steps are performed when the connect script is executed:

1. command execution

The script commands will be executed in sequential order with the aim to make a successful connection (see 3. below) with a remote BBS and to exchange traffic.

2. SID

When the port reports back a connection with the other end the script starts looking for a SID.

For the BBS named "RMS" the script will start a Winlink authorization (see the section on Winlink integration) below. The following SIDs are recognized:

  • RMS Express: the forwarding protocol is set to B2F
  • BPQ: the MSGTYPE feature is enabled (see below) and the BPQ version of B2F will be used if the B2F protocol is chosen
  • AEA controller: see below.
3. prompt

After receiving the SID BPQ starts looking for the remote prompt. If a prompt is received the connection will be considered to be successful and subsequent script commands will be ignored.

4. message exchange Both BBS use the configured protocol to exchange messages.
5. termination

The script terminates if either the last line of the script is reached or if a successful connection (see 3. above) terminates for whatever reason.

When the script terminates the forwarding timer is reset for the next script execution to come.

Furthermore a message partially received with B1F or B2F is kept for a later restart.

Our aim is to move the traffic at hand as quickly as possible and we therefore want connect scripts to always succeed. There are however a variety of reasons why connect scripts fail in the sense that traffic is not moved. Besides this failed scripts are a waste of resources (time, radio/ frequency usage etc.). So watch your logs carefully for these failures in order to improve traffic flow. We first have a look at the above mentioned reasons and then shortly introduce the builtin TIMES and ELSE commands to make your scripts more robust.

If the connect is already running nothing is done, not even reported in the logs. Reasons for a connect script to fail include:

a) idle timeout

Nothing happens until the idle timeout (900 seconds = 15 minutes) of the stream occurs. The log entries read

    <[BBS]     *** Connected to ...
    <[BBS]     DISCONNECTED
    |[BBS]     [BBS] Disconnected

and the DISCONNECTED message appears about 15 minutes after the "*** Connected" message.

b) port in use

A single-connection port is tried to ATTACH but is already in use and the switch closes the stream. The log entries read

    <[BBS]     ATTACH p
    <[BBS]     [NODECALL]} Error - Port in use
    |[BBS]     [BBS] Disconnected
c) channel busy

A connect attempt is made but the channel is busy and the station on the other end can thus not be connected to and the stream is closed by the port in use. The log entries read

    >[BBS]     C [CALLSIGN]
    <[BBS]     Sorry, Can't Connect - Channel is busy
    |[BBS]     [BBS] Disconnected
d) connect failed

A connect attempt is made but failed and the stream is closed by the port in use. Typical log entries read

    >[BBS]     C [CALLSIGN]
    <[BBS]     *** Failure with [CALLSIGN]
    |[BBS]     [BBS] Disconnected

The BBS parses the messages received back from the port to determine failed connects by looking for keywords like BUSY, FAILURE, ERROR, UNABLE TO CONNECT, DISCONNECTED, FAILED TO CONNECT etc.

e) no prompt received

The connect with the remote BBS succeeds but the BBS prompt is not received (e.g. because of excessive errors). The stream is either eventually closed by the port in use or by the switch when the idle timeout occurs. Typical log entries read

    <[BBS]     *** Connected to [CALLSIGN]
    <[BBS]     DISCONNECTED
    |[BBS]     [BBS] Disconnected

and are very much the same as for a).

f) link aborted

A successful connection with the remote BBS is established but the connection aborts typically because of excessive errors. The port then closes the stream. Typical log entries read

    <[BBS]     *** Connected to [CALLSIGN]
    <[BBS]      ... ... ...
    ... ... ... ... ... ...
    |[BBS]     [BBS] Disconnected

The two builtin commands TIMES and ELSE are to group commands by time and remote station and thus make up the skeleton of a connect script.

The TIMES command has the syntax "TIMES hhmm-hhmm" where the first group is the start time and the second group is the end time for the following commands to execute. Values are either in local time or UTC according to the checkbox "Use Local Time". The time slots must not overlap and the TIMES command has to be the first line of the connect script if it is used. If you do not have a matching time slot nothing will happen and the BBS log will show:

    |[BBS]     Connecting to BBS [BBS]
    <[BBS]     *** CONNECTED
    |[BBS]     [BBS] Disconnected

Even if you have the same commands for the whole day it may be a good idea to use the TIMES command (with TIMES 0000-2359) so that you have a template for a later change. The TIMES command has always to in the first line of the connect script.

Here is an example:

    TIMES 1400-1500
    ATTACH 2
    RADIO 21.0919 USB 2 D
    MYLEVEL 2
    C %W3JY
    TIMES 1501-1700
    ATTACH 2
    RADIO 14.1089 USB 1 D
    MYLEVEL 3
    C %KW1U

Note that ATTACH, RADIO, MYLEVEL, and C are standard switch/ port commands which are sent to the allocated stream. Once the port is attached subsequent commands (RADIO, MYLEVL, C) will be sent to the port.

When the connect with W3JY fails the script ends and the stream will be disconnected. However there may be multiple other stations to forward our traffic to which is accomplished with the ELSE command.

It is important to note that there is no inherent association between a BBS user name and the connect string to perform an outbound connection to. Any station may be connected within a connect script. From the (logical) perspective of the BBS you are connected to the BBS user whereas from the (physical) perspective of the port you may be connected to a totally different station.

As many ELSE branches as you wish may be chained:

    ... ...
    C CALL1
    ELSE
    ... ...
    C CALL2
    ELSE
    ... ...
    C CALL3
    ELSE
    ... ...

The commands are executed from top to bottom and script execution stops with a successful connection i.e. the remote prompt is received. Cases a)-e) above will result in the next ELSE branch being tried. Remember that a failed connect detaches the port so that it has to be ATTACHed again in ELSE branches, e.g.

    ATTACH 2
    RADIO 21.0919 USB 2 D
    MYLEVEL 2
    C %W3JY
    ELSE
    ATTACH 2
    RADIO 21.0919 USB 2 D
    MYLEVEL 2
    C %KW1U

We even set the radio frequency and controller protocol level again for the alternative connect even those should not have changed in the meantime.

Calling a station immediately after setting the new radio frequency may not be a good idea as the channel busy detector of the controller may not have adapted yet to the new channel. This is why there is a PAUSE command with the syntax "PAUSE n" which waits for n seconds, e.g.

    TIMES 1400-1500
    ATTACH 2
    RADIO 21.0919 USB 2 D
    MYLEVEL 2
    ; wait 2 seconds
    PAUSE 2
    C %W3JY

When connecting to a remote BPQ node (e.g. by packet radio) you can use it's ports to perform outbound connections (e.g. on HF) from there and use the "RADIO AUTH" command to control the radios of the remote BPQ node. You will find more on this in the BPQ documentation pages.

The command "INTERLOCK n" where n is a port number is used to limit the number of connections on a port to 1 which is reasonable for multi-connection ports only (see above; single-connection ports need to be ATTACHed beforehand anyway).

When the BBS receives a SID back from the stream it starts forwarding messages according to the protocol configured for the particular BBS. The following commands control details for this:

SKIPCON

The remote BBS sends a "connected" string in it's welcome text which needs to be ignored.

SKIPPROMPT

The remote BBS sends a ">" (prompt character) at the end of it's welcome message which needs to be ignored.

NEEDLF

Lines are usually terminated with the carriage return character but this particular BBS needs both a carriage return and a line feed character as line terminator.

TEXTFORWARDING

CLI commands are used with the remote BBS (instead of a message exchange protocol) to send messages. Note that you cannot receive messages from the remote side with TEXTFORWARDING. When BPQ detects from the SID that the remote BBS is an AEA PK controller it will always use TEXTFORWARDING.

Instead of connecting with a remote station through a port connect scripts can also be used to export messages to a file (FILE command), import messages from a file (IMPORT command), or even send them by email (FILE command). These commands are discussed in the section on file import and export.

The FLARQ command indicates that messages are to be send to a FLARQ station.

Furthermore the MSGTYPE command determines which messages to send and will be discussed in the next section.


Forwarding sessions

We have already seen above how user sessions work and forwarding sessions initiated by connect scripts are just a special case of this. This section mainly focuses on which messages are transferred to the remote BBS and how this can be controlled.

Once a forwarding session is established the following messages are sent to the remote side:

  • messages queued for the BBS
  • in case of an NTS MPS unqueued NTS messages one of the forwarding rules apply to
  • messages with the remote BBS callsign in the TO address part.

NTS messages are always sent first followed by personal messages. This may turn out to be problematic if the BBS never runs out of NTS messages. However, the builtin MSGTYPES connect script command can be employed to filter messages to be sent by type.

By default both personal and NTS messages are sent in an outbound forwarding session and messages are accepted from the other end. In a connect script this can be controlled with the MSGTYPES command which has to be placed before the connect with the remote BBS. Use the command with great care as it is independent of the routing decision. Make sure that all message types are covered by your script. The following options are supported by the MSGTYPES command:

  • P: send personal messages
  • T: send NTS messages
  • R: reverse; accept messages from the other end.

There are more options to control the size of the messages to be send which will not be discussed here. See the official BPQ documentation for more.

As an example "MSGTYPES PT" results in both personal and NTS messages to be sent to the remote BBS and messages from the other end are not accepted (option R missing).

Within a connect script the MSGTYPES command is not inherited across TIMES or ELSE branches and has therefore to be placed in each ELSE branch separately. Put it just before the port is attached. The structure looks like this:

    TIMES ...
    MSGTYPES ...
    ...
    C ...
    ELSE
    MSGTYPES
    ...
    C ...
    TIMES ...
    MSGTYPES ...
    ...
    C ...
    ELSE
    MSGTYPES ...
    ...
    C ...

When the other end also runs BPQ (detected from it's SID) the MSGTYPES command is sent as a comment line and when no pending messages fit the given MSGTYPES condition the script terminates and a log entry is created:

    ?BBS       Script MSGTYPES P
    ?BBS       Nothing to do - quitting
    |BBS       BBS Disconnected

Furthermore when reverse forwarding is not enabled by the MSGTYPES command and the other end sends a proposition to forward a message the connection will be closed with the following log statement:

    <BBS       FC EM ...
    <BBS       F> ...
    ?BBS       Reverse Forwarding not allowed
    |BBS       BBS Disconnected

Note that there is no entry in the other end's log why the connection was closed.

When a connection between two BBS aborts during message transfer the sending side does not know which messages have been received by the other BBS and thus all of them are proposed again by the sender during the next connection. The rules by which BPQ decides which messages to accept a second time depend on the message transfer protocol.

With B2 only the BID is checked against the BID database and messages already received will not be accepted again. This simple rule is due to the initial design of B2 as a last-mile protocol between a client and a WL2K RMS.

with B1 and MBL/ RLI things are different. Duplicate bulletins are always rejected. Duplicated P or T messages are rejected if the message is still on the BBS and it has state 'N' Y' or 'H'. If it has already been forwarded it is accepted again. This is designed to stop messaged being lost if a routing error occurs and the message ends up passing through the same BBS again. The message would be held as possibly looping, but the sysop could reroute and release it.

When a message is forwarded a routing header is added to the message. The timestamp of the header reflects the time the message is sent with MBL/ RLI and the time the message was received with BF, B1F, and B2F.


Manual forwarding

A BBS connect script can be manually executed by clicking on "Start Forwarding" in the Actions menu of the BBS GUI and then selecting a specific BBS or the entry "All".

Alternatively the CLI FWD command may be used which is available to sysops only. The syntax is "FWD [BBS] NOW" where [BBS] is the selected BBS, e.g.

    DL4FN de DB0NTS> FWD KW1U NOW
    Forwarding started
    DL4FN de DB0NTS>

This will execute the connect script for the KW1U BBS.

The command even allows to specify an alternative connect script known as temporary connect script. These temporary connect scripts can only be used for BBS which have a connect script configured. If you only want to use temporary scripts for a certain BBS put "BYE" into it's connect script field.

A temporary script is used only once for the particular command call and is listed right after the token "NOW" with it's elements separated by vertical bars e.g.

    DL4FN de DB0NTS> FWD KW1U NOW ATTACH 2|RADIO 21.0919 USB 2 D|C %W3JY
    Forwarding started
    DL4FN de DB0NTS>

Keep care not to place any blanks directly after a vertical bar as connect script lines starting with a blank are considered to be comments and are ignored.

In the above example all messages queued for the KW1U BBS will be forwarded to W3JY (using a robust Pactor connect) on 15m.


Message import and export

Both message file import and export use the same file format based on the MBL/ RLI syntax. The file is a sequence of messages of the form

    S(B|P|T) TO @ AT < FROM [$BID]
    SUBJECTLINE
    [ROUTINGLINE]*

    BODY

    /EX

This is the same as in the MBL/ RLI protocol. The first line starts with either SB, SP, or ST depending on which type of message you want to send. TO @ AT is the destination address with the atsign surrounded by spaces. FROM is the sender's callsign optionally followed by a dollar sign and a BID. The message subject is in the next line and may optionally be followed by one or more routing header lines. An empty line separates the possibly multi-line message body terminated by an empty line and the closing /EX token on a single line.

Here is a sample file showing two type T messages one of which comes with a BID and the other one with a routing header:

    ST 07405 @ NTSNJ < DL4FN $5231_DL4FN
    ATTN WB2FTX - SEP REPORT

    NR 5231 R DL4FN 17 ERBACH ODW OCT 1
    DAVID J STRUEBEL WB2FTX
    NTS EASTERN AREA DIGITAL COORDINATOR
    241 BOONTON AVE
    BUTLER NJ 07405
    973 838 9093
    BT
    DB0NTS NTSD MBO ACTIVITY REPORT
    SEP 2016 X SENT 445
    RCVD 176 TOTAL 621 X
    KIND REGARDS
    BT
    PETER DL4FN

    /EX
    ST EA4UC @ NTSEU < WB9FHP
    Madrid
    R:161007/2114z @:WB2FTX.#NNJ.NJ.USA.NOAM [BUTLER]Z:07405 #:57191

    NR 919 R WA4STO 9 WILBER NE OCT 2
    CHRIS EA4UC
    Christian Castillo
    Ave. Septima 22-2-1
    Madrid 28022
    Spain
    BT
    TEST MESSAGE HOSPITALS HERE EXPERIENCING
    SEVERE SHORTAGES OF ANTIBIOTICS
    BT
    DAVE MAYHEW

    /EX

A message file can either be imported manually with the BBS GUI by choosing "Import Messages" from the Actions menu or with the import CLI command available to sysops only. The syntax is "IMPORT [FILENAME]":

    DL4FN de DB0NTS> IMPORT c:/users/bpq/documents/var/tmp/import.txt
    ST 07405 @ NTSNJ < DL4FN $5231_DL4FN
    ST EA4UC @ NTSEU < WB9FHP
    2 Messages Processed

On Windows you can either use slashes or backslashes as path separator (internally modern Windows operating systems use the slash anyway and it is easier to type at least on a German keyboard). There is no prescribed place for import files. Best use either a subdirectory of the user's documents (typically C:\Users\[Username]\Documents) or temp (C:\Users\[Username]\AppData\Local\Temp) directory.

The BID is checked against the BID database when a message with a BID is imported so that it cannot be imported a second time. In case the BID is not specified on import the message is always treated as new.

The IMPORT command can also be used in connect scripts to import message files automatically into the BBS and the optional word "DELETE" after the filename means to delete the file after the import (to avoid duplicates) e.g.

    IMPORT C:/users/bpq/documents/svc-msgs.txt DELETE

When a message is received with subject "Batched messages for AutoImport from BBS [CALL]" (the subject may be prefixed with "//WL2K") which contains a sequence of message in the above standard form in it's body the messages from the body will be automatically imported into the BBS and the envelope message will be killed. [CALL] can be any callsign and it is not checked against the user database. In the log file this is shown as follows:

    161223 04:25:17 >IMPORT    ST DL4FN @ NTSEU < WB9FHP $75690_WB9FHP
    161223 04:25:17 >IMPORT    OK
    161223 04:25:17 ?IMPORT    Msg 19767 Routing Trace To DL4FN Via NTSEU
    161223 04:25:17 ?IMPORT    Routing Trace Type T TO DL4FN VIA NTSEU Route On NTSEU (null) (null) (null) (null)
    161223 04:25:17 ?IMPORT    Routing Trace NTS Matches TO BBS DL4FN Length 5
    161223 04:25:17 ?IMPORT    Routing Trace NTS Best Match is DL4FN
    161223 04:25:17 >IMPORT    >
    ... ... ... ... ...
    ... ... ... ... ...

Messages can be exported manually either by selecting one or more of them in the "Manage Messages" window and clicking the "Export" button or by using the CLI EXPORT command available to sysops. The syntax is "EXPORT [NR] [FILENAME]" with [NR] being the local message number:

    DL4FN de DB0NTS> EXPORT 1234 C:/users/bpq/documents/var/tmp/export.txt
    Message 1234 Exported

Note that the EXPORT command does not change the message status and that it overwrites an already existing file.

Connect scripts have the FILE command to export messages to a file. The command syntax is "FILE [FILENAME]". An already existing file is appended (not overwritten) and messages are marked as forwarded. Note that temporary connect scripts allow to manually export messages with the FILE command e.g.

    DL4FN de DB0NTS> FWD KW1U NOW FILE C:/users/bpq/documents/var/tmp/export.txt
    Forwarding Started

This will export all pending messages for the KW1U BBS into the given file. A variant of the FILE command also allows to forward messages by email. This is described in one of the following sections.


Integrating with Winlink

The BPQ BBS can be used to exchange messages with the Winlink 2000 system. For a brief introduction on the latter see the above chapter on accessing the Winlink CMS which also contains other useful background information.


The Basic Setup

The reserved BBS callsign "RMS" is used to exchange messages with WL2K and we have already encountered this particular BBS callsign in the above section on the routing of (personal) messages.

As a first step create a new user with callsign "RMS" and the BBS and Excluded flags activated. Connections to the WL2K CMS are made under your BBS callsign (BBSCALL) which therefore needs to be a WL2K user. Edit the appropriate user record by entering it's WL2K password in the "CMS PASS" field and active the "Poll RMS" flag. Alternatively, the WL2K password for BBSCALL can also be entered for the RMS user but it is not recommended to do so.

In the forwarding settings of the RMS BBS enter "RMS" in the TO field and activate the following flags: Enable Forwarding, Request Reverse, Binary, and B2. Choose a rather short period for the forwarding timer e.g. 1800 seconds (30 minutes) and a longer period for the reverse forwarding timer e.g. 28800 seconds (8 hours, i.e. check for new messages three times a day).

The connect script of the RMS BBS needs to connect with a Winlink CMS. Remember that a connect script first allocates a stream on the switch. So in case you are running an RMS application your script may simply consist of the single switch command "RMS". When using CMS TCP access in client mode you may use the "C p CMS" syntax instead and radio links may be employed to connect to distant RMS gateway stations. A combination of all of these is shown in the following example:

    C 1 CMS
    ELSE
    PAUSE 245
    C 1 CMS
    ELSE
    C 2 DB0LJ-10 DB0BOS DB0AAI IGATE
    ELSE
    ATTACH 2
    RADIO 7.050 USB 2 D
    MYLEVEL 4
    PAUSE 2
    C %HB9AK

A local internet connection (with the telnet port running in client mode) is tried first. In case of failure we try again after 245 seconds (which is slightly longer than the TCP TIME_WAIT interval of 240 seconds on this particular computer). Next we try a UHF packet radio link to an RMS gateway station and if that also fails our last resort is a HF Pactor link to a more distant RMS gateway station. You will get the basic idea of this approach.


Sending messages

Messages to be forwarded to WL2K are addressed as TO RMS with the AT part containing the email destination address (see the section on message routing above) which can be achieved by prefixing the destination address with RMS:, e.g. RMS:dl4fn@qsl.net .

Destination addresses of the form CALLSIGN@winlink.org do not need the RMS: prefix (see the section on message routing above). This feature may be (ab)used to rewrite NTS message addresses with the NTS alias file. See above for an example. If CALLSIGN happens to be a local user who picks up his WL2K at our BBS (i.e. has the "Poll RMS" user flag activated) messages will not be forwarded to WL2K but kept locally instead.

    170202 13:54:09 ?DF0NTS    Msg 20363 Routing Trace To RMS Via DL4FN@winlink.org
    170202 13:54:09 ?DF0NTS    Message @ winlink.org, but local RMS user - leave here

NTS messages are converted to personal messages when forwarded to WL2K. Furthermore the From field is used to set the email sender address to FROM@winlink.org .

Importing the message

    SP RMS:dl4fn@qsl.net < DF0NTS
    test message

    This test messages comes to you via WL2K.

    /EX

will result in an email

    +-------------------------------------------------+
    |From: DF0NTS@winlink.org                         |
    |To: dl4fn@qsl.net                                |
    |Subject: test message                            |
    +-------------------------------------------------+
    |R:170201/0416Z 20330@DB0NTS.#HES.DEU.EU BPQ6.0.13|
    |                                                 |
    |                                                 |
    |This test messages comes to you via WL2K.        |
    |                                                 |
    |                                                 |
    +-------------------------------------------------+

Note that the BBS adds a routing header with the timestamp the message was received (i.e. imported in this example) at which shows up in the message body.

All messages queued for the RMS BBS are listed with the command "L> RMS" but note that those messages directly addressed as CALLSIGN@winlink.org (opposed to RMS:CALLSIGN@winlink.org) are not included:

    DF0NTS de DB0NTS> LN
    20449  04-Feb PN      10 DL4FN  @WINLINK DF0NTS test
    20448  04-Feb PN      52 RMS:dl4fn@t-online.de DL4FN  greg

    DF0NTS de DB0NTS> L> RMS
    20448  04-Feb PN      52 RMS:dl4fn@t-online.de DL4FN  greg


Receiving messages

WL2K messages can be retrieved for local BBS users only. To this end a user needs to record her WL2K password in the "CMS Pass" field and the "Poll RMS" user flag needs to be activated. The former can be performed by the user herself (with the CMSPASS CLI command) and the latter needs the help of a sysop.

Messages can be picked up for the user's base callsign and up to three SSIDs. These are to be entered in the user properties screen in the GUI. See the Winlink FAQ on how WL2K handles SSIDs.

Authorization with Winlink employs password hashes so that WL2K passwords are never transferred in plain text. To this end the CMS sends a so-called challenge to the connecting station prefixed with PQ: (for "password question") right after the SID:

    <RMS       *** DB0NTS Connected to CMS
    <RMS       [WL2K-3.2-B2FWIHJM$]
    <RMS       ;PQ: 32091644
    <RMS       Wien CMS >

All callsigns the connecting station wants to retrieve messages for are listed in a line starting with ;FW: (for "forward") right after the SID with the first callsign always being the one of the connecting station itself. Callsigns and their corresponding hashes are separated by vertical bars except for the first callsign (of the connecting station) for which the hash is contained in a separate line starting with ;PR: (for "password reply") right after the SID:

    >RMS       ;FW: DB0NTS DF0NTS|35447849 DL4FN|01328932
    >RMS       [BPQ-6.0.12.35-B2FIHJM$]
    >RMS       ;PR: 93479689
    >RMS       FF
    <RMS       FQ
    |RMS       RMS Disconnected

In the above example DB0NTS connects to the CMS located in Wien and retrieves messages for the three callsigns DB0NTS, DF0NTS, and DL4FN.

The TO field of a message originally sent to CALLSIGN@winlink.org is populated with CALLSIGN and the AT part is left empty after retrieval by the BBS. The message may either be picked up by the user herself or forwarded based on the TO address part (see below for more on this). Here is how addresses are handled for a message originally sent to CALLSIGN@winlink.org and retrieved by the BBS:

Winlink addressing BPQ address fields after reception
Sender email address Destination email address From Email from TO AT
SENDER@winlink.org CALLSIGN@winlink.org SENDER @winlink.org CALLSIGN --
SENDER@any.other.domain CALLSIGN@winlink.org RMS SENDER@any.other.domain CALLSIGN --

The CLI command "L< RMS:" (note the colon) lists all messages received by the RMS BBS except those originating from Winlink accounts. Those are considered to be personal messages for the recipient:

    DF0NTS de DB0NTS> LN
    20471  06-Feb PN     142 DF0NTS         RMS:dl4fn@t-online.de //WL2K R/test
    20470  06-Feb PN     131 DF0NTS         DL4FN@winlink.org hello Peter

    DF0NTS de DB0NTS> L< RMS:
    20471  06-Feb PN     142 DF0NTS         RMS:dl4fn@t-online.de //WL2K R/test

    DF0NTS de DB0NTS> L< DL4FN
    20470  06-Feb PN     131 DF0NTS         DL4FN@winlink.org hello Peter

Although a message received from WL2K is always for a local user it may be necessary to forward it and the following table show what happens to the address fields in this situation:

Protocol BPQ address fields after reception BPQ address fields after forwarding
From Email from TO AT From Email from TO AT
MBL/ RLI,
BF, B1F
SENDER @winlink.org CALLSIGN -- SENDER -- CALLSIGN Dest. BBSCALL
RMS SENDER@any.other.domain CALLSIGN -- RMS: -- CALLSIGN Dest. BBSCALL
B2F SENDER @winlink.org CALLSIGN -- SENDER @winlink.org CALLSIGN --
RMS SENDER@any.other.domain CALLSIGN -- SMTP: SENDER@any.other.domain CALLSIGN --

In conclusion the address fields are preserved with B2F forwarding (which is achieved with the help of the B2 message header) but not with the other forwarding protocols. Here is an example.

A message from dl4fn@t-online.de is sent to DF0NTS@winlink.org and then forwarded to DL4FN using B1F. It arrives as: From:RMS:, TO:DF0NTS, AT:DL4FN. Thus the original email sender address gets lost.


Export and AutoImport

As already mentioned above the FILE command is available in connect scripts to export messages to a file. The same command can also be used to export messages to an email message to be sent via Winlink.

    FILE RMS:[email address]

When the command is executed all messages at hand are batched into a single new (B2) message queued for the RMS BBS. The standard file import/ export format is used to this end and the subject of the new message is "Batched messages from BBS [BBSCALL]". If you wish to forward every single message with a separate email check the "Don't wait for poll timer" box for the BBS.

If you send the messages to the Winlink address of another BPQ BBS and add the token AutoImport to the above command

    FILE RMS:[DESTBBS]@winlink.org AutoImport

the forwarded messages will automagically import into the destination BBS upon receipt as if they were received by radio. The special message subject "Batched messages for AutoImport from BBS [BBSCALL]" is used for those messages and triggers the import process on the receiving side. This mechanism is particularly handy to manually forward messages to another BPQ BBS.

Upon receipt of such an auto-import message a new private message is created for the received email and the file import parser is invoked on it's body. After the file import successfully finishes the private message is killed immediately. If you want to keep a copy you need to back it up before the next run of the housekeeping process. The message number of the private message is not show in the BBS logs but as message numbers are given out sequentially by BPQ it is easy to guess it.

    <RMS       [WL2K-2.8.4.8-B2FWIHJM$]
    <RMS       Perth CMS via DB0LJ-10 >
    >RMS       ;FW: DF0NTS
    >RMS       [BPQ-1.4.62.5-B2FIHJM$]
    >RMS       FF
    <RMS       FC EM 8RUVIYZK2641 402 243 0
    <RMS       F> 90
    >RMS       FS Y
    |RMS       Uncompressing Message Comp Len 243 Msg Len 402 CRC 5e2
    ?RMS       B2 Msg To: DF0NTS
    >IMPORT    ST DL4FN @ NTSEU < DL4FN
    >IMPORT    OK
    ?IMPORT    Msg 1028 Routing Trace To DL4FN Via NTSEU
    ?IMPORT    Routing Trace Type T TO DL4FN VIA NTSEU Route On NTSEU (null) (null) (null) (null)
    ?IMPORT    Routing Trace NTS Matches TO BBS DL4FN Length 5
    ?IMPORT    Routing Trace NTS Best Match is DL4FN
    >IMPORT    >
    >IMPORT    ST DL4FN @ NTSEU < DL4FN
    >IMPORT    OK
    ?IMPORT    Msg 1029 Routing Trace To DL4FN Via NTSEU
    ?IMPORT    Routing Trace Type T TO DL4FN VIA NTSEU Route On NTSEU (null) (null) (null) (null)
    ?IMPORT    Routing Trace NTS Matches TO BBS DL4FN Length 5
    ?IMPORT    Routing Trace NTS Best Match is DL4FN
    >IMPORT    >
    >RMS       FF
    <RMS       FQ
    |RMS       RMS Disconnected

The imported messages do not have an additional routing header referencing the Winlink transfer. Thus the only way to find out how such a message found it's way into your BBS is by looking at the log files.


Operational hints

A couple of everyday tasks relating to the operation of a BPQ BBS are discussed in the following subsections.


Check for messages on hold

Messages may be put on hold for various reasons. See the section on message creation above. Without any further action they will sooner or later be silently removed by the housekeeping process.

Therefore you should check for messages on hold at least on a daily basis. The BBS main window shows the number of messages on hold. Alternatively you may use the LH command at the CLI.


Watch your clock

Make sure that your system clock always has the correct time.

Inbound messages may be put on hold and later removed by the housekeeping without notice if your system clock is wrong. The same may happen to traffic originating from your BBS when being forwarded.

Once I received messages from an MBO the system clock of which was wrong by one year. These messages were put on hold and removed by the housekeeping process just a few hours later.


Dealing with unroutable messages

Basically there are two ways to deal with unroutable messages:

  • leave them unroutable and get a system message for each of them
  • route them to a default BBS.

The first option is how BPQ works out of the box and a system message is created for each unroutable message. Either adjust the message's destination address or it's route manually in the "Manage Forwarding" window of the BBS GUI. Then execute "Rerun Message Routing" from the BBS Action menu. The advantage of this option is that the sysop is notified upon each unroutable message. The manual repair is suitable for single messages but not for many of them.

The second option is to set up a default BBS which is a pseudo BBS user (e.g. _DEFLT) with only the wildcard character "*" in it's AT routing table and the connect script "BYE". All otherwise unroutable messages will then be queued for the default BBS. Messages may be rerouted as in the first option or they may be exported to a file with a temporary connect script. Repair their destination addresses using the search and replace functionality of your editor and import them into the BBS again. The advantage of this approach is that it works great for masses of mis-addressed messages. The downside is that you actively have to monitor the forward queue of your default BBS e.g. by executing the "FWD QUEUE" CLI command on a regular basis or by having a look at the Start Forwarding menu entry in the BBS main window.

If you like you can also modify the idea of the second option to forward all unroutable messages to your local message client or to forward them to your Winlink account.


Making changes to the system

When you change the parameters of the scanner in BPQ32.cfg you can tell BPQ to reload this part of the configuration by choosing "Reload Rigcontrol" in the Action menu of the main sub-window of the BPQ console. BPQ reloads the scanner config at a suitable time and writes the output to the main sub-window.

When you choose to reconfigure BPQ either by selecting Reconfigure from the Action menu of the main sub-window of the BPQ console or by issuing the reconfigure command at a sysop CLI you will be disconnected from the system and BPQ will restart itself.

However, I prefer to always restart the BBS for configuration changes:

1. Make a backup copy of the configuration files (BPQ32.cfg, BPQMail.cfg) first with prepending the current date to the filename (e.g. 20171227-BPQ32.cfg).

2. Change the configuration as needed while the system is still running.

3. Stop BPQ by selecting "Close all BPQ32 Programs" from the BPQ console at a suitable time and restart it. If a problem occurs with the new configuration revert to the old saved one.


Tracing a message by BID

All information on BBS traffic is in the BBS log files which is why a text search tool for files is needed to trace messages. Unix operating systems come with the "grep" program to this end which is also available for Windows as part of the Sourceforge UnixUtils project. Alternatively, you may use the standard Windows "find" utility.

In the following examples we will always use "grep".

To find a message by BID search the BBS log files for the BID in question:

    C:\Users\bpq>cd AppData\Roaming\BPQ32
    C:\Users\bpq\AppData\Roaming\BPQ32>grep 37536_KW1U Logs\*
    logs\log_170731_BBS.txt:170731 17:56:12 <KW1U      FC EM 37536_KW1U 416 317 IMPORT NTSEU DL4FN T
    logs\log_170731_BBS.txt:170731 19:05:14 >DL4FN     FC EM 37536_KW1U 467 345 0

We thus find two matching lines in one log file. Now open the BBS log file the BID appears in with your favourite text editor and look for further details.

Note that the "find" utility requires you to place the search string in quotes and that it lists all files in the directory. Here is the above example using find instead of grep:

    C:\Users\bpq>cd AppData\Roaming\BPQ32
    C:\Users\bpq\AppData\Roaming\BPQ32>find "37536_KW1U" Logs\*

    ---------- LOGS\LOG_170701_BBS.TXT

    ---------- LOGS\LOG_170702_BBS.TXT

    ... ... ... ... ... ... ... ... ...
    ... ... ... ... ... ... ... ... ...

    ---------- LOGS\LOG_170730_BBS.TXT

    ---------- LOGS\LOG_170731_BBS.TXT
    170731 17:56:12 <KW1U      FC EM 37536_KW1U 416 317 IMPORT NTSEU DL4FN T
    170731 19:05:14 >DL4FN     FC EM 37536_KW1U 467 345 0

    ---------- LOGS\LOG_170801_BBS.TXT

Remember that the BBS log will also show the local message number (Msg 24392 in our example) for the message in question:

    170731 17:56:12 <KW1U      FC EM 37536_KW1U 416 317 IMPORT NTSEU DL4FN T
    170731 17:56:12 <KW1U      F> FD
    170731 17:56:12 >KW1U      FS Y
    170731 17:58:08 |KW1U      Uncompressing Message Comp Len 317 Msg Len 416 CRC 2fc9
    170731 17:58:08 ?KW1U      B2 Msg To: DL4FN@NTSEU
    170731 17:58:08 ?KW1U      Msg 24392 Routing Trace To DL4FN Via NTSEU
    ... ... ... ... ... ...
    ... ... ... ... ... ...

The message can now be either displayed at the BBS CLI (R 24392) or at the OS command prompt:

    C:\Users\bpq\AppData\Roaming\BPQ32>type BPQMailChat\Mail\m_024392.mes
    MID: 37536_KW1U
    Date: 2017/07/31 14:53
    Type: Traffic
    From: IMPORT
    To: DL4FN@NTSEU
    Subject: DL4FN
    Mbo: KW1U
    Body: 289

    R:170731/1453Z 37536@KW1U.#EMA.MA.USA.NOAM BPQ6.0.13


    31 R  HXG NC4WB ARL 12   BOONE NC JUL 29
    ... ... ...
    ... ... ...


Tracing a message by radiogram number

When tracing a message by radiogram number (and station of origin) we have to search for the given data within the message files.

The grep tool supports wildcard matching which can be employed to search for radiogram number and station of origin within a single command. To find the message shown in the previous section use:

    C:\Users\bpq\AppData\Roaming\BPQ32>grep -i "31 .* NC4WB" BPQMailChat\Mail\*
    BPQMailChat\Mail\m_024392.mes:31 R  HXG NC4WB ARL 12   BOONE NC JUL 29

The -i option instructs grep to search the files for both upper and lower case. Now you use the local message number (24392) taken from the filename to search the BBS logs or you can read the message file with an editor to find out more (BID, routing headers).

Using the find utility instead is a bit clumsy as it lists all files searched through i.e. all messages on your system which may be thousands on an active BBS. Additionally, find does not support wildcards.


The secret of the blocking queue

The BxF protocols mostly used for message transfer are a bit rude demanding the remote side to close the connection in some cases including

  • protocol error (command line not starting with the letter F)
  • syntax error in message proposal
  • message check sum error.

BPQ considers in particular the following cases as message proposal syntax errors:

  • missing From, TO, or AT part in proposal line
  • TO or From part longer than 6 characters in proposal line
  • AT part longer than 40 characters in proposal line
  • BID longer than 12 characters in proposal line
  • more than 5 messages proposed in a single batch.

Furthermore if reverse message transfer is not allowed by the MSGTYPES command and the remote side issues a message transfer proposal the connection will be closed.

Note that messages exceeding the size limit are rejected.

When exchanging messages with another BPQ BBS agree on a message size limit to use on both ends. Otherwise one BBS will mark the rejected messages as being forwarded without them arriving on the remote side.

When exchanging messages with a non-BPQ BBS (e.g. Winlink Classic or FBB) have a look at the logs that connections are not closed for message proposal syntax errors. I once encountered a situation where a Winlink Classic BBS proposed a message the AT part of which was 7 characters long. This is perfectly ok with Winlink but BPQ closes the connection once the message is proposed for transfer. As a result more than 200 messages queued up behind the one with the 7 chars AT part.

Thus TO or From address parts exceeding the limit of 6 characters or corrupt messages (checksum errors) will result in BBS connections being closed. These messages may block any further message exchange with another BBS. Therefore read your logs carefully every day.


Linking RMS Express to BPQ32

To link RMS to BPQ32 add RELAYAPPL=BBS to the telnet port in the BPQ32.cfg file.

Then set RMS Express to TELNET WL2K mode and set it to RMS Relay.

TODO (Peter): this will be detailed in the chapter on the BBS

Related Links