Add Support for SES V2

[akefirad]

Type: Feature

Is your feature request related to a problem? Please describe.
There's a new SES API, version 2. It would be nice to have this support as well.

Happy to help with a PR.

[maciejwalkowiak]

Can you describe in more details what functionality do you have in mind?

[akefirad]

So there's a new SDK for SES API V2 which provides more functionalities (including more policy statement conditions). Here's a some examples from AWS. Does that help?

[maciejwalkowiak]

I'm still not sure how this will affect the functionality offered by Spring Cloud AWS, or is it more about autoconfiguring the client? Feel free to drop a PR perhaps it gets more clear then

[akefirad]

Imagine if I want to use version 2 (because of some specific feature available only in version 2) of SES client, I cannot use AWSpring SES module since this module is written on top of SES version 1 and won't work with version 2. Does that make sense? As for the PR, the question before attempting is how we want to support it? Duplicate the whole library? Or introduce an interface that abstract away the details of SES clients, V1 and V2. Or any other solution.

[maciejwalkowiak]

I see this making sense if we just drop SES v1 and replace it with SES v2. Are there any drawbacks of using SES v2?

[akefirad]

Hm good point. Since this is a major release, it wouldn't break existing code. The only thing I'm not sure is what you asked, is there anything we miss if we go with version2 altogether. I have to check. Would be nice if you have any connection with anyone on AWS side. (I'll try to dig into the docs anyway.)

[maciejwalkowiak]

@msailes are you aware of any drawbacks of switching to SES v2 or is it just a natural step and v1 should be considered as deprecated?

[akefirad]

As far as I can tell, they are not compatible, neither backward nor forward. Unless we hear something different from Mark, my guess is we have to support both. In the mean time, what do you think about having three interfaces and one implementation for each version:

public interface SendMessageResult {
  String getMessageId();
}

public interface AwsSesSimpleMessageSender {
  SendMessageResult send(SimpleMailMessage message);
}


public interface AwsSesMimeMessageSender extends AwsSesSimpleMessageSender {
  SendMessageResult send(MimeMessage message);
}

The scope of the above interfaces are just to convert the given message to an AWS SES request, send it, and return the result.
Then we can use the above interface bean in SimpleEmailServiceMailSender and SimpleEmailServiceJavaMailSender.

[maciejwalkowiak]

Lets rephrase it - what would make me use v1 for a new project? Is there anything in v1 that is not offered in v2?

[akefirad]

There's too much difference between the two at least in SDKs that it won't be easy to tell without knowing more about every single feature. I don't think it's safe to assume it's a simple upgrade. There seems to be functionalities that don't exist in SDK. Also different APIs means different permissions etc. So I'm not sure how migration-friendly the whole thing is. My suggestion would be to go with the abstracted interface. (I personally don't need V1, just thinking about the community.)

[maciejwalkowiak]

The point of SES integration is the JavaMailer with SES based implementation, so nobody should care what API version is used. If users want to use pure client, they can just configure new client as a bean.

[akefirad]

Fair enough. So does that mean only V2?

[maciejwalkowiak]

At this stage i don't have enough knowledge to make a decision but also dont see a reason to migrate. I think we can keep that open and consider for further releases if more people are interested with this change.

[MikhailStrokov]

I guess the main reason why you migt need to use v2 client is attachments limit.

Q: Is there a limit on the size of emails Amazon SES can deliver?

Amazon SES v2 API and SMTP accepts email messages up to 40MB in size including any images and attachments that are part of the message. Messages larger than 10MB are subject to bandwidth throttling, and depending on your sending rate, you may be throttled to as low as 40MB/s. For example, you could send a 40MB message at the rate of 1 message per second, or two 20MB messages per second.

Amazon SES API v1 accepts messages up to 10MB in size including any images and attachments that are part of the message.

https://aws.amazon.com/ses/faqs/#49

In our project we send PDFs so we have to use aws sdk v2 directly alongside with cloud aws starters because files exceeds 10MB limit. I don't know how crucial it is for the others but in my opinion it will be really nice to have possibility to use v2 client.

[bhaskar2509]

Bumping this up! This support is needed.

[juanmanuelagueda]

Bumping this up too! We need attachments bigger than 10 MB in my current project. Otherwise, we will have to uses the AWS SDK directly.

[maciejwalkowiak]

Alright! Can we add V2 support in a non-breaking and elegant way? Anyone would like to give it a try and submit a PR?

[bhaskar2509]

@maciejwalkowiak I can give it a go. The approach would be to create a new spring-cloud-aws-ses-v2 correct?

[maciejwalkowiak]

I'm not sure. Can we make current integration work with both clients? I can't give meaningful guidelines without diving into it, but if possible we should avoid duplicating all the code just with a new client.

[bhaskar2509]

@maciejwalkowiak I have implemented the feature, but the tests require localstack pro (SES V2 is part of the pro offering). Can you help me with the steps for the same?

[maciejwalkowiak]

@bhaskar2509 can you submit a draft PR with what you have? We have PRO licenses but did not add PRO variant of localstack to the project to not make it impossible for the community to contribute.