9

我有这些非常尴尬的情况，也许我误解了这些通知的使用。

我已将 AWS SES 设置为在发送电子邮件后发布到主题。我已将其设置为针对退回、投诉和交付发布。

我所做的是，当我在我的 Web 服务器上收到 SNS 通知时，我会在我的数据库中查找该消息 ID，然后更改其状态。例如，如果送达通知到达，我将消息状态更改为“已送达”。如果退回通知到达，我将消息状态更改为“退回”。

但是，现在我注意到其中许多电子邮件都向我发送了两个通知，并且它们并不总是按特定顺序发送。有时一个比另一个来得早，有时反之亦然。

因此，如果“Bounce”首先到达，然后是“Delivered”，我在数据库中的状态会变成“Delivered”，我认为这可能会产生误导。

第一个问题 如何检查这些通知的顺序？

第二个问题 我觉得我误解了“交付”通知。我试过阅读 AWS 文档，但老实说，它们并不是地球上最好的文档。谁能给我一个简单，清晰的解释？

第三个问题 我是否正确处理了这些通知？或者，还有更好的方法？

感谢您的帮助。

谢谢！

--

供您参考，我附上了一个示例，其中包含一组 2 个通知。一次反弹，一次交付。

{
    "Type": "Notification",
    "MessageId": "2efb9ee6-6bd5-576d-b80d-d0f5e3f44f23",
    "TopicArn": "arn:aws:sns:us-east-1:#####:ses_beamstyle_com_hk",
    "Message": {
        "notificationType": "Delivery",
        "mail": {
            "timestamp": "2015-07-05T19:30:40.441Z",
            "source": "<no-reply@bs.com.hk>",
            "messageId": "xxxxx
            "destination": [
                "<ooto@simulator.amazonses.com>"
            ]
        },
        "delivery": {
            "timestamp": "2015-07-05T19:30:41.101Z",
            "processingTimeMillis": 660,
            "recipients": [
                "ooto@simulator.amazonses.com"
            ],
            "smtpResponse": "250 2.6.0 Message received",
            "reportingMTA": "a9-140.smtp-out.amazonses.com"
        }
    },
    "Timestamp": "2015-07-05T19:30:41.179Z",
    "SignatureVersion": "1",
    "Signature": "xxxxx",
    "SigningCertURL": "xxxxx",
    "UnsubscribeURL": "xxxxx"
}





{
    "Type": "Notification",
    "MessageId": "b6e8bb7d-4e73-52ae-b690-f56ec6527ce5",
    "TopicArn": "arn:aws:sns:us-east-1:#####:ses_beamstyle_com_hk",
    "Message": {
        "notificationType": "Bounce",
        "bounce": {
            "bounceSubType": "General",
            "bounceType": "Transient",
            "bouncedRecipients": [
                {
                    "emailAddress": "ooto@simulator.amazonses.com"
                }
            ],
            "timestamp": "2015-07-05T19:30:41.000Z",
            "feedbackId": "xxxxx"
        },
        "mail": {
            "timestamp": "2015-07-05T19:30:40.000Z",
            "messageId": "xxxxx",
            "destination": [
                "<ooto@simulator.amazonses.com>"
            ],
            "source": "<no-reply@bs.com.hk>"
        }
    },
    "Timestamp": "2015-07-05T19:30:41.315Z",
    "SignatureVersion": "1",
    "Signature": "xxxxx",
    "SigningCertURL": "xxxxx",
    "UnsubscribeURL": "xxxxx"
}
4

1 回答 1

16

SMTP 传递的性质，即 SES 用于所有出站传递（无论您使用 SMTP 还是 API）的性质，使得退回和传递实际上有时确实会发生在同一封邮件上。

打个比方，想象一下我请你代表我给一家公司打电话，给简·史密斯留言，尽管（你不知道）那家公司里没有一个叫这个名字的人。将发生以下两种情况之一：

  • 在通话结束之前，你会被告知，“对不起，这里没有人叫那个名字”，或者，

  • 您将留下一条消息并结束通话，因为接听消息的人假设有人使用该名称，或者可能是接听者没有意识到不再存在的前雇员的名字。

在第一个场景中，如果我问：“你给简留了口信吗？” 你会说“不”。但在第二种情况下，你会说“是”。

但是……在您结束通话后，在第二种情况下，公司中的某个人随后会意识到该消息是发给一个陌生人的。如果他们彬彬有礼，他们可能会给您回电说：“我们无法传递您的信息，因为这里没有那个名字的人。”

现在，你打电话给我说，“我无法传递那个信息。” “等等，什么？你告诉我你已经做到了。”

但是，即使你说你做了，你也没有真正传递那个信息的原因是很清楚的。

电子邮件也会出现同样的问题。可以说，接收邮件服务器的正确行为是立即拒绝无法投递的邮件。

不幸的是，当电子邮件地址在 SMTP 事务开始时出现时，大量电子邮件提供商不会验证电子邮件地址。相反，他们接受他们应该接受的域的所有邮件，并将可送达性检查推迟到以后，这样他们就不可能主动拒绝传入的邮件......这是 SES 避免发送“误报”所必需的“ 送达通知。通过推迟检查，收件人系统有必要实际生成一封电子邮件返回给发件人（由于它们格式化消息的方式，这被证明是 SES）。在没有真正退回的情况下，SES 首先认为邮件已送达，然后认为邮件已退回。

在大多数情况下，从 SES 返回退回通知的电子邮件确实已退回……无论您收到任何送达通知。通常情况下，交付应该是第一位的，但也有可能让它们出现故障——尽管那应该是例外。

对于 ISP 退回邮件，Amazon SES 仅报告 Amazon SES 不再重试的硬退回邮件和软退回邮件。在这些情况下，您的收件人没有收到您的电子邮件，Amazon SES 不会尝试重新发送它。

http://docs.aws.amazon.com/ses/latest/DeveloperGuide/notifications.html

这很简单......但是，当然，有一个烦人的例外：

您会通过与退回邮件相同的方法收到外出 (OOTO) 邮件的通知，但这些邮件不计入您的退回邮件统计信息。

不在办公室的回复，在网上，看起来很像反弹。据推测，当 SES 无法确定要报告的更好的退回类型时，基于在目的地已经 - 显然 - 接受您的消息之后发送回的退回消息的构造......他们使用您在您的例子：

        "bounceSubType": "General",
        "bounceType": "Transient",

有关可能的组合，请参阅http://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html#bounce-types。

您最好的方法是可能存储所有响应，以防评估结果不够准确，并将瞬态/一般退回通知视为外出警报。

其他 Transient 子类型可能被解释为您将来可以成功发送给的人，而 Permanent 子类型是您应该避免发送到的地址，因为该地址被认为是永久无法投递。

除了不在办公室之外，退回邮件（在接收方没有错误配置）应该是一个合理可靠的指标，表明该特定消息没有通过。

于 2015-07-06T23:12:15.307 回答