((FREE)) Download Bounce Game Apk
Clemencia Branski
What I do is, when I receive an SNS notification on my web server, I will look up that message id in my database, and then change its status. For instance, if delivery notification arrives, I change the message status to "Delivered". If bounce notification arrives, I change the message status to "Bounced".
The nature of SMTP delivery, which is what SES uses for all outbound delivery (regardless of whether you use SMTP or the API) is such that both bounces and deliveries actually do sometimes occur on the same message.
An unfortunately vast number of email providers do not validate the email address when it is presented at the beginning of an SMTP transaction. Instead, they accept all mail for the domains they should, and defer that deliverability check until later, so that it's impossible for them to actively reject an incoming message... which is what would be necessary for SES to avoid sending a "false alarm" delivery notification. By deferring the check, it becomes necessary for the recipient system to actually generate an email back to the originator (which turns out to be SES because of the way they format the messages). In the absence of a genuine bounce, SES first thinks the mail was delivered, and then thinks the mail bounced.
In most cases, an email that returns a bounce notification from SES has, indeed, bounced... regardless of any delivery notification you receive. Typically, delivery should come first, but it's possible to get them out of order -- though that should be the exception.
For ISP bounces, Amazon SES reports only hard bounces and soft bounces that will no longer be retried by Amazon SES. In these cases, your recipient did not receive your email message, and Amazon SES will not try to resend it.
Out of office responses, on the wire, look very much like bounces. Presumably, when SES can't determine a better type of bounce to report, based on the construction of the bounce message that's sent back after the destination has already -- apparently -- accepted your message... they use what you see in your example:
Your best approach is to probably store all the responses, in the event this turns out to be a less than accurate assessment, and consider the Transient/General bounce notification to be an out-of-office alert.