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.