Hacker News Reader

Comment by keehun | Hacker News Reader

Interesting product with great potential. Their website doesn't seem to address my two main concerns:

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)?

They claim:

>> 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.)

View on HN

Hi keehun - thanks for posting this on HN! I'm the co-founder and CEO of Helm.

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.

> Your Helm server will then initiate a TLS session with the server hosting your recipient's email

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?

WRT to TLS, see here: https://transparencyreport.google.com/safer-email/overview?h...

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.

> Helm has no obligation or business need to log any metadata

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.

I disagree. Seizing data stored on a server in your house is much, much more difficult that seizing data stored on a cloud server.

I can see that going both ways.

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...

Also, if the feds raide your home you will know that your data was compromised. Apple won/can't tell you..

> Also, if the feds raide your home you will know that your data was compromised.

Not necessarily: https://en.m.wikipedia.org/wiki/Sneak_and_peek_warrant

Not really. If you are under investigation, seizing your server is as simple as a search warrant. The challenge is accessing the data - if you've encrypted it well, it's impossible to access. However, on your own server, you may get complacent and allow some data leakage.

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.

On a VPS, full disk encryption is not effective because the keys can be dumped from the hypervisor.

Not to mention having to wake up in the middle of the night when the VPS provider decides to reboot your VM so you can decrypt the volume on boot. Been there, done that for years.

not a problem for SMTP, which is store-and-forward.

nope. it's only fractionally more difficult as "the man" has to physically come to your house.

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.

According to this page (https://thehelm.com/pages/technology), the following is logged.

* 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.

I don't see what the issue with uniquely identifying a system is. The main metadata of concern is what other mail servers are being interacted with.

If everything has to go through their relay, they can pretty easily see what mail servers are being interacted with.

Thanks.

Please see my other questions here. https://news.ycombinator.com/item?id=18243685

Yes, but they don't have to log that, and given the way the system is described there's no reason it would by default.

The last bullet isn't intended to be a catch-all but to reflect the fact that we can't control what customers provide us via customer support.

It sounds like the hardware device is an SMTP server that sends the email itself directly over encrypted SMTP.

So, what's the subscription for?

Regarding #3, let's work through two use cases. A) I'm at home and B) I'm on the road.

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?

Hi newman314, we have a gateway server that we as a company manage the gives you remove access back to your Helm. We do this without requiring you to poke holes in your firewall because the Helm establishes an outbound VPN connection to the gateway.

Thanks.

Please see my other questions here. https://news.ycombinator.com/item?id=18243685

A) I can connect directly

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.

>> 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.

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.

Yeah, as somebody who has run their own mail server for years, #1 is a huge concern. It has been a real struggle for me despite having a server I own in a rack with net-neighbors I know.

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.

According to their FAQ, you are basically on your own since your device is the MX server:

> 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.

the sounds exactly like the nightmare the GP proposed. what happens when you're on vacation? or even not on vacation but the supply chain is borked or UPS loses your package? even if helm is self-configuring from stored cloud config, this is still a pain and being without email for even a day is painful. 3-5 days (more likely) is intolerable. and if it's longer mail will start to bounce.

So if they route everything through the same set of EC2 instances, that might actually take care of the SPAM issue. I run my own e-mail server and have run into that same issue of not being able to send to gmail/microsoft addresses (unless I contact the person via Facebook/Twitter/Reddit/etc. and tell them to check their spam folder):

https://penguindreams.org/blog/how-google-and-microsoft-made...

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.

"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.

It's actually a totally different product vs Sendgrid/Mailgun/etc.

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.

Rate-limiting would be interesting. If the cost of the service was specifically high enough to be unscalable. Like, $10 per month and you can send 200 emails per day. That’s expensive compared to anything else but fine for personal use.

fastmail already is available for $10 per month, so I guess problem solved?

Do they handle a send-only smarthost configuration that allows arbitrary from addresses within a domain?

As far as I can tell, yeah.

Pretty soon email will require stamps, like paper mail. I wonder if they will sell forever stamps?

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.

Proof of Work basically was invented to cope with email spam. That's more or less a stamp.

https://en.m.wikipedia.org/wiki/Hashcash

If you have a KvK in The Netherlands your PII details are public, and you will start receiving physical spam from companies despite such spam not being free to send. I never receive spam from individuals though; only companies.

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.

But this is exactly what I use mailgun for. The free price point kind of enforces that.

Maybe it's just been so long I'm whitelisted?

More likely you actually set it up correctly, with DKIM and stuff, and the parent didn’t.

I had everything set up correctly, including DMARC. I've been doing this a long, long time.

How about https://postmarkapp.com/ ? It is more tailored to "transactional emails", but seems pretty close to what you describe

> The big players make it difficult to run a small personal server

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.

> 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?

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.

Yeah. Even though I've had my own collocated hardware since Bubble 1.0, I'm looking to move all of that to the cloud. When your own hardware works, it works reliably for years. But when something breaks it's an urgent fire drill, [1] and I'm entirely over those.

[1] 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.

Hey bootsz, when your connection is down, you'll still have a local cache of your messages, contacts and calendar events. Email has retry built in and sending servers typically retry for at least 48-72 hours. The hardware has no moving parts so it should last for a long time, but when there is an inevitable failure, there are encrypted backups that can be downloaded to a replacement device and decrypted using keys only you have access to.

Last point especially. It would be like having all business contact go through IRC with no bouncer and no way to even tell if you were online.

> Yeah, as somebody who has run their own mail server for years, #1 is a huge concern.

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).

> 1. How do they ensure high, non-spam delivery rates to the main email services like Gmail, Fastmail, Yahoo, and Microsoft?

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.

I can't speak for outside the UK, but here the ISPs hand out non-static[1] IP addresses to residential customers. These IP ranges are in the spam-block lists that a lot of the other mail providers use. As such sending any email directly from your ISP given IP address is hit-and-miss affair. You don't even get any bounce notifications, the emails just disappear and never arrive at their destination, so you have no idea that something is wrong.

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.

---

[1] 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.

Same experience. Mostly fine to run your own server. I check the blocklist status of the IP before moving/setting up a new server.

We end up on Hotmail/Outlook's blocklist about once a year. They remove it within 1-2 hours after opening a ticket.

I lost $150 because a certain mail didn't arrive in time (an intercity bus trip ticket) when I couldn't actually afford to lose that money. I had to borrow money from a friend. Those 1-2 hours were quite valuable!

Running your own mailserver is easy enough if you have an IP that isn't blacklisted. Most residential IP's will be on the Spamhaus PBL which will cause issues. You can run a mailserver on a $5/month VPS without issue as long as you have a dedicated IP and you check for blacklist entries before you start.

In my personal experience, it was certainly a problem for a while when lists like SORBS and their notoriously hostile de-listing procedures were all over the place. Listed an entire IP block assigned to a data center I had hardware in as "residential" and it took weeks to get it addressed.

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.

There are very good open source projects, namely rspamd etc.

That helps check that you don't receive spam (and even so, rspamd is much weaker when applied to only one account). It doesn't fix sending other people what looks like spam.

I recall one of the major bulk mail services (perhaps Campaign Monitor?) has a service where you can feed your intended outbound mail into a large range of spam checking services before you send it, to alert you to problems in your mail that are likely to trigger spam filters.

(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...)

While I see others here who have had trouble with deliverability, I'd just like to say that I have never had a failed delivery to GMail/Google Apps, Yahoo, or Microsoft. There are tools online which will receive email from you and help you configure your system properly for full deliverability.

I suspect whatever this Helm thing is, they manage to do things right on that front as well; everything else I don't know.

Reply on news.ycombinator.com