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.
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.
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.
Iâm not comfortable recommending a product that says that the competition, (Proton, Tuta) is not end-to-end encrypted. And then links to the privacy guides, websites for the definition of end-to-end encryption. They are so implying that privacy guides agrees that the later arenât E2E.
This is very true. Itâs also true for you. There is no guarantee your hosted platform runs the same backend code as the one thatâs being published. I feel like Iâve said this before. But open source backend is an ideology advantage, not a security/privacy advantage for a hosted platform. I like what youâre doing, but you really shouldnât be spouting bad things about the competition that equally apply to you.
This is incorrect as we state the standard for E2EE is to use OpenPGP and WKD, and in the popups for OpenPGP and WKD we link to the Wikipedia pages as well.
Regarding Proton Mail E2EE, we link to an article, which subsequently links to several open GitHub issues filed on the Proton Mail repository.
Additionally, we also link to Tutanota similarly here with another link to a Reddit discussion, and subsequent links which show that they do not support OpenPGP. Tutanota does not support WKD either because of this.
By our definition, these providers do not use E2EE with OpenPGP/WKD (or have a broken implementation, e.g. due to Proton rewriting messages/signatures).
This is exactly why we said âany email service providerâ. Weâre very passionate about open-source and building trust too. We are following closely Mullvadâs efforts with System Transparency.
Your claims here seem slightly bad faith to me. So, I have decided to waste some of my time refuting them. What follows is an analysis of your comparison page (Link), feel free to refute any and all parts you feel are unfair. I will focus on Proton, as I am most familiar with their infrastructure. Hopefully, Tuta is also similar.
Lets Start
Analysis of their table headers
20 facts in comparison
Only 15 are actually listed. The 5 additional metrics in the header of the table (Hardenize, observatory, etc.) are measures of their website, not their service.
This is a test of their website (not service) security. It uses a very dated idea of HTTP security. Proton fails this due to no CSP policy (Link), which can lead to cross site scripting (XSS) attacks (Link). But, this does not matter on their website since:
Their website actually does not handle any credentials at all. All actual credentials and mails are handled by their webapp or their native clients. Their webapp was found to be vulnerable to XSS attacks in 2022, and was immediately patched. (Link)
Their website passes all other security tests, and uses HSTS and other measures for web security.
What about forwardemail? Well, since they use CSP, they must be invulnerable right?
No. Any and every site is ultimately vulnerable to XSS, due to how web works. Using CSP means they can disable inline JS attacks, but still need to load the JS from their CDN. Who is their CDN? Do they host their entire web infrstructure? Are they invulnerable to transport layer leaks? Are their web implementations bullet-proof? We will never know, since they have no audits of their service, and their website isnât actually tested regularly by security experts (unlike proton, which actually is tested on the daily by actual malicious actors and experts.)
Proton fails here as they do not resolve IPv6. This is not a bug, its a feature. IPv6 is very new and immature in security, and legacy IPv6 is a privacy risk. Interestingly, forwardemail also failed this test until recently (around 2023). (Link)
Pricing, storage, attachment are all accurate for proton. (as they should be lol, public info)
Open source: Correct claim that Proton backend is not open source. Appreciate forwardemail doing it all open-source, but again, no actual audit of the source. FLOSS is not security.
Sandboxed Encryption: No source for their claim of Proton using what they say proton uses, and no source/audit of what they say they use. Additionally, if e2ee is implemented well, rogue employees or anyone else cannot access that data anyway. Finally a personal opinion: Having individual SQLite mailboxes might add another attack vector where now each mailbox can be easily separated from the larger database by a rouge employee, who can then handover specific data to malicious actor rather than the entire database. No clue if this is true, but that is what I think.
Features: Donât see the point in debating unlimited domains, aliases, etc. since that is part of pricing models used, and will differ from company to company. Kudos to forwardemail if they provide all this in free plan.
SMTP, IMAP, POP3: Intentional implementation from Proton (Link). Kudos to forwardemail if they support all 3. Interesting thing to note is that both Proton and forwardemail provide SMTP and other protocols only in the paid plan. (Link). I also donât see any source for their claim of vendor lock-in, since the Proton bridge is open source.
API: Nice feature forwardemail has, but apparantly proton does not. Would be great to see audited reports of API security and its implementation.
E2EE: Insane quote of protonmail ârewriting your emailâ. Is data corruption and misidentification of protocol used so malicious as to be deemed ârewritingâ? The issue is simply Proton intentionally not implementing a feature of being able to use PGP keys not yet registered as a contact on mail service itself. It is a very opinionated choice, and one that people can dispute. But it is NOT, in any sense of the word, rewriting. I would recommend everyone actually read the linked Github issues (Link 1, Link 2). E2EE not being implemented would destroy Protonâs reputation and is a serious allegation. And anyways, we should move away from individually signing PGP keys and focus on automated implementations like Proton does.
OpenPGP and WKD: No issues.
Analysis of their footer
They ask you to review them on Trustpilot. Letâs explore that. (Link)
They have 55 reviews on Trustpilot. Oldest review is from 16th Jan 2023, while the service has been active from 2017 apparently. Most of the 5 star reviews are from people with only 1 review and sound similar in structure. Most of the 1 stars have a comment underneath disputing them and calling the people who reviewed them liars. Seems very interesting.
They seem to have same problems as Proton Mail does on Trustpilot: Reviews by people who were banned. But the difference in proportion of reviews is simply due to the fact that protonmail has a free tier with their own address, while forwardemail does not.
For note, what Tuta does is how you do a comparison in good faith while still showing how your product is better (Link). I do not like how Protonmail does this comparison either, but they at least donât have intentional misreads of competitionâs features. (Link)
Regarding Hardenize/CSP, we have a clear disclaimer that states that all boxes must be green in order to be considered passing (as you mentioned).
We recently obtained access to the Hardenize/Redsift API so that we can programmatically automate these badges/updates. Weâre waiting on answers to a few questions before we can automate the badges/results (and could even accurately share then in an automated way which tests are red/green/greyed out, e.g. CSP) so as to better reflect the comparisons.
Yes weâve had quite a few users post false content on Trust Pilot. For example, thereâs one user that claims we donât list an email address or any way to reach us for help on our site⌠when in fact thereâs clearly links to Help section, FAQ, and our email address (as well as GPG key for our email). Trust Pilot refused to take this down, even though we showed them screenshots. So itâs a constant battle there, but we do our best.
Other providers support end to end encryption though open source and audited client apps. With the encryption taking place within these apps. Not on the server.
What you seem to be referring to is how they handle unencrypted mail. But the same applies to you. With no way of verifying what code is actually running on your servers how can someone know that you canât read their email either?
Weâre rolling out a new feature today which makes it easy to provision existing aliases on macOS/iOS/Android â a new button âGet QR Codeâ which is similar to the âGenerate Passwordâ modal (as previously shown above), but allows you to get the QR code on the fly for provisioning your Apple or Android device.
This doesnât add to the discussion, but Iâm eager to start using Forwardemail once your team rolls out crypto payments, I truly love the transparency and straightforwardness youâve displayed here, itâs incredibly rare for email providers to be this open
You can now send mass email newsletters/announcements with Forward Email
tldr; You can now send marketing email through our SMTP servers â which means you can send mass announcements and newsletters to a list of your opt-in contacts/subscribers. We previously only supported sending transactional emails.
What does this mean?
Weâre now an open-source alternative to MailChimp, Brevo, and Klaviyo (albeit we require you to use something like ListMonk right now â see below) â but we also support IMAP, POP3, SMTP, CalDAV, API, webhooks, and much more â so weâre also an alternative to Gmail/Proton Mail/Sendgrid too!
Our vision is to be the all-in-one, enterprise-grade, open-source + privacy-focused email & security infrastructure platform â and always in alignment with our principles.
How do I send marketing email?
Just ensure you have proper opt-in and opt-out behavior â and include a List-Unsubscribe header as per our updated Terms disclaimer.
Weâre submitting a new pull request to ListMonk hopefully later today (follow this issue for updates) to add us as a built-in provider â but it already supports a custom SMTP server configuration (e.g. you could just use smtp.forwardemail.net and one of your aliasâ generated passwords or a domain-wide catch-all password â see the screenshot below).
You can also programmatically use our API to send a marketing email, just ensure that you have set a List-Unsubscribe and List-ID header in the headers object â and properly setup a bounce webhook endpoint on your server to maintain your list (see below).
Do you support bounce webhooks?
Yes, we now allow you to specify a âBounce Webhookâ in My Account â Domains â Settings for any of your domains. This should be a valid http:// or https:// URL.
To verify the webhook is from us, you can test that POST requests are submitted from one of our IP addresses and/or use SHA256 hash comparison with the payload body and our standard X-Webhook-Signature header (e.g. see this StackOverflow post) in combination with your domainâs webhook key.
Our SMTP servers will automatically submit a POST request to the webhook endpoint you specify with detailed information on the bounce (e.g. so you can perform an opt-out, etc).
If you want to learn more about bounce webhooks, see what the JSON payload looks like that gets POSTâed to your endpoint, and what kind of bounce information is available â then head over to our new FAQ section: Do you support bounce webhooks?
Maybe not totally related to the topic, but is there a plan to implement family plans and higher storage capacities? 10 GB is very low.
Also for your comparison chart, please remove Skiff. For M365, yes they donât have unlimited domain support but their limit is 5000 per tenant. That might qualify as unlimited in theory For aliases they have 400 aliases. High number but not unlimited. At least it is much better than many others. Microsoft doesnât support PGP/MIME but they support SMIME and PGP/Inline. As for API they support it.
Weâre rolling out a new feature today which makes it easy to provision existing aliases on macOS/iOS/Android â a new button âGet QR Codeâ which is similar to the âGenerate Passwordâ modal (as previously shown above), but allows you to get the QR code on the fly for provisioning your Apple or Android device.
For aliases they have 400 aliases. High number but not unlimited. At least it is much better than many others. Microsoft doesnât support PGP/MIME but they support SMIME and PGP/Inline. As for API they support it.