Open B2F -- Winlink Message Structure and B2 Forwarding Protocol

Last revised February, 2018

Introduction

This is a specification for the transfer of messages between Winlink Radio Mail Server (RMS) gateway stations and Winlink compatible user terminal programs (WL2K clients). This document also clarifies details of implementation of the B2F protocol so that Winlink stations' compliance with US FCC rules is clear. Using technical information here will allow an individual with development skills to create programs to clearly monitor intercepted on-air transmissions. B2F handles the preparation, compression, and interchange of messages over all radio and wire transfer modes, including: Pactor 1-4, WINMOR, ARDOP, VARA, Robust Packet, AX.25 Packet, Telnet over TCP/IP. Within the Winlink system and in all compatible user programs, the modem hardware or software that handles radio modes are always used without any native or proprietary capability to compress, obscure, or encrypt message content.

When connected with a non-Winlink client or another MBO (Non-Participating Mail Box Operator) that is not a Winlink RMS then messages will be forwarded using the current FBB protocol. The B2F protocol is an extension of the original FBB amateur packet protocol that was aimed at the manual keyboard user. Standard FBB B1 and lower protocols do not support multiple address messages and messages with embedded attachments. This protocol extension does.

Winlink message flow and packaging is described in the document file entitled 'Winlink_Data_Flow_and_Data_Packaging.pdf' downloadable below.

Message Structure

A message will consist of three parts:

The first is the header which contains the properties of the message such as its MID, origination date, originator, destination(s), subject, etc. This is described below. The address header is always in ASCII text and each line is separated by carriage return/line feed. Packet headers received from a packet connection may optionally be retained as part of the body of the message. RFC 822 headers received as part of a message from Internet will be parsed and removed at the point of entry into the Winlink system.

The second part is the body of the message, which may not be empty. The body of the message is limited to ASCII characters and is separated from the address header by a single blank line. The exact length (in characters) of the body of the message is indicated in the address header. The body of the message is terminated with a carriage return/line feed character sequence. These two characters are not included in the length of the message body indicated in the address header and are in addition to any carriage return/line feed characters that may be in the body of the message.

The third part of the message is the attachments. There may be any number of attachments. For each attachment there is a parameter in the address header that includes the exact length of the attachment and the original file name and extension for the attachment. The file name and extension is limited to 50 characters. An attachment is a sequence of 8-bit bytes without restriction. An attachment is always terminated by a carriage return/line feed. The carriage return/line feed sequence is not included in the attachment length indicted in the address header.

Compression

All of the parts of up to five messages are combined into a single “file” that is then compressed as a unit before transmission. Winlink uses the same compression program used for FBB B1 compression and available as B2Compress.exe in the FBB bulletin board package. Compatible derivative forms of the compression algorithm (LZH or LZHUF) are freely available online, and it's open development history can be explored by examining documentation within code sources. A formal description of the LZH format is at http://www.onicos.com/staff/iz/formats/lzh.html. The actual source code used in Winlink programs is freely available and publicly archived at https://github.com/ARSFI/Winlink-Compression.

Address Header

The address header will contain the following elements. There is no requirement of a specific order other than the “Mid:” parameter must appear on the first line and the “File:” fields must be in the same order as the following attachments but it is probably wise to follow a consistent format.

Mid: 12345_K4CJX
Date: 1999/09/22 14:33
Type: Private
From: SMTP:[email protected]
To: W1AW
To: W4ABC
Cc: N8PGR
Cc: SMTP:[email protected]
Subject: This is a sample address header
Mbo: SMTP
Body: 1302
File: 3556 NOLA.XLS
File: 5566 NEWBOAT.HOMEPORT.JPG

The header is case insensitive, however, the case of characters received in the From, To, Cc, and Subject fields will not be changed when stored or forwarded.

The Mid: field is a unique sequence of up to 12 text characters to identify the message system-wide.

The Date: field is the UTC date and time the message was originated and is in the format YYYY/MM/DD HH:MM.

The Type: field may be “Bulletin”, “Private”, “Service”, “Inquiry”, “Position Report”, “Position Request”, “Option”, or “System”. System messages are only used within the Winlink system between RMS stations and connecting user clients.

• Bulletin messages are messages sent to the CMS via RMS or telnet for servicing in the WL2K catalog system. The system operator may intercept posted bulletins before they are added to the database. Bulletins sent to a user as a result of an inquiry message are sent as Private messages.
• Private messages are messages addressed to end users.
• Service messages are messages directed to the operator (sysop) of a Winlink station of any type. If the “To:” field is simply “SYSOP” or “Service” then the message will go to the sysop of the station first receiving the message. It may be addressed to another Winlink station sysop by addressing the message "SYSOP." or "Service.". The CMS SYSOP can be reached by substituting “CMBO” for the call.
• Inquiry messages are messages requesting the down loading of specific bulletins. (See WL2BUL.DOC)
• Position Reports are messages send by users reporting their geographical position. (See WL2QTH.DOC)
• Position Requests are message sent by users requesting a report of the position of other user(s). (See WL2QTH.DOC)
• Option messages are message sent by users to change parameters in their station’s record in the Winlink system. (See WL2OPT.DOC)

The From: field is the address of the originator. Any address that is from a non-winlink.org domain (originating on the internet) will include “SMTP:” as the initial five characters of the address.

The To: field is the address of a destination. There may be any number of To: fields. Note: A message must have at least one To: field.

The Cc: field is the address of a destination. There may be any number of Cc: fields.

The Subject: field contains the message’s subject, up to 128 characters.

The Mbo: field is the call of the originating RMS or “SMTP” or “CMBO”.

The Body: field contains the exact count of the number of characters in the message body.

The File: field contains the exact count of the number of characters in an attachment and the file name (up to 50 characters [5/27/2020 -- amended to allow up to 255 characters]) of the original file. There may be any number of File: fields. The order in which the File: fields appear in the address headers must be the same order that the attachments are added to the message file.

Any other field designator appearing in the address header will be ignored and will not cause a error at the receiving end. This will allow for graceful additions to the header format in the future.

Transmitting Messages

Transmitting messages is subject to the protocol used on a specific channel. If a station cannot support the B2 protocol then only the message body is transmitted and information content of the header is lost. Only single radio addresses are supported by FBB message protocol B1 and lower.

FBB B2 Forwarding Protocol Expansion

Introduction

This is the specification for the expanded FBB message forwarding protocol used in the Winlink system. Other BBS client software (e.g. AirMail, Paclink, RMS Express) and many packet programs also use this format and protocol for intercommunicating and message forwarding. It is open for use by other software, freely shared by authors who have contributed to it over many years. This document assumes the reader is familiar with the present FBB protocol. For more details on the original FBB specifications please refer to respective information at http://www.f6fbb.org/. Information regarding the FBB protocol's SID (System Identification) structure, i.e. [WL2K-5.0-B2FWIHJM$], is given at the same site.

The purpose of this protocol expansion is to allow for transfer of additional message types, as required by the Winlink system as described above.

Any BBS wishing to adopt this expanded feature is to follow the connected BBS’s feature SID. The connected BBS needs to support the F feature (FBB protocol) and the B2 feature (expanded FBB protocol described here).

Any BBS employing level B2 FBB protocol needs to be fully backward compatible, meaning that it needs to also support FBB ASCII and level B0 and B1. Therefore, a level B2 BBS must also accept FA and FB proposals according to ASCII and B0 and B1 rules, depending on the connected station’s SID.

FA and FB proposals used in level B2 conform to B1 rules. (see http://www.f6fbb.org/protocole.html)

Specific B2 Expansion

FBB level B2 allows for FC proposals.

The FC proposal is initially used for any Winlink encapsulated message or Winlink control message. Other message types may be added in the future.

Standard messages of type Private or Bulletin may be proposed using either the lower level FA or FB proposals using the level B1 rules, or as an encapsulated message using level B23.

Unlike FA and FB proposals, the FC proposal does not include sender or receiver address information, as that is included within the encapsulated messages’ header as described above.

FA, FB and FC proposals may be intermixed in any combination within a proposal block.

The FC proposal has the following elements:

• FC
  Proposal code. Requires B2 SID feature.
• Type
  Message type (1 or 2 alphanumeric characters)
• CM
  WinLink Control message
• EM
  Encapsulated Message *
• ID
  Unique Message Identifier (max length 12 characters)
• U-Size
  Uncompressed size of message
• C-size
  Compressed size of message

Further expansions in the form of comments proceeded by ';'

Any line preceded by ';' MUST be considered a comment and ignored (unless a supported extension).

Winlink uses several comments to implement internal (Winlink only) extensions to the protocol.

• ;PQ
  Account authentication challenge
• ;PR
  Account authentication response
• ;FW
  Forward message(s)
• ;PM
  Pending message(s)

With the requirement for all Winlink accounts to have and use passwords, the ;FW extension now also must supply a password hash for any additional accounts for mail forwarding, i.e., you must know the password for any account you are picking up mail for.

For example:
;FW: N2XXX OCANN|84595756

The first callsign is the login callsign (for cases where packet nodes may have altered the SSID for the connected callsign).
The second callsign is one foe which N2XXX wishes to pick up mail. The code passed with this callsign is constructed using the same ;PQ challenge that was used for the primary account secure login process and the password for OCANN. Additional callsign|code constructs can also be included separated by a space.

Other FBB protocol Proposals

All the other FBB proposal commands remain the same and are used exactly as specified in the original specification. This includes in particular the FS proposal response, including partial recovery, and the FF and FQ commands.

FA and FB proposals follow level B1 rules.

Notes Regarding Winlink Compliance with FCC Rules

As explained in the introduction, B2F and it's payload compression mechanism is always implemented on top of a transport (radio or wireline) protocol, such as Pactor 1-4, ARDOP, VARA, AX.25, Telnet over TCP/IP, etc. In the specific case of using SCS Pactor modems to handle the radio protocol, Winlink programs connect to the hardware using W8DED extended host mode and initialize the hardware using the hardware's "MODE 0" command, which puts the hardware into strict ACSII mode without any native compression. This is the case for other radio modes as well, if their modems implement native compression or manipulation that would obscure the meaning of content payload, or hamper on-air monitoring with the correct tools. It should also be noted that any SCS modem has a built-in function called "listen mode" that allows direct on-air monitoring of ARC packets in real time, even if the transmissions are not using Winlink B2F and use any of the modem's native compression levels. This information is provided to specifically clear questions regarding compliance with FCC 97.309.

Though Winlink associated programs do not use it, SCS has a paper that describes the advanced compression choices that are built into their Pactor modems. It is downloadable from here:
http://www.p4dragon.com/download/PACTOR_Advanced_Data_Compression.pdf

Questions and Other Information

General information about Winlink is available at www.winlink.org

Technical questions and comments on the Winlink message protocol and B2 Protocol expansion should be directed to the Winlink Development Team.

* WinLink encapsulated messages can be any known Packet/HF message as well as more complex messages with multi address headers and any number of attachments.