Let’s have another look at our high level block diagram…
Ackpf! A public Internet connection?
Many readers of this post are likely, and rightly, shocked by the notional connections of the VAPN system to the Internet. After all, our crowing up to this point has preached the mighty gospel of security assuredness wherein the best and safest course of action to prevent break-ins is simply to never connect the gear to the Internet. Unfortunately the #1 most requested feature from potential VAPN patrons is some form of connectivity to the public email system. Winlink is often the other word in their feature request. With this hair raising request in our minds, we set about researching just what it takes to accomplish the goal.
Winlink and BPQ32
The BPQ32 software system provides two ways of interaction with the Winlink system:
- A more or less transparent pipeline between a BPQ node user and a Winlink Internet server;
- A way for the BPQ mail system to cache Winlink messages on behalf of a BPQ user.
The first “pipes” Winlink service to the VAPN service area. The second stores messages on VAPN equipment for later retrieval by a VAPN patron.
Given the alleged propensity of Winlink to not monitor each and every message sent through its system, the obvious concern is VAPN gear storing and/or transmitting such info thereby being partially responsible for FCC rule violations and subject to fines. This is not without precedent…
FCC levies fines along message chain
The F.C.C. says it is merely enforcing the law. It issued fines and warnings to amateur radio operators last month after they relayed, some unwittingly, an antiwar solicitation that officials said violated rules against commercial messages on amateur radio waves.
Much has been said since the 1991 New York Times article. Hope comes from rule 97.219(c),..
Sec. 97.219 Message forwarding system
(a) Any amateur station may participate in a message forwarding system, subject to the privileges of the class of operator license held.
(b) For stations participating in a message forwarding system, the control operator of the station originating a message is primarily accountable for any violation of the rules in this part contained in the message.
(c) Except as noted in (d) of this section, for stations participating in a message forwarding system, the control operators of forwarding stations that retransmit inadvertently communications that violate the rules in this part are not accountable for the violative communications. They are, however, responsible for discontinuing such communications once they become aware of their presence.
(d) For stations participating in a message forwarding system, the control operator of the first forwarding station must:
(1) Authenticate the identity of the station from which it accepts communications on behalf of the system; or
(2) Accept accountability for any violation of the rules in this part contained in messages it retransmits to the system.
[59 FR 18975, Apr. 21, 1994]
Emphasis added. All that said, the 1991 actual FCC action is the most recent I have found yet concerning packet radio – Actual case action trumps rules until the new rule is actually tested. It’s reasonable to take the threat seriously. Banning all email connectivity entirely is the obvious safe play, but we are nonetheless exploring options to see what might be viable.
The $10,000 question
A very good question concerns a message from an outside email to someone on packet. Is the intermediate gateway the person placing the message into the ham system once it transmits the message to the packet user? Or is the email sender considered the originator? Questions like these definitely make mere technical hurdles seem simple by comparison.
It is important to understand the FCC’s jurisdiction is finite. Don’t expect part 97.anything to help you if you pass a defaming message or a zero-day virus/link through your system.
Email and BPQ32
One fallout from our research was the pleasant find of a POP and SMTP capability directly within BPQ32 BBS application. “Whoa what’s this?” was our immediate reaction. We’ve tested this capability on our operating prototype system and it works. As part of our test, we bootstrapped a fresh MX machine on the Internet just for this purpose and the results are quite positive. There is no “pipeline only” operation in this scheme as messages to and from Internet email addresses are stored like any other message in the BBS system. Hence, VAPN still runs the risk of transmitting inappropriate content on the ham bands when the VAPN user retrieves messages over the air.
Difference between VAPN and Winlink Internet email
As the colors in the above figure attest, we have no control over anything Winlink does with their system concerning security and message vetting. We do, however, have full control over our mail exchange machine we maintain strictly for VAPN email purposes. With such control, we can rule over the email gateway with strong authoritarianism to better manage and perhaps reduce the risk of rule violation.
Yeah I’m sure the Winlink folks are working hard on some or most of these issues, but until some sort of collective acceptance of their ways settles in, we are likely better off “rolling our own” mail for now. Thankfully, the BPQ32 software’s email gateway feature provides the perfect opportunity to bootstrap an email solution.
Another aspect to keep in mind of the two approaches is this… One approach uses legendary server-grade, mail-exchanger software running on an up to date, well secured, Linux system managed by paranoid, security conscious, server admins in a data center environment. The other approach is Winlink. Think the two are the same? Maybe they are, but we don’t know how to tell. One of the notes in the Winlink FAQ suggests as of 2007 the WL2K software has about 20 man-years of development effort. This is a serious effort no doubt, but one has to wonder how well that competes with traditional email server software with development efforts measured in man-decades.
VAPN email gateway authoritarianism
You might be wondering just what we mean with a word like authoritarianism. Keeping in mind the amateur radio frequencies were never meant to be a substitute for all-too-often-far-more-appropriate commercial communication services, the following rules may find their way into our vapn.org email machine:
- Accept email only for actual users (firstname.lastname@example.org) of the VAPN BBS (obvious right?);
- Severely restrict the size of the received email to be compatible with low speed packet systems (also obvious… right?);
- Accept only Whitelisted senders to VAPN BBS users (no real need to receive email from everyone);
- Strip attachments (BPQ apparently supports attachments in some form, but VAPN will likely quash them).
Winlink does perform some of the above with Emcomm in mind. Our goal with the VAPN is to provide a short messaging service with use for situations like this example…
Example health & welfare VAPN to Email message
Message from amateur radio husband at campground with no cell service using packet gear to wife’s email:
The kids and I made it to Big Meadow campground fine.
Thinking of you.
…to which the wife responds via email to the vapn.org address…
Thanks for letting me know – I “really” appreciate it.
Don’t forget the anti-histamine meds in the top pocket of the knapsack.
Jack picks up the message from Jill a few minutes later and all is well. No 10k messages needed here. Health and welfare in its purest form. Amateur radio making a difficult communication possible. Messages much larger than the above suggest the purchase of a satellite phone/modem to solve your digi-commo problem.
Note: Winlink FAQ Question #170 says “120,000 bytes is the largest ‘compressed’ message size that will be accepted for Winlink,” but advocates using much smaller sizes as a practical matter. Despite this rock solid advice, the mere capability of a message this large is way too generous for serious use on pragmatic amateur radio digital modes. On the other hand Winlink has a loftier, more Emcomm oriented, goal than VAPN.
Why bother with Internet email at all
In a perfect world, our significant others would be hams as well so both would use amateur radio to communicate the above Jack and Jill example. The real world is the real world so it’s no surprise the feature requests we receive concern contacting loved ones via an email gateway. Add the fact our gracious hosts providing VAPN with some hilltop rack space are making these requests. We have to listen and see if there is a fit.
If we do support the email gateway feature, keep in mind if we ever feel our amateur licenses are threatened by operating the VAPN, it will be promptly brought down for good – life’s too short.