Motivation

While testing an SES/SNS sample, we encountered an issue where sending an email with SES with an SNS event destination configured that would have another SES subscriber, it would trigger an infinite loop.

There were 2 problems:

• SNS was sending the send and delivery notification even if you didn't configure it
• it was sending for event destinations that exists for all ConfigurationSet, even if you did not specify a ConfigurationSetName. SES only sends event notification if you pass a ConfigurationSetName because EventDestinations are inherently linked to a configuration set, see https://docs.aws.amazon.com/ses/latest/dg/monitor-sending-using-event-publishing-setup.html

The following steps required for setting up event publishing are covered in the topics below:

• You must create a configuration set using the Amazon SES console or API.
• Add one or more event destinations (CloudWatch, Firehose, Pinpoint, or SNS) to the configuration set, and configure parameters unique to the event destination.
• When you send an email, you specify which configuration set to use that contains your event destination.

There is still one somewhat big issue because Moto only accepts one EventDestination per configuration set, even if AWS accepts multiple, Moto will overwrite it every time you call CreateConfigurationSetEventDestination, but this is out of scope.

Changes

• refactor a bit the SNS sending to centralize in one point and not have to modify the code 3 times, and for it to be easy to extend. We will probably need to refactor it again if we want to extend the SNSEmitter and add new kind of destinations
• add a new LocalStack only test because we cannot really look into received emails when validating against AWS
• write some TODOs about behavior problem of Event Destinations