forward.bbs

Forwarding partnerships are defined in this file. The data of this file describes the actions taken by NOS in forwarding to remote partners. The file contains a series of forwarding records, three or more ascii lines per record, each record being separated by a line containing two or more hyphens. The template for each forwarding record is:

Target BBS-callsign time-specs poll-flag
Connection Spec with route
Connection Command Script      <zero or more lines>
List of areas to be forwarded  <one per line>
--------                       <end of record>

This excerpt example is to forward two areas:

--------
ve4wws 0007 P
ax25 430 ve4wws
ve4wws
mb
--------

Target BBS

This is simply the ordinary call of the remote BBS. A typical (but not random!) entry might be simply the line:

```
sm0rgv
```

The callsign may be followed, on the same line, by a comma separated list of valid intervals when forwarding is to take place. Each valid interval is a four digit number: the first two digits are the beginning hour of the valid interval, the last two digits are the final hour of the valid interval. For example, if the first line of a forwarding record looks like:

```
sm0rgv 0006,1414
```

then forwarding to sm0rgv will take place only during hours numbered 00, 01, 02, 03, 04, 05, 06 and 14. Ticks of the mbox timer outside of these times will not cause mail to be forwarded to sm0rgv. The default interval for forwarding is 0023.

If you desire to force a connect to occur, even if we have no traffic to transfer, then use the poll flag, P, in addition to any time specs.

Connection Spec

This is the method by which communication is to be established with the remote BBS. The first token on the line is the type of protocol to be used. This is one of:

ax25 - The connection is over the basic AX.25 radio network
netrom - The connection is to one of the nodes known to NET/ROM
tcp - the connection is to a node over the TCP/IP network
hf - the connection is over the basic AX.25 radio network using HFDD device
file - a file is built for transport by other means at other times

Following this is whatever further information the chosen protocol requires to make the connection, perhaps a digipeater route. Some example:

```
ax25 ax0 g3dlh
```

Establishes an ax25 connection on interface ax0.

```
ax25 ax0 g3dlh via k5arh uv-3 kb5ogn-1
```

Establishes an ax25 connection on interface ax0 with a route thru various digipeaters.

```
file <path_to_export file>
```

To specify forwarding to a file for transfer by another means, perhaps FTP,

Connection Command Script

Connection commands may, optionally, follow the connection route. These take the form of a single character command followed by suitable argument strings. Supported commands are:

.text text (with CR suffix) is sent to remote.
+text establish a search string.
@NN read a line with timeout of NN secs, and fail unless it contains the search text established with the + command.
*NN read and discard lines until a line matching desired string is encountered or until NN secs has elapsed.
. any search string is reset.
# comment_text comment text is ignored
! eschew FBB compression

For example, suppose that we wish to establish a netrom connection with sm0rgv-2, through the netrom node #sth67. Then the connection route and connection command portion of the record would look like:

```
netrom #sth67
.c sm0rgv-2
```

Another example, this time we use ax.25 protocol to connect with a netrom node, k7uyx-1, and then connect to another netrom node:

ax25 ax0 k7uyx-1    <- initial connection to netrom node
.c rlimb            <- ask for a netrom connect from this node
+Connected          <- if we don't get this, things went wrong
@60                 <- maximum one minute wait !

If the station is reached through digipeating, then the digipeater callsigns should either be specified in the connect line (described above) or be in the ax25 route to the destination callsign. For example, if you wish to forward traffic to r2nod, implicitly using r1nod as a digipeater, then you should have the line:

```
ax25 route add r2nod r1nod
```

in your AutoexecNosFile file.

List of material to be forwarded

This is a list of files in the /spool/mail directory which will be considered for forwarding to the remote BBS. There are two contexts for handling material: mail and bulletins. The determining factor is that bulletin files are listed in the AreasFile. Please note that ONLY FILES IN /spool/mail are checked. In particular, the outbound SMTP mail queue is NOT checked.

When r1nod IS NOT in AreasFile an entry here of the form:

```
r1nod
```

will cause forward server to scan the file named r1nod.txt for unread messages. Any such messages are sent to the remote BBS and deleted from the local file when successful.

When amsat IS listed in AreasFile an entry here of this form:

```
amsat
```

will cause forward server to search the amsat.txt file for any messages contained therein which have not already been forwarded to the BBS in question, and these will be forwarded now. These bulletins will NOT be deleted from the local file.

Changing the recipient address

Normally, NOS uses the information in the To: header line to determine the parameters used by the "S" command during BBS forwarding. Occasionally, one might want to change this behavior. In this case, a line of the form:

```
area  newaddress
```

in the list of areas to be forwarded will replace the originally typed destination with the string newaddress instead.