Forward Email (email provider)

[forwardemail]

The reason we charge people is for (1) storage costs and (2) to protect IP reputation.

Any provider has costs – and we do too. If you’re on a paid plan, you get those features (IMAP/POP3/CalDAV/outbound SMTP) for $3/mo. We don’t charge per user unlike others either.

Most VPS providers charge $5/mo, so we’re already $2 cheaper per month than spinning up your own VM and hosting your own email server infrastructure (and subsequently dealing with IP reputation, load balancing, fighting spam and malicious actors, DNSSEC, MTA-STS, DMARC, DKIM, SPF, ensuring uptime and everything else on your own – basically our entire business). There are some providers that offer $2.50/mo VPS, but most if not all of those only offer IPv6 address, and not all MX servers support sending to IPv6 AAAA addresses as resolved from MX lookup – some only support IPv4 anyways too.

Regarding your second “red flag” – this has already been addressed in this thread. We’ve been around for 8 years now and we have never increased prices.

[securitybrahh (Sovereign Shadow)]

@forwardemail

Regarding your second “red flag” – this has already been addressed in this thread. We’ve been around for 8 years now and we have never increased prices.

The cost of bandwidth & storage is exponentially decreasing last I checked.

You should be decreasing your prices

Jk

[jonah (Jonah Aragon)]

Please be respectful of people’s time and be constructive. It is not acting in good faith to simply complain about pricing without trying to have a conversation about why. It’s just negativity for no reason.

I warned you all 10 days ago in this thread and this will be the final warning, any other bad faith behavior from anyone will see them removed from the forum.

[forwardemail]

Great news As requested on GitHub issues, we’ve added webhook signatures today!

Now you can verify the webhook signature (e.g. in addition to verifying the request was coming from one of our IP addresses). See this GitHub issue for more insight or simply visit My Account → Domains → Settings → Webhook Signature Payload Verification. Also see this reference section in our FAQ for more insight.

Screenshot:

[forwardemail]

Also another update – we’ve added a dedicated page for our time to inbox (“TTI”) monitoring section. Before it was just in the footer of every page of our website – but this required the user to scroll down the page to see it. Now you can simply go to “Time to Inbox” link under Developers section or bookmark https://forwardemail.net/tti.

[brivacy]

I am using the service.
The only thing i think is missing a application if possible a application would be nice to have and i really don’t know much but asking that do you have an security audit as most services does this through cure69.

[gnuguy]

I’m using it too, and it’s great. Keep it up, no complaints

[lepras]

@brivacy

a application would be nice to have

@forwardemail does the site has PWA and is the site has nice mobile UI?

[rollsicecream]

@brivacy

cure69

cure69? Never heard of that. You surely meant Cure53.

[anon35626300]

Also, what are these comparisons.

Fastmail vs mailbox.org Comparison (2024)

Uploading private key is a security issue? And Mailbox.org has WKD

[brivacy]

Another point that someone has risen @forwardemail can clarify if it is a bug or something else.






Which website is showing that unlimited domain with free account but this not there if you want to use. Or avail. I never saw that.
And another question will be the existing one

@brivacy

do you have an security audit as most services does this through cure69.

We know money is required but the words used in the website is kindly contradicts with other part.
If that is a bug in website or design that can be solved but if not kindly clarify.

[forwardemail]

@brivacy

do you have an security audit as most services does this through cure69.

It is planned for later this year. See our list of security audit companies we’re plan to use at https://forwardemail.net/blog/docs/best-security-audit-companies.

@brivacy

Another point that someone has risen @forwardemail can clarify if it is a bug or something else.

If you’re on the free plan, it’s all DNS-based. You can add as many aliases as you want in DNS records as per our FAQ guide at https://forwardemail.net/en/faq#how-do-i-get-started-and-set-up-email-forwarding. See options A through G in that section. We’ll make that pop-up message clearer.

[forwardemail]

@anon35626300

Uploading private key is a security issue? And Mailbox.org has WKD

Thanks – is there anywhere publicly though that they claim to provide WKD support?

We searched and found https://wiki.gnupg.org/WKD#:~:text=claims%20to%20offer%20web%20key%20directory%20lookup so we’ve updated our website to show that they have WKD support – however, it’s not clear if they actually do since it’s not anywhere on their website nor does not seem like their SMTP outbound mail uses WKD.

If you refresh the page at https://forwardemail.net/en/blog/fastmail-vs-mailbox-org-email-service-comparison#:~:text=GnuPG.org%20states%20that%20it%20is%20claimed%20they%20offer%20WKD%2C%20but%20it%20is%20not%20advertised%20on%20their%20website%20currently you will see it’s been fixed as per https://github.com/forwardemail/forwardemail.net/commit/2f590b8b4f6b8acaa211e34196f48f18d7f77e1a.

[forwardemail]

@anon35626300

Uploading private key is a security issue?

Yes, that means then the provider itself can read your emails. They aren’t open-source either, nor is Proton Mail, so you have no idea what’s going on in the back-end (or at least an assumption of what could be going on).

Decryption of emails that are encrypted with a public key should always be done client-side. That’s the whole purpose of encrypting in the first place; so nobody else can read your mail. See https://forwardemail.net/en/faq#do-you-support-openpgpmime-end-to-end-encryption-e2ee-and-web-key-directory-wkd for a complete list of every platform and the associated plugins that can be used client-side.

[jonah (Jonah Aragon)]

To be fair, encrypting incoming emails on Mailbox.org only requires the public key: Your encrypted mailbox | Knowledge Base

The article you link to where they talk about uploading your private key is only for encrypting outgoing emails in their webmail client.

[forwardemail]

@brivacy

or design that can be solved

This is now fixed from design perspective. We now inform the user much clearer for that one button “Add Alias” if you’re on the free plan.

Before:

After:

[forwardemail]

Thanks @jonah, we’ve updated mailbox[dot]org on our website comparison page:

[forwardemail]

@lepras

@forwardemail does the site has PWA and is the site has nice mobile UI?

Yes, try it out on any screen size/device at https://forwardemail.net.

We plan to add webmail support first and then cross compile it across desktop and mobile. In the interim we have an Apps dropdown on our website which highlights our recommended mail clients to use:

[brivacy]

That is nice

[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.