Mail Message Scanning
Contents
NOS determines if a piece of traffic was entered into the network by a BBS by looking for a BBS system ID (like the "[JNOS-IHM$]" block issued by NOS) on the incoming connection prior to messages being uploaded. The scan process is based on one of the four possible entry routes for mail message traffic into the system:
- Traffic received by SMTP server
- If the traffic was received form a remote system the rewrite file is scanned and any changes applied.
- If the traffic appears to be addressed to the local system then the alias file is scanned and any changes or explosions applied.
- Any copies to the local system are delivered; then copies for remote delivery are placed in the SMTP outgoing queue.
- Traffic received by mailbox from user entered mail
- The rewrite file is scanned and any changes applied;
- The traffic is passed to the SMTP client.
- Traffic received by mailbox from forwarding actions of a remote BBS
- The rewrite file is scanned and any changes applied;
- The traffic is passed to the SMTP client.
- Traffic entered by external mechanism
- No scanning occurs
- The traffic is passed to the SMTP client.
Headers
Appropriate RFC-822 headers are added to all incoming traffic. Traffic entering through the mailbox receives a full complement of RFC-822 headers; traffic coming through the SMTP server has only a "Received:" header applied. On forwarding to a BBS, if an item of traffic contains BBS R: headers, the RFC-822 header is converted to an appropriate R: line at the time that NOS forwards the message. (This change only occurs for BBS forwarding; forwarding by SMTP retains the RFC-822 headers.)
Bulletin Identifiers (BIDs)
The AX.25 BBS system has evolved a reasonably efficient way of reducing overhead when forwarding bulletins. When a bulletin is originated on a BBS, it is given a unique bulletin identifier (BID). This BID should (theoretically) travel with the bulletin, and should never be changed during the distribution of the bulletin.
- Each system keeps track of all received BIDs. If a forwarding station wishes to forward a bulletin to a BBS, then the receiving station checks its local list of known BIDs and informs the transmitting station if it already possesses the bulletin in question.
The NOS mailbox conforms to this protocol. Received BIDs are stored in the file HistoryFile, and are encoded in the Message-ID: header line of the message by NOS. Messages forwarded from areas listed in the AreasFile will have their BID (re)generated from the Message-ID: line. Note that ALL messages from public areas are forwarded with a BID, whether or not the message was produced with the "SB" command.
Like other BBSes, NOS will inform a transmitting station not to transmit a bulletin if it is one that NOS already has locally; likewise, it understands similar messages from other stations to which it tries to forward.
Note that the BID mechanism is not a part of the SMTP world. If you are forwarding bulletins through SMTP, there is no certain mechanism by which the receiving station can reject the attempted delivery of a bulletin, even if it already exists on the recipient system. JNOS will generate a bid that will match the bids that other JNOS systems generate from the same message, but this convention is not universally followed. (Note that another possible workaround is to deliver bulletins to TCP/IP stations using TCP instead of SMTP. Alternatively, one could use NNTP, as NNTP commands utilize the Message-ID: line, from which the BID is derived.) The BID is preserved no matter which mechanism is used to deliver the bulletin.
Traffic in practice
Now, the big question is, how does one set up these various files to perform intelligent manipulation of mail? A number of examples follow. Note that, often, there is more than one way to accomplish an objective. The following are merely examples (and not necessarily the most efficient method possible for any given case). The format used will be:
typed destination -> intended destination followed by the necessary entries in the files alias: (/alias), rewrite: (/spool/rewrite) and forwarding: (/spool/forward.bbs)
Using familiar names - SMTP destination
bdale -> bdale@n3eua.ampr.org alias: bdale bdale@n3eua.ampr.org rewrite: forward:
Exploding local mail
sysops -> nq0i, n5op@n5op.ampr.org alias: sysops nq0i n5op@n5op@ampr.org rewrite: forward:
Using familiar names - BBS forwarding
g4bki -> g4bki@gb7bil.2712.gbr.eu, to be forwarded by ai0c alias: rewrite: forward: ai0c ax25 ax1 ai0c g4bki g4bki@gb7bil.2712.gbr.eu ai0c
Handling incoming bulletins by subject
tcpip@* -> nq0i, tcpip, bdale@n3eua.ampr.org, ai0c@ai0c [a BBS] alias: tcpip nq0i tcpip bdale@n3eua.ampr.org ai0c rewrite: tcpip@* tcpip forward: ai0c ax25 ax1 ai0c ai0c
Let's walk through the above example. An incoming item comes in addressed to TCPIP@ALLUS. A scan is made through the rewrite file, and a match is found. The item is redirected to tcpip. The alias file is scanned; a total of four copies of the item exist after this, three in local areas tcpip, nq0i and ai0c, and one on the SMTP queue (for bdale@n3eua.ampr.org). When the mailbox timer next ticks, the mail in the local ai0c area will be forwarded on the ax1 interface to ai0c.
Routing based on Hierarchical addressing
Wyoming -> KE7VS (SMTP) Nebraska -> AG0N (BBS over the NETROM, NETROM ID WNBBS) Europe -> W0LJF (BBS over AX.25) alias: rewrite: *.noam $1.na r *.us $1.usa.na r *.usa $1.usa.na r *.ne $1.ne.usa.na r *.wy $1.wy.usa.na r *@*.wy.usa.na $1%$2.wy.usa.na@ke7vs *.ne.usa.na ag0n *.eu w0ljf forward: ag0n netrom ax0 wnbbs ag0n ---------- w0ljf ax25 ax1 w0ljf w0ljf ----------
Why is the example rewrite file apparently so complicated? This is to handle poorly constructed hierarchical addresses in a reasonable way. A full U.S. hierarchical address has the form:
callsign@BBS.#localid.state.usa.na.
Many states have no #localid field. In the example rewrite file above:
the first three lines convert non-standard, but frequently used, U.S. designators to the more standard format. It is common for users not to use a full hierarchical address if the destination is relatively local. For example, a user might easily use only .wy instead of the full .wy.usa.na if he is geographically close to Wyoming.
The second grouping of two lines handles this problem. Note the third, "r", field in all the entries so far.
The remainder of the file handles properly formatted hierarchical addresses.
General bulletin handling
The details of bulletin handling will vary somewhat from place to place, as there are several distinct styles of bulletin handling currently in use in the AX.25 BBS world. In general, it is necessary to arrange one's system so that it accepts bulletins from BBSes, forwards them to one or more stations, and also handles intelligently bulletins input by users into NOS. Suppose that we wish to handle bulletins @JUNK. We are to deposit them locally in the junk area, and also forward to BBS g4bki. We also know that we generally receive @JUNK bulletins from g4amj, a local BBS which handles much bulletin traffic.
alias: rewrite: *@junk junk forward: g4bki ax25 ax1 g4bki g4bki junk ---------- g4amj ax25 ax1 g4amj g4amj junk ----------
All incoming @JUNK traffic is written to the junk area (which should be an explicit entry in the AreasFile). Each tick of the mailbox timer, NOS scans the junk area for traffic not forwarded to g4bki or g4amj and attempts to deliver unforwarded bulletins. Usually, g4amj will respond with a "Have it" message and the bulletin will not be forwarded. Any bulletins @JUNK deposited locally by users will automatically be sent to both g4bki and g4amj.