Forward Email (email provider)

[ph00lt0 (Mare Polaris)]

Please stop tagging team members. Thank you.
Your product will be reviewed by us and the rest of the community as per our standards. This does take a while and please respect that. The reasom being our careful considerations and assesments. Especially email is a very vital tool to do right and making wrong recommendations like has happend in our community before is a burden on our readers, this is the reason we proceed with at most care. Do note we have not forgotten about you, but please remain patient.

[anon49578468]

I also think the provider is being too pushy with this. I know how hard it is to run a privacy oriented service, especially when the community is full of skeptics, but some of the pressure directed here feels a bit aggressive from them. For example, see this Wikipedia listing they are pushing which keeps being rejected (for “not having reliable source”, since they keep citing their site as a reference).

Additionally, their constant claims of being open-source and not having “closed-source” servers are irrelevant, since if the client side is implemented well and audited to do what it is supposed to do, most E2EE services don’t actually need to show how their servers function (since a lot of these services actually have a threat model of third parties like AWS operating their infrastructure). This is a fundamental misunderstanding of how Proton and other services work, especially in their native clients.

[shaunw]

Sorry if it’s coming off as pushy. Just trying to keep up with feedback and keep updates in a central place here for reviewers as they may be going back and forth. We can keep those in a changelog or similar to make sure those here can reference back if they’re missing updates.

Also this has been open for a year, so we’re just trying to figure out what else is needed and doing our best to stay engaged.

The wikipedia issue was my fault. I haven’t done that before and was trying to tweak the sources and links and having issues with the template / tags. User error on my part.

[jonah (Jonah Aragon)]

Hi Shaun, if you’re affiliated with Forward Email please DM me so we can verify that fact. I appreciate the updates, it’s made keeping up with Forward Email development very convenient.

[lulnull0x00]

Not related to the product, but i dig the developers for being so communicative. Really awesome to see. They clearly are passionate about what they are doing.

[forwardemail]

We’ve just added the ability to export as MBOX format too!

It’s similar to EML export; it’s all done using streams and zipped using AES 256 encryption, and at no point is anything written to disk.

There is also now a dedicated section in the FAQ for exporting with some additional open-source resources for converting/viewing exported files too.

Commit: feat: added MBOX export support, updated FAQ, sync locales · forwardemail/forwardemail.net@ab4edcb · GitHub

[123]

Hi @forwardemail

The service you offer is very interesting and I appreciate your commitment to the open-source software.

I try to understand your encryption process, I read the article on your site:

Quantum Resistant Email Service in 2024

I have a few questions:

1. You use symmetric encryption (AES) to encrypt the mailbox inside a SQLite database (separate DB per user) and whenever I connect to the server my IMAP password is used to decrypt the mailbox. Is this correct? So while I’m connected to the server 24/7 my mailbox is in decrypted state for the whole time. That’s ok, I understand that there is no solution to this issue.

2. But is there also an option to upload my public GPG key to the server so that all incoming emails that were not encrypted by the sender are encrypted on your server? If the server is later compromised this would protect my past emails (only content, not metadata of course) even if I am connected to the server and my mailbox is decrypted. I think this is what Mailbox,org and Posteo do.

3. Also, how is the temporary database encrypted while I’m offline? Symmetric or assymetric?

4. What are your thoughts on the JMAP protocol? Will it replace IMAP/SMTP? I know it doesn’t support E2EE by default, by maybe it would simplify encrypting email metadata?

5. How do you respond to the court/government requests/orders to handle user data or intercept communications? I fully understand that as a legally operating company you have to comply but there are companies/organisations (e.g. Posteo or RiseUp) that try to challenge the orders with the help of attorneys so if the requests are invalid or too broad they are legally rejected. This is of course a significant financial cost.

6. Will you accept cryptocurrency payments already this year or it will take a bit longer?

[forwardemail]

Hi there @123 – thanks for joining this thread.

@123

You use symmetric encryption (AES) to encrypt the mailbox inside a SQLite database (separate DB per user) and whenever I connect to the server my IMAP password is used to decrypt the mailbox. Is this correct? So while I’m connected to the server 24/7 my mailbox is in decrypted state for the whole time. That’s ok, I understand that there is no solution to this issue.

All SQLite databases (mailboxes) are encrypted using ChaCha20-Poly1305 using your IMAP password. We do not store your IMAP password, only you have it. When you connect over IMAP, your password is encrypted in-memory (currently using AES-256-CBC but we plan to switch entirely to use ChaCha20-Poly1305 everywhere) and used to open your database. For long-lived IMAP connections, we keep your database open in-memory using a JavaScript Map instance so that IMAP commands can quickly operate (e.g. if we close and re-open on every IMAP command, it adds 100-300ms overhead; which quickly adds up). See forwardemail.net/sqlite-server.js at ab4edcbc39578382f9f0d5379e2ddab31586ab49 · forwardemail/forwardemail.net · GitHub, https://github.com/forwardemail/forwardemail.net/blob/ab4edcbc39578382f9f0d5379e2ddab31586ab49/helpers/get-database.js#L478-L493, and https://github.com/forwardemail/forwardemail.net/blob/ab4edcbc39578382f9f0d5379e2ddab31586ab49/helpers/on-auth.js#L576-L577.

@123

But is there also an option to upload my public GPG key to the server so that all incoming emails that were not encrypted by the sender are encrypted on your server? If the server is later compromised this would protect my past emails (only content, not metadata of course) even if I am connected to the server and my mailbox is decrypted. I think this is what Mailbox,org and Posteo do.

Yes, this is mentioned earlier in this thread at https://discuss.privacyguides.net/t/forward-email-email-provider/13370/36 (screenshots included), but there is a FAQ section regarding this at https://forwardemail.net/en/faq#do-you-support-openpgpmime-end-to-end-encryption-e2ee-and-web-key-directory-wkd.

@123

• Also, how is the temporary database encrypted while I’m offline? Symmetric or assymetric?

While you’re offline (no IMAP connection established) we use ChaCha20-Poly1305 using a secret key of ours. Note that if you configure an OpenPGP key (as discussed in previous question) then your inbound email will be encrypted using your key in this temporary database. See https://github.com/forwardemail/forwardemail.net/blob/ab4edcbc39578382f9f0d5379e2ddab31586ab49/helpers/parse-payload.js#L1000-L1013.

@123

What are your thoughts on the JMAP protocol? Will it replace IMAP/SMTP? I know it doesn’t support E2EE by default, by maybe it would simplify encrypting email metadata?

We do not think that JMAP will ever be widely adopted nor will it replace IMAP/SMTP. See the thread at https://github.com/nodemailer/wildduck/issues/2#issuecomment-1765190790. We have no plans to support JMAP.

@123

How do you respond to the court/government requests/orders to handle user data or intercept communications? I fully understand that as a legally operating company you have to comply but there are companies/organisations (e.g. Posteo or RiseUp) that try to challenge the orders with the help of attorneys so if the requests are invalid or too broad they are legally rejected. This is of course a significant financial cost.

See the discussion at https://discuss.privacyguides.net/t/forward-email-email-provider/13370/57 and https://forwardemail.net/en/report-abuse#for-law-enforcement.

@123

Will you accept cryptocurrency payments already this year or it will take a bit longer?

See https://discuss.privacyguides.net/t/forward-email-email-provider/13370/50– perhaps later this year we will start accepting crypto with https://github.com/alexk111/One-Time-Address or something similar.

[forwardemail]

Hi there @MMA-block – specifically, “As law permits” is the text that is important here, and it is related to emergency data requests (“EDR’s”). Note that the same folks that monitor the support inboxes are also the core engineers here at Forward Email (we have a small team). It should be known that we are experts in email verification (e.g. SPF/DKIM/DMARC checks, or lack thereof; and subsequent independent verification), and more for any such EDR – therefore it is extremely unlikely that a scammer could trick us into providing information to a fraudulent EDR. We would of course contact the requester by their phone (from an independent search and research/verification process) to verify the EDR and would never just blindly send information.

See Emergency data request - Wikipedia and Wikimedia Foundation Requests for User Information Procedures and Guidelines - Wikimedia Foundation Governance Wiki

We do not have your IMAP password, so we cannot access your emails stored in your mailbox, and we also do not store any forwarded emails to disk (it’s all done in-memory).

Additionally, outbound mail is immediately redacted after sending. See https://github.com/forwardemail/forwardemail.net/blob/ab4edcbc39578382f9f0d5379e2ddab31586ab49/app/models/emails.js#L722-L735.

Consider us a “zero-knowledge service”.

Also – if PG were to make any sort of disclaimer, our opinion is that disclaimer should be directed at companies such as Proton Mail and Tuta that advertise as open-source, yet their backends are completely closed source.

[forwardemail]

See similar EDR policies, which is standard in the industry:

Cloudflare: https://www.cloudflare.com/trust-hub/law-enforcement/#:~:text=types%20of%20information-,Emergency%20requests,-In%20accordance%20with

Digital Ocean: https://www.digitalocean.com/legal/law-enforcement-guidelines#emergency-requests:~:text=S.C.%202523.-,Emergency%20Requests,-As%20US%20law

Also – we’re well aware of hackers exploiting this, e.g. see this article from The Guardian, but again keep in mind we try to be a zero-knowledge service while still providing a good user experience.

[ph00lt0 (Mare Polaris)]

@forwardemail

disclaimer should be directed at companies such as Proton Mail and Tuta that advertise as open-source, yet their backends are completely closed source

We do not agree and this has been explained many times to you in this thread. Can you stop bringing up the same arguement each time. While we love open source there is no benefit to the user for open source backends as all encryption is implemented in the open source client apps.

[ph00lt0 (Mare Polaris)]

@forwardemail

emergency data requests (“EDR’s”).

In the case of Tuta and Proton (not sure about mailbox) they only provide information after a judge has given the order for that. Now that is quite a difference from your policy. I unfortunatly also see that police forces do many warrentless requests often not in good faith. I am not familair enough with US law to know whether such policy is viable you, but surely that would be preferred.

[forwardemail]

@ph00lt0

I am not familair enough with US law to know whether such policy is viable you, but surely that would be preferred.

Emergency data request (“EDR”) are only honored in good faith belief that disclosure is permitted (see 18 U.S.C. §2702 (b)(8) and §2702 (c)).

[ph00lt0 (Mare Polaris)]

More of a techical question tho. From your CSP I can see you allow a form from a marketing affiliate company anrdoezrs[.]net why is that?

[forwardemail]

@MMA-block

But here’s the thing: the language in your policy still raises red flags. Specifically, the clause allowing data disclosure “as law permits” without a subpoena, court order, or search warrant. Even with a crack team, this could be a backdoor for exploitation. Law enforcement has a history of stretching the truth to push through urgency, and your phrasing like “when we believe that doing so without delay is needed” feels like a loaded gun left on the table. In the wrong hands, that’s a vulnerability.

We already went over this. Here is why you should not worry about this:

1. They are honored in good faith, to our discretion, and with independent verification. If someone sends us an email (spoofed or not) as coming from a government, state, or local jurisdiction/law enforcement – regardless of what information is the in email, we’re going to independently call the office (as from the phone number in public listing and/or on their website or government; e.g. .gov website) to verify the request. We would also check other metadata, such as where the email came from (IP), headers, who sent it, etc. We wouldn’t simply honor an EDR over email alone. We have to operate within the law, according to 18 U.S.C. §2702 (b)(8) 2 and §2702 (c) as previously linked. ‘As law permits’ means that it’s with accordance with these sections.

2. Anything stored with IMAP/POP3/CalDAV is encrypted using ChaCha20-Poly1305 your IMAP password in a SQLite file. Unlike other providers, we don’t use massive shared relational databases. Additionally, as mentioned, we do not store forwarded emails, it is all done in-memory. This means that we have little to no information that could be even provided for such an EDR or even a valid subpoena in general.

@MMA-block

A privacy-first service can’t afford to have policies open to interpretation. It needs to be bulletproof, leaving zero room for ambiguity or external pressure.

We’re a business and our policies must be in compliance within United States law. We cannot falsely advertise either. We’re transparent and actively participating here.

@MMA-block

they’ve earned their stripes through years of consistent, transparent actions

Proton was founded in 2014, Tuta 2011, mailbox 2014, Skiff was 2020, Forward Email 2017.

[forwardemail]

This was a legacy artifact from a few years ago when we used Commission Junction’s Namecheap affiliate program for when people purchase domain names. This is now fixed, thank you pinging us about this.

Commit: https://github.com/forwardemail/forwardemail.net/commit/aed372cf7c639307420ff05ed34b272ae10664e3

Screenshot:

Link: https://forwardemail.net/domain-registration

[forwardemail]

We’re going to look at updating verbiage on that page to be clearer and not open to misinterpretation. We’ve just updated the verbiage on that page for clarity.

See https://forwardemail.net/en/report-abuse#law-enforcement-emergency-requests

Thank you for your feedback

[Catalyst2422]

@forwardemail

Unlike other providers, we don’t use massive shared relational databases.

What risk is there in other providers using a shared relational database?

[forwardemail]

Shared relational databases (e.g. MongoDB, SQL Server, PostgreSQL, Oracle, MySQL, etc) all require a login (with user/password) to establish the database connection. This means that anyone with this password could query the database for anything. Be it a rogue employee or evil maid attack. This also means that having access to one user’s data means you also have access to everyone else’s. On the other hand, SQLite could be considered a shared database, but how we use it (each mailbox = individual SQLite file) makes it sandboxed.

Since we use sandboxed and individually encrypted SQLite files to hold your data (each with their own password which only you have), this means that none of our employees can ever access your data – it is a core design decision/system architecture difference.

Additionally this also completely eliminates the threat of SQL and NoSQL Injections (e.g. one user can’t do a query injection for your data, as it’s in a completely different database on its own connection). It also eliminates the risk of accidental data deletion, and makes it much easier to maintain backups, restore, and completely delete and purge data if needed on an individual basis.

[Catalyst2422]

Thanks for the reply.

Given that other providers, namely Proton and Tuta encrypt and decrypt the data at the client. And only store encrypted data on the server. Surely anyone who gained access to their databases could only access encrypted data?

It seems that with your system you just access the encrypted data in a different way? You’ve just added a layer of complexity. Do you not use a databse to manage access to the individual SQLite files?

Another question if I may.
Are users mailboxes decrypted on your server and held in memory so that they can be accessed via IMAP? If so does that mean that an attacker with server access can view the decrypted data? Whereas with other secure providers the decryption only takes place on the client devices?