I read through your website and I don't understand what your service is. You sorta seem like an email host but seem to very intentionally and carefully not advertise as an email host.
We've considered adding a E2EE comparison column as well (with the issues such as Proton rewriting your emails @ http://jfloren.net/b/2023/7/7/0 highlighted).
Unlike Skiff, Proton, and Tuta... we're _actually_ 100% open-source. Those providers that advertise as open-source really only open-source the front-end, when the back-end is the most sensitive part of an email service.
This is really nice, but the blog does not address the weakest link in the chain: what if you receive a warrant from the US government? The SMTP server would be able to collect inbound/outbound emails in plaintext.
@cedws I think one of us might be confused with the context here (?) TLS is just a form of encryption to establish socket connections. Please thoroughly read through our article and our source code.
A PGP encrypted email doesn't get "decrypted" when it's being transferred. That's the whole purpose of PGP encryption, to encrypt it before it even gets transferred or stored, which is what we do. If you set up a PGP key, use WKD, then your emails will be stored as encrypted (not only is your database encrypted with your password, but the emails themselves can be PGP encrypted this way), and any sender attempting to send to you will automatically have their message PGP encrypted to you, if it is not already (in case their mail client doesn't use WKD).
I think there is a miscommunication. I am not talking about PGP encrypted emails - sure, those can be decrypted client side. Plaintext emails, as the majority of emails are, will be received by your server in plaintext, minus transport encryption. How can you guarantee those will not be intercepted by authorities?
We use MTA-STS (for inbound AND outbound) with our mode set to enforce[1], to require senders to communicate with us only using TLS encrypted sockets. There is no legal precedence currently requiring software services to implement backdoors.
Also - you should note that we largely operate in-memory and don't store to disk any information or logs (unless essential, e.g. IMAP storage, or if they are error logs). We have all of this in our privacy policy and terms on our website. We are extremely transparent.
That is not true. You can upload a PGP key and all your email written to SQLite (IMAP/POP3) will be stored with your PGP key. Not plain text. SMTP is for outbound, IMAP/POP3 is for inbound.
Right, but inbound emails over POP/IMAP will be TLS encrypted. You're saying emails are encrypted at rest, but they cannot be encrypted in-flight because it's forwardemail that holds the TLS private key.
Have you considered offering a bulk email service for folks who want to send newsletters? It looks like an interesting tool though it seems like you specifically ban that use case, even though it seems like it could be great for that.
This looks cool, but do you have any plans to support reverse aliases like simplelogin does? So users can reply from their emails even if an email is aliased, without having to add forward email SMTP settings.
I have an alias user@example.com which forwards to user@gmail.com
The idea is when user@gmail.com gets an email through the user@example.com alias, they can also reply to it and it will show up as user@example.com.
Simplelogin does this through a reverse alias, the reply to address is not the actual address, rather it's an alias for the reply-to address, so it can rewrite the message as if it came from the alias.
Thank you, we've put a ton of work into this. Not only are your mailboxes encrypted with SQLite using ChaCha20-Poly1305 [1], but you can also now add an OpenPGP key [2] (for double encryption).
We support SMTP, POP3, IMAP, API, webhooks, regular expressions, and more.
Sorry; I was being unnecessarily ironic because there really is no "quantum safe" things yet. Otherwise nice work; always nice to see more competition in this space!
We are the *only* email service provider that is 100% open-source. Proton Mail [1], Skiff [2], and Tuta [3] all have closed-source back-ends, despite advertising as closed-source.
RE: Quantum Safe:
ChaCha20-Poly1305 is generally considered to be quantum safe [4] [5].
I am not an expert in this space but, as far as I can tell, these are all work-in-progress, as is quantum computing itself. There are several research groups and committees involved, including at, say, IETF and the like.
Really? How many open source databases do you offer? Some may say it’s not right for randos to complain when you give something away and they complain that it’s missing basics. I just happy someone else wrote most of what I need and I can extend it if needed.
I think having “encrypted SQLite” as a column is a bit too specific, and biased to favor your own product in the comparison. I think a more fair column would be “encrypted at rest” – even if it comes out that your own solution is the only one that ends up with a green check mark.
We also thought of renaming it to "Mailboxes Encrypted Individually". We really wanted to make it clear that each individual mailbox is encrypted. Any other suggestions?
Why does that matter? As in if I as a user have three mailboxes, they're encrypted individually? Or each customer has their mail encrypted separately to other customers? I think the latter is worth mentioning more than the former (though if you're doing the former you're of course doing the latter also).
Correct, the former. There are no other open-source email servers (or closed even) that does the former that we know of. The deep-dive write-up is here if you want to read more https://forwardemail.net/encrypted-email.
Edit: It matters because if someone has access to the filesystem, or our MongoDB database, then they still can't read/write to your email mailbox because they don't have your IMAP password (which we only show to you _once_ for 30 seconds and render in-memory). We use ChaCha20-Poly1305 encryption on the SQLite mailboxes (which is generally considered quantum-secure[0]). Passwords are generated[1] via Node.js `crypto.pbkdf2`.
I guess since you encrypt the whole sqlite db that means you can still offer indexing and FTS while remaining encrypted. But, the application would still have the encryption key in memory. So this protects against an attacker/bad-actor that can access the FS but not if they could access the memory space of the application serving mail items. Is that right?
On "matters" - I was distinguishing all of a customer's mailboxes being encrypted together vs their mailboxes being individually encrypted. I was saying that the former is the most useful point of comparison I'd want to see - is my data encrypted separately to other people's - not the latter. But I may not be representative.
We currently serve UMD, Tufts, Swarthmore, and more.
https://forwardemail.net