Define the intention of `sender_display_name` notification config

[doshitan]

Context

Notifications have a per-service-env configuration for a "display name" on emails. This is used by the identity provider module (by default at least, projects could override the setting on a per-service basis if the identity provider is desired to show a different name).

Some goals:

• It's not entirely clear what the intention/scope of this variable is. That should be defined.
• Does it make sense to have a singular "display name" for a service in the first place?

Options

A) sender_display_name overrides

If an application infra config has sender_display_name set, the service (and any connected resources) should be assumed to just always use it.

Possibly add restrictions on the IAM policy around this.

In a highly-regulated environment this might be desirable.

B) sender_display_name is a default

Applications are expected to override/use other display names as desired.

Update default service env vars to include the "sender email" in addition to the existing full "from email":

template-infra/infra/{{app_name}}/service/notifications.tf

Line 11 in 5afca08

AWS_SES_FROM_EMAIL = module.notifications[0].from_email

Open questions:

• Should the identity provider use a different default?

C) Remove sender_display_name

Determine that in typical use cases an application will want multiple display names for different contexts and a single variable does not make sense.

Possibly provide a config item in app-config/env-config/identity_provider.tf or other default for account emails.

Success criteria

• Update comments and docs to represent decision
• Application templates provide a utility function implementing default logic
  • For rails maybe utilize https://api.rubyonrails.org/classes/ActionMailer/Base.html#method-c-email_address_with_name

[lorenyu]

@doshitan I don't have a strong opinion about this at the moment. Maybe we just see how projects end up using this? I'm open to (C) cleaning it up / removing it to reduce the number of stuff in the infra template, but feels lower priority, and we'd need to replace it with the new config in identity_provider.tf as you suggested.

[doshitan]

@lorenyu it's already coming up, like see in OSCER there was a request for emails to show a certain display name
(further updated later ) that you would not want to use for account emails.

[lorenyu]

@doshitan
I see thanks. Do you have a recommendation? I don't have a strong opinion of this. It sounds like you're recommending:

• Getting rid of sender_display_name from notifications config and module, letting each use case handle their own display sending
• Keeping the AWS_SES_FROM_EMAIL env var
• Adding a default sender_display_name for identity provider config / module to handle account emails use case