1. How do they ensure high, non-spam delivery rates to the main email services like Gmail, Fastmail, Yahoo, and Microsoft?
2. How would the product work in case Helm the company/service goes away (or even just service outage)? Can the device work on its own without the need for their web service (perhaps with lower delivery rate/higher spam score)?
>> We’ve designed your Helm to ensure as little information about you as possible is communicated back to us. That’s why the only account you create is directly with your server, not with us, and why only encrypted data passes through our servers.
But how does that work with sending emails? (Please excuse my ignorance on this matter.)
1 - First, we cross reference IP addresses we assign to gateway against known blacklists. This helps ensure emails will be delivered. We also fully support email authentication (DMARC, DKIM, SPF) and configure reverse DNS as well. Lastly, the IP address for a gateway stays fixed so the domain and IP will build reputation over time. Helm servers require the service to work to get around the residential internet connection challenges in the US (port blocking, dynamic IPs, untrusted IPs)
2 - We will be doing 2 things - first, we will publish as open source what is required for people to be able to run their own gateways with their own AWS account in the event Helm has to shut down. Second, the unit economics on the service are positive so as long as we have customers, my co-founder and I are dedicated to running the service. We take a page from Garry Tan and Posthaven in this regard.
3 - The way this works for sending emails, your devices that you compose emails on will connect directly with your Helm server over TLS. Your Helm server will then initiate a TLS session with the server hosting your recipient's email. So we as a company have no visibility to any of that data - at rest, or in transit. I hope this helps - I'm happy to explain this in more detail as needed.
If my helm server connects directly with the recipient's email server won't it create problems with SPF validation? Home networks usually don't have a fixed IP address so I am not sure how SPF will work.
I'm not sure how Helm doesn't see the metadata:
* For outbound (as described) and inbound mail, do all mail servers support TLS connections? I was under them impression that many still communicate unencrypted.
* How does Helm avoid seeing the metadata, who is communicating with whom and when?
It seems that Helm has no obligation or business need to log any metadata if they are providing each customer with a dedicated relay. Any abuse will come from that relay IP and can trivially be attributed to the correct customer.
The point of Helm is to provide privacy (and end-user control) through technical means, if I understand correctly. If it's just a matter of trusting motives, I don't need a home server.
The feds know that Apple (for example) are fully lawyered up, and that they need all their legally required paperwork with it's "i"s dotted and "t"s crossed before Apple will even look at their request for your data. While we know they _will_ hand over legally required data when they can and the paperwork is OKed by their legal department, they also very publicly go head to head with law enforcement when those requests are legally questionable or technically impossible.
I suspect an overly broad probable cause warrant to seize all the electronic devices in your house is gonna be much easier to slip past an leo friendly judge and whatever legal representation you can muster up when they dawn-raid you - than "slipping one past" Apple's legal team.
Having said that, if you've got the feds interested in your digital comms, you probably want to be getting your security advice from a much more private and trustworthy source than randoms on Hackernews...
Not necessarily: https://en.m.wikipedia.org/wiki/Sneak_and_peek_warrant
additionally, email is more usefully between 2+ parties. For normal people, the other parties are very likely to be using a cloud email provider. I would not be surprised to learn that it is common to issue a warrant not for a specific recipient, but for anyone that has corresponded with a specific person, ie for the sender instead of the receiver -> google, give me all emails sent by user@foo to any user on your server.
this is actually a big problem of SMTP and a big weakness of helm. i didn't study the product but it seems that it would be difficult for a user to know (and prove) that another user is a helm'er. if data seizure is the issue you care about, protonmail and other such services are a better solution.
Major providers like Gmail and ICloud will have a longer and more convoluted process to provide your data to state actors, but analysing that data is going to be far easier since it will come in a standard format.
If your goal is to make your data difficult to seize, a better option is probably to self-host on either a cheap VPS or a corporate-grade cloud service. That keeps the data out of reach of a warrant on your home, and keeps it unreadable after they've actually jumped through the hoops to seize it from your provider.
* Name, address, payment information, domain, DNS records
* Device diagnostics (such as temperature), software versions, enabled services, connection status, connection type, serial number
* Anything related to customer support, including information customers provide
So plenty of information to uniquely identify a system. The last bullet is a little concerning as it seems to be a catch-all.
Please see my other questions here. https://news.ycombinator.com/item?id=18243685
So, what's the subscription for?
A) I can connect directly, no biggie.
B) I am assuming that you would require a port opened/forwarded in the firewall to work in this case. Is this correct?
Can you? you'll probably need your own DNS resolver because if the clients are configured for my.custom.domain.com, it's not going to resolve to 10.10.10.10 and your connection is down. So you can have the box do that, but generally, split horizon DNS is a thing you don't want to set up in a set it and forget it install.
Another big one for me is the failure modes. What do I do when my home connection is down? How about when my connection is down and I'm traveling? What happens when the hardware fails? How about when the hardware fails 5 years from now?
Having email just down for a couple days while you wait for new hardware to would be a very bad experience.
The way most of these providers deal with spam is they slowly white-list IP addresses. When a company like Mailchip or Mailgun spin up a new server, it's always in a large subnet range they've purchased and they slowly start sending low priority e-mail through it to existing/known receivers and throttle it up to full speed.
If you're running a personal server that sends like 5 or 6 e-mails a days, well that's an issue.
The big players make it difficult to run a small personal server, but running a dedicated business or corporate server that sends 100s of e-mails per day is typically fine once it's well established.
You know what would be a better product? A relay SMTP server that works with Google/Microsoft/Amazon/Fastmail et. al. to pump e-mail from personal servers and ensures it won't get caught in spam filters.
That's basically Sendgrid or Mailgun or even Fastmail itself. They can all relay SMTP for arbitrary domains.
Such a product would need to have a ToS that states it can only be used for low volume personal and business correspondence, and have per-account rate limiting to enforce that. Doing it this way is necessary to avoid having mail treated as bulk.
I've tried relaying through mailgun to get mail to outlook.com, it does not work.
Jk, I just thought it was funny that we pay for services which were always seen as a free alternative to paper mail and stamps were a thing of the past.
On top of that, the costs of electricity are not the same everywhere (they are very expensive in The Netherlands, for example, than in the USA, and China is very cheap). Nor is it widely stable available everywhere (examples include India and Africa). Proof of Work is basically a waste of energy as well.
Maybe it's just been so long I'm whitelisted?
how so? the way i see it, only by making it too easy to use them. if you mean, they reject mail from (eg) dynamically assigned home subscriber IP addresses, you can blame spammers for that, not the big email players.
There's little to no additional security from having email on-site, and much hassle. Assuming you use google or outlook, the advertising bogeyman is just that - a bogeyman.
this is a super niche product, with a lot of useless industro-consumer design thrown in. it's doomed as a business and then where are you? back to gmail.
> While offline, emails sent to you will not be delivered. This does not, however, mean that they are lost. If your email server becomes unreachable for any reason, the sender’s email server will periodically retry sending the email at a later time. Email servers are generally configured to retry rapidly at first and then back off and increase the time between retries.
> Once your email server comes back online and a retry is performed, you will successfully receive the sent email. If your email server is offline for an extended period of time, the sending server will eventually give up and send a bounce message to the person who sent you the email.
This is the big obstacle preventing me (and I assume others) from moving away from cloud. Cloud services just work, everywhere, all the time (effectively). I'd love to get the privacy benefits of bringing my data "in-house" but I'm not sure I want to take on the equivalent of a part-time sysadmin job.
 Unless you have warm spares for everything, but that means you're paying twice as much and still will have a non-urgent fire drill to replace the failed hardware so you're back to n+1.
Perhaps relay the email out via your ISP account? I do that and it works well.
> Having email just down for a couple days while you wait for new hardware to would be a very bad experience.
Perhaps set up a fallback MX that directs traffic to e.g. a Mailfence account when your primary MX is down? Works for me. Also, mail servers can be cheap hardware (an old x220 will do).
I run mail servers. I believe the idea that mail delivery is a problem for small mail providers is largely a myth. If you act somewhat reasonable (that is: if someone complains to you don't ignore it, don't send spam, check your logs for indications someone might put you on a blocklist) it's no big problem.
I think the myth comes largely from people who are actually spammers, but don't see themselves as that.
Some ISPs allow you to pay for a proper static IP to get around this problem, but again some of the ranges are still in the block lists. The only way I could guarantee that my IP wasn't blacklisted was to switch to a business account with my ISP and thus have IPs from a different range.
If you are stuck on a non-static IP, the easiest way around the problem is to send via the SMTP smarthost that your ISP hosts.
 They are technically dynamic IPs, but are sticky in that you keep the same IP unless your router goes offline for more than a couple of hours.
And more recently, I'm still unable to send email to Verizon.net email addresses from a VPS because they too insist it's in a residential IP block. (it's not.)
For the first few weeks I had a VPS and moved a small business to it, sending anything to Gmail was a hassle as it was all automatically going to the spam folder. The typical responses from others was "find a new provider" even though checking blacklists showed the one I chose was just fine.
I too have run mail servers, and have seen enough to realize that it's definitely not a myth. It's just that there are enough spammers making a mess of things for the rest of us, which is unfortunate.
We end up on Hotmail/Outlook's blocklist about once a year. They remove it within 1-2 hours after opening a ticket.
(On the other side of that problem though, if my email account starts sending mail "what looks like spam", it's almost certainly because my account's been compromised and is actually sending spam. There's a _start_ difference between typical personal person-to-person email and spam. I suspect _some_ business email might blur the line there - but part of me thinks if your business email is blurring the line about being "spammy", then it deserves to get filtered...)
I suspect whatever this Helm thing is, they manage to do things right on that front as well; everything else I don't know.
Open up the hardware component as a platform for anyone to extend (allowing direct ssh, or using my own hardware). It's fine to not open source the email server code. But I would like to utilize the hardware to do other things, like file storage, etc. Instead of waiting for your company to build other features, I would rather have community contributed (preferably open source) plugins that integrates with your ecosystem and runs on the hardware.
When the iPhone came out, it didn't support apps - just built-in features like Mail and Mobile Safari. I agree with you that an app store for Helm could be valuable.
I know Nylas tries to do this, but their model doesn't really work for me.
Also, it is not clear how it works without a static IP from my ISP.
> use or run dedicated, stand-alone equipment or servers from the Premises that provide network content or any other services to anyone outside of your Premises local area network (“Premises LAN”), also commonly referred to as public services or servers. Examples of prohibited equipment and servers include, but are not limited to, email, web hosting, file sharing, and proxy services and servers
> You also may not exceed the bandwidth usage limitations that Verizon may establish from time to time for the Service, or use the Service to host any type of server.
> using such account for the purpose of operating a server of any type;
To build a plug and play solution, we knew that our server could not require listening for inbound connections on a residential internet connection. So we set about looking into how we could route traffic to and from a home server but we needed to do this in a way that prevented us from being able to spy on traffic. We investigated solutions like sshuttle and eventually settled on the combination of a simple iptables configuration combined with a VPN connection. Helm establishes an outbound VPN connection to a dedicated EC2 instance with an iptables configuration that routes packets to and from the connected Helm server. The EC2 instance also has a static IP address associated with it.
It's important to stop here and explain that the only way this architecture is viable while adhering to our design tenet of knowing as little about our customers as possible is because of the Let's Encrypt project. Every Helm server has a unique domain associated with it and trusted certificates for that domain are fetched from Let's Encrypt. We strive to ensure that all inbound and outbound traffic routed through the EC2 instance is using TLS with these certificates from Let's Encrypt. This way, our EC2 instance is effectively just an extra hop on the Internet.
I hope that answers your question, let me know!
I am glad you are doing this because running a mail server is non trivial. I have done it for a long time now and love the fact that I own my email identity. It is one of the few things left you can own online.
A hard problem, and I don't envy anyone trying to solve it.
Secondly, I think you underestimate the time intensive work that goes into clearing up an IP. I've run mail servers with users in the thousands. It's basically a full time job to keep a single ip clean. And that's with a half or less percentage of clueless users. I'm unsure how this will scale to hundreds of IPs let alone the thousands(x100) that would probably be needed to make creating your own hardware profitable.
Third, you're going to need to reach incompetent customers to make this profitable.
EDIT: Just realized I responded to the wrong person :(
Or, maybe I just misunderstand smtp idk
Thanks for the question and your support!
I understand that it's just an encrypted VPN connection, and are not actually storing email on the EC2 instances. But is there any way for your customers to ensure that? Can your customers shell into the Helm and/or EC2 instance(s)?
I'd suggest allowing customers who're concerned to run their own instances with your code on it (perhaps a Docker image?) - but giving random customers shell access to gateways you're responsible for (at least to Amazon) - would be insane...
Signal/WhisperSystems are doing some interesting work on how to prove the code running on their servers is identical to their published and auditable code - might be worth checking that out (for a post MVP roadmap idea).
Then you create an infrastructure for relaying the mail from your boxes to the Internet. Then you work with the various spam agencies to create both a way to respond to spam complaints and to detect and throttle or cut off spam senders. You'll find that spammers will offer to pay you a premium to "look the other way" but don't take it, many good companies died going down that road. Without the spammers it will be harder to make your numbers but concentrate on keeping your efficiency high and ultimately you will be better off.
You don't talk a lot about data protection on site for things like disk failure. What do you do in that regard to keep people from losing all of their mail if the disk goes tits up?
Isn't throttling outbound email count/day from the start the only real solution?
People have lives which can sometimes look spammy, like you are made the coordinator of the school potluck and suddenly you're sending email to 150 parents asking them to volunteer to bring food. But after that event you go back to your regular rate.
Because this isn't a "PC" in the sense that it is more difficult to be overtaken by a virus and start sending spam without your knowledge, and as a mail service provider you know that email originating from the device has to come from a specific domain, you have a lot more tools to detect that someone is being a bad actor or not.
> To build a plug and play solution, we knew that our server could not require listening for inbound connections on a residential internet connection. So we set about looking into how we could route traffic to and from a home server but we needed to do this in a way that prevented us from being able to spy on traffic. We investigated solutions like sshuttle and eventually settled on the combination of a simple iptables configuration combined with a VPN connection. Helm establishes an outbound VPN connection to a dedicated EC2 instance with an iptables configuration that routes packets to and from the connected Helm server. The EC2 instance also has a static IP address associated with it.
> It's important to stop here and explain that the only way this architecture is viable while adhering to our design tenet of knowing as little about our customers as possible is because of the Let's Encrypt project. Every Helm server has a unique domain associated with it and trusted certificates for that domain are fetched from Let's Encrypt. We strive to ensure that all inbound and outbound traffic routed through the EC2 instance is using TLS with these certificates from Let's Encrypt. This way, our EC2 instance is effectively just an extra hop on the Internet.
> I hope that answers your question, let me know!
This doesn't seme to address the question of whether this violates the ToS, regardless of whether this is technically feasible.
(Note: I've been doing a similar home-rolled version of this, where I have a mail server under my couch that opens a reverse ssh tunnel and forwards port 25 and 465 from whichever transient EC2/Azure/DigitalOcean/Hertzner/CloudAtCost VPS Ive got listed as my MX records. A little bit of Route53 API automation, some Ansible to set up the ssh tunnelling, and some "canary" gmail and live.com email addresses to check outbound deliverability when I go to switch VPSs... It's been running pretty much untouched since 2014 or so...)
It can be argued that using a browser or any other client violates that language by sending responses to requests.
The ISP won’t do squat if it’s encrypted; they have no idea who is being connected to and what’s being sent.
A TOS is as broad and vague as they can make it. A good lawyer could undermine such language if it went to court.
Still wouldn't solve "how do I know my emails won't end up in spam" but at least we're getting closer (to at least what I would want to pay for.)
The 2015 Order said this, "A person engaged in the provision of broadband Internet access service, insofar as such person is so engaged, shall not block lawful content, applications, services, or nonharmful devices, subject to reasonable network management."
I would argue that banning personal email servers or personal servers at all is not reasonable network management (e.g. a nest thermometer or a smart microwave or an Alexa/Siri thing is a server), and if we're looking to explore home appliances that decentralize the web, we need to ensure that broadband providers' policies don't block them. Google Fiber screwed this up too.
Honest question: What stops a malicious employee on your end sshing to this server and dumping plaintext messages from memory? What stops a court from ordering you to do that?
Even if you disable remote access, what stops someone from adding a new LaunchConfiguation that enables it silently on the next instance rotation in spite of whatever configuration is in place today?
At the end of the day it seems like you -can- spy on the traffic just as easily as you could if you were running the smtp services on an ec2 instance directly.
Given that, what is the value proposition here?
(Or if I am totally wrong, by all means call me out accordingly)
A lot of mail servers don't support this though, so it would be on the client to also be able to ensure it will not relay mail except to TLS endpoints verified by a well known CA.
In my experience this is rarely the case, but if it is and Helm is willing to tell end users "sorry I can't safely send mail to this endpoint" then I could see some value to this approach.
You could still record every incoming and outgoing email as it goes through your server, couldn't you?
I really don't see the advantage of Helm.
Further, "the provider could intercept email" and "the provider stores all email" are very very different.
Overwhelmingly at 0% in most regions which they say are:
> domains in terms of volume of email to and from Gmail, in alphabetical order
Something doesn't add up there.
I've seen amazon ec2 ips being used for ddos attacks and I blacklist the entire range for many of my websites/projects. The vast majority of visitors we get from there are abusive.
edit: I guess I should be clear that I have an elastic IP (which is free) and setup reverse DNS and DKIM and SPF, but I think those are fairly standard now a days (I don't know honestly I've only run an email server for a few months).
Why? The SPAM Scoring Industry is a kind of monoculture that will impede or cancel delivery of messages. Most big email providers outsource SPAM scoring to a third party like Symantec or Brightworks. And when your email is found offensive by Brightworks with one of their clients, you’re banned on all of their clients. Part of how SPAM scorers gather intel us by hooking into the CFL system so they get a notification when a user hits the junk button to delete an email. Another way is by checking for mass duplication in your emails. Another way is tracking open rates via the email provider’s UI sending metrics to the scorer’s APIs.
And then there’s the CIDR block lists they coordinate and distribute as a courtesy for their customers. So you might be able to deliver to @gmail.com and then @yahoo.com won’t even take a connection from your server’s IP.
Why does all this happen? According to my friend who works for a midrange ISP on their email service, they have about 120PB to store real email. And the amount of SPAM they reject outright (never reaches any box, not even the junk box) is 93% of all their email traffic. They simply can’t afford to store all the SPAM.
GMail is more reasonable with perhaps being spam filtered but never blocked outright. I have also been blocked by government labs and academic institutions. I also have complied with RDNS, DKIM, SPF and got a top score on mx toolbox. Now that I have been up for a while I have had less issues besides with the ones that block cloud provider spaces.
Some things that should be delivered are not. I'd have to dig back into this to see what the exact issue is.
Free when in use, you pay for it when it is not in use.
However, there are a few things to do, more specifically, you must contact AWS to get "clean" IP ranges (fresh IPs, never allocated to instances), sign some agreements and pay additional fees.
It's not exactly as simple as an API call to create an ec2 instance, but it's doable.
With random IPs, there is a good chance indeed that it is already burnt by a previous allocation.
Amazon EC2 throttles traffic on port 25 of all EC2 instances by default, but you can request that this throttle be removed: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-p...
Doubt that AWS would allow anyone to send on behalf of 3 parties like Helm appears to do though.
Do you have a plan to help make email security features easy to consume: SPF, DMARC, MTA-STS etc.?
Is there a way to opt out on the information that is collected?
I looked on your site but it does not show a logical architecture which might be useful for some of us.
We automatically configure SPF, DKIM and DMARC for our customers. We are also investigating MTA-STS.
Device diagnostics are opt-in by default so they are not collected. Customer data like shipping and billing information is not opt-out unfortunately as we need to be able to process payments, ship the unit and track warranty coverage.
Appreciate the feedback on wanting more architectural details. This will be coming in a series of technical posts explaining how we designed and built the product. Stay tuned and thanks for your questions!
SMTP is more problematic because of spam: outbound traffic on port 25 is blocked, so a true home mail server won't work without a reachable gateway mail server somewhere else. That's basically what the linked product is: they manage the protocol side of the service on your behalf, and forward all the content to your local device which connects to them via some internal protocol.
They’re still clueless. I tried to explain that it’s being blocked by AT&T and not my router but eventually I just gave up. Their process involves a logmein session where they take control and mess with your router. Gahd it’s awful.
They also randomly added my “device” (home server) to the DMZ so all of its ports were exposed. Be very careful.
NTP was part of a massive DRDoS not too long ago. It's possible they pruned it somewhere much further up the network under the (not insane) assumption that most customers don't need to run their own time servers that answer public queries.
Considering how easily it is to setup authenticated SMTP and how effective it is at reducng spam for the ISP, I'm Surprised it took AT&T this long.
I use a VPS as a proxy. SSH with AutoSSH. I use a VPS ($15/yr), map the ports from the VPS to the server at home.
For example, when you hit 80/443 on the VPS, it's routed to a reverse proxy in the apartment, then to the correct service.
Not a bad setup.
When it comes to consumer internet services, the US is a 3rd world country, which is kinda odd considering most of the western world does their business there.
I just checked the terms on my 300/300 fiber connection, as well as my (backup, company paid) 25/5 ADSL.
They're almost identical:
* no spamming.
* no racism/unethical behavior.
* no portscanning.
* no illegal downloads/uploads.
Besides that i can use it for whatever i like. They block port 25 though, and you can only get it opened by purchasing a commercial connection. It has a dynamic IP address that only changes when i reboot my modem, which happens once every 2 years or so, so practically static IP :)
The ADSL has all ports open and a staic IP.
Generally they don’t care if it’s for personal use. I’ve heard of them shutting people down for something they saw as business related. They didn’t really get shut down, it was more like a friendly “We see what you’re doing and a business plan would allow you to do it for $30 more a month”.
That seems to have potential for abuse.
I guess the terms of service allows them to shut someone down if they felt like it, but I wouldn't really worry about it. If you have a site that generates so much traffic they even took notice, I presume you'd want to be on a real hosted environment anyway.
Germany's third biggest city, I can only get 50/10 Mbit, maybe 100/20 - no fiber in sight. No static IP and no guarantees anyone will accept mail from this dialup subnet.
From my experience, at least in Munich it's hit or miss which of the 2 cable company services your building - it's not even on the street level.
Also I'm not really complaining. Say what you will about Deutsche Telekom, but I've been a happy customer since 1998. Everytime I had a different ISP (mainly M-Net) I had more problems than uptime. This is more expensive, but I'm having less than one noticeable downtime every 2 years...
If you are in a major city, it might be time to check the other ISP in town. I'm glad I did.
Static IP might cost extra.
I pay AT&T $80 a month for symmetrical 1Gb FTTP with no data cap.
They don't explicitly disallow it in their TOS, they just make it impossible by disabling the underlying tech.
> no racism/unethical behavior. * no portscanning. * no illegal downloads/uploads
"unethical" behavior is the most arbitrary, un-objective clause one can ever have. Your ISP may find your hosting an email server "unethical", and this clause allows them to ban you.
Europe is NOT superior in any way
They also specifically disallow distribution/downloading of child pornography and leaks like "fappening", which i translated to "illegal downloads/uploads".
The list of things that are disallowed is very specifically worded in Danish, as legalese usually is. Furthermore it is also customary in Denmark to allow all traffic. in or outbound.
All "metadata" is logged for 5 years, mandated by law, so every IP i connect to is there along with port, duration, protocol (if available).
> provide network content or any other services to anyone outside of your Premises local area network
I'm not sure if Verizon has the same intention, but if they take their own wording exceptionally strict, you would be in the wrong whenever you play a multiplayer game and end up being the host.
Generally in my own experience they don't want you hosting a service opened to the general public running all the time. I think running an open mail relay would get you banned very quick. It seems like this product is intended to be used purely for yourself.
Now the terms still would give them an out if they decided they didn’t want you, but honestly as long as you’re not hurting the network they’d rather take your money.
>• with respect to dial-up accounts, using any software or device designed to defeat system time-out limits or to allow Customer's account to stay logged on while Customer is not actively using the IP Services or using such account for the purpose of operating a server of any type;
I have many servers on att internet, including email.
And yes, the no servers clause is an issue, it was raised initially by people doing peer to peer torrenting, and some folks running servers.
Enforcement is a bit tricky though because folks like Comcast and Verizon get so much value from being able to see all of your Internet traffic that they won't actually cut you off for running a local server but they will be passive aggressive about it. For example, they will start changing your IP every couple of hours (they set the DHCP lease time to be low and force the DHCP server to always give you a different IP).
The common solution is a VPN tunnel which is what Helm is doing, but that tunnel has to end up somewhere so that can be a problem if that 'somewhere' is commonly used by bad actors. (Like say in Ukrainian data centers)
I expect that this restriction will go the way of paid SMS messages eventually but for now it is going to be troublesome.
Also IANAL but "services to anyone outside" does not sound like it includes un-firewalled, password-protected, services for personal use. The word used is "anyone outside" not "any machine outside". The resident themself would presumably be an insider regardless of their physical or network location.
Also I think a reverse proxy with end-to-end encryption could solve the problem with no public-facing open ports. That doesn't count as a server in my book.
(Combined with fiber, it's ideal for a small home server.)
I don't think there is a good enough definition of "server" or "serving" for such restrictions to be enforceable except is an arbitrary way.
I have an MUA that retrieves email from a server and sends email to a server. It might run in a browser and interact with GMail. It might be a mobile app or Thunderbird or Outlook. It might be sendmail or postfix or Exchange. Which of these are "servers"? Which are banned and which are ok?
> with respect to dial-up accounts, using any software or device designed to defeat system time-out limits or to allow Customer's account to stay logged on while Customer is not actively using the IP Services or using such account for the purpose of operating a server of any type;
AFAIK, AT&T does not prohibit running a server on broadband accounts.
What's being done by Helm is not much different than using Back to my Mac or Plex or SlingTV.
In any case, these ToS are over-broad and most customers probably violate them every day, especially the copyright provisions. The ToS are not enforced to the letter but allow the ISP to terminate an account if the violations are egregious. I don't think running a Helm server would get you booted.
This serves to protect them technically (residential systems are not designed to withstand a large number of inbound requests), legally (you can't sue them for failing to serve your site) and of course to promote their more expensive business lines.
If you're going to tin your own mail server, it's paying for a good VPS. Beside the guaranteed static IP, being on an IP block with a good reputation, good VPS provider have redundant power sources and console access over the web, which you are unlikely to have either from home.
"Helm connects securely to a unique gateway, which is assigned a static IP address so Helm is reachable by other mail servers and secure TLS sessions can be established."
Which I dont see the point of then. That way they are your gatekeeper of your mail/files etc. Not much of an improvement.
I wonder what happens if nextcloud does a full sync to a new device.
As far as what happens with a full sync: it's not really doable outside of the LAN for several reasons. One is I have a data cap from Comcast of 1 TB/month. Another is the upload speed is only 10 Mbps. That's actually one of the reasons I went to self hosting.
Lawyers, really? Why wouldn't they just cancel your account?
- You run the risk of hardware failure, which would take days to recover. When your warranty expires, it'd cost you, too.
- Disk failure may lose all your data.
- Fire, theft, or hurricanes may destroy it.
- You still give access to your data to a company, which controls software updates and the EC2 proxy (in this case).
- Many home ISPs have shitty upload connectivity, so your email won't work that well on the go.
- Internet and power outages mean you won't send or receive any email.
- You lose the knowledge email providers get from scale, including ever-evolving spam filters, and a guaranteed clean outgoing IP.
If you really want to control your data, just spin up something like ownCloud (not sure if that's the best solution, just an example). Companies like DigitalOcean make it as simple as point and click.
Helm actually solves this exactly - they already have continuity of service coming in the pipeline, and the product as-it-ships will support encrypted backup/restore out of box, similar to how your iPhone supports iCloud backup.
I've run my own mail servers for Posterous before and it was probably 2 to 10 hours a month of maintenance, software updates, etc. And that's not something normals can do.
The company itself is run by folks who are committed to running this as a sustainable long term business that takes are of its customers and is super responsive to the community. As a board member I promise you we'll do that.
I looked for the founders bio, a company contact info. There is nothing on their site. All I saw was a letter in the "About" section by the founder.
You might have gotten to know these guys after various meetings and due diligence process. There is nothing on their website that sells me on trusting them or the company.
I had to go the "Careers" section to see the location of the company.
When you're in the business of selling trust, you really need to focus on selling trust first and not technology (maybe they're connected ultimately) but I just don't feel I can trust this company based on the materials provided on their website.
Hope this feedback is meaningful.
What's the base operating system and hardware architecture the box is based on? It says "Linux" on the page but doesn't go into specifics.
Why not just use regular hardware, e.g. Intel NUCs, or even allow people to run your software on their own hardware (like OwnCloud does)?
In Germany there was/is a startup, Protonet (https://protonet.com/), that had almost the exact same idea a while ago. They went bankrupt though and one of the reasons was that it cost a ton of money to design and produce their own hardware, which also looked very cool (orange hexagon!) but didn't provide much added value beyond what a normal, boring-looking compact PC could provide (at 500 € less than their box for the same specs). They also marketed their own OS, which was based on a modified Linux distribution, modified open-source software and a shiny management layer on top as well. They found out that developing and maintaining a Linux fork isn't so easy either, so they eventually canned it. So what's different about Helm in your opinion?
We are using an ARM-based SoC from NXP. We chose this to ensure that the device can only run signed, trusted code by implementing secure boot and signature verification of software updates. We will make a developer program available in the future.
I didn't use Protonet so I shouldn't speculate about what's similar or different about the products. I think we are in a time right now where people have a strong desire to own their data and are looking for a viable alternative to the cloud. They key, beyond building something very private and secure, is in nailing the experience and we're excited to share more about that.
Okay, so that narrows it down to the i.MX family.
We chose this to ensure that the device can only run signed, trusted code by implementing secure boot and signature verification of software updates.
Maybe read this?
Hopefully the HAB fix is the reason for the 8. Otherwise this seems like overkill for the work involved.
But if I don't actually need to be able to reach the box in order to use my email - if it will work even when the box is offline, powered-down, stolen, or destroyed - then what, exactly, is the point of the $500 box itself?
It's not privacy, it seems. If it were private, how could it work when the box is offline?
I'm not opposed to a "pay for your email instead of it being ad-and-surveillance-supported" model. I just don't see the point of paying $500 for a box that you're telling me the service will function just fine without.
Down? There's continuity of service if you have a 2nd box online, and it's as easy to restore from a live backup as an iPhone from iCloud.
Email is the first app, and there will be more.
For $1000 I get 2 boxes I can't use for anything else right now (and still not very reliable inside my home), whereas with Fastmail (for example) I can get an email service for 20 years @ $50/yr that is very reliable. I'm not sure of the value proposition for this thing.
I think it is a great idea to have a device which is as simple to use as a router but focused on typical cloud services. As security is a critical aspect of the whole idea, the subscription service is a smart move too. Maybe you should offer a monthly subscription too (consumer friendly).
Are there any plans to start shipping to Europe in the near future?
This is the key question, in my mind. There's only one reason I'd want to own the hardware—to manage/add/create my own services and handle my own backups because I don't trust a company's involvement in these.
If this is so tightly controlled that I can't add my own services and I can't restore a backup without Helm's involvement, why do I even want the hardware?
 I don't mean that I don't trust them in a privacy sense. I mean that I don't trust them to make sure the backups are actually working and able to be decrypted and restored. Or be able to be restored without their software/hardware. There doesn't seem to be any transparency wrt/ these concerns.
How do you know who to trust? You surely have to trust someone. It feels generally true that we can trust Apple since we pay them for hardware and their ongoing business interest is in protecting their revenue streams through their hardware and iOS app store, which means you are aligned.
Generally for Helm that's a good case. That's why we charge money for this hardware and software: it aligns interest.
Free cloud services are not truly free and that's what most people seem to be OK with... but not all people.
This is the classic trade-off. Open source software you can read the code but usability suffers. For the people on HN, most people can run their own servers, but for normal people that's not an option.
Apple has managed to create a computing environment that is highly usable for normal people. This is what Helm is trying to do too.
I still don't understand why this is a hardware play. There are advantages to owning the hardware but none of those advantages seem to apply here.
The hardware feels like a bit of an albatross.
In my experience, the average person doesn’t really understand what GMail or Facebook or whoever do with data or the extent of their knowledge about individuals. Even basic things like lookalike audiences or retargeting across the web regularly blow people’s minds.
I hope this project is successful, partly because that would show that people do understand these things enough to view Helm as solving an urgent need. I wonder if we’re there yet.
I definitely look forward to these posts!
Hosted services like protonmail (great option) support some key management but that's rare. Most everyone stores all your data in the clear, and that sets you up for Facebook-style hacks where people just steal a database en masse, and/or leave you open to warrantless wiretap which has been a problem for email services broadly in the past.
I want to point out that email is just the first part of what Helm wants to do. What is super valuable is that Helm can run its own software and add things like distributed anonymized VPN, or file sharing, and these things are all federated in a way that wasn't possible before.
Not everyone is going to care about this, but enough people should. People reading this thread should care: decentralization and federation of this sort is the way we maintain an open Internet. You can take down individual nodes but you can't take down millions of them. That's the ultimate goal of Helm.
Remember, there's no such thing as a cloud, it's just someone else's computer.
This statement indicates a lot of passion (and I side with it in spirit), but it feels irrelevant and out of place wrt/ this product.
My data is only (available from) my own private Helm server. If mine gets taken down, the existence of millions of other "nodes" doesn't help me. Helm the company can help me with new hardware and my backups, presuming that they're allowed to—but what if they aren't. Then we're back in the same place.
They’re probably not going to go door to door confiscating millions of devices; the cost to do that would be astronomical. You’d still be at risk if they were targeting you personally, but not if they were targeting all Helm users en masse. That’s a big improvement. And even if you were targeted personally, you’d at least be in a position to defend against surreptitious snooping, assuming that took the form of agents physically entering your home to hijack the device.
Of course, there’s a lot of counterfactuals baked into that scenario. Helm does not currently have millions of users, for one. For another, the EC2-based proxy service run by Helm is a single point of failure that someone could take down, though supposedly Helm will release tools to replace it with your own server. And most problematically, the closed-source software could be silently subverted by Helm in an update, with no reasonable means for the user to detect this, even in theory.
Still, it’s a lot better on that front than most cloud email services.
In the parent, the private keys are not on the premises of the cloud company.
I think Helm comes with some obvious trade-offs, but the product looks nice and I think (judging from other HN comments) there's a market for it. I don't know if it's a large market for this to be a success, but it seems interesting at least, and at first blush the product looks well-made.
I don't think this product is exactly for me as my main email, but it could be interesting as a side email service, or one for really sensitive emails. Depending on the price point, I'd consider purchasing. If the price point is too high or the maintenance costs are too large, then I won't. What's the big deal? That trade-off not working for you or me doesn't mean the product shouldn't exist.
Like, backups. Everyone knows how this can be done. Have automated scheduled backups. Encrypt them. Send to offsite storage. This should be handled through a generic backup protocol so you can choose your provider and be sure the app doesn't siphon your personal data.
Users should not need to manually fuck around to set this up for every computer and every app they use. This should be absolutely standard. Preferably built at OS level. I know Ubuntu had something of this sort, but IIRC it wasn't based on an open standard where you could choose your own storage provider. Windows? Hah.
Instead, developers strip users of all control over their data claiming it's for their own good, and push everything to a myriad proprietary cloud solution through random protocols with dubious security implications.
Does Helm use one of those? I suspect not, because I don't know of any such ubiquitously implemented open standard for automatic encrypted backups.
So: is Helm going to put in the effort to define such an open standard and push for it to become ubiquitous?
Even if Helm implements automatic encrypted backups, it's still contributing to a fragmented world siloed into incompatible apps and platforms. Making your siloed service better than others won't fix that problem.
Here is a question for the parent poster and anyone else. Do you think it would be worthwhile to gather some people and try to design such open protocol? Without having an implementation first? Or would that be just a waste of everyone's time?
> You still give access to your data to a company, which controls software updates and the EC2 proxy (in this case).
Because you read all code changes every time you `pkg upgrade` or `dpkg dist-update`.
> Many home ISPs have shitty upload connectivity, so your email won't work that well on the go.
Is that really an issue? I probably use <100kB personnal email per day anyway. Even in the US, 100kB/day upload is not unheard of.
Also, the "on-the-go" issue is DL speed: from your device to your server. How long your server takes to send the mail is mostly irrelevant - instantaneous transmission should be done by phone.
> Internet and power outages mean you won't send or receive any email.
More comments around here about sending servers that MUST retry, and fail only after a few days.
> You lose the knowledge email providers get from scale, including ever-evolving spam filters, and a guaranteed clean outgoing IP.
That could be a real issue, but the ever-evolving filters at my ISP clearly can't spot (nor stop) the spam I receive anyway.
The outgoing IP shouldn't be a problem if you've registered it in your DNS, and it matches the SMTP or whatever subdomain.
Not commenting on the rest: you download incoming mail from your server, i.e. your home uplink. If someone sends you a photo or zip file, that’s the bottle neck.
Not to mention syncing email with the brain dead protocol that is IMAP…
It's also dangerous to say because you don't understand or see the value in something, that there possibly can't be any.
Today's home connectivity + LTE fail over is reasonable to rely on. One could put a vps proxy in front of it if you really wanted.
Running a home appliance is not out of the question or unreasonable. I have a Mac mini server that is coming on 8 years of age and zero issues.
Today, the combination of Ubuntu, docker, and ready to go setups make it super easy. Offsite backups are not an issue anymore. Running owncloud is good for files locally, but email is worth it in some cases.
We own a lot of appliances at home that have a lifecycle to maintain already.
The reality is the above issues have a much lower chance of happening than 10-15 years ago.
Hardware is far more reliable and than it was, my 15 year old servers pulled from my data center were still working when I virtualized.
A discovery I made was owning a PDU (like an APC Masterswitch) cleans the electricity so much enough that attached equipment don't seem to fail. I ran my own email server in a datacentre for clients for a long time because it was the norm.
With Home Automation adoption increasing I suspect a home appliance of some kind will become a reality anyways. If personal data became a feature of it, that would be useful.
The challenge with email is that once you give out any mail address to people, you are on the hook to ensure that it's a functional address. Not something you can just try for 6 months and then easily move on from. And if you decide to move on from this service, will the average person be able to easily migrate that custom domain to a different email provider? (Yes, technically this is possible, but can normal users do it easily? Is it part of the service that Helm provides?)
Not sure if you have spent any time around data centres, but they have to deal with power outages just the same. My power doesn't go out often, how about you?
Backup batteries (UPS') are trivially cheap as well, especially for equipment that sips electricity. Everyone should have one on their internet connection and wifi anyways. A $200 ups can give a few hours of power.
Your offsite worries could be alleivated by mirroring 2 devices, or mirror one to a cloud. Realistically, incoming email is queued for redelivery from 24 to 48 hours until it can be delivered. Beyond that, outgoing email can be sent thru a third party temporarily (migadu, etc). Next question?
Migrating email isn't hard. Most services have import feature. I suspect you may not have done this before.
If there was a way to run a zero knowledge vm in the cloud that was fully encrypted that might be an option too.
Part of the point (and the impressive software that has been built here) is that backups happen transparently, and if anything ever happens to the Helm you can get another one and get back up and running by restoring from online backups. It's the same principle: things can happen to your iPhone but you can get up and running with a new one easily.
Elsewhere in the thread, Giri says it uses a VPN connection. Is it TLS + something else?
helm.garrytan.com:3333 for example responds with a self-signed localhost cert, not LE keys. IMAPS (still not sure why that’s there but I asked that in a different comment so let's have that thread there) and 8443 do answer with LE though :)
Data loss is more or less a solved problem. You don't need Google for that. ;-)
On the other hand, even without putting my tin hat on: I get customized ads best on my email contents, WTF?! Everybody can see based on the browser ads what kind of sites I'm surfing to.
Except if you have a charged battery and LTE. ;-) In fact just a charged battery is needed when network is down to read old mails.
> Fire, theft, or hurricanes may destroy it.
Solved problem. Encryption...
For example, in a power outage, Helm won't work. You say it's not a problem with a charged battery and LTE. I think you're talking about a cell phone and I don't understand how that's related. Sure, one could run Helm on a UPS with LTE backup. But then that's extra infrastructure against the promised simplicity.
Also I don't see how encryption prevents the device from being physically destroyed.
I mean you can connect it to a Uninterupptible Power Supply "USP".
It's not clear if they have a high power USB connector to connect USB batteries, however:
"Built-in battery backup for safe shutdown
On mode: 10 W
Standby: 0.4 W"
> LTE backup. But then that's extra infrastructure against
> the promised simplicity.
There are low-cost routers with USB ports that allow plugging in an LTE stick.
> Also I don't see how encryption prevents the device from
> being physically destroyed.
You can create a backup and store it on an untrusted storage (cloud for instance).
I'm surprised these devices didn't take off 5 years ago already, as this is technology wise almost a step backwards into the 90s. But I think it's worth it, and in fact you don't need helm to set up a system like this yourself. Get a Raspi, stuff an LTE stick and a juicy USB storage into it together with external USB-battery in passthrough and you even have a superior device.
If you can accept the bad availability Helm looks like a fine solution to get your mail out of the cloud.
I'm a Fastmail user and pretty happy with the service. But, what's the real world benefits of Helm over an encrypted email service, like ProtonMail?
Assuming the software works flawlessly (if it doesn't, it doesn't matter where it runs) you'll need RAM and storage access to recover the keys and the data. If you're in the cloud, you won't notice when insiders or state agencies take a peek. If the device is in your home, you can set it up so you notice.
It all depends on the threat model.
AWS, like every non-clownshoes provider, is transparent about the security controls on its datacenters. It has those verified by independent third parties and auditors (for relevant compliance standards). They have published whitepapers and compliance/audit reports, and continue to.
The odds that someone compromises a Helm update and the odds that someone walks out of us-east2a with a drive are not in the same ballpark.
To reiterate, because somehow I'm in the "FDE is an important threat model!" corner: it is not. Walking away with a Helm is not the easiest way to read e-mail on that thing, especially not for an organization capable of dragnet surveillance in general.
Sure, but why are you comparing a software compromise against physical access? There are attacks that work against cloud providers which don't work against Helm. If somebody can compromise a Helm update they essentially got root. And that is a step up from just read access to storage.
Here's how I see it: There is a provider that runs my mail infrastructure. They can either run it on AWS, or host it at my home. If the data is in my home I don't have to trust Amazon. I still have to trust my mail provider ultimately, but using AWS doesn't improve on that.
gsreenivas: Most cloud-based email services hold email in the clear
lvh: are you suggesting cloud e-mail services don't use FDE?
lolc: They may but they also hold the keys.
lvh: it's a lot easier to walk out with a box in my kitchen than it is to walk out with a drive from us-east-2a
lolc: How many people have access to drives in us-east-2a?
In that last quote I should have said "storage", because I didn't mean physical access only. So apologies if that set you on the wrong track.
EDIT: removed bit about 993/587 because you're answering that elsewhere.