Forward Email (email provider)

[brivacy]

Have anyone looked into the email forward service like simple login

Free Email Forwarding for Custom Domains

100% opensource

Forward Email - Open-source & Privacy-focused Email Service (2023)

[anon30510143]

We’ve already got a section on the site:

Encrypted Private Email Recommendations - Privacy Guides

[jonah (Jonah Aragon)]

I think he’s referring to this service specifically, renamed topic and moved to Tool Suggestions.

[ph00lt0 (Mare Polaris)]

Does not support GPG as of yet. Not sure what would be the advantage of this tool. I feel like this is a saturated market.

[brivacy]

But it is good.

[rollsicecream]

update!: Add Forward Email to email service providers

[forwardemail]

Thank you @rollsicecream for sharing our PR

We are the official team behind Forward Email.

We are sharing a few highlights below about our service:

• Unlike Proton Mail, Skiff, and Tuta we are actually 100% open-source on GitHub.
• We support ~550,000+ custom domain names using our MX service (this is way more than Proton Mail and Fastmail).
• Used by some notable organizations including:
  • Netflix
  • The Linux Foundation
  • The PHP Foundation
  • Fox News Radio
  • Disney Ad Sales
  • jQuery
  • LineageOS
  • The University of Maryland
  • The University of Washington
  • Tufts University
  • Swarthmore College
  • Government of South Australia
  • Government of Dominican Republic
  • RCD Hotels
  • International Correspondence Chess Federation
  • John Graham-Cumming (Cloudflare)
  • Isaac Z. Schlueter (npm)
  • David Heinemeier Hansson (Ruby on Rails)
• You’ll see in our PR that we already support OpenPGP and WKD.* We are planning to release calendar, contacts, and newsletter support in early 2024.
• You don’t need a bridge or need to use proprietary apps to use us, you can simply use Thunderbird, Apple Mail, Outlook, or Gmail (we support standard SMTP, POP3, IMAP, API, etc). We also do not rewrite your messages like Proton Mail does.
• Our website is translated to 25 languages (even our API, SMTP, POP3, and IMAP error messages are translated to your locale thanks to our work with @ladjs/i18n and mandarin (npm packages). No other service comes close to us in terms of internationalization support.

Some questions we receive frequently are listed below, and we’re happy to answer more.

P.S. We’d love to be included in the Privacy Guides list and have already submitted a PR adhering to your existing code practices – happy to make changes as requested. We’re also available at support@forwardemail.net and we have a Matrix Chat channel #forwardemail:matrix.org.

Do you have any reviews online anywhere?

Yes, we have a list of reviews on Trust Pilot at https://www.trustpilot.com/review/forwardemail.net.

How can you claim to not increase prices?

We haven’t since 2017 and don’t plan to. We abide by a set of principles (see link below to the SQLite article which includes them in a section titled Principles); which keeps us in tune with our product and customer base. We reached the limit for links to be posted in a first-timer here on PG so we referenced the section, but it’s available at the link below.

Do you have a status page?

Yes, our status page is linked in the Resources dropdown of our website, on the footer of every page, and our website also updates in real-time of any errors (and automatically presents a notification if necessary of any issues). We also have a TTI (time to inbox) monitoring feature that is public, it’s on the footer of every page of our website and shows response times from Gmail, Outlook/Hotmail, and Apple iCloud. An example screenshot is below from the present time (it updates every 5 min):

How does your encrypted SQLite database feature work, and why SQLite?

We have an entire article dedicated to this at https://forwardemail.net/blog/docs/best-quantum-safe-encrypted-email-service.

Unlike every other email provider, we use individually encrypted SQLite mailboxes with ChaCha20-Poly1305 encryption (using your strong passphrase, which only you have; you can audit our source to see that we do not store this anywhere and it’s only presented client-side when rendered in-memory). Other email providers use shared relational databases to store your emails, and most of them that use MongoDB and PostgreSQL have LUKS encryption, but NOT encryption at rest (of the actual database). SQLite encryption allows us to have both LUKS encryption AND the actual database encrypted itself. Even if a bad actor got access to the block storage device with yourmailbox.sqlite they still couldn’t open it. If a bad actor has access to the shared relational database of any other email service provider, they have full access to your mailbox.

Do you have a FAQ section?

Yes, see our website FAQ section (note if you hit CMD+F or CTRL+F it will expand everything so you can easily search). We haven’t yet added something like Algolia or TypeSense yet but plan to do so in a privacy-focused way.

[forwardemail]

Also, can we edit this title? From Forward Email (email aliasing service) to Forward Email (encrypted IMAP/POP3/SMTP/API service) or something? Having “email aliasing service” makes it seem like we only support email forwarding or aliasing, but we actually support everything.

[forwardemail]

We now support PGP and WKD, see the footer of our website with our PGP and the info icon link to the FAQ section regarding PGP and WKD support.

Edit: Supported as of December 2023.

[rollsicecream]

You’re right. Though @ph00lt0 has made this comment in July of the last year, so it’s normal that he said that.

[ph00lt0 (Mare Polaris)]

Yes seems you now do, but please note my comment was from about 6 months ago.

[forwardemail]

Yes sorry, forgot the word “now” Looks like I already included the word “now”, mainly wanted to update you!

[ph00lt0 (Mare Polaris)]

@forwardemail did you guys get a public audit yet? I couldn’t find it so far.

I am not entirely sure about any criteria we might miss for this. But I think we should follow the same criteria as for other mail products: Encrypted Private Email Recommendations - Privacy Guides

Others have this:

• addy.io passes independent security audit - addy.io
• SimpleLogin passes an independent security audit

Also should you want to make it easy for everyone maybe you could go through the requirements also and tell us if you notice any shortcomings on our or your ends. It is quite possible that some things aren’t applicable to a forwarding service. I’ll go though the list myself later.

[forwardemail]

Hi @ph00lt0 – just wanted to make sure you knew we’re not just an email forwarding service; we’re a complete email service (IMAP/POP3/SMTP/API). Early in 2024 we’re adding calendar, contacts, and newsletter support (most likely within the next 2 weeks we’ll have public availability).

---

RE: Audit: Correct, we don’t have an audit yet (by a third party), but we’ve already reached out to Cure53 and Assured, and that’s planned for early 2024 as well. Unlike any other provider, anyone could audit our source code (the complete backend as well). However we don’t have a third-party source that has access to our servers for auditing yet, but we plan to do so (as mentioned) to continue to build public trust.

---

RE: Requirements for Inclusion: Regarding the requirements outlined, we’ve answered everything in detail with response to each section (see below). We also provided some notes for each where relevant, and happy to answer further questions.

---

NOTE: This section “Technology” below is a response driven section derived from the current page of Privacy Guides minimum to qualify email section as of January 2, 2024 with respect to our service. We put a , a , or a where appropriate, and provided notes too. Let us know of any further questions.

Technology

Minimum to Qualify:

Encrypts email account data at rest with zero-access encryption.

Yes, we use encryption at rest, encryption in transit, support E2EE, and the actual individual SQLite mailbox databases themselves are encrypted using ChaCha20-Poly1305.

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

Yes, we support exporting to Mbox, EML, and we also support users downloading their entire SQLite encrypted database that we store on our side (instantly, at any time). Users can also make instant backups at any time, and see when their last backup was made. We also provide instructions for users as to how to open the SQLite guide and which open-source tools to use. Users can export and migrate at anytime using our migration guide in our FAQ.

Here’s a few screenshots showing this:

Allow users to use their own domain name. Custom domain names are important to users because it allows them to maintain their agency from the service, should it turn bad or be acquired by another company which doesn’t prioritize privacy.

Yes, users can add as many domains as they want (unlimited - we don’t charge per domain or per user like other providers).

Operates on owned infrastructure, i.e. not built upon third-party email service providers.

Yes, we operate on our own infrastructure, and we do not rely on any third parties. We don’t use Amazon SES, Mailgun, or any other provider. We use and dogfood our own service. Dig for example:

dig forwardemail.net mx
forwardemail.net.	3581	IN	MX	0 mx2.forwardemail.net.
forwardemail.net.	3581	IN	MX	0 mx1.forwardemail.net.

Best Case:

• Encrypts all account data (Contacts, Calendars, etc.) at rest with zero-access encryption.

• Integrated webmail E2EE/PGP encryption provided as a convenience.

• Support for WKD to allow improved discovery of public OpenPGP keys via HTTP. GnuPG users can get a key by typing: gpg --locate-key example_user@example.com

• Support for a temporary mailbox for external users. This is useful when you want to send an encrypted email, without sending an actual copy to your recipient. These emails usually have a limited lifespan and then are automatically deleted. They also don’t require the recipient to configure any cryptography like OpenPGP.

  NOTE: We consider this to be a security issue and anti-pattern and we do not support temporary mailboxes for recipients E2EE. We do provide plenty of documentation and plugin links for tools that can be used for OpenPGP in our FAQ.

• Availability of the email provider’s services via an onion service.

• Subaddressing support.

  NOTE: Yes, we support this, e.g. similar to Gmail, you can do you+filter@yourdomain.com. We also support regular expressions and webhooks, and you can even put in an IP address or domain name as a recipient to forward everything across.

• Catch-all or alias functionality for those who own their own domains.

• Use of standard email access protocols such as IMAP, SMTP or JMAP. Standard access protocols ensure customers can easily download all of their email, should they want to switch to another provider.

Privacy

Minimum to Qualify:

• Protect sender’s IP address. Filter it from showing in the Received header field.
• Don’t require personally identifiable information (PII) besides a username and a password.
• Privacy policy that meets the requirements defined by the GDPR.

Best Case:

• Accepts anonymous payment options (cryptocurrency), cash, gift cards, etc.)

  NOTE: We previously accepted BitPay and tried Coinbase Commerce, but those providers had issues with reliability and developer support (from our in-depth experience) - and so we will eventually support crypto in a manner similar to the payment flow of Mullvad, a VPN provider. We do however support PayPal and Stripe (all payment methods). We plan to offer gift card vouchers on Amazon and elsewhere in 2024 for anonymity. Keep in mind that owning a domain name requires a purchase from a registrar, and most registrars do not accept crypto.

• Hosted in a jurisdiction with strong email privacy protection laws.

  NOTE: We do not store passwords for IMAP (and the databases themselves are individually encrypted, so we don’t have access to begin with. Despite having access to your-mailbox.sqlite we can’t open it – only you can, via in-memory SMTP/IMAP/POP3 access. Additionally for email forwarding, we operate entirely in-memory and do not store logs nor do we store emails to disk. We are hosted in the United States and operate from the United States.

Security

Minimum to Qualify:

• Protection of webmail with 2FA, such as TOTP.

  NOTE: We support passkeys, Webauthn, and 2FA via TOTP. We do not support SMS-based 2FA due to the potential attack vector of a man in the middle attack.

• Zero access encryption, builds on encryption at rest. The provider does not have the decryption keys to the data they hold. This prevents a rogue employee leaking data they have access to or remote adversary from releasing data they have stolen by gaining unauthorized access to the server.

• DNSSEC support.

• No TLS errors or vulnerabilities when being profiled by tools such as Hardenize, testssl.sh, or Qualys SSL Labs; this includes certificate related errors and weak DH parameters, such as those that led to Logjam.

  NOTE: See bottom of this reply where we have provided a section with links to the latest Hardenize and Qualsys SSL Labs test results (where we get A+ results ).

• A server suite preference (optional on TLSv1.3) for strong cipher suites which support forward secrecy and authenticated encryption.

• A valid MTA-STS policy.

  NOTE: We set ours to “enforce” mode so MTA-STS is always enforced. We also support MTA-STS for outbound SMTP and MX servers (we support it everywhere basically).

• Valid DANE records.

  NOTE: We await the support for Node.js to have TLSA record DNS lookup (see GitHub nodejs issue #39569), and then we can support DANE.

• Valid SPF and DKIM records.

• Have a proper DMARC record and policy or use ARC for authentication. If DMARC authentication is being used, the policy must be set to reject or quarantine.

  NOTE: We use DMARC, ARC, DKIM, SPF, MTA-STS, SRS, and more.

  NOTE: We have strict p=reject everywhere and we also instruct users how to set this up in addition to DKIM, MTA-STS, and SPF (see our FAQ).

• A server suite preference of TLS 1.2 or later and a plan for RFC8996

• SMTPS submission, assuming SMTP is used.

• Website security standards such as:

  • HTTP Strict Transport Security
  • Subresource if loading things from external domains.

• Must support viewing of Message headers, as it is a crucial forensic feature to determine if an email is a phishing attempt.

---

SSL Labs Test Results

Here is a link to our SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=forwardemail.net

---

Hardenize Test Results

Here is a link to our Hardenize test: https://www.hardenize.com/report/forwardemail.net/1704231279

---

DNS over HTTPS

We wanted to also mention that we use DNS over HTTPS everywhere using a package we made called Tangerine (instead of using the built-in Node.js DNS module, which uses c-ares under the hood). This allows us to use privacy-focused DNS servers, smart DNS rotation, and DoH across our entire application stack (with support for caching and 1:1 accuracy globally around the world with our service). See the “Tangerine” repo on our GitHub.

[anon30398290]

Sorry for tagging you, @forwardemail.

You advertise as being a complete email service provider. Ok. But unless I got your registration process wrong, the user needs to provide an existing email to use it. Can you explain that?

Thanks in advance. I really liked the design of the privacy policy by the way, pretty simple

[forwardemail]

Hi there @banana1993 - thanks for your question, happy to answer.

You can sign in with Apple (privacy masked address) or use any other service, and then change your email address after. We don’t actually enforce email verification codes for signup, only a Cloudflare Turnstile captcha (it’s a captcha alternative that’s easier and way less annoying than having to put together a puzzle, or click on some weird AI-generated image like hCaptcha and reCaptcha ask you to; which every other provider seems to use).

We mainly support custom domains, but we also have a few vanity / global domains available for paying customers (e.g. you@hideaddress.net, you@secret.fyi, you@hash.fyi, and you@mailsire.com). We are adding more and also going to allow users to use these for registration (and also use them for SMTP/IMAP/POP3 as well).

[ph00lt0 (Mare Polaris)]

Damn you work fast haha. Thanks for the detailed answers. This is super valuable. I indeed didn’t understand that you are a full on email provider. I should make a test account soon I guess

I do think not being audited is a problem as I believe we should enforce the high standards here. Glad to know your pick on reputable auditors though. Looking forward to see that report coming our way ;).

Without having verified the answers the only other left issue that needs to be addressed would be DANE. But I do also see some other DNS related configuration items that should be improved on the website:

• Email test: forwardemail.net (mail)
• Website test: www.forwardemail.net (website)

Amongst f.x. outdated cipher suits and TLS versions. This should be easy to fix. (You probably would get these recommendations in an audit too, so you can make a bit harder for them to find something :P)

Oh and feel free to ignore the % on these tests i linked above. Ipv6 is not a privacy or security concern.

[ph00lt0 (Mare Polaris)]

Hi @forwardemail noticed you introduced DANE, well done!

I probably will follow with more questions later, but something I happen to notice. In your DNS records for custom domains, you ask for an email address (I assume of the associated accounts). Wouldn’t this result in large amounts of spam messages as this DNS record can be indexed? I wonder why you chose to do it the way. Usually I see a secret string here for confirmation, but a hash would do the trick even. Is there any technical reason one would need to expose the user’s mail in the DNS records?

Free Email Forwarding for Google Domains

[forwardemail]

@ph00lt0 That is for the free plan; as we started as a free forwarding service in 2017. Our initial service (which is still widely used) was purely using DNS records; there was no database or sign-up required. If you are on a paid plan, then the record is encrypted with a hash. There’s a note about the differences on the Pricing and FAQ pages. In the future we’re going to make it so there are encrypted records by default, but we will still always have the free plan available because of it’s simplicity (you can set up email forwarding, regex, webhooks, and more from simply your domain registrar or DNS provider).

[ph00lt0 (Mare Polaris)]

I think this is a considerable downside. It basically defeats the anonymity of an alias service.