SES事件序列
我无法识别来自SES的事件序列。 我正在使用SNS通过电子邮件发送JSON。
发送电子邮件时，我需要对我们系统上的电子邮件传输记录进行状态更改。 这个想法是收集事件消息并影响我们系统上电子邮件对象的状态更改。
使用他们的测试沙箱，我发送了一封电子邮件给他们的反弹和他们的投诉测试电子邮件帐户。
收到的事件如下所示：
{
"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"
}
}
和
{
"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-"
}
}
和
{
"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"]
}
}
根据邮件对象的文档，时间戳字段应该是'原始邮件发送的时间（以ISO8601格式）'。
反弹对象文档指出，此对象的时间戳是'发送反弹的日期和时间（采用ISO8601格式）。 请注意，这是ISP发送通知的时间，而不是Amazon SES收到通知的时间。“
投诉对象文档指出，此对象的时间戳是'发送反弹的日期和时间（采用ISO8601格式）。 请注意，这是ISP发送通知的时间，而不是Amazon SES收到通知的时间。“
我无法看到规定的字段描述如何引起我所看到的乱序问题。
我相信这些事件应该是在退回或投诉之前作为交付的命令，以便退回或投诉是列出的收件人的最终状态。
邮件对象时间戳序列
2016-03-09T07:05:57.000Z （反弹） 2016-03-09T07:05:57.166Z （送货） 2016-03-09T07:05:57.946Z （投诉） 邮件在发送之前如何被弹回？ 这是否意味着退回电子邮件的最终状态已交付？
通知类型对象时间戳序列
2016-03-09T07:05:57.000Z （投诉） 2016-03-09T07:05:57.686Z （送货） 2016-03-09T07:05:57.785Z （反弹） 如何在投递前投诉？
我在这里吃疯狂的药吗？ 我应该如何确定发送给每个收件人的电子邮件的最终状态？
其实，看起来相当简单。 不，我当然在开玩笑。
然而，严肃地说，当你考虑下级机制时，下面的措词似乎揭示了可能发生的情况：
请注意，这是ISP发送通知的时间，而不是Amazon SES收到通知的时间。
这当然是最严格意义上的无意义陈述，因为在简单的语言中，ISP发送消息的时间和SES接收的时间完全相同 - 没有中间SMTP分类程序这会导致这两次分歧。 显然（对我来说）正确的解释是，这是指源于服务器的通知所放置的时间戳......其准确性是不确定的。
在分析反弹和投诉响应时，SES必然会发挥一定的魔力，因为SMTP臭名昭着。 这可能包括提取标题数据...像时间戳......这很可能不会精确到毫秒...给你一个错误的精度感。
如果您认为具有000毫秒的时间戳事实上仅准确到秒，而不是毫秒，您会发现您看到的问题......消失。
当然，这也可能只是一个不好的例子。
但问题的核心在于，假设交付先于反弹或投诉，但确实是不正确的，尽管通常会这样做。 反弹也可能不会在交付之前发生。
如果在反弹后得到交货，这没有意义。 值得注意的是，但没有意义，因为SES不会发送它尚未放弃尝试发送的邮件。
如果您单独测试反弹和投诉模拟器，也可能会有所帮助，因为您会在一条消息中用两个不同的收件人混淆水。
链接地址: http://www.djcxy.com/p/32153.html上一篇: SES Event sequence