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.

Hi there @shortformblog - yes, we are releasing calendar, contacts, and newsletter support early this year.

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.

[1]: https://github.com/forwardemail/mta-sts.forwardemail.net/blo...

Sorry but does that actually address cedws' question about subpoena?

Our policies for law enforcement are publicly available at https://forwardemail.net/en/report-abuse#for-law-enforcement

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.

Memory can still be observed. Encrypted content in memory cannot.

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.

https://forwardemail.net/en/faq#do-you-support-openpgpmime-e...

Here is the actual code in the back-end where we use your PGP public key:

Source code for PGP encryption for storage when you're connected (we only use your password in-memory, and never write it to disk on our side) @ https://github.com/forwardemail/forwardemail.net/blob/562a52...

Outbound email automatically checks for PGP key in case you didn't include the recipients (we use WKD): https://github.com/forwardemail/forwardemail.net/blob/562a52...

Your individual mailbox is a SQLite database file and is encrypted using ChaCha20-Poly1305 as well (using your password, which only you have access to; we only use it in-memory and don't write it to disk).

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.

Isn't this just advertising your own company?

That's not inherently bad if the comment is relevant and the relationship is made clear in the comment.

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.

Hi there @jacooper - we already support this via domain-wide catch-all passwords. We also support filtering such as [email protected].

No i meant it differently.

I have an alias [email protected] which forwards to [email protected]

The idea is when [email protected] gets an email through the [email protected] alias, they can also reply to it and it will show up as [email protected].

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.