A few paramters apply to all forwarding. These are the maximium message sizes you are prepared to send or receive, the Alias List, and the (at the moment disabled) options to make the Alias processing change the message itself, rather than just change the way it is handled by this BBS. If you are using the normal FBB forwarding protocols, your system will refuse any messages larger than "Max Size to Receive". It will hold any message larger than Max Size to Send", whether input locally or received from another BBS.
You have to have a BBS record for each station that you forward from or to, whether or not you initiate the connection.
See here for information on configuring forwarding to/from the Winlink 2000 system.
You must specify the HA of the BBS. You can choose to forward only Personal Messages. You can select which varients of the FBB Binary protocol you want to use. I suggest you use B1 where possible, as this supports restarts, and
gives additional checks against corruption. You should only use B2 of the other end insists on in (only RMS, as far as I know). You can specify the maximum size of a forwarding block.
If you want to connect, rather than just letting the other BBS poll you for messages, you must specify a Connect Script. If you want to connect automatically, (not just via the "Actions/Start Forwarding" menu),
you must set "Enable Forwarding", and an appropriate Interval. If you want to limit forwarding to certain times of the day, set Time Bands.
If you want to connect to the other station even if you don't have any messages to send,
you need to set "Request Reverse". I suggest that normally this isn't necessary - it is better for both ends to be set up only to connect if they have something to
send - this avoids continually connecting, but not passing any messages.
Note that all times are in UTC. You can limit times of day for automatic forwarding to occur. So if you want to forward only between 0800 and 1200, and 1400 and 1600 enter:
0800-1200 1200-1600
If you want to specify a range ending at midnight, you must enter 2359, eg
0000-0800 1800-2359
Note that you can also use this to forward at certain minutes past the hour. So to forward only during the first 10 minutes of each hour between 0800 and 1200, enter
0800-0810 0900-0910 1000-1010 1100-1110
If you do this, remember to set Interval to less than the length of your time bands, or you may miss some. There is no limit on the number of bands you can specify.
A connect script may be just a single connect command, or may require a series of steps to connect via a node. You can also include most BPQ32 node commands, if you wish to change some link parameters. For example it may be appropriate to change PACLEN, MAXFRAME, FRACK, etc if forwarding over an HF link.
Forwarding via Nodes C NODE1 C NODE2 C 3 BBSCALL Note that you don't need to program the node responses - the software knows what to look for. HF Forwarding. PACLEN 80 PACLEN is a user level command - doesn't need SYSOP status PASSWORD (the word PASSWORD, not a password! causes immediate entry to SYSOP Mode if entered locally MAXFRAME 4 1 RETRIES 4 10 FRACK 4 30 Frack is in units of 1/3 secs. C 4 CALLSIGN
You can control what types of messages will be sent during this connection, whether to accept messages for the other end (Reverse Forwarding), and the maximum sise to send. . If the other BBS is also running an up to date BPQMailChat it will apply the same limits to messages it sends to you. The MSGTYPES command goes before the C command.
MSGTYPES PT Send only P and T messages. Dont accept messages from other end. MSGTYPES BR Send only Bulls (any size). Accept forwarding from the other end. MSGTYPES PTRB1000 Send all types, but only bulls of up to 1000 bytes. Accept forwarding from the other end. MSGTYPES P1000T1000B1000R Send all types, but only up to 1000 bytes. Accept forwarding from the other end.
Normally you would not include the 'R' option if not forwarding to another BPQ BBS, as you have no control of what it sends you.
Normally if sending to another BPQ BBS, you would include the 'R', and your MSGYTPES command will be passed to
the other BBS and will control what it sends you.
You can use different MSGTYPES commands in combination with ELSE (see below), so that, for example, you could send all messages
over your main path, but only P and T over an HF backup link.
You can have different forwarding scripts for different times of day. For example:
TIMES 0000-1159 C G8BPQ TIMES 1200-2359 PAC 80 ATTACH 4 C G8BPQ
This would forward via axip/netrom between midnight and midday, and by Pactor midday to midnight. It also allows you to forward on different HF frequencies at different times. See Rigcontrol Documentation for details
TIMES 0000-1159 ATTACH 5 RADIO 14.110 USB 2 C G8BPQ TIMES 1200-2359 ATTACH 5 RADIO 7.080 USB 2 C G8BPQ
You can have sets of forwarding scripts so a second is tried if the first fails. For example:
RMS ELSE C G8XXX-10 ELSE C G8YYY-10
You can use ELSE within TIMES sections.
Some nodes return a > at the end of their CTEXT. This could be treated as the first prompt from the BBS. You can use the SKIPPROMPT command to get round this situation.
C G8XXX-10 C G8YYY-10 SKIPPROMPT
If you want to allow time for the PACTOR or WINMOR busy channel detect to stabilize after changing frequency, you can add a PAUSE command after the RADIO command.
ATTACH 5 RADIO 7.080 USB 2 PAUSE 2 C G8BPQ
Allows you to limit the number of connects on a port to one,
INTERLOCK 1
Gerarates and sends a one time password to allow RIGCONTROL to be used on a remote machine. Use the Keyphrase from the RIGCONTROL configuration.
RRADIO AUTH Keyphrase
Enables basic text mode forwarding (no SID Exchange, end with ctrl/z or /ex) for forwarding to dumb TNC based PMS systesms
Forward to a file (export). See here for details.
The software differentiates between Bulls that have reached their target area, called "Flood Bulls", and those
that have not (eg a Bull sent to ALL@GBR from the USA), called "Directed Bulls". Directed Bulls are forwarded as if
they were personal messages. It is worth noting that in a properly configured network, Directed Bulls will be quite rare.
Generally all routing should be done on HR wherever possible, except for purely local distribution of personal messages, which may be done on the TO field. There is an implied AT route to each BBS you forward to, so that if you forward to G8BPQ, a message addressed to XXXXX@G8BPQ.#23.GBR.EU will be sent to G8BPQ irrespective of any other forwarding entries.
Personal Messages, and Bulls that have not reached their target area are forwarded to only one BBS - either the first BBS to match on a TO field, or the one with the most matching elements in the HR. So if you define BBS1 with HR EU and BBS2 with HR GBR.EU, a message for G8BPQ@G8BPQ.#23.GBR.EU will be sent to BBS2. Any other EU message (eg FRA.EU) would be sent to BBS1. There is no need for an exclusion rule to stop GBR.EU going to BBS1.
Bulls which have reached their target area will be sent to all BBS's that:
A). Are in the target area. So if the Address of a BBS
is G8BPQ.#23.GBR.EU, then it would be considered for Bulls sent to EU or GBR.EU, or #23.GBR.EU but not #24.GBR.EU
or FRA.EU.
B). Matches the Bull HA list. The message must match all elements of HA list entries. So if ther above station wants all Bulls,
just enter WW. It will then get WW, EU, GBR, and #23.GBR messages.
If it only wants local messages, and not national or internationals, put the required level - eg GBR.EU wouldn't get
@EU or @WW messages.
The Hierarchical Routing system will only work if messages have a valid, full (ie including continent) HA.
Personal messages with a HR derived from the White Pages system will usually be ok. The software understands Country Codes,
so a message addressed to ALL@USA will be handed as if addressed to ALL@USA.NA, and also the mapping from two
character to four character Continents, so ALL@USA.NA and ALL@USA.NOAM are equivalent. Ideally SYSOPs should try to educate
their users to use correct addresses for Bulls, but as this won't always be possible, and some non-geographical addresses
(such as @AMSAT) are so well established that some method of handling them is needed. It would be possible to route on the
AT field, but this will defeat the code that limits Bulls to the desired target area. So I've provided an Aliasing
facility that enables the software to treat a non-standard Dest as a valid HA. Note that (at least with the current version)
the address in the message isn't changed - just how this BBS interprets it. So you could have in the aliases list:
AMSAT:WW
ALLUS:USA
CALIF:CA.USA
CANADA:CAN
Also sometimes a distribution may be required that does not fit with the HR system - for example a group of adjacent
areas. These can be agreed between adjacent BBS sysops, and forwarded on the AT field.
A message will be considered a "Flood Bull" if the address can't be converted to hierarchic form.
Let's start with something simple. A radio club wants to run a BBS for it's members. It has established a link to an existing BBS,
whose sysop has agreed that he/she will forward any messages to or from the new bbs. The club wants to receive all Bulls. So all the club BBS
has to do is send all messages to it's neighbour.
Simply set both Personal and Bull(flood) HA fields to WW. So long as members address Bulls to valid hierarchical addresses (eg all@ww, all@usa, all@ca.usa)
then they will match the WW rule. If someone insists on being awkward, and sends messages to USBBS, there would have to be an ALIAS
entry of USBBS:USA.
The feeding bbs config is even simpler. It only needs to forward personal messages for the club BBS, and all messages addresses
@clubcall will be send automatically. (via the Implied AT rule). To forward all Bulls, set the Bull HA field to WW.
Several clubs, set up as above, want to send messages directly to each other over radio, rather than via the upstream feed. In this description the upstream bbs is called HUB. They also want to be able to send bulls to all the clubs in the group, but not have them appear anywhere else. Lets assume they are all in area #NCA.CA.USA.NA. If all BBS's in the group can forward to each other, then personal messages will be handled by the implied AT rule. Lets assume it is not that simple. There are four BBS's, BBS1, BBS2, BBS3 and BBS4. BBS1 can only connect to BBS2. It needs to forward messages for BBS3 and BBS4 via BBS2. It sets HR (Personals) to:
BBS3.#NCA.CA.USA.NA BBS4.#NCA.CA.USA.NA
Note that it does not need BBS2.#NCA.CA.USA.NA, as this is implied. It also does not need to do anything to stop these messages going via HUB - Personal messages are only sent to the BBS
with the most matching elements in the HR.
To create a local distribution list for Bulls (eg all@local), simply put LOCAL in the AT field of each BBS record.
Let's assume we have a station that has forwarding partners in each continent, who are set up to handle distrubution
within that continent, called EUHUB, ASHUB, SAHUB, etc.
For each of these, Bulls are handled simply with WW in the HR (Bulls) field. The filtering on BBS HA will ensure that Bulls
don't go where they are not meant to be.
Personals are handled by a single entry in the HR(Personals) field:
EUHUB: EU ASHUB: AS etc.
Note again you don't need exclusion rules.
Obviously you also need forwarding partners within your continent to handle local distribution.