pganon looks like forwardemail’s alt account after the ban.
5 Likes
I just subscribed to them last week after looking for a couple weeks for a new mail provider. (I wanted a 100% open source provider that allowed pgp encryption and custom domains) Can anyone provide more info on what they said? Removing/redacting their ‘banned’ comments here and on github isn’t really helpful in these situations to provide context, maybe just put a disclaimer on the message? I don’t have a good answer for that, but reviewing both sides is imperative when making informed decisions.
2 Likes
FWIW - I follow(ed) them closely on this forum and - from what I saw - there was nothing raised that was egregious from technical perspective. If you use them and are happy with the service I wouldn’t hold the ban against them.
4 Likes
Most of it they removed themselves others flagged by community or perhaps taken down by github, generally I am not really considering this request as these policies are there not for nothing. It is up to you whether you decide not to follow our recommendations. That’s really your choice but don’t expect some kind of helpline from us if you decide differently.
Personally, their tech is probably good. It’s just the PR and marketing side of things they just flopped on. I’ll be interested to see where they go. I do hope they focus more on marketing that their product is solid instead of bashing heavy on competition.
Hi,
This thread has been going on for a while, and as some of you might have noticed I haven’t been as active within the Privacy Guides community due to other commitments which have taken my time.
I am somewhat disappointed to see how this thread went off track in regard to conspiratorial accusations related to other providers and even staff/community members. You’re all better than this 
.
At a further in depth look at the documentation it would seem that Forward Email provides some at rest encryption. The documentation talks about the “sandboxed encryption” which appears to be the encryption of values in the sqlite mailbox database for each user. This is achieved server-side meaning that an unencrypted copy is processed at least momentarily, (even if it is not written to the disk).
Hypothetically if Forward Email was to receive a legal order (eg an NSL) from a US judicial institution requiring a preserved copy they would be required to do so just like everyone else. There are no mail clients, and no web based mail clients so there’s absolutely no way I can see this occurring “with zero knowledge”. The OpenPGP implementation, looks to largely be what mailbox.org or lacre.io does.
Though I did note that “8.4.1 Webmail Service Development”, of the whitepaper suggests this might be a future area of expansion. “4.1.3 End-to-End Encryption Support”, just tells you to use OpenPGP and S/MIME and a random link to an article about quantum cryptography (which lacks relevance). From a privacy perspective I am unable to see how this makes Forward Email a better choice than any other provider.
On the topic of the whitepaper, it largely seems to be documenting high level infrastructure decisions rather than the software implementation, for example I expected to see a section about processing of data, eg where an email is received, what happens to it, and where it ends up. Normally a project like this would have some details about the sequence of events (sequence diagram) on the data processing.
There does seem to be a huge focus on marketing claims of certain large clients using this service, but from a cursory look, checking MX and TXT records it seems to be limited to some smaller scale use cases or specific uses cases where Forward Email’s APIs were beneficial in the solution, and not as much for “privacy purposes”. For example the “Government of South Australia” is mentioned, inferring the whole SA government uses this product, and that is absolutely not true, as they primarily have Microsoft related partnerships, as do pretty much all Australian government departments.
In regard to the pull request #2358, we write those ourselves based on things we’ve personally tested, which was not the case with this one.
In terms of marketing, these would be my personal suggestions:
- Quite a bit of duplication leading to a very busy page (especially the landing page).
- Less focus on other providers in comparisons that don’t really make sense (eg E2EE).
- More focus specifically on Forward Email’s product and it’s strengths. This would create less work in maintaining pages like the email comparison one, where skiff is mentioned and that service doesn’t even exist anymore.
- Have a single testimonial page perhaps, mentioning your clients. There is no need to mention it on the front page, the about page, throughout the documentation and in your whitepaper. Seems overkill to me. I would also not mention any of the ones which cannot be verified, are missing a case study which I assumed those clients approved.
I will still continue to watch this project, as it looks interesting and has some unique functionality, but I do think it’s privacy features not quite there.
4 Likes
On the topic of Forward Email’s marketing, I feel like their very obviously AI generated logo and blog images can give off a cheap impression.
Firstly, there are nonsensical, inhuman inconsistencies in every picture. Judging by the artstyles, it seems they’ve used GPT4o, which is an astonishingly unprivate AI to be used by a so-called privacy service. Forward Email’s lack of transparency about their use of AI is also not befitting of a service like theirs that necessitates transparency.
I understand Forward’s pre-redesign design may have seemed unpolished, but it also felt authentic and charming, which fit the vibe of a committed, underdog service.
3 Likes
It does feel a bit strange the re-brand. I don’t think there was anything particularly wrong with the old logo. It does somewhat feel a little aggressive in terms of being listed, like it is a goal before a particular deadline (we all remember Andrew).
CTemplar made the mistake of “trying to nail the competition” with hit piece articles. To me they seem like the wrong direction due to negativity, and often miss the point.
For example: The Closed-Source Deception: What Proton and Tutanota Don’t Tell You:
Proton Mail advertises itself as open-source, but this only applies to their frontend applications. Their backend—where your emails are actually processed and stored—remains closed-source[7]. This means:
- You can’t verify how your emails are being handled
- You must trust their privacy claims without verification
- Security vulnerabilities in their backend remain hidden from public scrutiny
- You’re locked into their ecosystem without self-hosting options
The reality is the same applies to Forward Email as well, as you cannot audit their production systems. What is to say their source code on github actually matches what is on the server? Well well nothing really but “trust us” and that can be okay to a certain extent.
As a result for a service like email transparency about who is running it, honesty about the service and it’s limitations are crucial. Comparing apples to oranges is not how you go about doing this. That’s why articles like this seem like a whole lot of wasted energy. I think for them to salvage credibility from it they should:
- Significantly reduce information on the landing page, and stick to first impression of their product. This page is supposed to be designed to capture reader’s attention.
- Use a documentation section for developer documentation this usually is something like docs.example.com or developer.example.com. A major selling point of Forward Email is how it can be utilized by other developers.
- Be very curated in blog articles. Keep them positive and centered on the Forward Email product.
- Don’t use AI to write copy material, it generally does a poor job at it.
I like AI when usually applied to the right problem, but unfortunately some examples like this just give it a terrible look.
7 Likes
But that argument isn’t really fair.
At least here you have the option of viewing the source code.
In addition, anyone who finds this insufficient can host the backend entirely themselves.
This is not possible with Proton others.
Is there even an alternative with a similar feature set that you can host yourself?
Hi, I reached this thread while searching the forum for a Mailchimp alternative. I noticed that this is a very long discussion thread but I’m struggling to understand the conclusion of this service. The OP account seems to have been suspended.
-
May I ask that someone tell me what is the conclusion? We still await an audit for it to be listed?
-
would it be a useful feature for PG forum: that someone like me here to search for a specific service replacement and finds a long thread like this to find an uptodate conclusion of where we’re standing? (which gets updated when/if there’s any progress)
thank you
Account was suspended from forward email being pushy on getting a recommendation, and somewhat edging the lines of advertising. But I also believe staff didn’t give forward email a proper evaluation chance.
The service seems pretty solid from what I see, but I cannot vouch for it as a mail chimp replacement.
2 Likes
I appreciate the update thanks. Is there anything we can do to get things going into a decision by staff?
I doubt the staff will make a swift decision here.
However, just because PG does not recommend something does not mean it can’t be used. I do suspect forward email is better for privacy than mailchimp, but I cannot say for certain if it meets the same requirements you are looking for.
1 Like
This is the ultimate email question, Signal has verifiable binaries, and as both sender and receiver use libsignal, we can indeed satisfy mathematically that its indeed e2ee.
Now forwardemail has a frontend client, you can verify the hashes against the running code, and encryption can happen on the client side with providers that support keys via API, WKD and other forwardemail users.
On the inbound side you are trusting every email service there is no RFC that has made email e2ee yet.
Why not pull Proton from the recommended email services?
1 Like
There’s already been discussions about this if you go down the rabbit hole. Plenty of links on this post if you want to read:
1 Like
There is still no public audit of Forward Email as far as I know. Until then it is pointless to proceed as we deem it nessecary to gain trust in this provider and it’s cryptogaphy implementation.
I am closing this thread as questions like yours that are already answered above only make the thread long and thus contribute to the problem you faced. We have a website as summary of recommendations. The forum is to discuss and will require more reading to participate.