This specification describes the transfer of messages between Winlink Radio Mail Server (RMS) gateway stations and Winlink compatible user terminal programs (WL2K clients).

When connected with a non-Winlink client or another MBO (Non-Participating Mail Box Operator) that is not a Winlink RMS, 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.

The B2F protocol MUST operate over a 8-bit clean communication bearer, which provides reliable and ordered delivery.

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.

; Proposal Code: "FC"
B2F_PROPCODE = %x46 %x43
 
; Message type. CM = WinLink Control Message, EM = Encapsulated Message 
B2F_TYPE     = 1*2(ALPHA / DIGIT)
 
; Unique Message ID
B2F_MID      = 1*12VCHAR
 
; Uncompressed size
B2F_USIZE    = 1*DIGIT
 
; Compressed size
B2F_CSIZE    = 1*DIGIT
 
; Proposal definition
B2F_PROPOSAL = B2F_PROPCODE SP B2F_TYPE SP B2F_MID SP B2F_USIZE SP B2F_CSIZE CR

The calling station identification command is to be sent PRIOR the calling station SID.

;FW CALLSIGN

ABNF Grammar:

CALLSIGN      = 1*(%x41-5A / DIGIT)
B2F_CALLER_ID = %x3b %x46 %x57 SP CALLSIGN CR

The exchange happens after the SID has been transmitted.

The server sends a ;PQ proposal with an authentication challenge, which is formatted as follow:

;PQ 99685857

The client computes the response using the following pseudocode:

// Trailing salt
uint8_t sl_salt[] = {
   77, 197, 101, 206, 190, 249,  93, 200, 
   51, 243,  93, 237,  71,  94, 239, 138, 
   68, 108,  70, 185, 225, 137, 217,  16,
   51, 122, 193,  48, 194, 195, 198, 175, 
  172, 169,  70,  84,  61,  62, 104, 186,
  114,  52,  61, 168,  66, 129, 192, 208,
  187, 249, 232, 193,  41, 113,  41,  45, 
  240,  16,  29, 228, 208, 228,  61,  20
};
 
// Concatenate the challenge, the password and the salt.
payload = concat( challenge, password, sl_salt)
 
// Compute the md5 of the last result
md5sum = md5(payload)
 
// Take the first 4 bytes of the hash, flip the byte-wise endianness, and cap the first byte to 0x3f
response = ( (uint8_t)(md5sum[3]) & 0x3f ) << 24 | (uint8_t)(md5sum[2]) << 16 | (uint8_t)(md5sum[1]) << 8 | (uint8_t)(md5sum[0]) )
 
// Keep the 8 least significant digits in base 10 of response. 
// If response is shorter than 8 digits, 0-pad from the left.
resval = itoa( response % 100000000, base10)
sprintf( result, "%08d", resval)

The result is then sent to the server using the following format:

;PR 99685857

ABNF Grammar:

B2F_AUTH_CHALLENGE = %x3B %x50 %x51 SP 8DIGIT CR
B2F_AUTH_RESPONSE  = %x3B %x50 %x52 SP 8DIGIT CR

Reference source code in paclink-unix, function compute_secure_login_response() and wl2k-go

A message is structured in 3 parts:

The first is the header which contains the properties of the message such as its MID, origination date, originator, destination(s), subject, etc. The address header is US-ASCII encoded. Each line is separated by carriage return/line feed (0x0d 0x0a).

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 the Internet will be parsed and removed at the point of entry into the Winlink system.

The second part is the message body, which MAY NOT be empty. The message body is limited to ASCII characters. It 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 message body 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, 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.

ABNF Grammar: