Question

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

我已将AWS SES设置为在发送电子邮件后发布到主题。我已将其设置为发布Bounce，Complaint和Delivery。

我所做的是，当我在网络服务器上收到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"
}

Answer 1

SMTP交付的性质，即SES用于所有外向交付的内容（无论您使用的是SMTP还是API）都会导致实际上有时会发生跳出和交付信息。

为了得到一个平行线，想象一下，我请你代表我给公司打电话，并给Jane Smith留言，即使（你不知道）那个公司里没有一个人用这个名字。将发生以下两件事之一：

在通话结束之前，你会被告知，“我很抱歉，这个名字里面没有人，”或者，
你会留言，并结束通话，因为收到该消息的人假设有一个名字的人，或者也许是接听者没有意识到的前雇员的名字是不再在场。

在第一个场景中，如果我问，“你是否给Jane留言？”你会说“不”。但在第二种情况下，你会说“是的”。

但是......在你结束通话后，在第二种情况下，公司的某个人随后会意识到该消息是针对一个不知名的人。如果他们有礼貌，他们可能会打电话给你说，“我们无法传递你的信息，因为这个名字里面没有人。”

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

但即使你说过，你实际上没有传递这个信息的原因已经足够清楚了。

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

遗憾的是，大量电子邮件提供商在SMTP事务开始时显示电子邮件地址时不会对其进行验证。相反，他们接受他们应该使用的域的所有邮件，并将该可传递性检查推迟到以后，这样他们就不可能主动拒绝传入的消息......这是SES避免发送“误报”所必需的“ 送达通知。通过推迟检查，接收方系统有必要实际生成回发信方的电子邮件（由于它们格式化消息的方式，结果是SES）。在没有真正反弹的情况下，SES首先认为邮件已经发送，然后认为邮件被反弹了。

在大多数案例中，从SES返回退回通知的电子邮件确实已经退回......无论您收到任何投放通知。通常情况下，交付应首先进行，但可能会使它们无序 - 尽管这应该是例外。

对于ISP反弹，Amazon SES仅报告亚马逊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 / General退回通知视为外出警报。

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

除了不在办公室外，跳出应该（在收件人方面没有错误配置）是一个相当可靠的指示，告诉你这条特定的信息没有通过。

通过AWS SES发送后，“发送”和“退回”SNS通知

1 个答案: