SES 事件序列

Question

我无法确定来自 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"]
    }
}

根据 mail object 的文档，时间戳字段应为 'The time at which the original message was sent (in ISO8601 format).'.

bounce object 文档指出此对象的时间戳是 '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.'.

并且 complaint object 文档指出此对象的时间戳是 '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.'.

我看不出规定的字段描述是如何导致我看到的乱序问题的。

我认为事件应该是在退回或投诉之前交付的订单，以便退回或投诉是列出的收件人的最终状态。

邮件对象时间戳不一致，它改变了事件，时间顺序使事件超出了预期的顺序。
事件时间戳也将事件从预期的顺序中取出。

邮件对象时间戳序列

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 （反弹）

发货前如何投诉？

我这是在吃疯狂的药吗？ 我应该如何确定发送给每个收件人的电子邮件的最终状态？

Answer 1

实际上，看起来很简单。不，我开玩笑的，当然。

不过，严肃地说，当您考虑正在发挥作用的较低级别机制时，以下措辞似乎可以阐明可能发生的情况：

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.

这当然是最严格意义上的无稽之谈，因为在通俗的语言中，ISP发送消息的时间和接收消息的时间SES 完全相同——没有中间 SMTP-sorter-in-the-sky 会导致这两个时间发生分歧。显然（对我而言）正确的解释是，这是指发出通知的服务器在通知上放置的时间戳……其准确性不确定。

SES 在解析退回和投诉响应时必然会发挥一些作用，因为 SMTP 是出了名的草率。这可能包括提取 header 数据……比如时间戳……这很可能不是精确到毫秒……给你一种 false precision.

的感觉

如果您假设 000 毫秒的时间戳实际上只精确到秒，而不是毫秒，您会发现您看到的问题……消失了。

当然，这也可能只是一个不好的例子。

但问题的核心在于，假设交付先于退回或投诉确实是不正确的，尽管通常情况下是这样。也有可能在退回 而不是 之前完全交付。

如果你在退回后收到货，那是没有意义的。这是值得注意的，但没有意义，因为 SES 不会在尚未放弃尝试投递的邮件上发送退回邮件。

如果您分别测试退回模拟器和投诉模拟器，这也可能会有所帮助，因为您会在一封邮件中将两个不同的收件人混为一谈。

SES 事件序列

SES Event sequence

amazon-web-services

amazon-sns

amazon-ses