a STANAG-5066 HF MailServer at work

this is a good example of a STANAG-5066 based HF Mail Server (an MTA, Mail Tranfer Agent) at work: the HF Mail Server receives one email transmitted by a wireless client (over-the-air path) which is addressed to multiple non-HF recipients, and then it takes care of each single delivery by forwarding each message through an infrastructured TCP/IP path and returns back the email transmitted notifications to the sender (Fig. 1). Just the copy of the over-the-air "notifications" allowed to retrace the scenario.

The transmission concerns HF mail tests from a Turkish HF newtork, most likely belonging to the Coast Guard, and was (accidentally!) copied by KarapuZ. The HF Mail Server sits in the middle and acts as default MTA for the turkhfmail.com domain, so it's  "transparent" to the users. Both the sender and the Mail Server are in the same STANAG-5066 HF network: respectively, 1.0.0.3 and 1.0.0.1 (S-5066 Addresses).

Fig. 1

The used HF waveform is STANAG-4285 with ARQ extension provided by upper STANAG-5066 data link protocol (Fig. 2), the channel is used in half-duplex mode.

Fig. 2

The transmission, as said, convey test emails in clear-text, so these are not critical/secure messages, however only the domain names are visible while the account names are obscured. As I mentioned several times, I'm only interested on the way the "boxes" travel on-the air and not in their contents.

Figure 3 shows the transmission of the email from a certain <user>@turkhfmail.com (the sender at gw-HF-mail) to some recipients belonging to different not-HF email domains. Notice that the Adobe license is the content used as test message (so nothing important, just a text).

Fig. 3

the HF mail server reports the emails status to the original sender by transmitting a single notification for each addressed recipient: in this case the sender is the HF mail server.

I wanted to illustrate more clearly two of those test notifications in order to understand the involved users and their role. Figure 4 shows the status notification of the email which is addressed to Directorate General of Coastal Safety, Figure 5 show the status of an email addressed to Selex ES headquarter in Turkey

Fig. 4

Fig. 5

The Turkish Directorate General of Coastal Safety is the client and the Italian Selex-ES is the solution vendor: it's quite obvious that these are the recipients since they are the most interested on the results of the tests. 

Some other informations can be acquired from the headers. 
1) The used protocol is CFTP (Compressed File Transport Protocol). CFTP is used to reliably send compressed SMTP e-mail over a STANAG-5066 HF subnetwork from one SMTP mail server to another. In operation, when an email message is received at a 5066 node, it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent (DA), removes mail from this incoming folder and processes the mail for delivery over HF via 5066. The CFTP DA compresses the message and information about the message, e.g. size, id, recipients, etc. into a file. This compressed file is then transferred to the destination HF 5066 node(s).
2) User-Agent at the sender node is Mozilla/5.0 rv:12.0 Thunderbird/12.0.1 on Windows NT 6.1
3) The email domain name is turkhfmail.com, usually mail servers use mail.<domain name> as their hostname so I tried to nslookup mail.turkhfmail.com and got 212.156.62.66 (relay7.selex-comms.com.tr); the mail server is owned by Turk telekom and hosted directly by Selex-ES (Fig. 6)

Fig. 6

The HF mail server, as an MTA, also delivers messages from senders outside the HF network to STANAG-5066 HF recipients as shown in Figure 7

Fig. 7

It's worth noting the match of the mail server public IP address.