SES Event sequence
I am having trouble identifying the sequence of events coming from SES. I am using SNS to deliver the JSON through email at the moment.
When sending an email I need to make state changes to the record for the email transmission on our system. The idea is the collect event messages and affect state changes on the email object on our system.
Using their test sandbox I sent an email to both their bounce and their complaint test email accounts.
The received events look like:
{
"notificationType": "Delivery",
"mail": {
"timestamp": "2016-03-09T07:05:57.166Z",
"source": "-redacted-",
"sourceArn": "-redacted-",
"sendingAccountId": "-redacted-",
"messageId": "-redacted-",
"destination": ["bounce@simulator.amazonses.com",
"complaint@simulator.amazonses.com"]
},
"delivery": {
"timestamp": "2016-03-09T07:05:57.686Z",
"processingTimeMillis": 520,
"recipients": ["complaint@simulator.amazonses.com"],
"smtpResponse": "250 2.6.0 Message received",
"reportingMTA": "a8-55.smtp-out.amazonses.com"
}
}
and
{
"notificationType": "Bounce",
"bounce": {
"bounceSubType": "General",
"bounceType": "Permanent",
"reportingMTA": "dsn; a8-55.smtp-out.amazonses.com",
"bouncedRecipients": [{
"action": "failed",
"emailAddress": "bounce@simulator.amazonses.com",
"status": "5.1.1",
"diagnosticCode": "smtp; 550 5.1.1 user unknown"
}],
"timestamp": "2016-03-09T07:05:57.785Z",
"feedbackId": "-redacted-"
},
"mail": {
"timestamp": "2016-03-09T07:05:57.000Z",
"source": "-redacted-",
"sourceArn": "-redacted-",
"messageId": "-redacted-",
"destination": ["bounce@simulator.amazonses.com",
"complaint@simulator.amazonses.com"],
"sendingAccountId": "-redacted-"
}
}
and
{
"notificationType": "Complaint",
"complaint": {
"userAgent": "Amazon SES Mailbox Simulator",
"complainedRecipients": [{
"emailAddress": "complaint@simulator.amazonses.com"
}],
"complaintFeedbackType": "abuse",
"timestamp": "2016-03-09T07:05:57.000Z",
"feedbackId": "-redacted-"
},
"mail": {
"source": "-redacted-",
"timestamp": "2016-03-09T07:05:57.946Z",
"sourceArn": "-redacted-",
"sendingAccountId": "-redacted-",
"messageId": "-redacted-",
"destination": ["bounce@simulator.amazonses.com",
"complaint@simulator.amazonses.com"]
}
}
According to the documentation for the mail object, the timestamp field should be 'The time at which the original message was sent (in ISO8601 format).'.
The bounce object documentation states that the timestamp for this object is 'The date and time at which the bounce was sent (in ISO8601 format). Note that this is the time at which the notification was sent by the ISP, and not the time at which it was received by Amazon SES.'.
And the complaint object documentation states that the timestamp for this object is 'The date and time at which the bounce was sent (in ISO8601 format). Note that this is the time at which the notification was sent by the ISP, and not the time at which it was received by Amazon SES.'.
I cannot see how the stated field descriptions cause the out of sequence issue I see.
I believe that the events should be orders as delivery before bounce or complaint so that bounce or complaint are the final states for the listed recipients.
Mail Object timestamp sequence
2016-03-09T07:05:57.000Z (bounce) 2016-03-09T07:05:57.166Z (delivery) 2016-03-09T07:05:57.946Z (complaint) How can an email be bounced before it is delivered? Does that mean the final state for the bounce email is delivered?
And the notification type object timestamp sequence
2016-03-09T07:05:57.000Z (complaint) 2016-03-09T07:05:57.686Z (delivery) 2016-03-09T07:05:57.785Z (bounce) How can a complaint be made before delivery?
Am I taking crazy pills here? How should I determine the final state for the email sent to each recipient?
Actually, seems fairly straightforward. No, I'm kidding, of course.
Seriously, though, when you think about the lower level mechanisms at play, the following phrasing seems to shed some light on what's likely happening:
Note that this is the time at which the notification was sent by the ISP, and not the time at which it was received by Amazon SES.
That, of course, is a nonsense statement in the strictest sense, because in plain language, the time a message is sent by the ISP and the time it is received by SES are precisely the same -- there's no intermediate SMTP-sorter-in-the-sky that would cause those two times to diverge. The apparently (to me) correct interpretation is that this is referring to the timestamp placed on the notification by the server that originated it... the accuracy of which is indeterminate.
SES is necessarily working some magic when parsing the bounce and complaint responses, because SMTP is notoriously sloppy. This likely includes extracting header data... like timestamps... which very well may not be granular to the millisecond... giving you a sense of false precision.
If you assume the timestamps with 000 milliseconds are in fact accurate only to the second, not the millisecond, you find that the issue you are seeing ... disappears.
Of course, this could also be simply a bad example.
The core of the problem, though, is that it really isn't correct to assume that delivery precedes bounce or complaint, even though it usually does. It's also possible for a bounce not to be preceded by a delivery at all.
If you get a delivery after a bounce, It's not meaningful. It's noteworthy, but not meaningful, because SES does not send bounces on mail that it has not yet given up on trying to deliver.
It might also be helpful if you tested bounce and complaint simulators separately, since you will muddy the water with two different recipients on one message.
链接地址: http://www.djcxy.com/p/32154.html上一篇: 自定义sns主题订阅确认邮件
下一篇: SES事件序列