Feat: Add txt-record encryption

zmcandee commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Hmm, good point. I see two potential solutions:

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).
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 commented 2 years ago

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 commented 2 years ago

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

niftylettuce commented 2 years ago

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 commented 2 years ago

This plan sounds amazing!

NvrBst commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

mstaal commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 10 months ago

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 commented 10 months ago

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

titanism commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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

titanism commented 9 months ago

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

mstaal commented 2 months ago

Could you add this issue in https://github.com/forwardemail/forwardemail.net to keep track of the progress on this?

mstaal commented 2 months ago

I have added https://github.com/forwardemail/forwardemail.net/issues/254 in https://github.com/forwardemail/forwardemail.net to keep track of the issue in the actively maintained repo.

titanism commented 1 month ago

Expect an update soon!

titanism commented 1 month ago

Hi folks :wave: We now support encryption on TXT records for free! 🎉 🚀

As of today we now allow you to encrypt records even on the free plan at no cost. Privacy should not be a feature, it should be inherently built-in to all aspects of a product. As highly requested in a Privacy Guides discussion and on our GitHub issues #254 and #251, we've added this!

Visit https://forwardemail.net/encrypt or click the "Encrypt Plaintext TXT Record" link in the nav/footer of any page on our site. We've also mentioned this tool in our FAQ as well.

Behind the scenes we encrypt your input with ChaCha20-Poly1305 and then convert it to a Base64 string.

Thank you for your patience, we've been hard at work! Our IMAP/POP3/CalDAV service is snappy now – and we're going to integrate iOS Mailbox IMAP Push support sometime soon too.

Here is a screenshot of the encrypt plaintext TXT page in action:

forwardemail / free-email-forwarding

Feat: Add txt-record encryption #251