Smtp Deployment step

[agriffard]

Fixes #5493

Import works but the password is encrypted based on the data protection key so it won't work on another tenant.

[deanmarcussen]

You could remove the password field from the export, as is done with the Id property in the contents step

Then it's no longer part of the schema, so is more known that it isn't possible to export/import it.

objectData.Remove(nameof(ContentItem.Id));

[agriffard]

Yes, but people will not understand that the password is not exported/imported.

[sebastienros]

I think we should have the encrypted settings (any of them) exported as a different step. This way you can decide if you want to export them as you might know that it will work or not (for instance sharing the protection keys between a staging and production, either on the FS, blob storage, database, ...).

Another option would be to decrypt them, send them unencrypted, then re-encrypt locally. This could be an option of the specific step for encrypted data, to decrypt it or not.

In the end we would have these options:

• deploy without secrets
• deploy the secrets encrypted using the custom secret step. The DP keys need to match on both ends, and using a File export is safe. Deploying a secret is opt-in.
• deploy the secrets unencrypted (if the option of the setting step is set) and File export should be disabled, or only accessible with specific permissions. But the devs take the responsibility to do that.

[sebastienros]

TODO to merge this PR: Remove the encrypted secrets from the payload.
On a separate PR we will create a custom step to export these encrypted values.
On another PR we will add an option to export these values unencrypted.

[JoshLefebvre]

Any further progress on this PR? This is an important one for me as I would really like to automate the process of setting up Smtp settings for new tenants

[agriffard]

Replaced by #6421