SES 事件序列

Question

我在识别来自SES的事件序列时遇到问题。我目前正在使用 SNS 通过电子邮件传递 JSON。

发送电子邮件时，我需要对系统上电子邮件传输的记录进行状态更改。这个想法是收集事件消息并影响我们系统上电子邮件对象的状态更改。

使用他们的测试沙盒，我向他们的退回邮件和投诉测试电子邮件帐户发送了一封电子邮件。

收到的事件如下所示：

{
    "notificationType": "Delivery",
    "mail": {
        "timestamp": "2016-03-09T07:05:57.166Z",
        "source": "-redacted-",
        "sourceArn": "-redacted-",
        "sendingAccountId": "-redacted-",
        "messageId": "-redacted-",
        "destination": ["[e-mail]",
        "[e-mail]"]
    },
    "delivery": {
        "timestamp": "2016-03-09T07:05:57.686Z",
        "processingTimeMillis": 520,
        "recipients": ["[e-mail]"],
        "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": "[e-mail]",
            "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": ["[e-mail]",
        "[e-mail]"],
        "sendingAccountId": "-redacted-"
    }
}

和

{
    "notificationType": "Complaint",
    "complaint": {
        "userAgent": "Amazon SES Mailbox Simulator",
        "complainedRecipients": [{
            "emailAddress": "[e-mail]"
        }],
        "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": ["[e-mail]",
        "[e-mail]"]
    }
}

根据邮件对象的文档，时间戳字段应为"发送原始邮件的时间（ISO8601格式）"。

退回

对象文档指出，此对象的时间戳为"发送退回邮件的日期和时间（ISO8601格式）。请注意，这是 ISP 发送通知的时间，而不是 Amazon SES 收到通知的时间。

投诉对象文档指出，此对象的时间戳是"发送退回邮件的日期和时间（以ISO8601格式）。请注意，这是 ISP 发送通知的时间，而不是 Amazon SES 收到通知的时间。

我

看不出所述字段描述如何导致我看到的顺序错误问题。

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

1. 邮件对象时间戳不一致，它会随着事件而变化，并且按时间顺序将事件从预期的序列中移除。
事件
2. 时间戳也会将事件从预期的序列中移除。

邮件对象时间戳序列

1. 2016-03-09T07:05:57.000Z（弹跳）
2. 2016-03-09T07:05:57.166Z（交货）
3. 2016-03-09T07:05:57.946Z（投诉）

电子邮件在送达前如何被退回？这是否意味着退回电子邮件的最终状态已送达？

和通知类型对象时间戳序列

1. 2016-03-09T07:05:57.000Z（投诉）
2. 2016-03-09T07:05:57.686Z（交货）
3. 2016-03-09T07:05:57.785Z（弹跳）

如何在交货前提出投诉？

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

Answer 1

实际上，似乎相当简单。 不，我当然是在开玩笑。

不过，说真的，当你考虑较低级别的机制时，下面的措辞似乎揭示了可能发生的事情：

请注意，这是 ISP 发送通知的时间，而不是 Amazon SES 收到通知的时间。

当然，从最严格的意义上讲，这是一个无稽之谈，因为用简单的语言来说，ISP发送消息的时间和SES接收消息的时间完全相同 - 没有中间的SMTP分类器会导致这两个时间出现分歧。 显然（对我来说）正确的解释是，这是指发起通知的服务器在通知上放置的时间戳......其准确性是不确定的。

SES在解析退回和投诉响应时必然会发挥一些魔力，因为SMTP是出了名的草率。 这可能包括提取标头数据...像时间戳...这很可能不是细到毫秒的......给你一种虚假的精确感。

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

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

然而，问题的核心是，假设交付先于退回或投诉确实不正确，即使它通常也是如此。 退回邮件之前也可能根本不会有交付。

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

如果您分别测试退回邮件和投诉模拟器，也可能很有帮助，因为您将在一封邮件上与两个不同的收件人混淆视听。