B2F -- Winlink Message Structure and B2 Forwarding Protocol

June 1, 2001
Revised: October 3, 2017


This is a specification for the transfer of messages between Winlink Radio Mail Server (RMS) gateway stations and Winlink-compatible user client programs (WL2K clients), or between any gateway or client and any Common Message Server (CMS) or RMS Relay program running with a telnet server.

When connected with a non-Winlink client or another MBO (NPMBO) that is not a Winlink gateway then messages will be forwarded using the current FBB protocol. This protocol is an extension of the original 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 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 2000 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.

All of the parts of a message are combined into a single “file” that is then compressed (using the same compression program used for FBB B1 compression and available as B2Compress.exe) as a unit before transmission.

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
Cc: SMTP:[email protected]
Subject: This is a sample address header
Body: 1302
File: 3556 NOLA.XLS

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 2000 system between RMS stations and connecting user clients.

  • Bulletin messages are messages sent to a PMBO to be posted at the CMS 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 2000 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 2000 station sysop by addressing the message "SYSOP." or "Service.". The CMBO 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 2000 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) 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


This is the specification for the expanded FBB protocol used in WinLink telnet connections. Other BBS software (e.g. AirMail, Paclink, RMS Express) also use this format and it is open for use by other client and gateway software. 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/

The purpose of this protocol expansion is to allow for transfer of additional message types, as required by the WinLink system and 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

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.

Winlink Extensions

The below 'commands' are implemented as extensions applicable only to connection to the Winlink system. Since these commands all start with ';' they are seen as comments to any program that does not explicitly support them.

Secure Login
For a gateway connection:
The Telnet server prompts for a password hash computed using the supplied challenge phrase.
;SQ: [challenge_code]
The gateway responds with
;SR: [response_code] [frequency] [mode]
The Telnet server validates the response, frequency, and mode of the connection. If any of these fail, the connection is aborted.
The client portion of the connection continues by prompting for a password hash computed using the supplied challenge phrase.
;PQ: [challenge_code]
The client responds with
;PR: [response_code]
The Telnet server validates the response. If this fails, the connection is aborted.

Mail forwarding ;FW
During login a challenge phrase is created and used during the secure login protocol exchange. That same challenge phrase is used by programs to validate account access for the mail forwarding feature.
If a client program is sending “;FW:” the first parameter must be the original callsign:

A program wishing to retrieve messages for a callsign (or tactical address) other than the one used to log-in will send “;FW: ” followed by the original login callsign (for cases where the connected callsign SSID has been altered by a packet node) then followed by one or more callsigns (or tactical addresses) with adjoining challenge response value (multiples separated by a space). If a tactical account has no password the challenge response is omitted. For example:
;FW: ZZ0TST ZZ1TST|123456 ZZ2TST|2456244 MYEOC|78546743 NOPASSTAC

The above example requests message ID’s for the account used to log in (ZZ0TST) then two callsign accounts (ZZ1TST and ZZ2TST), a tactical address that has a password, and finally a tactical address that does not have a password – no challenge response is included in this case (tactical addresses do not have to have a password and you can’t use them to log-in to a CMS). Each challenge response is computed using the same algorithm and challenge phrase as that used during the initial secure login process.

The CMS will responded with message ID’s for all pending messages for the validated accounts. If a challenge response is incorrect or an address is invalid a warning will be returned (;WARNING followed by some error text). These warnings should be captured to the application’s log and presented to the user as appropriate.

Pending Messages ;PM
Once logon has successfully been completed, the Telnet server will send notification of any messages pending for the login callsign and any callsigns listed in the ;FW: command string that were validated.
Here's what it looks like:
;PM: ZZ0TST WY0OLVZE2E2D 157 [email protected] Testing mail preview
;PM: ZZZTAC-NO AY0OUY3DV42D 570 [email protected] Testing mail preview
;PM: ZZZTAC-PW HYG78DDM9AQE 432 [email protected] Testing mail preview
The list starts with ;PM: (for pending message), followed the callsign of the recipient, the message ID, Message Size, and From Address. The rest of the line is the subject of the message.

Questions and Other Information

General information about Winlink is available at https://winlink.org.

Questions and comments on the Winlink message protocol and B2 Protocol expansion should be directed to the Winlink Development Team on the support email reflector .

* 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. The make-up of encapsulated messages is described in another document.

Winlink Linkomatic