Amazon SES new endpoint

ℹ️ Support
1

I have a working phplist configuration which uses amazon-ses plugin and delivers mail without any issue for the api endpoint:
Europe (Ireland) eu-west-1 email.eu-west-1.amazonaws.com

However when I try with new api endpoint, it always fails:
Asia Pacific (Mumbai) ap-south-1 email.ap-south-1.amazonaws.com

I get the following error: InvalidClientTokenId The security token included in the request is invalid.

All necessary things are done for ap-south-1 endpoint, such as domain and email verification, moved away from sandbox.

Tried with different access id and secret, in every case eu-west-1 is working and ap-south-1 fails.

Asia Pacific (Mumbai) API endpoint is newly available SES endpoint.

Anybody face similar problems and any known workarounds?

1 Like
2

@andrewcv I get the same error trying to send on two new regions using the same access key and secret key

https://email.eu-west-2.amazonaws.com/
and
https://email.ap-south-1.amazonaws.com/

but does work for the original region

https://email.us-east-1.amazonaws.com/

@danwaterloo Dan, do you know the steps to be able to send from a different region?

3

I believe your access key and secret key are only authorized for one region at a time. I would suggest to generate a new access key and secret key for the other regions…
I.e. I am authorized to send from us-west-1, but the keys to do that do not work for other regions. You need to setup new keys authorizations to send from other regions.

4

@danwaterloo thanks for the response. I have tried creating a new access key but sending fails for both of the “new” regions. From what I can see access keys are independent of regions.

image
image811×118 14.5 KB

Oddly, I also verified my domain with another region us-west-2 (Oregon) and sending works for that region with the same access key and secret key. Maybe my account is limited to the US regions but I cannot see that mentioned anywhere.

5

@andrewcv @danwaterloo I think that the problem is with the version of the AWS signature that the code uses. It uses version 2, and the new regions require version 4

https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html

6

Hi @duncanc, Thanks for figuring this out…

Dan

7

@andrewcv @danwaterloo There is a new release, 1.3.0, of the plugin that uses AWS signature version 4, instead of version 2. That works for me with the “new” regions as well as the old ones.

You can update the Amazon SES plugin on the Manage Plugins page but you also need to update Common Plugin as well to version 3.12.0. Or you can continue using your currently installed plugins if you want to.

There is an additional field on the Settings page for the region, e.g. ap-south-1.

8

@duncanc Had a new issue… the plugin settings are set to go usa-west in the database, but the test emails seem to bypass some of the settings, and use the defaults, which are:

'amazonses_region' => [
    'value' => 'us-east-1',
    'description' => 'SES region',
    'type' => 'text',
    'allowempty' => false,
    'category' => 'Amazon SES',
],
'amazonses_endpoint' => [
    'value' => 'https://email.us-east-1.amazonaws.com/',
    'description' => 'SES endpoint',
    'type' => 'text',
    'allowempty' => false,
    'category' => 'Amazon SES',

So the test emails are trying to go through amazon east, which doesn’t work because we’re authorized to go through the west, not the east.
the defaults are in the plugin’s AmazonSes.php file.

9

By the way, i just noticed that the database settings were updated to us-east-1 when I upgraded the plugin (to support the new curl commands). Previous to the update, it was set to us-west-2, which is where I am authenticated.

10

@danwaterloo Hi Dan

The region was a new field which defaults to us-east-1 but the endpoint should have not been changed by the plugin update. It looks like that gave you an inconsistent pair of fields. Are you able to confirm whether that is what seems to have happened?

11

Hi Duncan, yes, that seems to be what happened. Somehow the endpoint was automatically defined or re-defined when updating the plugin. It could be that I originally defined the endpoint in the config.php file, and one one of the more recent updates of the plugin it defined it in the database, which overpowered the config file?

12

@danwaterloo Hi Dan,

the plugin has only ever used the values entered on the Settings page that are stored in the database config table such as amazonses_endpoint etc.

Any values in the config.php file will have been for core phplist processing that also lets you send through the SES API, such as AWS_POSTURL.

The recent upgrade to the plugin should not have changed the amazonses_endpoint value, but it did introduce the amazonses_region, which as I commented earlier could be inconsistent with the endpoint.

13

Thanks Duncan. Once I changed the settings via the config webpage, everything worked as expected.