Every message sent uses a new credentials instance

[kichik]

Describe the bug

With the default configuration, every message sent via Rails triggers the creation of a whole new AWS SDK credentials object. When sending a lot of emails and using instance profile authentication, this may cause IMDS throttling for the entire instance.

Original bug report: aws/aws-sdk-ruby#3162 (comment)

Expected Behavior

With default configuration, I would expect safe behavior that doesn't (a) waste resources on calling IMDS constantly and (b) isn't prone to being throttled by IMDS.

Current Behavior

Rails calls dup on the mailer method before sending every message.

https://github.com/mikel/mail/blob/d1d65b370b109b98e673a934e8b70a0c1f58cc59/lib/mail/message.rb#L126

That duplicates a clean instance of Aws::ActionMailer::SES with its own clean instance of Aws::SES::Client, which doesn't have an initialized credentials object.

aws-actionmailer-ses-ruby/lib/aws/action_mailer/ses/mailer.rb

Lines 22 to 26 in c2b91df

	def initialize(settings = {})
	@settings = settings
	@client = Aws::SES::Client.new(settings)
	@client.config.user_agent_frameworks << 'aws-actionmailer-ses'
	end

When the email is sent, the credentials are finally loaded, saved into the client instance, but immediately disposed because the next message will just dup Aws::ActionMailer::SES again from a clean state.

Reproduction Steps

Send a few emails from Rails console with default configuration. Use it on an EC2 instance with SES permissions. I edited the source code for InstanceProfileCredentials to print a message in initialize. You might have a better way of debugging it. Either way you should notice it prints that message for every single email sent.

Possible Solution

The SES client can become a class object instead of an instance object (sorry not sure if those are the right Ruby terms but hopefully you get what I mean). Another solution would be initializing the credentials in initialize by accessing the internal credentials object from the client and calling sts:GetCallerIdentity.

Additional Information/Context

No response

Gem name ('aws-sdk', 'aws-sdk-resources' or service gems like 'aws-sdk-s3') and its version

aws-actionmailer-ses

Environment details (Version of Ruby, OS environment)

Amazon Linux 2023 aarch64

[mullermp]

Thanks for moving this over. I agree that this can be a sharp edge and I can take a deeper look, but this seems to be the pattern Rails wants for action mailer adapters. The mailer method that dup is called on I think is a symbol and not an instance. The railtie adds the delivery methods which is defined in rails here.

I think for sure we can add a README entry for this. Global config can be used as you've done, but I think the expected config for Rails is:

Rails.application.configure do |config|
  ...
  config.action_mailer.delivery_method = :ses
  config.action_mailer.ses_settings = { credentials: Aws::InstanceProfileCredentials.new() }
  ...
end

and you can use any delivery method and settings here - I believe rails will create <delivery_method>_settings methods automatically.

[kichik]

Maybe the default config.action_mailer.ses_setting object can be that chain credentials default object? That would keep it the Rails way but also still avoid the footgun.

[mullermp]

Hmm. That is an interesting idea. Let me think about that. The credential provider chain is not a public API - we could also consider a full client override (default settings to have SES::Client.new).

[matt-domsch-sp]

If there were a way to pass a pre-made client into initialize(), then the (singleton) client becomes the caller's responsibility. I'd prefer my code not having to know it needs an Aws::InstanceProfilesCredential object, when the Aws::SESv2::Client code already has the hierarchy for determining if and how it should retrieve credentials.