Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple AWS accounts #16

Open
roshanjonah opened this issue Sep 1, 2020 · 5 comments · May be fixed by #19
Open

Multiple AWS accounts #16

roshanjonah opened this issue Sep 1, 2020 · 5 comments · May be fixed by #19

Comments

@roshanjonah
Copy link

Great piece of software!

  1. We have multiple AWS accounts and was wondering if there was a way to tell the program which one to use based on the FROM addresses or simply just which account to send it through.

  2. Also is there a way to set throttle so it sticks to thresholds given by AWS?

  3. Is increase capacity equal to simply upgrading the server to higher specs or do we need to make any code changes to handle higher concurrent loads?

@blueimp
Copy link
Owner

blueimp commented Sep 6, 2020

Hi @roshanjonah,

  1. If you want to use different AWS account based on the FROM address, your best bet is to implement this logic before you sent it to aws-smtp-relay. The relay is specifically built to not have to define AWS accounts and access permissions, but to use AWS roles instead, see also https://github.com/blueimp/aws-smtp-relay#credentials

  2. There is no in-built throttling nor rate-limiting, but with a good use case, contributions are always welcome. :)

  3. For horizontal scaling, you could potentially make use of AWS Network Load Balancer, with multiple aws-smtp-relay containers behind it. Otherwise yes, you can scale vertically by increasing specs.

@cyraxx
Copy link

cyraxx commented Nov 11, 2020

I have a similar issue: The SES identity that I'm sending mails as is in a different AWS account. It is my understanding that for cross-account sending, the ARN of the identity needs to be passed to SES either via the SourceArn parameter in the API call or the X-SES-SOURCE-ARN email header.

Unfortunately the SMTP client I'm using does not support adding custom headers to the email so it seems to me that SourceArn support would have to be added to aws-smtp-relay. Do you have any advice or a different solution?

@blueimp
Copy link
Owner

blueimp commented Nov 14, 2020

Yes, providing the SourceArn parameter in the API call from aws-smtp-relay to the SES API would be the right approach in my opinion.

If we add it, we probably wanna add support for SourceArn, FromArn and ReturnPathArn:
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/sending-authorization-delegate-sender-tasks-email.html#sending-authorization-delegate-sender-tasks-api-sendrawemail

This capability would have to be added to the project as a configuration parameter, similar to the other options:
https://github.com/blueimp/aws-smtp-relay#options

@mmacaula
Copy link

mmacaula commented Jun 7, 2021

Not sure if it helps, but we were able to do cross account sending by setting the AWS_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. Obviously these are secret but it did get us what we needed

@blueimp
Copy link
Owner

blueimp commented Jun 15, 2021

@mmacaula Setting those secrets as environment variables somewhat defeats the purpose of this project:

SMTP server to relay emails via Amazon SES or Amazon Pinpoint using IAM roles.

If you are ok to use credentials to send emails, I would recommend you to make use of the official SMTP APIs instead:

clark42 added a commit to akirosit/aws-smtp-relay that referenced this issue Nov 17, 2021
clark42 added a commit to akirosit/aws-smtp-relay that referenced this issue Nov 17, 2021
clark42 added a commit to akirosit/aws-smtp-relay that referenced this issue Nov 17, 2021
@clark42 clark42 linked a pull request Nov 17, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants