Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helm: Personal Email Server

thehelm.com

Post reply on HN
Print view View original

551–560 of 592 posts

Re: Helm: Personal Email Server

#551

Post by chaitanya »

gsreenivas wrote: post #125
keehun wrote: post #3

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 d…

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 se…

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

Re: Helm: Personal Email Server

#552

Post by chaitanya »

(I sent this as an email to helm's support but since the founders are responding here I am duplicating this here)

Your technology page mentions that you provide an mx gateway (presumably for inbound email for home networks that don't usually have a static IP address). You also mention that emails forwarded to the helm server via your gateway are encrypted end-to-end and your gateway cannot read the contents of that email.

I am unable to understand how this happens. TLS is not end-to-end -- since the sending mail server will establish a TLS connection with your gateway it means that you necessarily have to decrypt the incoming email before forwarding it to the helm server.

Can you explain to me how I am wrong here?

Re: Helm: Personal Email Server

#553

Post by ylmm »

leokennis wrote: post #525
amelius wrote: post #467

Earlier quoted context omitted.

How would material on a website provide trust, without a means to verify that information?

What other way is there? Have a button to “let the CEO call me and pinky promise me that the website info is truthful, complete and correct”? Would you believe it then?

That's obviously not what he's suggesting? He's just saying (and correct me if I'm wrong) that, for a company whose business is based in no small part on trust, it's a bit weird to not have any information about any of the people involved in the project.

Re: Helm: Personal Email Server

#554

Post by gsreenivas »

lvh wrote: post #316
gsreenivas wrote: post #262

Earlier quoted context omitted.

Hi lvh - it's not a proxy. The EC2 instance can't see your emails. The Helm server initiates and receives TLS connections through the instance so it's really an extra hop on the internet. We don't see or keep data on deliverability of individual Helm servers. We use a dedicated EIP that we ensure are not on blacklists and configure reverse DNS as well.

If that’s the case, why does it listen on IMAPS/993 and 587?

because it's forwarding packets to/from the Helm server in the home

Re: Helm: Personal Email Server

#555

Post by gsreenivas »

cycop wrote: post #272
gsreenivas wrote: post #253

Earlier quoted context omitted.

Hi TrueDuality - Giri Sreenivas, co-founder and CEO of Helm here. We will be publishing more details to answer your questions in depth in a series of coming posts. I'll give you some quick answers right now. We use Yocto to spin our own Linux build. Key projects we utilize: OpenLDAP Postfix Dovecot Darwin Calendar and Contacts Certbot OpenDMARC OpenDKIM OpenSSL Python SPF Policy Sieve SpamAssassin Duplicity StrongSwa…

I would like to see the option for backups to be held on you own own cloud account of choice. I am in Canada and I use a Canadian cloud company called sync.com for my secured data storage knowing it will not be stored in the US. The price point is also a bit high for a Canadian Customer, so I like the idea but a bit too pricey for North of the boarder after currency exchange.

Thanks for the feedback - we will take this into consideration.

Re: Helm: Personal Email Server

#556

Post by gsreenivas »

sjs382 wrote: post #259
gsreenivas wrote: post #230

Earlier quoted context omitted.

We use duplicity for backups so there's nothing proprietary in our approach. There will be more transparency coming in a series of technical posts about how the product works, what open source software we use, etc. Appreciate the feedback - we'll keep this in mind as we move forward.

I understand that this is a new product launch and you can't have all answers to all questions front-and-center on the website on day one. With that in mind, kudos to you and garry for being so active in these threads. I definitely look forward to these posts!

Thanks!

Re: Helm: Personal Email Server

#557

Post by gsreenivas »

joezydeco wrote: post #232
gsreenivas wrote: post #195

Earlier quoted context omitted.

We spin our own build of Linux using Yocto. 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 ri…

We spin our own build of Linux...We are using an ARM-based SoC from NXP. 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? https://blog.quarkslab.com/vulnerabilities-in-high-assurance...

Good guess and we looked at the i.MX but did not select that line of SoCs. We are using the Layerscape line of SoCs from NXP

Re: Helm: Personal Email Server

#558

Post by gsreenivas »

lvh wrote: post #543
lolc wrote: post #536

Earlier quoted context omitted.

How many people have access to drives in us-east-2a? Do you know? Can you verify? 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 mo…

> How many people have access to drives in us-east-2a? Do you know? Can you verify? 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…

I'm curious about how you arrived at the conclusion that we are capable of dragnet surveillance. Connections to/from the Helm server use TLS end to end.

Re: Helm: Personal Email Server

#559

Post by gsreenivas »

newman314 wrote: post #429
ryan-c wrote: post #238

Earlier quoted context omitted.

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.

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 l…

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.

Re: Helm: Personal Email Server

#560

Post by gsreenivas »

ryan-c wrote: post #545
TheGrumpyBrit wrote: post #526

Earlier quoted context omitted.

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…

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.
Post reply on HN