Forward Email (email provider)

[forwardemail]

Hi there folks!

As far as we can see, the only concerns regarding our service in this thread for the expressed Privacy Guides inclusion criteria having been met are the following:

1. An independent security audit
2. How the free plan did not encrypt your forwarding configuration (privacy even on free plan was requested)
3. Export as EML/MBOX

Rest assured, we’ve resolved (2) and (3) completely — and have plans for an audit… keep reading!

Criteria Concerns

1. An independent security audit

Regarding the audit: no service out there (other than us) is 100% open-source. Others advertise as open-source, but they aren’t. Take Skiff for example, they advertised as open-source, but only their front-end was. And then they shut down.

Another is Proton Mail, and yet again, only their front-end is open-source.

Other providers advertise as having an audit, but if you look closely, either it’s never been published (e.g. Skiff) or they only have listed vague information on their website about the audit.

These “other providers” are already listed in Privacy Guides too. Additionally, the top recommended provider of Proton Mail has yet to publish an audit of their back-end. This was already discussed previously in this thread:

@forwardemail

RE: Proton Mail Audits: We have yet to see any audit that discusses Proton Mail’s backend. Discussion is at 3rd party audit of PM backend server ? : ProtonMail

It’s one thing to audit front-end apps, it’s entirely different (and should give some serious concern) to not publish back-end source code nor an audit of the back-end infrastructure, and claim to be privacy-focused and open-source when it comes to user’s email and private data. Here is Proton Mail’s page on being open-source (front-end only).

Mullvad is a perfect example of this done right. We take a lot of inspiration from them with everything they do (and we’ve read every one of their audit whitepapers). We’ve even used them as inspiration for our ansible scripts through these published audits and their related blog posts.

Note that we do have plans to conduct an audit. We’re trying to complete some other more pressing items right now in advance of one – and as mentioned earlier in this thread, we’ve already prepared this list of security audit and penetration testing companies we’re looking at. We’ve already reached out to some of them including Cure53 to obtain pricing and more information.

Lastly, it’s simply not part of the criteria to have an audit. See the discussion at https://discuss.privacyguides.net/t/forward-email-email-provider/13370/30. This isn’t going to deter us from obtaining one though – and we hope that isn’t a reason for exclusion from being listed on PG’s recommended email services.

2. How the free plan did not encrypt your forwarding configuration (privacy even on free plan was requested)

As of July 2024 we now support TXT encryption even on the free plan. Throughout our website, FAQ, and guides, there is an “Encrypt” button (even on the free plan) and a dedicated page at https://forwardemail.net/encrypt which goes into detail on this. All users, regardless of how much they pay (even $0), can hide and mask their email forwarding configuration and email addresses/webhooks/ports/domains/regular expressions.

Additionally we’ve published our GDPR and DPA pages at https://forwardemail.net/gdpr and https://forwardemail.net/dpa respectively. We took a lot of care (and time) to publish these and be sure to list all of our sub-processors (we only have 5):

Cloudflare (US; DNS, networking, and security provider), Vultr (US; hosting provider), Digital Ocean (US; hosting provider), Stripe (US; payment processor), PayPal (US; payment processor)

Unlike others, we don’t even use any third-party tracking/analytics software (e.g. we don’t use Plausible Analytics, Google Analytics, or anything similar for telemetry). We even built our own logging system using our tools Axe and Cabin, our own job scheduler called Bree, our own DNS over HTTPS layer called Tangerine, and our own Spam Scanner. Our goal is to have as few SPOF as possible, all open-source.

3. Export as EML/MBOX

One criteria/bullet point that this thread didn’t give any attention to yet that we wanted to bring up was exporting as an EML/MBOX file:

• Export capability as Mbox or individual .eml with RFC5322 standard.

We already did support this (in a sense, albeit not the easiest) – but at anytime a user could export their mailbox using Thunderbird (e.g. set it up in Thunderbird, download their message over IMAP, and then export).

We have a migration guide as well and users could already download their raw encrypted SQLite database file at anytime as well (or a backup) and open it with SQLite Studio for inspection.

BUT we just went one step further and just now deployed a new feature to production!

You can now export EML files directly in Forward Email for any of your mailboxes. MBOX is coming soon. At no point in time is your encrypted database leaked on disk during this export process. We use in-memory streams and AES-256 encryption with your password on the ZIP file, which is only available for download in Cloudflare R2 for 4 hours with the download link provided over email.

Here’s a few screenshots:

Source code: https://github.com/forwardemail/forwardemail.net/blob/1798cab7e78270b9f4dd4b93d04bcca9298eb7b7/helpers/worker.js (see backup function)

In conclusion

All other criteria listed has been met. We’ve already established in earlier comments that we’ve met them; see these comments https://discuss.privacyguides.net/t/forward-email-email-provider/13370/24 (and before/after comments).

Our pull request is still available at https://github.com/privacyguides/privacyguides.org/pull/2358. We’re happy to make any changes necessary or update/rebase it as needed.

Hopefully this post gives you the confidence in our service (and our participation over the past year+ too here on PG)!

If there is anything more we can do to get your support for inclusion, or anything we’re missing, please do let us know!

For your consideration!

Edit: Also – we’re only 3 years younger than Proton Mail / mailbox; been running since 2017.

[ph00lt0]

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.

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]

Hi there @anon23293884 – 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 Legal: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]

@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]

@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]

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]

@anon23293884

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.

@anon23293884

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.

@anon23293884

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?

[forwardemail]

@Catalyst2422

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?

Yes, we use MongoDB for users/domains configuration and to store a salt of the password.
Here is how we validate the password against the salt https://github.com/forwardemail/forwardemail.net/blob/e37e31d1cd9ca188b15f26b59a073de3469be1ea/helpers/is-valid-password.js#L41-L59

@Catalyst2422

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?

The reason why we stressed open-source backends so much is that when someone emails you @proton.me, @tuta.com, or @mailbox.org that it is going to first go through their MX servers. This means it could be being stored by them (or in a log). Additionally, even if you email someone from your account on Proton or <other service>, the moment that other person replies, it’s going to hit the MX server again (most likely unencrypted) and can be stored by them. Without seeing any code, and without an audit, the only thing you can rely on is marketing material and what is advertised.

@Catalyst2422

And only store encrypted data on the server.

This statement cannot be confirmed without an audit or backend code being shared.

There have been zero publicly shared audits of any currently listed PG email service provider’s backend infrastructures nor open source code snippets shared of how they process inbound email. Nor have they shared anything on their backend infrastructure in public. It is possible that any email service provider could be storing a copy of your messages without your knowledge, and there’s no way to verify they aren’t, or even assume they aren’t, because nobody has seen the code, nor an audit. Not all senders implement PGP/WKD either, e.g. someone that emails you from a Gmail to Proton isn’t going to have the content encrypted on the Gmail side – so once it hits the MX server all of your original outbound messages could be seen.

@Catalyst2422

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?

It is all done in-memory. An attacker would have to gain server access, modify code, and avoid being detected. We also have taken steps to completely disable swap, transparent huge pages, USB devices, and other memory-related security concerns.