It used to be possible to run your own SMTP server, inbound and outbound, from home. This was so badly abused by spam that port 25 is blocked almost everywhere.<p>Domestic systems tend to be in configurations that make it hard to accept inbound TCP connections. You could serve SSL on a random port and open a port using UPNP, and it will work <i>most</i> of the time.<p>It's a difficult circle to square. The most trustworthy system is one you administer yourself and manually inspect all updates, but in practice the amount of work required makes that almost impossible. If you allow the OEM to do updates they can compromise you. If you don't do updates you end up vulnerable to exploits.<p>The "send a reference to the message not the message" technique was part of DJB's "internet mail 2000" proposal: <a href="https://en.wikipedia.org/wiki/Internet_Mail_2000" rel="nofollow">https://en.wikipedia.org/wiki/Internet_Mail_2000</a>
This looks very similar to what we built one year ago at <a href="https://kinko.me" rel="nofollow">https://kinko.me</a>. And then we even managed to solve most of the problems outlined in the comments here (Port 25 blocked, etc.) But our crowdfunding campaign failed, and I have seen other campaigns with similar topics and target audiences fail since.<p>Consequently I doubt that a relevant audience for that type of device really exist -- even though I wished own-mailbox would succeed.
How does transmitting an HTTPS link solve email encryption for people who don't have PGP? The link is sent plaintext. Does the system require users to register out-of-band somehow? That's how corporate email "encryption" systems work (the "send an HTTPS link" approach is popular with financial firms).<p>The underlying approach this system uses --- webmail, but on a special purpose box the user owns --- is actually sound. It seems like a pretty good refinement of Mailpile.<p>On the other hand, they should tone the rhetoric down. I winced at "100% secure".
The reason for SMTP servers being better off in a proper data-center is not really due to port 25 being blocked at home, it's the entire infrastructure that assures reliability, so if your power goes out or your home router decides to die or your ISP is having issues, etc, you would start losing emails right away.<p>EDIT: I understand SMTPs are resilient but it also depends on the type of error they get back, even then it can't be expected that all servers keep retrying for long periods of time or even handle triple bounces.
So you 'could' start losing emails right away, is a better way of saying it.
SC4 is in-browser encryption that works with your current email account:<p><a href="https://github.com/Spark-Innovations/SC4" rel="nofollow">https://github.com/Spark-Innovations/SC4</a><p>It's open-source and audited. Based on TweetNaCl. Feedback very much appreciated.
A couple of problems as noted already that will make this a show stopper:<p>> Port 25 is blocked inbound on most residential accounts - preventing you from receiving email<p>> Many SMTP servers are configured to automatically bounce email from residential IPs - so sending would be a problem<p>The point of GPG is to make sure that the only person that can read the message is the one you sent it to. Having a HTTPS site doesn't prevent the random person from viewing the link and doesn't verify the user. Now - this might be interesting if the web app that shows the email has as GPG library in Javascript requiring the user to have GPG keys.<p>I think a better scenario is if keys haven't been exchanged - to send an email with "Alice would like to communicate over secure email - please download and generate a set of keys" with instructions on what to do. But I have no idea how not to make it look spammy.<p>This is just hilarious:<p>> Why shouldn't I trust and use any cloud email service with JavaScript client-side encryption?<p>> Encryption is done in JavaScript, and therefore relies on browser's JavaScript engines, which 80% of the time [1] are proprietary software coming from Google, Microsoft, and Apple, most eminent NSA collaborators.<p>The author does know that Chrome is open source right (well I guess technically Chromium but I hope it's based on the same code)?<p>> Why not use a raspberry Pi?<p>> Mainly because it cannot be trusted enough for this kind of application. [...] The Raspberry pi is provided with non-free software and the hardware needs non-free driver to work.<p>I've used Debian Linux on it before and didn't need to install third party drivers?
* Reliability of ones Internet connection should not be much of an issue, because SMTP servers should retry to deliver a mail for several hours/days. Otherwise a secondary MX could be used as a backup for mails in transit.<p>* Policies of ones ISP are often a problem for something like this, you likely need a "business connection" for something like this.<p>* Dynamic DNS could be used for receiving, but you won't have much success in sending mails unless you have reverse DNS working and that requires a static IP as far as i know. Most users will only get a static IP for "business connections".<p>* I'd be really interested how the combine their usage of GPG with multiple client. Is there some sort of key management included? How does it work with Webmail/Roundcube? Is the same key used for desktop and mobile phones?
While I understand the team behind this is French, the broken English and bad capitalization are haunting.<p>"rasberry Pi"<p>"Plug at your home"<p>"Through a webmail"<p>"Plug it in mini-usb to your computer"<p>"Will I get a root access"<p>Why not have somebody with English as their first language give it a look before making it public?
Its main feature is security, which is great for paranoid people. But what happens when you are miles away from home and your internet connections to the server goes down? How are you going to check your e-mail?
If you're concerned about privacy, it seems the best method is still to cut-and-paste encrypted envelope into regular mail client to avoid possible vulnerabilities, both physical and software. The obvious problem with a self-hosted server that you order from a company is that it can be intercepted or otherwise compromised before it arrives at your home. Thus it is potentially even more vulnerable than just pasting GPG encrypted message directly into gmail client.
> What about SSL certificates and authorities for HTTPS?<p>> Each Own-Mailbox will generate automatically its SSL key at first setup, and send to us the public part.<p>> Letsencrypt Certification Authority will be used , it is free and very easy to setup, and it will be handled automatically by your Own-Mailbox. Every Own-Mailbox will automatically ask for certification for its key indepently from us.<p>Interesting idea.
Regarding hardware-assisted self hosting, there is <a href="http://internetcu.be" rel="nofollow">http://internetcu.be</a> which, among other things, does email (and bypasses ISPs restrictions by bundling the "box" with a VPN and providing static IPv4 and 6 addresses to each user).<p>It's some sort of "freedombox" [0] come true. It works out of the box, in a plug and play fashion (and it's based on free hardware [1] and free software [2]).<p>[0] <a href="https://en.wikipedia.org/wiki/FreedomBox" rel="nofollow">https://en.wikipedia.org/wiki/FreedomBox</a><p>[1] <a href="https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME/open-source-hardware" rel="nofollow">https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-...</a><p>[2] Debian, <a href="https://yunohost.org" rel="nofollow">https://yunohost.org</a> ,...
The funny thing that most people who obsess over encryption forget is that using tough encryption attracts attention, and all the encryption in the world won't save you from simple workarounds (<a href="https://xkcd.com/538/" rel="nofollow">https://xkcd.com/538/</a>) and ordinary surveillance.<p>The solution for all of us is to make ordinary communication more expensive to break into rather than to go out on a limb with attention-getting extraordinary measures.<p>I'd also have to say -- no offense intended -- that what I take to be a central European accented voice-over advocating using a new security product to avoid NSA surveillance doesn't fill me with confidence. I'm pretty sure the NSA is at least well-intentioned.<p>I'd suggest your best pitch accent would be scandinavian or perhaps Australian (not that the Australian government isn't horrible, but it's pretty harmless).
How are they going to receive mail? All blocks of IP's from any provider are blocked, usually huge blocks, larger than /24 often. No one is getting to any comcast users, they as do many others publish lists of their IP ranges so you can block then in your server or use an RBL.
I thought Posteo [1] is already 100% confidential? Please someone correct me if I'm wrong.<p><a href="https://posteo.de/en/site/privacy_policy" rel="nofollow">https://posteo.de/en/site/privacy_policy</a>
I see a small market for this: bundled with verifyable co-location space.<p>At home, it's simply not going to work unless they also offer a VPN service for the ports in use. SMTP on an eyeball provider IP is simply dead these days.
Wow. I suggested this once (maybe even on HN):<p>Meta-data are also problematic. We are working on a solution for that, but it won't be included directly in our first version.<p>It will probably come for free with updates. Our idea is that for every email you send, your box randomly sends ten encrypted fake-emails, at random moments, at ten random addresses. Recipients server automatically sees that it is a fake email when it decrypts it, and automatically drops it.
I've been working on this exact idea on and off for almost a year now. Very cool to see someone else working on it, they've some nice solutions for hard problems too.<p>I don't really like the choice for RoundCube, but without decent funding or a couple of expert web developers they'll be hard pressed to build something better.<p>Also nice to hear they're also from Europe, it goes to show the U.S. surveillance worries are very much alive here.
This only address the issue of government surveillance of email through service provider backdoors. Since this would as well require auto software update to be as user friendly as the video advertise, you might as well give up the same amount of security for a service that is hosted in a liberty-friendly nation and not have to deal with SMTP flagging and home power issues.
I run my own mail server even though my ISP blocks port 25 OUTBOUND. I use DynDNS's Mail relay service. Only costs about $20/yr. I never have have a problem being flagged as spam or anything else. I can receive mail on port 25 INBOUND with no issues. I set my MX RR to my home IP and add a secondary to a dynamic address, also through DynDNS. works great!
If you want to set up something like this on your own hardware (not just email, also owncloud, jabber, etc), check out sovereign
<a href="https://github.com/sovereign/sovereign" rel="nofollow">https://github.com/sovereign/sovereign</a>
I, like everyone else in this thread, wanted to run an SMTP server from home, only to realize port 25 was blocked.<p>Now I rent a VPS from DigitalOcean, and availability is like 99.999% and run SMTP and other daemons no problem. I love it.<p>So go out there and find some cheap VPSs people! :)
I don't see anybody mentioning this anywhere.
Why isn't there a wi-fi connection option?<p>I'm aware of the security issues with low or none wifi secure networks, but most folks (myself included) never have a cable around.
This looks like a great project. One thing I noticed about the website: There doesn't seem to be a way to dismiss the video overlay. I had to refresh the page.
I want to know if the code will be available for auditing.<p>Also, if these devices can be blocked by spam blocklists, then there should be some way to use a vpn to handle this.
How do you deal with key management? Specifically, what do you do if someone doesn't remember their passphrase or loses their private key entirely?
literally no one i know uses public key encryption - so now everyone needs to clink on a link to read an email from me? don't get me wrong I think this is a cool idea, but it still doesn't address the core problem with all of the encrypted email services/clients/etc., user adoption...
> The Own-Mailbox sends a HTTPS link to your correspondent, so that he can access the message in encrypted form. He can answer you using HTTPS protection.<p>So anybody who can read the unencrypted mail containing the link can access and read the real mail?