Forward Email (email provider)

Are you guys profitable? I’ve been bitten three times by email services shutting down on me and I’d rather not jump onto you guys and have it be four.

PS. I can’t see how much storage is available on the free tier anywhere on this page. That should probably be on there

Edit: It seems you only get the forwarding service in the free tier. Is that correct?

@Ganther Yes we are profitable; we are focused on building a sustainable business, abiding by our principles at https://forwardemail.net/blog/docs/best-quantum-safe-encrypted-email-service#principles. The free tier is for free email forwarding only, there is no storage for free users (yet at least). Paid users ($3/mo) get 10 GB of encrypted SQLite storage for email (with built-in support for calendar/contacts coming soon at no extra cost). Additional storage is currently +$3/mo per 10 GB.

Update: Note that unlike other email providers, we use an attachment de-duplication technique. This saves you considerable amount of storage (since attachments are only stored once, and hashed/fingerprinted in your SQLite encrypted database). We use a MIME tree to re-build the email structure when IMAP/POP3 commands are called to list/fetch messages, and use the magic hash detected from attachments. For more insight see https://github.com/nodemailer/wildduck/blob/8b7f6c923ef89fd4391862f3719810b56008ca22/docs/in-depth/attachment-deduplication.md and implementation at https://github.com/search?q=repo%3Aforwardemail%2Fforwardemail.net%20attachment&type=code.

1 Like

@ph00lt0 Understood, we will add PGP support for free plan and launch a tool online to convert existing records, just need a moment. We are wrapping up a response to your other comment.

3 Likes

@ph00lt0 all good now! :white_check_mark: :100: :tada:

Also we posted a comparison (with tests against other PG recommended email providers) at https://discuss.privacyguides.net/t/email-provider-security-tests/16033.

A few notes:

We’re looking into the PGP encryption for forward-email TXT records, but this shouldn’t be an issue for including us, as we are much more than just email aliases, and have met all the other criteria documented and exceed tests when compared to other providers currently listed by PG.

Let us know of anything else or other concerns you have? Thank you :pray: :heart:

5 Likes

Nice work haha, just note we do not care for ipv6 really. But this is good progress on your end :slight_smile:

Are there any blockers that are preventing https://github.com/privacyguides/privacyguides.org/pull/2358 from being merged? What are the next steps? Who are the approver(s) and what concerns/questions/blockers do they have? We have definitely met the criteria!

  • Well, for now you still do not meet minimal requirement of having an audit. We’ll have to wait for that for sure.
  • Probably, some core team members will want to test your service.

I warned you before, this can take a while :wink:

I am also still wondering myself how this will fit on the website, the way you offer your service is quite different from the other email providers as it requires use of third party clients etc. Nothing wrong with that, but something we need to make clear in some way. It’s undeniable that for the average internet user, it is much more seamless to get an account at Skiff or Proton. I mean this in the nicest possible way, it just is quite a different approach.

Edit:
got to add to this that I really admire your speed of improving your service. It’s surely a good thing.

2 Likes

Maybe the missing discussion at Project Showcase

But because you don’t have the developer badge, you cannot post there. Also, to be clear, I’m not a team member of PrivacyGuides, so I cannot grant you the badge.

This wasn’t opened by the developer, tho. I directed them here to an existing discussion. Probably good they are answering concerns here IMO. Conflict of interest was obviously super clear. Anyway if you want me to change the category of this thread, DM me. Better to keep it sane and not spread this among different threads.

1 Like

Hi @ph00lt0, I think that this should not be a requirement (at least for now), and here is why:

  1. Having an audit is not listed as required in the email provider listed criteria at https://www.privacyguides.org/en/email/#criteria.
  2. Tuta is not listed with an audit on the PG email provider page. They state at https://www.reddit.com/r/tutanota/comments/101lf4a/independent_security_audit/ however the link doesn’t even provide a PDF nor write-up https://tuta.com/support/#certification.
  3. All of the existing audits did not share transparency nor insight with what is actually running on the servers. There are no claims such as “we checked the code and we didn’t see any bad behavior”.
  4. We are the only 100% open source provider. Literally the only one. We are the only service that lets you independently audit the source code of what’s actually happening with your email, where it is stored, etc. Others claim to be open source, but in reality the most sensitive part (the backend) is closed source. Many of them have said they would open source, but they still haven’t. We’ve been completely transparent since 2017 and everything has been published on GitHub.
2 Likes

Your arguments are valid and I do not challenge them.

However, Tuta has been known in the field for a while and has that advantage to be known to be reputable. I get that this might sound unfair to you, but personally I would vote to await the audit, especially given this was already scheduled.

Can you also confirm the last requirements on the website? From Trust and onwards, you did not provide answers yet.

RE: Tuta - they are only 6 years prior, and also most importantly they still do not support IMAP and POP3. We already support everything and already have more domains using us than Proton Mail, Tuta, Mailgun, Fastmail, and Skiff. Here is a screenshot for proof from Nov 17, 2023 (via Security Trails):

RE: Other sections - we missed that at first, thank you! See below!

Trust

Minimum to Qualify / Best Case

  • :white_check_mark: Public-facing leadership or ownership.

    NOTE: Independently owned and operated, under Forward Email LLC (registered in Delaware, USA). If in the future we receive requests for information, we would most likely provide transparency reports, albeit may be restricted under some circumstances for a duration of time before disclosure is permitted under US law. Keep in mind we don’t store logs and don’t have access to email to begin with.

Marketing

Minimum to Qualify / Best Case

  • :white_check_mark: We do not use any analytics services nor third parties.
  • :white_check_mark: We claim to be quantum safe/resistant (as ChaCha20-Poly1305 is generally considered to be quantum-safe), but not totally unbreakable. We do not use the word unbreakable or uncrackable anywhere.
  • :white_check_mark: Our documentation for everything (e.g. SMTP/IMAP/POP3/WKD/OpenPGP/API/SPF/DKIM/DMARC/MTA-STS/ARC/SRS) is extensive at Frequently Asked Questions About Email (and translated into 25+ languages). We even document how our entire system works, how we store your email, and more (technical detail too, not just marketing nonsense).
2 Likes

Forward Email looks really promising. In my view, requiring to use a third-party client might be a good thing for the development, since the developers won’t need to diverge resources to developing the app.

Does Forward Email support zero-knowledge encryption for existing emails, like imported ones? I knew for incoming emails, one can set up open PGP to encrypt them. AKAIK Mailbox doesn’t support encrypting existing emails, but Tuta, Skiff, and Proton do.

Sure thing however they have also set different goals:
“P.S. Don’t worry – we’re coming out with our own desktop, mobile, and web apps soon!” Is written on the website

@ph00lt0 @iamthesenate yes as mentioned on our website, we have plans to release 100% open-source email clients for iOS, Android, and Desktop. These clients will NOT require a Forward Email account, but instead will be an open-source replacement and alternative to email clients such as Thunderbird. This means you can use them for your own mail servers or existing providers without even having a FE account, and they will also have zero telemetry. Basically we’re building our everything we wanted from scratch, dogfooding it, and open-sourcing it.

1 Like

@iamthesenate Yes, you can set up an OpenPGP key on your account on a per-alias basis, and we already support OpenPGP/WKD.

Screenshot:

We have a complete guide for OpenPGP/WKD/E2EE available in our FAQ section at https://forwardemail.net/faq#do-you-support-openpgpmime-end-to-end-encryption-e2ee-and-web-key-directory-wkd.

Screenshot:

1 Like

Active Domain Names By Provider

Provider Domain Names MX Record
Forward Email 418,477 mx1.forwardemail.net
Proton Mail 253,977 mail.protonmail.ch
Fastmail 168,433 in1-smtp.messagingengine.com
Mailbox 38,659 mxext1.mailbox.org
Tuta 18,781 mail.tutanota.de
Skiff 7,504 inbound-smtp.skiff.com

As you can see, we are the leading custom domain email provider (other than Gmail and Outlook of course) vs. any similar competitor. You can see we are trusted at a large scale already.

Source: Security Trails reverse MX search as of January 5, 2024.

1 Like

Interesting, never how I had never heard about yoh before. Still happy to do so now. I’ll do some limited testing of your service in coming weeks. Hopefully some other users can report in here too.

Can you share something on userbase aswell? Not that it matters much just curious.

It seems like an incredible investment. Email isn’t easy, I am bit confused on how this is profitable for you at all. Surely will be following this.

We are a small team that’s dedicated and knows how to ship code.

Years and years of open-source efforts:

https://github.com/forwardemail/forwardemail.net/blob/51319040045fd8ae05ed6dc6533a1977afb0d493/package.json#L24

3 Likes