I want to get the delivery status of the mails sent through Amazon SES by hitting an API and saving the response in my database. I know of Amazon SNS and sending notification through email, but could not find a solution for this. Is there a solution to this?
There is no polling mechanism in SES for delivery status.
The SNS delivery/status notifications that SES provides, which you have indicated you are familiar with, is the standard mechanism for this.
Enable these and then subscribe an SQS queue, or a Lambda function, or even an HTTPS endpoint from your app, to the designated SNS topic. It should be relatively simple using any of these mechanisms to code a solution to store the reports in the database as they are provided to you by SES.
Related
Im using AWS Lambda for sending emails by Amazon SES.
Each time that the request send_email succeeds I got the message id like confirmation.
But now, I want to use somehow this messageId. For example to know if this message concretelly get delivered or bounced.
CloudWatch offers me metrics, with the number of delivered or bounced messages but I want to look throught each one.
¿Is there any statement that allows to know the state of a message by id?
Due to the asynchronous nature of SMTP and how mails are being routed, you can't have this information immediately when sending an e-mail (via SES or otherwise).
However, AWS provides a feedback system which notifies an SNS topic when a message is delivered, bounced, or a complaint was received.
While the documentation is very detailed, the general idea is that you subscribe your own lambda(s) to the configured SNS topic(s) and you can then handle these events as you see fit (i.e. persist data on DynamoDB, call your unsubscribe API and so on).
On AWS I'm trying to create a cloudwatch alarm that sends a notification to a sns topic that in turn triggers a lambda function that is subscribed to the topic, but have run into a bit of a snag in which my lambda is never triggered. I've followed several tutorials on how to do this, I've manually tested the sns -lambda connection and this is working as is attaching the notification trigger onto cloudwatch.
I've done this all through cloudformation.
I have also tried to configure it manually from the cloudwatch console and then noticed something strange. Underneath the Send a notification to select box as shown in the image below, there is a message which says Only email lists for this account are available. So I'm guessing from that, that somewhere in this account, there is a weird setting that needs to be changed?
Updated answer:
Is the CloudWatch alarm actually in the "Alarm" state? Can you add 2 more notifications to be triggered by the "OK" and "Insufficient data" state respectively?
by reading the original post, SNS should have the right permission to invoke the Lambda function.
previous answer:
That is a general message, it has nothing to do with your SNS topic settings. I reckon it's meant to say only emails opt-in to that SNS topic will get emails.
Q: How does Amazon SNS validate a subscription request to ensure that notifications will not be sent to users as spam?
As part of the subscription registration, Amazon SNS will ensure that notifications are only sent to valid, registered subscribers/end-points. To prevent spam and ensure that a subscriber end-point is really interested in receiving notifications from a particular topic, Amazon SNS requires an explicit opt-in from subscribers using a 2-part handshake:
i. When a user first calls the Subscribe API and subscribes an end-point, Amazon SNS will send a confirmation message to the specified end-point.
ii. On receiving the confirmation message at the end-point, the subscriber should confirm the subscription request by sending a valid response. Only then will Amazon SNS consider the subscription request to be valid. If there is no response to the challenge, Amazon SNS will not send any notifications to that end-point. The exact mechanism of confirming the subscription varies by the transport protocol selected:
For HTTP/HTTPS notifications, Amazon SNS will first POST the confirmation message (containing a token) to the specified URL. The application monitoring the URL will have to call the ConfirmSubscription API with the token included token.
For Email and Email-JSON notifications, Amazon SNS will send an email to the specified address containing an embedded link. The user will need to click on the embedded link to confirm the subscription request.
For SQS notifications, Amazon SNS will enqueue a challenge message containing a token to the specified queue. The application monitoring the queue will have to call the ConfirmSubscription API with the token.
Note: The explicit “opt-in” steps described above are not required for the specific case where you subscribe your Amazon SQS queue to your Amazon SNS topic – and both are “owned” by the same AWS account.
I am currently trying to configure a way to track the emails that i am sending through Amazon SES by using multiple domains. What i really want to achieve is to be able to track how many emails have been sent from each domain seperately. It is something i can achieve throught SES API ?I couldn't find any solution to this.
There is no AWS offered API for that. You can set up SES delivery notifications. This pushes notification to SNS topic. You can then create a subscription to this SNS topic. This really opens up much more possibilities of what you can do to achieve your goal. The simplest approach could be just sending an email and processing it in your email client if you don't have many emails sending out from SES. More sophisticated approaches may involve setting up an HTTP endpoint and letting SNS send back HTTP(S) data, or utilizing AWS lambda and SQS, etc.
I know that Amazon Pinpoint enables 2-way SMS, but I was wondering whether it was possible to save the message that the client sends. I'm finding myself going down the AWS rabbit-hole a bit, but I was wondering if anyone has any recommendations as to what AWS services could hold onto response data.
Just to clarify, I understand that Pinpoint allows us to return automated messages when the client passes a keyword. I am also aware that we can create user segments to save user attributes, I am moreso inquiring whether there is a way to stream user responses (that are not keywords) to another service or topic. Thank you!
An overview of Amazon Pinpoint two-way messaging can be summarized as per the above sample architecture.
You can capture the incoming messages from your users using the SNS topic you would have created when activating Pinpoint two-way messaging i.e When your users reply to your SMS message using the long code number, Amazon Pinpoint sends a JSON payload to the Amazon SNS topic that you designated. As a developer you handle these incoming messages by adding subscriptions to this SNS topic. The supported subscriptions include SQS, Lambda, email, HTTPS endpoint or SMS.
A sample JSON payload that your SNS topic subscriptions would receive would resemble the following :
{
"originationNumber":"+27155550000",
"destinationNumber":"+2722255511111",
"messageKeyword":"START",
"messageBody":"Hello World from Amazon Pinpoint",
"inboundMessageId":"cae173d2-66b9-564c-8309-66b9",
"previousPublishedMessageId":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
Hope this Helps!
What's the easiest way to save/log every message published on a AWS SNS topic? I thought there might be a magic setting to automatically push them to S3 or a database, or maybe a database service supporting the HTTP destination automatically, but doesn't seem to be the case. Maybe it needs to be done via a Lambda function?
The purpose is just for basic diagnostics and debugging while setting up some SNS publishing. I don't really care about high scale or fast querying, just want to log and perform basic queries on all the activity for a few minutes at a time.
You can setup a trigger to push your SNS messages to SQS queue. Push is automatic and does not require any code.
According to the docs, SNS can publish to:
http – delivery of JSON-encoded message via HTTP POST
https – delivery of JSON-encoded message via HTTPS POST
email – delivery of message via SMTP
email-json – delivery of JSON-encoded message via SMTP
sms – delivery of message via SMS
sqs – delivery of JSON-encoded message to an Amazon SQS queue
application – delivery of JSON-encoded message to an EndpointArn for a mobile app and device.
lambda – delivery of JSON-encoded message to an AWS Lambda function.
So yes, a simple approach would be to trigger a lambda function to write to S3 or CloudWatch.