Насколько я могу судить, этого вопроса здесь еще нет, но если он есть, прошу прощения.
С 1 января изменилось название нашей компании и, соответственно, изменились наши адреса электронной почты. Переключение прошло успешно, за исключением нескольких странных ошибок «5.1.1 User Unknown», которые возникают у некоторых внешних отправителей, когда они пытаются отправить нам электронное письмо.
Я поговорил с внешним консультантом, чтобы узнать их мнение, и они, похоже, думают, что у получателей устаревшие записи DNS. Записи MX для нашего сервера существуют на нашем внешнем DNS более месяца - 1 января новый домен был установлен в качестве нашего «основного».
Мне удалось получить несколько отчетов об ошибках от получателей, и они выглядят так. Любая помощь будет оценена в этом вопросе
The following recipient(s) cannot be reached:
'User Name' on 13/01/2012 11:07 AM
550 5.1.1 <user@new-domain.com>... User unknown
РЕДАКТИРОВАТЬ: указанный выше домен является «новым доменом». Электронные письма, отправленные на старый домен, по-прежнему отправляются без проблем. Я также могу проверить, что политика была установлена для этого пользователя и что новый адрес электронной почты существует на их вкладке «Адреса электронной почты».
РЕДАКТИРОВАТЬ 2: На принимающем почтовом сервере работает VamSoft ORF для защиты от спама. Ни журналы Vamsoft ORF, ни журналы обмена не показывают никаких признаков того, что электронные письма попадают в наш домен, однако, когда они используют старый домен, они проходят без проблем.
Ключ к устранению этой проблемы - заставить кого-нибудь просмотреть журналы исходящей SMTP-транзакции на сервере отправителя. Вы можете попытаться сопоставить их сбои с вашими собственными журналами отслеживания сообщений, журналами протокола SMTP или анализом трафика, но лучшие данные будут поступать с собственного SMTP-сервера отправителя. Если у отправителя есть ИТ-персонал, я бы порекомендовал связаться с ними. Если они этого не сделают, попытайтесь заставить отправителя предоставить вам отчеты о недоставке с полными транспортными заголовками.
Вам нужно знать, на какой SMTP-сервер отправитель фактически пытается выполнить доставку, и оттуда вы сможете отследить источник проблемы. Если они разговаривают с сервером, которым вы управляете, вы сможете получить журнал SMTP-разговора, возможно, вплоть до анализа трафика. Если они не разговаривают с вашим сервером, вам нужно выяснить, почему они этого не делают (например, устаревший кеш DNS).
DNS-запросы, кэшированные на совершенно неподходящее время, не являются чем-то неслыханным, но и не обычным. Если вы знаете, кого отправитель использует для восходящего DNS-сервера, вы можете попробовать выполнить поиск записей MX для вашего домена на этом DNS-сервере, чтобы узнать, что вы получите в ответ.
Я поговорил с внешним консультантом, чтобы узнать их мнение, и они, похоже, думают, что у получателей устаревшие записи DNS.
Пошлите этого "консультанта" в жопу! Он производит безграмотный бред! Я SMTP-сеанс установлен с правильным сборщиком (назначен как MX для домена и домена, обрабатываемого на сервере), и только некоторые электронные письма не сопоставляются с существующей проблемой назначения. ваш местный правила перемотки | MDA в Exchange или (вероятно существующие) border-MTA - ничего не могу сказать без исследования глубокого пути доставки вашей почтовой подсистемы.
К сожалению, я ничего не знаю о MTA Exchange (кроме хорошо известного в мире почтмейстера знаменателя «Фигня!»), Но, как давний почтмейстер, могу видеть:
Добавлено после обсуждения с Эваном
Вы должны определить, что недоставленная почта является вашей проблемой на вашем сервере. Попросите любого владельца сообщения о недоставке («MIME-forward», с полным исходным сообщением в качестве вложения) ответить вам и проверить заголовки сообщений о недоставке (Received), чтобы подтвердить (или отклонить) участие вашего MTA в качестве вышибалы
Со своей стороны я могу предложить (некоторое количество) свое время, внимание, разум, руки и свой smtp-эмиттер для тестовых прогонов входящего SMTP.