[SOLVED] Password Recovery Email to specified email address

Hi Appwrite team, we are thinking about further email encryption so our Users don't have their clear email anywhere on our server. We encrypt them locally and format them as encrypted@example.com as valid email addresses. This way, Appwrite does not save the actual address but we still get the benefit of Using the Appwrite User-ID for storage and database purposes. I didn't look at the documentation enough and missed the part where Appwrite uses the email parameter in createRecovery to identify the user and send the email to the saved address instead of the passed address.

So finally my question: Is it possible to specify a different address to send the email to? We would handle the encryption locally, we just need to send an email to an actual address insted of our made-up encrypted one. And if not, do you think it might make its way into an upcoming release as an optinal parameter?

Thanks a lot 🙂

TL;DR

The user wants to send password recovery emails to a specified email address instead of the saved address in Appwrite. They suggest encrypting email addresses locally and using them as valid email addresses. The suggested solution is to create an Appwrite function triggered by `users.recovery.create` event, decrypt the email address in the function, and send the actual email using an SMTP of choice. It is mentioned that the real solution would be to customize Appwrite's Docker image. The user is unsure about how to handle sending the email and asks for guidance. The solution involves triggering the function manually when password recovery is needed. There is a suggestion to open

Not sure why doing this if anyways you will have their emails in your Appwrite instance in order to authenticate them 🤔

For now by default emails are the main identity identificator

I won't have their emails, just an encrypted version (encrypted@example.com) in my Appwrite instance. Maybe it's overkill to encrypt them as well but it adds another layer of security so their email addresses won't get matched with the sensitive data we store in Storage.

We store the encryption key in the .env file so the mail addresses get encoded and decoded locally and our Appwrite instance does not eed to know the clrear email address.

Not sure, but to send an email, I think you will always need to have a decrypted version

Which is why I am suggesting to add the address you want to send the actual email to as an optional parameter. that way we could store only encrypted addresses and i n the case of a recovery password request we could identify the user by their encrypted email (encrypted@example.com) but send the email to the additional parameter (e.g. john@gmail.com).

We just don't want to store the decrypted email addresses on our Appwrite instance, if possible (which it is not currently I believe)!

If unspecified, this additional parameter shouldn't change anything from the current procedure.

Does that make sense to you or am I explaining horribly?😅

@D5 it's probably best to open a feature issue for this over on https://github.com/appwrite/appwrite/issues, right?

Not sure, I think with functions or server sided you could achieve this

Okay thanks! I haven't used functions yet. Would be cool to be able to do this! Could you please check my thoughts about this before I leave you alone?

create function and select users.recovery.create as trigger event
pass secret key in .env file
write e.g. python code that handles the decryption

How would I then send the actual email?

Thanks for you time, maybe you could point me in the right direction with a link to something functions related? I still think adding the optional parameter to this makes sense, so I'll maybe open an issue anyways😅

Nope, trigger the function manually when recover password is needed

Alright, I still don't quite get how that would solve my problem. What would I have to call in the function so that it sends an email to a different address than that saved along my Appwrite user?

In the function you decrypt the email and send to the email the password recovery

But didn't you say that's not possible with the current Appwrite functionality? Would I have to build something myself to send the emails?

Because if I understand correctly, Appwrite uses the provided email to search for the user and sends the link containing secret etc. to the email address. But if I decrypt the email Appwrite can't find the user, because i never sent the clear email to my Appwrite instance.

What am I missing in your suggestion?

First you can track and 👍 this issue https://github.com/appwrite/appwrite/issues/2358 as this will provide a way for you to "inject" your logic.

Workarounds

Second, for now you can have some workarounds like this 👇:

Function

1.<:appwritehero:826863791131852810> Give any user random email address at your domain. 1Azdf3@yourdomain.com 2.<:functions:1108648038156746792> Create Appwrite function, make it to be trigger by any event you like to customize is email sending. for example users.*.recovery.*.create. 3.<:appwritemagic:946072213465993256> In the function you can now process the data and use and SMTP of your choice to send the email while using some of the event data.

Check about events here: https://appwrite.io/docs/events

Editing the container files.

But, the real solution as your use-case is very specific would be to customize Appwrite <:docker:740465484373295127> image being used in you self-hosted Appwrite. It's more complex but will provide you a solution for the long term.

What you'll need to do is to track the Appwrite's fetching the email address. Like in here in mails worker https://github.com/appwrite/appwrite/blob/master/app/workers/mails.php#L33

Then you can bind your file to mails worker. Check here for binding example with Appwrite: https://discord.com/channels/564160730845151244/1110920292685053972/1128718973370892318

You can also change your local Appwrite image by committing your image changes, check this: https://phoenixnap.com/kb/how-to-commit-changes-to-docker-image

Thank you and @D5 for the helpful and detailed responses! Makes sense, I will look into it. Probably functions for now and container editing later on.