Назад | Перейти на главную страницу

Ошибка доставки электронной почты почтмейстера

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

"Это сообщение с уведомлением о сбое доставки, указывающее на то, что письмо, которое вы отправили на адрес электронной почты: - XXXXX.XXXXXX@XXX.XX не может быть доставлено. Проблема, по всей видимости, следующая: - Ошибка связи. Дополнительная информация: - Нулевой результат из сокета Это условие возникло после 30 попыток доставки в течение 92 часов. Если вы отправили электронное письмо нескольким получателям, вы получите одно из этих сообщений для каждого из них, доставка которого не удалась, в противном случае они были послал."

Мне нужна помощь в устранении неполадок, я раньше не видел этой ошибки, и Google не показывает результаты для этой конкретной ошибки.

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

Если у нас самая простая ситуация; MUA -> MTA отправителя -> ваш MTA -> почтовый ящик; такого рода ошибка может возникать, скорее всего, на MTA отправителя, когда он пытается подключить ваш MTA. Поэтому, хотя это и предлагается в комментариях, это даже не будет отображаться в журналах на вашем почтовом сервере. От подключения и отключения может быть максимум два события. Кроме того, если почта из другого места поступает нормально, маловероятно, что этот домен отправителя будет обрабатываться иначе.

Когда можно ограничить проблему одним сервером:

  • Кто-то должен проверить журналы на исходном сервере; тот, который отправил сообщение о недоставке. Если сервер находится на стороне отправителя, у вас даже нет доступа к этим журналам, и вы также не можете проводить тестирование; пройти инструкции.
  • Убедитесь, что MTA отправителя получает правильные записи MX для домена получателя.
  • Проверьте эту связь с этим mx.example.com:25 можно установить, например, что вы получаете правильное приветственное сообщение SMTP при попытке установить Telnet для вашего MTA :25 от отправителя MTA.
  • Проверьте маршрутизацию между серверами, например с участием traceroute mx.example.com.

Если проблема в другом месте, все то же самое относится к этому серверу и следующему MTA.

Я не уверен, поможет ли это, но мы только что столкнулись с чем-то с очень похожими симптомами.

Все сводилось к тому, что брандмауэр получателя отклонял соединение, поскольку заголовок SMTP был «слишком длинным». Получатель обновил программное обеспечение на своем брандмауэре, и теперь электронные письма отправляются.