As Ars security-meister Dan Goodin noted in his initial write-up back in October, the Helm Personal Server is a small-ish ARM-based email server that sits in your home and does for you what Gmail or Outlook.com or whomever your current email provider does for you. It’s a full-featured, single-domain (for now) MTA in a box that you can use with an unlimited number of email addresses and accounts, and it gives you 128GB of space to use as a mail store for those accounts. It also gives you CalDAV calendaring, notes, and CardDAV contacts, and it does it all with open-source applications that are chosen and configured in a way that demonstrates a solid bias toward individual security and privacy.
And I like it. I like it a lot. I didn’t think I would, but after spending a week with the device, I’m almost ready to spring for one—almost. And that’s high praise, coming from a paranoid email self-hoster like me.
Based on my short time with the Personal Server, the praise is properly earned. The Helm team based its product mostly around the same mail stack that I personally prefer and use—the holy trinity of Postfix for SMTP, Dovecot for IMAP, and SpamAssassin for keeping things clean. The device properly uses SPF, DKIM, and DMARC—and handles all the DNS stuff necessary to make those things work. End-user data is smartly encrypted at rest and in flight. Clever use of tunneling to AWS-based gateways transparently works around common ISP blocks on email service ports. And, perhaps most importantly, you don’t have to know what any of that stuff means to use the device securely—casual folks who maybe just want to lessen their reliance on Google or Microsoft will find the transition to Helm relatively painless, and there aren’t many ways to screw it up and make yourself less secure.
But technical users might balk at some of its shortcomings and annoyances—the underlying Postfix/Dovecot configuration (along with the constellation of smaller apps like OpenDKIM that are necessary to make it work) can’t be viewed, changed, or edited. If you’re bringing an existing domain to the Helm service, you currently need to transfer your domain’s authoritative DNS to Helm’s AWS-based DNS servers so that the service can manage the necessary MX and TXT records. The choice of AWS for DNS means Helm currently doesn’t offer DNSSEC support. And a few other minor issues might make experienced email sysadmins hesitant—though conversations with Helm’s support team during the review have me convinced of the company’s willingness to evolve the product in a direction more compatible with the (sometimes difficult) demands of power users like me.
All that being said, the tl;dr here is that I like Helm. I like what the company is doing, and I like the way it’s doing it. With a few minor changes (and some more exposed knobs and levers so I can tweak things a bit), I’d happily buy a device and transition my email hosting off of my current setup.
Now let’s dig a little deeper into what we’ve got here.
How Helm fits into the email-hosting dilemma
In early 2014, I penned a four-part series about how to host your own email for your own domain, based on my own adventures in self-hosting. Although the guides are at this point in dire need of updating, they’re among the most popular things I’ve written in my entire tenure at Ars (eclipsed only by the time I talked non-stop about farts for a whole week). Doing my own email hosting has on the whole been a rewarding and challenging endeavor that’s yielded tremendous amounts of knowledge, experience, and gray hair—and, after doing it for a bit more than five years, I have no plans to stop.
There are significant benefits to self-hosting your email, but they come with significant downsides, too—most notably, you’re on the hook for any mistakes or problems. “Email,” said Past Lee, “is like a puppy, and once you step up and own your own puppy, you’ve got to take care of it, clean up after it, and make sure evil people don't infect it with horrible viruses and transform it into a zombie.” Looking after an email server does occasionally require work—a responsible sysadmin needs to keep up with updates, keep an eye on the log files, check regularly on RBLs, be mindful of deliverability and sender reputation, and other miscellaneous sysadmin-y tasks. It’s not overly onerous, but it’s not hands-off, either.
Helm aims to give you the best of both worlds—the assurance of having a device filled with sensitive information physically under your control, but with almost all of the heavy sysadmin lifting done for you.
The primary difficulty Helm will face here is the marketing message—who is this thing for? Most folks in the angry graybeard set (of which I count myself a member) are either already self-hosting or have dismissed self-hosting as far more trouble than it’s worth; the casual-user set doesn’t really think much about how email works or what “hosting” really means.
Helm therefore has decided in its marketing literature to lean heavily on the privacy aspects of self-hosting. Helm’s website leads with that message and plays up how switching to Helm is a way to take ownership of one’s online identity and divorce oneself from technological dependence on giant data-hungry corporations:
Your most critical data (like emails, search history, passwords, photos, and videos) is stored on a massive corporate server outside your home.
Increasingly, this leaves you vulnerable to hacks, companies profiting from your data and online behavior, and mass government surveillance.
It’s a marketing message not without some necessary caveats—as long as you’re exchanging emails with other people who use those big corporate services, you’re just as vulnerable to mass surveillance and data harvesting as before, since marketeers (along with any interested three-letter agency) will simply vacuum up your message on the receiving end rather than the sending end. And Helm’s usage of AWS for so much of its infrastructure—even with a responsible eye toward encryption and keeping sensitive data properly siloed—means you’re still depending heavily on one of the most data-hungry corporations of them all.
The message, however, isn’t wholly inaccurate—you’re better off self-hosting. It remains an open question, though, of whether the average consumer (or even the average tech-savvy Ars reader) would be willing to spend $499 and an additional $99 each year for a nebulous and difficult-to-fully-quantify increase in security. Convincing people to do so will be Helm’s greatest challenge—probably a great deal harder than actually designing the service in the first place.
The Helm service—or, “where does my $99 a year go?”
I want to talk just for a moment about exactly what that ongoing $99/year charge pays for. Obviously, Helm has employees, and they need to make payroll; the Helm service requires ongoing work behind the scenes for it to remain long-term functional. But the subscription fee also covers a fair amount of real AWS-based infrastructure costs that come with each Helm device sold.
Helm utilizes Amazon’s Route 53 DNS service on the back-end, which gives you a robust DNS setup with a large number of fast, geographically distributed resolvers. To work around ISP restrictions on ports and to do away with the Sisyphean task of trying to use a residential ISP IP addresses for email service, the company spins up Amazon EC2-based gateway machines that establish tunnels to the residential Helm devices. “All the gateway does is forward packets back and forth,” explained Helm CEO and co-founder Giri Sreenivas to Ars. "All TLS terminates on this device. All we’ve done is introduce an extra hop on the Internet. We’re funneling encrypted traffic.”
Helm also puts some care into the AWS IP addresses assigned to the Helm gateway, doing all the necessary legwork to vet those addresses against the ever-changing list of anti-spam IP address blacklists utilized by most email servers.
The AWS costs for Helm also include built-in cloud redundancy; the company uses Amazon’s US-West-2 region for its gateways and keeps machines in all three of the region’s availability zones. The company uses a separate region, US-East-1, for all of its data storage—that is, the place where your gigabytes of encrypted email back-ups live.
The mail flow
Those EC2-based gateways are one of the keys to making Helm work. When your local Helm server powers on, it establishes an IKEv2-based tunnel to an EC2 gateway. That EC2 instance is assigned the public IP address referenced in your domain’s MX records, and utilizes good ol’ iptables to forward select packets through the tunnel to your Helm server.
The path is the same whether you’re an IMAP client checking your inbox or another email server transmitting a message over SMTP—everything goes via the gateway.
Interestingly, this means that email clients on the same LAN as the Helm server still run their traffic across the Internet, through the tunnel by way of AWS. When you configure your client, you point it at “helm.yourdomain.com” for SMTP and IMAP and forward DNS lookups on that hostname will always return the AWS gateway’s Internet IP address.
I asked Helm support about bypassing the tunnel and addressing the Helm server’s mail ports directly on the LAN, which might be something a customer with split-horizon DNS would do. The response was reassuring: “This shouldn't be a problem," the support people said. “If the user sets up DNS to point directly to the local Helm IP address for local clients, those ports are currently open, and so it should work. This isn’t a configuration that we have tested, however, but technically we don’t see any issue with this.”
(While the SMTP and IMAP ports are locally addressable, there’s not much else you can actually do to the Helm server directly—there is no way to log into it. Configuration tasks are all done via an app, which we’ll get to shortly.)
The decision to wrap all server comms in a tunnel pleasantly sidesteps the two major issues that often come with trying to self-host an email server on a residential ISP connection. Namely, you don’t have to worry about your ISP blocking inbound connections on common email ports, and you don’t have to worry about the fact that most residential IP addresses are permanent residents on just about every blacklist ever. By shifting the connection point to Amazon’s cloud and being choosy with the IP address pool they have to work with, Helm saves you no shortage of headaches. (You also don’t have to worry about updating a DNS entry when/if your home IP address changes, but that’s mostly a solved problem at this point anyway.)
Unboxing and setup
The server comes packaged with a quickstart guide, a network cable, a good-quality branded AC adapter, a USB key for storing your backup encryption key(s), and a Helm sticker (our review device also came with a separate USB stick loaded with press assets and images).
Setup is pretty darn easy. You unbox the server, peel off the plastic protective film around it and its AC adapter, plug it in, and connect it to your LAN. The device has built-in 802.11ac and can be run wireless, but you need to set things up wired first before you can configure Wi-Fi. After you've plugged in the network cable, you turn the thing on, install the mobile app on your iOS or Android device, and follow the steps.
Those steps, pictured in a gallery below, will see you first pairing your Helm server with your smartphone via Bluetooth to kick off the setup. The Helm server and your smartphone perform a token exchange via Bluetooth that enables your phone to continue being used for admin tasks; configuring new smartphones to work with the Helm app requires physical proximity and another Bluetooth connection. (Configuring smartphones to send and receive email with Helm, though, does not—you only need to worry about the one-time Bluetooth connection for devices you’re going to use to administer the server.)
It’s important to pause and reiterate that, after the initial token exchange via Bluetooth, all communications between your management smartphone and the Helm server happens over the Internet via the AWS gateway. That’s the case even if your phone and the Helm server are on the same LAN segment. This is actually a relief for folks like me who are perhaps more than a little paranoid about putting a device we can’t manage or upgrade on a trusted LAN segment with other trusted devices—since there isn't any direct communication between your management device and the Helm server, there’s no reason you can’t permanently plop the Helm server on your IoT VLAN if you have one or even onto its own isolated segment.
Per a note from Helm support, the only thing the box needs to be able to do is send outbound traffic on UDP ports 500 and 4500 and on TCP port 443. You don’t need any incoming port-forward rules.
The review units Helm sent out were preconfigured with test domains (I got “helmdomain21.com”), but if you’re an actual customer, you’ll either have purchased a domain from Helm when you bought the device or you’ll have switched your existing domain’s authoritative DNS over to Helm’s DNS servers when you bought the device.
Regardless of how you got there, the setup continues by showing you the domain assigned to you and asking you to enter an activation code Helm sends you at purchase. After that, you create your first mailbox for the domain, which is also your administrator account.
The setup assistant then prompts you to insert that flashy silver USB stick into one of the Helm’s ports. At this point, the server generates an encryption key pair and writes the private key to the stick. The encryption keys are used both for encrypting the Helm’s local filesystem and also for encrypting the server’s automated backups, which are automatically uploaded to AWS for you. If your Helm server dies or is stolen, you’ll need this physical key to restore your email backups and configuration to a replacement Helm device.
Finally—at least on iOS, which is what I use—the application generates a set of profiles containing your Helm account’s email, calendar, and contacts settings. Then the application installs all of that for you, though you have to hit OK a few times to shepherd the process along. This is a nice convenience that eliminates you potentially needing to copy-and-paste (or, worse, write down and manually enter) a bunch of server and account settings.
Once the profiles are installed, you’re immediately able to send and receive email from your new domain. After that, the app has a set of wizard-like tasks in the main window to show you how to import email from external accounts, create more email addresses, and set per-device passwords on your Helm account so it can be accessed on other devices like a laptop or tablet.
If you’re looking to migrate off of an existing service, like Gmail or Yahoo or Outlook.com, the app provides an easy way to automate what can be a tedious process. Briefly, Helm uses good ol’ IMAP to clone your mailbox from other services, and it appears to do a good job of it.
However, it can take some time, and the migration process isn’t very informative if you want to know how far it’s gone and how much it has left to go. I decided to put Helm’s migration skills to the test by seeing how well it fared with my crufty original Gmail inbox, which has about 40,000 emails in it stretching back to September 1996 (I did a big IMAP import from my ISP inbox when I signed up for Gmail in 2004).
It’s not enormous by any means—Gmail says I’ve only got 4.31GB in use—but as I sit here writing this on the afternoon of Sunday, December 2, the import process has been running non-stop for about 49.5 hours. How much longer it has to go is unclear. The only thing you’ve got to key on for progress info is the “Storage” field in the app, which shows the amount of disk space consumed, but that’s not terribly helpful. Before I started the import, it showed 1.9GB of the Helm’s 128GB NVMe disk in use; 24 hours ago, it showed 6.4GB used, and currently it shows 10.2GB used. I’ve only got 4.31GB of mail to import, so I’m not sure how to correlate those numbers, other than noting that the used space number keeps getting bigger and that’s probably a good sign.
Annoyingly, the app will occasionally throw up a “Network error” dialog, but it’s utterly unclear if the error is with the IMAP sync or the communication with the Helm device itself. Worse, it’s also unclear if the error means I need to restart the sync process or if it’s continuing on its own. (I think it’s the latter, but it’s just not obvious.) If the import process finishes before I have to turn this piece over for edits, I’ll make sure to add an update here on how long it took.
(Quick note from a Monday afternoon edit pass: finally finished after a total of right at 53.5 hours, and the app shows 14.4GB used, for whatever that’s worth.)
The good news is that the import process doesn’t render your device unusable or anything like that. Old Gmail labels and messages are definitely filling up my Helm inbox as the import grinds along, and I can send and receive Helm email without a problem.
Advanced users looking for a more direct approach to pulling in their inboxes (say, by using Google Takeout or some other method of getting a single archive together and then upload that archive directly to the Helm server) will unfortunately be disappointed. It’s IMAP or the highway, at least for now.
How to use the thing for email
Perhaps unsurprisingly, one of the most important parts of the review—“How well does it actually send and receive email, damn it?!”—is going to be one of the shortest: it works fine.
I used my Helm email to send and receive several messages to and from a variety of other services, including Gmail, iCloud, and my own domain, and I didn’t have any trouble with messages being rejected or showing up in the spam bucket. Firing off an email to my favorite mail test site shows properly configured DKIM, SPF, and DMARC records, along with no complaints from SpamAssassin and no RBL hits.
I had no trouble creating multiple accounts and configuring those accounts to work on several devices. The native iOS mail client likes Helm just fine, as does my preferred desktop client. Everything just kinda works. The only issue I'm running into is that, while emails sent from Helm to other addresses are delivered within seconds, emails sent to Helm seem to take between 4-5 minutes to appear in the Helm inbox. I observed this delay when sending from my own server as well as from Gmail and iCloud accounts. I don't know if this is a side effect of receiving email during the IMAP import process, which is still ongoing as I write this, or if the delay has another cause (Dovecot configuration, perhaps?).
Watching the log file on my real server as I send email to Helm shows the Helm server properly receives the message and queues it for delivery within about 30 seconds:
Dec 3 09:56:38 mail postfix/smtpd: connect from c-73-32-132-234.hsd1.tx.comcast.net[18.104.22.168] Dec 3 09:56:38 mail postfix/smtpd: Anonymous TLS connection established from c-73-32-132-234.hsd1.tx.comcast.net[22.214.171.124]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits) Dec 3 09:56:38 mail postfix/smtpd: E6DBB4404A8: client=c-73-32-132-234.hsd1.tx.comcast.net[126.96.36.199], sasl_method=PLAIN, firstname.lastname@example.org Dec 3 09:56:39 mail postfix/cleanup: E6DBB4404A8: message-id= Dec 3 09:56:39 mail postfix/qmgr: E6DBB4404A8: from=, size=1125, nrcpt=1 (queue active) Dec 3 09:56:39 mail postfix/smtpd: disconnect from c-73-32-132-234.hsd1.tx.comcast.net[188.8.131.52] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8 Dec 3 09:56:41 mail postfix/smtp: E6DBB4404A8: to=, relay=helm.helmdomain21.com[184.108.40.206]:25, delay=2.9, delays=0.19/0/1.2/1.4, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 894A06C14E3) Dec 3 09:56:41 mail postfix/qmgr: E6DBB4404A8: removed
Timing issues aside, there is one truly sour note, which may or may not matter to you: there’s currently no webmail option for Helm. I don’t think anyone really likes using webmail if given the choice, but there are times when it’s inarguably a convenient alternative to have. At least for now, though, you’re stuck with needing a mail client to access your messages. (Or I guess you could do email in ultra-hard mode with nothing but curl and the command line if you’re looking for a real challenge.)
How to admin the thing
This one’s easy: you can’t log into the server, period, so you’ll do all of your admin tasks from the iOS or Android app.
The app allows you to keep tabs on your server’s heath and functionality, as well as manage user accounts and mailboxes (you can have as many accounts as you want, so the only thing stopping you from offering email to your friends and family is your own desire to not be on the hook for somebody else’s email tech support).
The app allows you to manage your DNS zone file, which will be vitally important to anyone who wants to use Helm and also do stuff with your domain’s DNS. You can view, modify, add, or delete records as needed via the app. It’s less convenient than controlling your own DNS, but it’s not a bad way to do things and at least acknowledges that DNS is important for more than just mail-related records.
One thing that you cannot do—at least not yet—is add more than one domain to the Helm server. Helm support confirmed that this functionality is planned the future, but is yet not present.
You also use the app for creating and managing additional mailbox accounts, and Helm uses a local instance of OpenLDAP for storing account information. The device supports an unlimited number of additional mailboxes. You can also use IETF RFC 2822-compliant plus-style dynamic email aliases (like email@example.com if you want to correspond with a business you think might start spamming you) for existing accounts, though unfortunately you cannot yet create true virtual email aliases. Helm support indicates that support for true Postfix virtual alias maps is coming, but not yet present.
There are a few other things in the app that matter. You can see the time of the last successful backup of all server state and email data to the cloud, and you can trigger a manual backup if needed. You can trigger additional IMAP imports from other accounts, easily add per-device passwords for configuring more email clients, and set your SpamAssassin spam threshold.
The app is generally functional, but I’m not a fan of management-by-app—I’d prefer a command line option. The app also pauses for 2-3 seconds every time you change screens; the wait is a consequence of all communications between the app and the Helm server going through the AWS-based gateway.
The app has also crashed on me a few times during the review process, but at the same time it's received several updates in the course of about 72 hours, so it’s clearly being worked on at a rapid pace.
Under the hood
Helm co-founder Giri Sreenivas penned a decently long Medium post that walks through some of the Helm service's configuration details. However, it’s worth focusing up a bit on what’s going on under the hood.
The Helm Personal Server runs a customized embedded ARM Linux build constructed via Yocto. It’s based around kernel version 4.4.65, and the mail services deployed on the box are containerized with Docker for clean service isolation and ease of upgradeability. The device uses Postfix as its main MTA, Dovecot for IMAP, and SpamAssassin for anti-spam. Other FOSS tools utilized include LetsEncrypt’s Certbot, OpenLDAP, OpenDMARC, OpenDKIM, Duplicity for encrypted backups to the cloud, strongSwan for the VPN tunnel, and the Darwin Calendar and Contacts Server.
The list of exposed ports that are forwarded from the Internet via the tunnel to the Helm server is reasonably short and curated. A quick scan with nmap shows the following TCP ports are open to the world:
TCP 25 (SMTP)
TCP 80 (HTTP, for LetsEncrypt's Certbot tool)
TCP 587 (SMTP with STARTTLS)
TCP 993 (IMAP with SSL)
TCP 3333 (mobile app access)
TCP 3334 (for bootstrapping the authentication process)
TCP 8443 (CalDAV and CardDAV)
(Port 22 also shows open, but that’s not forwarded to the local Helm server—that’s actually for Helm folks to log into the AWS gateway itself.)
Hitting the Helm server with nmap directly on its LAN interface shows that in addition to the above, TCP ports 2377 and 7946 are open to LAN traffic. Helm support claims that those two ports will be utilized by Docker Swarm if they ever decide to release some kind of Helm clustering solution. These ports are LAN-only—they are not forwarded from the AWS gateway.
There are a variety of ways to configure Postfix itself, too. Helm shared some specific settings from their Postfix main.cf file in response to my questions but asked that I not directly include those settings in the article. I can say that I am satisfied with the configuration choices that their engineers have made and that they are similar to my own Postfix configuration choices.
What is and isn’t encrypted
I’m not going to pretend to be nearly as familiar with the ins and outs of crypto as your average security researcher, and I don’t have any way to analyze or audit what’s on the Helm server. That being said, Helm gives a number of assurances that privacy and security were first in mind when they were pulling the product design together, and encryption features heavily into the mix.
Specifically: the Helm server’s NVMe local storage is locked up with 256-bit AES-XTS full-disk encryption, which is transparent in ordinary use but which should provide a significant amount of protection against someone pulling the NVMe drive out of the Helm and trying to directly access its stored data. The file system encryption keys are generated when you first set up the device and stored securely in two places: the TrustZone secure enclave on the Helm server’s ARM Cortex-A72 SoC, and the USB stick you insert into the Helm during initial setup.
You ordinarily don’t need that USB stick, but you absolutely will need it if you ever have to restore mail, or the server itself, from backup. Without the key, you’re not going to restore squat. Keep it secret, keep it safe.
It is very important to note that Helm doesn’t natively support email encryption via PGP or its equivalents. Please don’t assume that any email you send with this device is “encrypted,” because it isn’t. Helm does utilize full disk encryption (thus providing “encryption at rest”) and TLS encryption with LetsEncrypt auto-renewing certificates when sending or receiving mail (thus providing “encryption in flight” or “encryption in transit”), but the emails themselves are still plaintext. If you want to add actual email encryption to the mix, you’ll need to provide it yourself.
(And that’s probably a good thing, because adding PGP encryption at the MTA level is just kind of a gross thing to do that really violates the concept of separating your services into distinct layers. Plus, in most other cases where it’s implemented, it’s done poorly. You should properly add message encryption at the MUA level.)
Power, heat, and noise
Last things first: the device is fanless and there’s no noise. That, coupled with sharp (literally) industrial design, means this is a device you don’t have to hide in your closet—it looks perfectly respectable on a shelf, and it’s not going to drive you nuts with sound. Going fanless is a smart decision, considering that you can’t really open up the Helm to mod in a lower-noise fan without potentially breaking things.
For the time I had with the device, power usage stuck remarkably close to about 12-ish watts (and this was with a multi-gigabyte Gmail IMAP import happening for almost the whole duration of the review period). The only times I saw power spike above that corresponded to the times when the Helm server was doing its daily backups. During those hour-ish long windows, power usage would rise to about 15-ish watts.
Using the current US national average of $0.12/kWh and figuring on a worst-case of 13 watts average continuous sustained usage, that works out to 113.9 kilowatt-hours of juice used in a year, at an estimated energy cost of $13.67—so, a bit over a buck a month in power costs. Calculating real power cost is difficult because your electricity rate almost certainly varies within a single billing cycle depending on usage and whatever crazy billing practices your electricity provider has, but regardless, this is a low-power device that doesn’t add much to your overall power burden.
The device gets warm to the touch but not crazy-hot. I shot some infrared images of the Helm after it had been churning away at elevated load levels for more than 20 minutes, and while some portions of the exterior showed temperatures as high as 120F (about 49C), it never got too hot to comfortably handle. The warmest spot was the metal frame that buttresses the main plastic housing.
No disassemble, Stephanie!
I’d planned on unscrewing the cover on the Helm server and exposing its guts to the world, but unfortunately, the device is glued and snapped together in a somewhat permanent manner. There’s an empty 2.5” SATA bay hidden inside one of the thing’s eaves, presumably for storage expansion, but I didn’t have a spare 2.5” disk to shove into the thing to test with.
There’s just not much I could take apart. The flat metal foot upon which the Helm sits can be taken off by removing six screws, but other than that, there’s just no obvious place to jam a spudger or pick. I spent about 15 minutes poking and prodding at various plastic seams, and then decided I'd better ask the experts before I broke something.
“Unfortunately we don't have a disassembly procedure we can share and we ask that you keep the product intact,” Helm support told me when I asked if there was some obvious procedure I was overlooking. “There's a reason for this,” they continued. “Taking the cover off the Helm without proper care may result in tearing connectors to the antennas for Wi-Fi and Bluetooth and potentially the antennas themselves. Also, taking the cover off without proper tools may result in cosmetic damage to the cover.”
Well…fine. You win, review hardware. This time. This time.
However, the Helm folks were gracious enough to send over some pix of the device’s internals, which I’ve added below.
The Helm Personal Server has a tail that you can’t really see, but it’s one that should be obvious at this point in the review: it’s a server that lives in your home, but it depends on several portions of Amazon’s cloud service in order to continue functioning.
Starting with the basics—in the event of an AWS outage, your Helm-hosted email will stop working until the outage is over. That’s not necessarily a huge big deal for a short outage, since other email servers trying to send email to you will simply queue their messages and re-try until the outage is over.
However, the part that’s perhaps a little more important is that your Helm server can perform backups (both fulls and daily incrementals) of itself and its mail store to AWS. The backups are enabled by default, but they can be suspended or turned off entirely if desired. The advantage to auto-backups like this is that if your Helm is stolen or broken, you can drop a new one in place, restore your backup, and be up and running again.
The disadvantage, of course, is that it somewhat puts you back in the position of having to trust one of the most data-hungry of companies with your email. However, it’s not as bad as all that—as with the file system, the backup data stored in AWS is encrypted with 256-bit AES and a 2048-bit RSA keypair, and the private keys exist only on the SoC’s secure enclave and on that Helm USB stick you use during setup. As noted earlier, without the physical USB stick, your backups are useless (reminder: don’t lose it!).
I asked Helm about any other places where customer data might be exposed or at least visible on the cloud side of things, and the company’s responses were reasonably reassuring. “Customer data exists in AWS, Shopify, and Stripe,” explained Helm support. “Each of these services are restricted to only certain employees having access and all accounts require MFA. We also make sure to collect as little data as necessary about our customers.”
There’s no way for external users to audit these claims, but I’m willing—at least right now, based on the attention given the product’s design and functionality—to extend the benefit of the doubt.
But what if the company shuts its doors?
The gateway and backup Amazon dependencies raise one big question: if you spend your $500 on a Helm server and move all your stuff into it, and then Helm goes out of business, are you stuck with a worthless pointy plastic box that you can’t repurpose?
Once again, Helm support provided what I would consider to be the only acceptable answer: “If we cease operations, we will open source what’s required for customers to spin up their own service in an AWS account so the server continues to work. Similarly, the dockerized services will be open sourced next year so they can continue to stay current with security patches.”
And if the company remains perfectly fine, but you decide to switch your email hosting to somewhere else? Fortunately, migrating off the Helm service is about as pain-free as migrating onto it: "We will never lock users out of access to their data," was the company's response. "An IMAP import that all major email service providers offer will work with Helm. An alternative is to perform the clone using an IMAP client on a desktop or laptop."
So…couldn’t I just do all of this myself?
Let’s be crystal clear here: if you want to roll your own version of Helm that looks and acts more or less the exact same way, you totally can. If you’re willing to put in the time and the work, you can use the Helm stack as a blueprint for building your own personal self-hosted email service with an AWS gateway. You can build the same level—or more!—of redundancy, the same encrypted backup scheme, and even the same end-user experience if you want to code up a handy-dandy app. Or, you could forego the app and admin everything from the command line, old-skool styles.
However, the value proposition for self-hosting with this type of device or service is that you can trade time for money. Helm’s specific value proposition—at least for the kinds of people who are reading an Ars review!—is that you can make that trade with a lot more comfort about the underlying technology choices and configuration decisions than you might get elsewhere.
Should you buy it?
There’s a whole continuum of potential decision points here, and it’s impossible to issue a single “yes” or “no” verdict. Whether or not Helm works for you will depend quite a bit on who you are and what you want to do.
If you’re just a regular person who doesn’t know or care much about email, it’s hard to justify the spend, both up-front ($499 for the device, plus potentially another $10-$50 or more for a domain) and recurring ($99/year, plus again the cost of renewing your domain). The privacy and control are nice to have, but that’s very difficult to assign a value to for the average user.
If you’re the typical Ars reader who stays reasonably current with the ever-evolving privacy landscape, Helm is something to consider. The cost is pretty good for what you get, and it’s only slightly more work than using any other dedicated email host. If you’re looking to break your email out of Google or Microsoft jail (or, worse, from your local ISP, with their ability to read your email directly from their servers' disks), this is the way I’d recommend doing it.
If you’re an angry graybeard sysadmin who hates GUIs, you’ve likely already made up your mind, but I’ll weigh in anyway: the convenience and security are great, but you’ll almost certainly be frustrated with the lack of advanced options. It’ll be even more frustrating knowing that all the crunchy Postfix goodness is there under the hood—you just can’t touch it. It’s also more than a little troubling to have a device on your LAN that you can’t log into and audit yourself, but you can at least shove the Helm device onto its own private isolated VLAN if it helps you sleep a little better at night. (This is what I did, because I’m right there with you.)
I can tell you that I will probably buy one, once Helm addresses my two major sticking points: I want to be able to create true email aliases (that is, a real address aliased to an existing account, not just a Gmail-style dynamic “plus” aliases), and I don’t want to give over control of my DNS zone file. Both things are possible—Helm is looking at adding the former feature and there are workarounds for the latter, so I’m growing in certainty that at some point in the next few months I’ll be plopping down my $500 and donning my Helm.
A genuine, workable solution for hosting on-premises email
Plenty here for newbies and experts both to love
Setup is easy, profile installation is well done
Thoughtful design with an eye toward security
Does pretty much everything it's possible to do to give you high deliverability and a good sender reputation right out of the box
Easily usable even by someone on a residential ISP connection with a dynamic IP address
Uses encryption smartly, at the correct places in the stack
The highest praise I can give: I've been self-hosting for years, and I like this thing and I'll probably buy one
No local administration option and no ssh access—app only
Can't create true aliases with the existing toolset (yet)
No webmail support (yet)
Can't host multiple domains (yet)
Base functionality depends on cloud services—no AWS means no email
Doesn't offer DNSSEC (though that's properly a limitation of AWS Route 53)
IMAP only—no POP3, if you happen to need POP3
Importing mail is done by IMAP over the Internet—no option to directly bulk import an MBOX file or other mail archive
Security-focused marketing glosses over the reality that sending email to Gmail, Yahoo, or another big provider still makes you part of the data collection machine
As much as I like the device, I think Helm has an uphill battle ahead of them trying to market and position a $499 single-purpose "email appliance" for the masses in a way that will actually interest the masses.
If you don’t mind the up-front and recurring costs and the minor admin limitations, the Helm Personal Server is probably the best choice for self-hosting email. There are a few things stopping me from using it for my own domain’s email hosting—mainly the lack of true alias creation and the fact that at least for now you have to let Helm control your domain’s DNS zone file—but those are not insurmountable problems.
Helm as a company so far appears responsive, interested in constructive suggestions for improvement, and committed to security and customer safety. If you’re looking to kick Google or Microsoft to the curb and claw back control of your email, this is in my opinion the best and easiest way to do it.
As a quick postscript, I want to take a moment and thank the Helm support team for putting up with my long lists of technical questions while writing this review—it’s unusual to find a company willing to respond in-depth and with transparency to questions about their fundamental security architecture. Helm rightfully deserves props for fast, clear answers to a big stack of very nosy questions.