3

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

Мне также сказали, что ловцы спама часто просто спамят электронное письмо, не уведомляя отправителя. Это, на мой взгляд, квалифицируется как доставленное письмо, но ловушка спама просто перемещает его в папку нежелательной почты.

Однако иногда вы отправляете электронное письмо и никогда не получаете ответ. Через неделю вы звоните им, и они говорят, что так и не получили. Вы знаете этого человека. Вы отправили им электронные письма раньше без проблем. Иногда ваше "невидимое" электронное письмо было даже ответом на их исходное письмо. Так что, пока у вас есть их по телефону, вы отправляете другое, а они этого не получают! Что ты должен делать?

Чтобы провести расследование, вы можете попробовать отправить электронные письма на все задействованные адреса, а затем проверить, доставлены ли они:

  1. от вашего основного до основного вашего друга.
  2. от вашего среднего до основного вашего друга.
  3. от вашего первичного до вторичного вашего друга.
  4. с вашего вторичного электронного письма на вторичное.
  5. все обратные заказы по вышеуказанным пунктам, всего отправлено восемь электронных писем.

Что вы можете сделать в обстоятельствах, когда одно или все эти восемь тестовых электронных писем не получены и что это означает, если не было возвращено "недоставленное" сообщение? Где на пути доставки может быть остановлена электронная почта и как это исправить?


В моих конкретных обстоятельствах это произошло недавно с двумя клиентами (бизнес, поэтому это жизненно важно).

С первым клиентом были проверены электронные письма:

  1. me@my_primary.com to client1@their_primary.com - не получен, не возвращен, не найден в барахле.
  2. me@my_primary.com to client2@their_primary.com - не получен, не возвращен, не найден в барахле.
  3. me@my_secondary.com to clientany@their_primary.com - получено
  4. clientany@their_primary.com to me@my_primary.com - получено

Со вторым клиентом были проверены электронные письма:

  1. me@my_primary.com to client1@their_primary.com - не получен, не возвращен, не найден в барахле.
  2. me@my_secondary.com to client1@their_primary.com - получено
  3. clientany@their_primary.com to me@my_primary.com - получено

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

Мои первичные электронные письма через домен, размещенный на bluehost с выделенным IP. Согласно технической поддержке Bluehost, входящие электронные письма направляются через этот IP-адрес, но все исходящие электронные письма Bluehost маршрутизируются через вращающийся прокси-IP-адрес. По сути, мой выделенный IP-адрес даже не затрагивается исходящими электронными письмами. Это означает, что исходящие электронные письма по-прежнему подвержены IP-адресам из черного списка, вызванным тем, что другие пользователи не ведут себя самостоятельно. Согласно технической поддержке Bluehost, во время отправки моих неудачных электронных писем возникла небольшая проблема, и не каждый домен с ошибочными отправками получал отскок назад. Это могло быть моей проблемой.

2 ответа2

1

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

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

Единственное безопасное время, чтобы отослать сообщение, прежде чем оно было принято. Многие серверы принимают все сообщения и только позже проверяют, могут ли они доставить сообщение. Как только сообщение будет принято, отскок, вероятно, будет отправлен на домен, в котором была подделана их идентификация, и будет считаться спамом обратного рассеяния.

Еще одна причина, по которой не следует пересылать сообщения, это защитить список действительных адресов электронной почты. Отскок сообщения no such user ошибок позволяет очистить списки потенциальных адресов электронной почты. Это упрощает целевые почтовые кампании, которые могут использоваться для фишинга.

Электронная почта, которая занимает значительное место по показателям спама, часто просто отбрасывается. Вот что происходит со всеми мошенническими сообщениями «419», которые я получаю. Некоторые черные списки считаются достаточно надежными, чтобы ваше сообщение могло быть просто отброшено.

Сообщения, отправленные с динамического IP-адреса, также могут быть отброшены, поскольку вероятность того, что это спам, превышает 99%. Извините, на динамических IP-адресах много спам-ботов. Статический IP-адрес с DNS, проходящим обратную проверку, вероятно, будет действительным.

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

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

Я опубликовал несколько подробно на электронной почте. В моей статье « Обнаружение подделки почтового сервера» перечислены некоторые службы проверки. Моя оригинальная статья « Запуск почтового сервера» - это напыщенная речь, поскольку в то время я имел дело с несколькими неправильно настроенными серверами. Более крупные организации расширяют применение политик, содержащихся в моем http://www.systemajik.com/blog/email-policy/.

1

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

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

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .