Уведомления о доставке и отказе в социальных сетях после отправки через AWS SES

У меня действительно неловкая ситуация, возможно, я неправильно понимаю использование этих уведомлений.

Я настроил AWS SES для публикации в теме после отправки электронных писем. Я настроил его на публикацию для отказов, жалобы и доставки.

Что я делаю, это когда я получаю уведомление SNS на моем веб-сервере, я ищу этот идентификатор сообщения в своей базе данных, а затем изменяю его статус. Например, если приходит уведомление о доставке, я меняю статус сообщения на «Доставлено». Если приходит уведомление об отказе, я меняю статус сообщения на «Отказано».

Однако теперь я замечаю, что многие из этих писем отправляют мне оба уведомления, и они не всегда в определенном порядке. Иногда одно наступает раньше другого, а иногда наоборот.

Таким образом, если сначала приходит «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": "<[email protected]>",
            "messageId": "xxxxx
            "destination": [
                "<[email protected]>"
            ]
        },
        "delivery": {
            "timestamp": "2015-07-05T19:30:41.101Z",
            "processingTimeMillis": 660,
            "recipients": [
                "[email protected]"
            ],
            "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": "[email protected]"
                }
            ],
            "timestamp": "2015-07-05T19:30:41.000Z",
            "feedbackId": "xxxxx"
        },
        "mail": {
            "timestamp": "2015-07-05T19:30:40.000Z",
            "messageId": "xxxxx",
            "destination": [
                "<[email protected]>"
            ],
            "source": "<[email protected]>"
        }
    },
    "Timestamp": "2015-07-05T19:30:41.315Z",
    "SignatureVersion": "1",
    "Signature": "xxxxx",
    "SigningCertURL": "xxxxx",
    "UnsubscribeURL": "xxxxx"
}

person Thomas Cheng    schedule 06.07.2015    source источник


Ответы (1)


Природа доставки SMTP, которую SES использует для всей исходящей доставки (независимо от того, используете ли вы SMTP или API), такова, что и возврат, и доставка действительно иногда происходят в одном и том же сообщении.

Чтобы провести параллель, представьте, что я прошу вас позвонить в компанию от моего имени и оставить сообщение для Джейн Смит, даже если (вам неизвестно) в этой компании нет человека с таким именем. Произойдет одно из двух:

  • перед окончанием разговора вам скажут: «Извините, здесь нет никого с таким именем» или,

  • вы оставите сообщение и завершите звонок, потому что человек, принимающий сообщение, предполагает, что есть кто-то с таким именем, или, возможно, это имя бывшего сотрудника, которого принимающий не осознает, что его больше нет.

В первом сценарии, если я спрошу: «Вы оставили сообщение для Джейн?» вы бы сказали «нет». Но во втором сценарии вы бы сказали «да».

Но ... после того, как вы завершите разговор, во втором сценарии кто-то в компании впоследствии поймет, что сообщение адресовано неизвестному человеку. Если они вежливы, они могут перезвонить вам и сказать: «Мы не можем доставить ваше сообщение, потому что здесь нет никого с таким именем».

Теперь вы звоните мне и говорите: «Я не смог доставить это сообщение». «Подожди, что? Ты сказал мне, что уже сделал».

Но причина, по которой вы на самом деле не передали это сообщение, хотя вы и сказали, что сделали, достаточно ясна.

Та же проблема возникает по электронной почте. Возможно, правильным поведением сервера входящей почты является немедленное отклонение сообщения, которое не может быть доставлено.

К сожалению, огромное количество провайдеров электронной почты не проверяют адрес электронной почты, когда он указывается в начале транзакции SMTP. Вместо этого они принимают всю почту для доменов, которые они должны, и откладывают эту проверку доставляемости на потом, чтобы им было невозможно активно отклонить входящее сообщение ... что было бы необходимо для SES, чтобы избежать отправки «ложной тревоги». " Уведомление о доставке. Откладывая проверку, для системы-получателя становится необходимо фактически сгенерировать электронное письмо обратно отправителю (которое оказывается SES из-за способа форматирования сообщений). При отсутствии подлинного возврата SES сначала думает, что почта была доставлена, а затем считает, что почта возвращена.

В большинстве случаев электронное письмо, которое возвращает уведомление о недоставке от SES, действительно было отклонено ... независимо от любого полученного вами уведомления о доставке. Как правило, доставка должна быть на первом месте, но их можно вывести из строя - хотя это должно быть исключением.

Для отказов интернет-провайдеров 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, чтобы узнать о возможных комбинациях.

Ваш лучший подход - вероятно, сохранить все ответы, если это окажется неточной оценкой, и рассматривать временное / общее уведомление о сбоях как предупреждение об отсутствии на работе.

Другие временные подтипы могут быть интерпретированы как кто-то, кому вы могли бы успешно отправить в будущем, в то время как постоянные подтипы - это адреса, на которые вам следует избегать отправки, поскольку адрес считается навсегда недоставленным.

За исключением случаев отсутствия на работе, отказы (при отсутствии неправильной конфигурации на стороне получателя) должны быть для вас достаточно надежным индикатором того, что это конкретное сообщение не было отправлено.

person Michael - sqlbot    schedule 06.07.2015
comment
Когда сервер отклоняет электронное письмо из-за того, что отправитель находится в черном списке (что происходит с SES), вы также получаете общий отчет о сбоях в переходном процессе. Похоже, вы не можете отличить OOTO от отказа, вызванного черным списком. - person gaefan; 02.12.2017