Feat: Add txt-record encryption

[zmcandee]

As an alternative to keeping the forwarding email addresses safe in the API database, provide a public key for encrypting the TXT records. Obviously this isn't perfectly secure but it will add a reasonable size hurdle for anyone looking to just collect easy addresses to SPAM and it removes the storage burden from your server. To protect your revenue stream you could rotate the key quarterly making it a hassle for large customers to re-encrypt all of there addresses and/or leave it as an undocumented feature.

How I would implement:

• Add a key pair to the config (and the previous key pair if you decide to rotate occasionally)
• Post the public key on the webpage or add an API endpoint that takes the address and returns the encrypted TXT record
• Add a new record identifier for encrypted forwarding addresses with a key identifier and optional comment so customers can differentiate between multiple records eg {recordPrefix}-enc=[comment]#<key_id>#<encrypted_entry>
• In getForwardingAddresses
  • strip off the comment
  • compare key_id to the current and previous key_ids
    • for current and previous keys decrypt and add to validRecords
    • for previous key send nag email to forwarding address
    • for older/invalid keys add the domain to the blocklist as a dormant user

[KartikSoneji]

I would be open to implementing this if @niftylettuce is open to merging the PR.

To protect your revenue stream you could rotate the key quarterly making it a hassle for large customers to re-encrypt all of there addresses

Or, limit the number of encrypted emails to ~10 or so.

[astrob0t]

The challenge that I see here is that the final text string for the end user would need to be encrypted string and not a hash. And hence if the user tries to encrypt a large amount of text, the final encrypted string would also be larger.
A typical encrypted string for a couple of emails can easily exceed 255 characters. But the DNS manager will not allow to enter a TXT record more than 255 characters as per RFC 1035 section 2.3.4.
The encrypted string would need to be broken up into 255 characters chunks and stored/retrieved .

[KartikSoneji]

Hmm, good point.
I see two potential solutions:

1. Concatenate all configuration records together, encrypt the whole thing, then split into 200 character lines.
   Additionally, that will allow switching to a more structured format like JSON if needed.
   Using JSON will make the parsing much simpler, and also allow the possibility for more complex rules.
   Each line will be in it's own sequential record like:

   forward-email-config-0=<~200 characters>
   forward-email-config-1=...
   forward-email-config-2=...
   

   Then, concatenate the records in order.
   Although changes will break everything until all DNS records are updated (might be another incentive to upgrade to a paid plan).

2. Encrypt each record separately, split into 200 character lines, and add both an identifier and a sequence number.

   forward-email-config-a-0=<~200 characters>
   forward-email-config-a-1=...
   forward-email-config-a-2=...
   
   forward-email-config-b-0=...
   forward-email-config-b-1=...
   

   The benefit of doing it this way is a new record can be added without modifying other records, but the downside is it might increase the number of txt records by as much as 2x.

[zmcandee]

That seems needlessly complicated. The trade off of encrypting your email address is that you accept the 120% character overhead and have one email per txt entry. We don't need unbreakable encryption so much as a little obfuscation to slow down the SPAM bots crawling the dns records.

Having more than one entry per txt or more than one txt per entry makes management way too much of a hassle. One email per line allows commenting and easy management.

Using a simple chacha20_poly1305 with a 12 byte nonce and 32 byte key yields sufficiently small b64 strings. This of course is symmetric encryption so we would need a asymmetric layer or an api that returns the encrypted string so the key remains secret. Additionally the nonce shouldn't be reused like it is in the examples.

Example:

Original: test:test@example.com
Comment: test3 <-- shouldn't match the email but allows identification of the encrypted string
Key Identifier: 213 <-- Year 2021 quarter 3
Nonce (b64): QB/YNhDaroQwIGNw

forward-email-enc=test3#213#QB/YNhDaroQwIGNwDNdM9Q1acIehCjn1Y5R3htKslexAmWVa0jCy2qwsume/+k2ppw==

ChaCha can provide authentication of the non-encrypted comment and key identifier such that only changing the comment changes the encrypted string.

Original: test:test@example.com
Comment: bills 3rd account
Key Identifier: 213 <-- Year 2021 quarter 3
Nonce (b64): QB/YNhDaroQwIGNw

forward-email-enc=bills 3rd account#213#QB/YNhDaroQwIGNwDNdM9Q1acIehCjn1Y5R3htKslexAsfy3IGNuhVHWKxEnaBRqaw==

Really long emails still fit, this is only 192 characters so there is still room to grow.

Original: test:superlonguselessemailaddresswithnumbers123144@andacrazylongdomainprobablyusedforspam.com
Comment: test4
Key Identifier: 213 <-- Year 2021 quarter 3
Nonce (b64): QB/YNhDaroQwIGNw

forward-email-enc=test4#213#QB/YNhDaroQwIGNwDNdM9Q1dYISwODDibJ5ymdLuk/BefvRENiqMrpc3YixbpmPODiwMfDg7wHSNpYcuz9FWvttY5lhg9v4ZIU3/NjtwiVpLIgN9LIG6RfucXQziHmmL++rfofAfdJbnWYi5xrVxon32bN7MpcY6Tw==

[KartikSoneji]

@zmcandee You're right!
That is what I get for not actually checking the overhead.
This seems like an excellent implementation.

[niftylettuce]

Just wanted to follow up here - tentatively planning to give everyone Enhanced Protection concept of this encrypted hash that correlates to our database (while still supporting legacy Free plan), and instead all paying users on Enhanced Protection will get SMTP support (total replacement for Gmail).

[hagai-helman]

This plan sounds amazing!

[NvrBst]

Just wanted to follow up here - tentatively planning to give everyone Enhanced Protection concept of this encrypted hash that correlates to our database (while still supporting legacy Free plan), and instead all paying users on Enhanced Protection will get SMTP support (total replacement for Gmail).

This would be amazing. Would look forward to this, as the service, in general, promotes privacy. Would be nice to have the encryption email to protect from spam for free, and offer other services to the paid users.
Any idea on a timeline for this?

[im-machakata]

Well it's been more than a year now since this issue was created. If something isn't done soon, we'll be back to square one.
This site is already tracking (us) all websites using this service and sooner or later, who or where the email's being forwarded to.

[titanism]

We are adding this support in the near future, it is still planned, however we are working on SMTP and IMAP support right now 😄

[mstaal]

Is there any news about this? I hoped “near future” would be in less than 3 months. Thanks for your efforts. :-)

[mstaal]

@titanism : And what does IMAP support refer to? I know what IMAP is, but have not seen any reference on your website to you implementing IMAP, so I am curious to see how it will work.

[hackerb9]

If the amount of time it would take to implement this is preventing the roll-out, how about giving free users the option to obfuscate their email with ROT13? forward-email=rot13 cbfgznfgre@sbejneqrznvy.arg.

In the future, when there is more time, it can be replaced with an asymmetric algorithm. But for now, it at least makes the spammers jump through one more hoop.

[titanism]

We're very focused on getting SMTP ready for release right now, but we're commenting just to let you know we've seen this and will look at it again in our roadmap soon.

[falo2k]

What's "soon" in your roadmap, as this seems to have been "near future" or "soon" a few times. Currently shopping around for this sort of service where I'll likely be mixing some free and some paid domains due to differing requirements.

[zmcandee]

Read the room. No commits in over a year makes this abandonware. I think most people have moved on.

[titanism]

We're incredibly active @zmcandee and we are adding PGP support soon (and this TXT encryption concept as well for non-paying users). IMAP support will be released today. Please check commit history at https://github.com/forwardemail/forwardemail.net.

[titanism]

@zmcandee This repo is being merged with https://github.com/forwardemail/forwardemail.net FYI - please use that repo moving forwards, we will update this once we are ready.

[titanism]

Also in case it's not obvious - or if you haven't read https://forwardemail.net/about lately:

• We launched SMTP support in May
• We launched IMAP support for outbound mail in October
• We're launching IMAP support for inbound mail (so you can both receive mail with a mailbox and use an email client to access it – and also forward email elsewhere too as you already do)
• We'll add PGP support soon after
• The free email forwarding with DNS TXT records will still be around, the basic forward-email=user@example.com is what got us started and is still widely used today. We'll add an encrypted form soon for other users as this issue describes. Unfortunately this isn't highly demanded, so it has been pushed back quite a bit (IMAP support was definitely way more important, e.g. people want to use us as a 1:1 alternative to services like Gmail, Proton Mail, Fastmail, etc.
• Thank you for your patience and support 🙏

[titanism]

See https://forwardemail.net/encrypted-email 🚀

[titanism]

We now support IMAP! 🎉 Just check this checkbox when you create/edit an alias: