9

私はこれらの通知の使用法を誤解している可能性があります。

E メールの送信後にトピックに発行するように AWS SES をセットアップしました。バウンス、苦情、および配信用に公開するように設定しました。

Web サーバーで SNS 通知を受信すると、データベースでそのメッセージ ID を検索し、ステータスを変更します。たとえば、配送通知が届いたら、メッセージのステータスを「配送済み」に変更します。バウンス通知が届いたら、メッセージのステータスを「Bounced」に変更します。

しかし、これらの電子メールの多くが両方の通知を送信しており、常に特定の順序で送信されているわけではないことに気付きました。どちらかが先に来ることもあれば、その逆もある。

したがって、「バウンス」が最初に到着し、次に「配信済み」の場合、このメッセージのデータベースでの私のステータスは「配信済み」になります。これはおそらく誤解を招くと思います。

最初の質問 これらの通知の順序を確認するにはどうすればよいですか?

2 番目の質問 「配送」通知を誤解していると思います。AWS のドキュメントを読んでみましたが、正直なところ、地球上で最高のドキュメントではありませんでした。誰かがこれについて簡単で明確な説明をしてくれますか?

3 番目の質問 これらの通知を正しく処理していますか? それとももっと良い方法がありますか?

あなたの助けに感謝します。

ありがとう!

--

参考までに、2 つの通知のセットで構成されるサンプルを添付しました。バウンス 1 回、配信 1 回。

{
    "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

SES がすべてのアウトバウンド配信に使用する SMTP 配信の性質 (SMTP と API のどちらを使用するかに関係なく) は、同じメッセージで 実際にバウンスと配信の両方が発生することがあります。

例えるなら、私の代わりにある会社に電話して、ジェーン・スミスに伝言を残してほしいと頼んだと想像してみてください。たとえ (あなたには知られていないのですが) その会社にはその名前の人はいません。次の 2 つのいずれかが発生します。

  • 通話が終了する前に、「申し訳ありませんが、その名前の人はいません」と言われます。または、

  • メッセージを残して通話を終了します。メッセージを受け取った人は、その名前の誰かがいると想定するか、元の従業員の名前であり、電話の受信者がもう存在していないことに気付いていない可能性があるためです。

最初のシナリオで、「ジェーンにメッセージを残しましたか?」と尋ねたら、あなたは「いいえ」と言うでしょう。しかし、2 番目のシナリオでは、「はい」と言うでしょう。

しかし... 通話を終了した後、2 番目のシナリオでは、社内の誰かがメッセージが見知らぬ人に宛てられたものであることに気づきます。彼らが礼儀正しい場合は、「あなたのメッセージをお届けできません。その名前の人がここにいないため」と言うためにあなたに電話をかけるかもしれません。

さて、あなたは私に電話して、「そのメッセージを伝えることができませんでした」と言います。「待って、何?もうやったって言ったでしょ」

しかし、あなたがそのメッセージを伝えたと言ったにもかかわらず、実際にそのメッセージを伝えなかった理由は十分に明らかです.

メールでも同じ問題が発生します。おそらく、受信メール サーバーの正しい動作は、配信できないメッセージを直ちに拒否することです。

残念ながら、非常に多くの電子メール プロバイダーは、SMTP トランザクションの開始時に電子メール アドレスが提示されたときに、その電子メール アドレスを検証しません。代わりに、彼らは必要なドメインへのすべてのメールを受け入れ、その到達可能性チェックを後まで延期するため、受信メッセージを積極的に拒否することは不可能です...これは、SESが「誤警報」の送信を回避するために必要なことです. " 配達のお知らせ。チェックを延期することにより、受信者システムが発信者に返信する電子メールを実際に生成する必要が生じます (メッセージのフォーマット方法により、これは SES であることが判明します)。本物のバウンスがない場合、SES は最初にメールが配信されたと考え、次にメールがバウンスされたと考えます。

ほとんどの場合、SES からバウンス通知を返すメールは、実際にバウンスされています... 受信した配信通知に関係なく. 通常、配送が最初に行われますが、順序が乱れる可能性がありますが、それは例外です。

ISP バウンスの場合、Amazon SES は、Amazon SES によって再試行されなくなったハード バウンスとソフト バウンスのみを報告します。このような場合、受信者は E メール メッセージを受信せず、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 に答える