Недавно у меня возникла проблема с моим сервером Exchange 2003. Я не могу получать электронные письма с определенных доменов. В частности, существует только 2 доменных имени (только один пользователь из каждого домена пытался отправлять электронные письма в наш домен).
Я включил фильтры, чтобы проверить, была ли это проблема с фильтрацией, но безрезультатно. Я также просмотрел журналы отслеживания сообщений, но не заметил НИКАКИХ писем из любого домена, когда отправитель сказал, что они отправили нам несколько тестовых писем. Я могу подключиться к серверу через telnet и получить соответствующие ответы EHLO и HELO, мы не занесены в черный список, а все остальное выглядит нормально.
Мне было интересно, есть ли у кого-нибудь предложения относительно того, что я могу проверить дальше или изучить. Если я забыл важную информацию, извините, дайте мне знать, и я опубликую дополнительную информацию. Заранее спасибо.
Я предполагаю, что вы получаете электронную почту непосредственно из Интернета через запись MX, которая относится к вашему компьютеру с сервером Exchange (на основе ваших утверждений re: использование TELNET для запуска SMTP «вручную»). Если у вас есть какая-либо антиспамовая / антивирусная фильтрация, вы должны дважды или трижды проверить это, прежде чем начать жаловаться сторонним системным администраторам.
Сказав это, лучшее место для устранения этой проблемы в следующий раз будет на стороне отправителя. Если вы не можете получить от них поддержку для отслеживания исходящего потока электронной почты, вы можете попытаться захватить трафик на своей стороне, но, скорее всего, вам придется прочесать гигантский стог сена.
Отправители должны искать журналы протокола SMTP или то, что в их почтовой системе эквивалентно Exchange «Отслеживание сообщений» (/var/log/mail.log и т. Д.), Чтобы узнать, как их сервер обработал сообщение об ошибке (которое отправитель должен сможет помочь им идентифицировать себя в своих журналах). Предполагая, что они «теряют» сообщение, блокируются политикой и т. Д., Глупо, что их серверы не отправляют отчет о недоставке обратно отправляющему пользователю. Запутанная исходящая электронная почта никогда не поможет. (Отправка отчетов о недоставке по входящей электронной почте, возможно, может быть не такой уж и хорошей идеей. Да, да - я знаю, что в некоторых RFC говорится, что вам следует ...> вздох <)
Если отправители не могут вам помочь, тогда ваша единственная надежда - это, скорее всего, захватить трафик на вашей границе и попытаться определить попытки соединения (или его отсутствие) с их исходящего сервера. Предполагая, что вы можете заставить кого-нибудь отправить сообщение по команде (скажем, во время телефонного звонка), и предполагая, что инфраструктура исходящего сервера не займет много времени для обработки сообщения, вы сможете записать SMTP-разговор с сервером отправителя ( или ничего, если до вас никогда не доходит).
По правде говоря, это действительно не ваша проблема с технической точки зрения. К сожалению, пользователи и руководство не понимают природы «дикого запада» электронной почты в Интернете и часто видят в ней надежную форму связи. Когда реальность доказывает обратное, они часто обвиняют ближайшего системного администратора электронной почты, а не соглашаются с тем, что, в отличие от обычной почты, это ненадежная система.
Это проблема, которая может пойти не так в трех местах:
Для 1) вам, очевидно, понадобится помощь человека, который управляет почтой на сайте отправителя. На самом деле вы мало что можете сделать, кроме как спросить их, блокируют ли они определенные письма (например, блокируют всю почту определенного размера и этого человека при отправке вам огромных файлов iso)
2) Получатель: ну, похоже, вы проверили большинство вещей на своей конечной точке. И вы получаете все остальные письма (ну, исключите еще одного отправителя). Осталось только проверить, получаете ли вы свою почту напрямую или через третье лицо.
3) Если почтовый сервер отправителя не связывается с вашим почтовым сервером напрямую, а использует непрямой маршрут, тогда у вас есть несколько дополнительных мест, где что-то может пойти не так. Все вне вашего контроля.
Лично я столкнулся с аналогичной проблемой, когда спамеры начали размещать спам в файлах PDF. Все или почта была получена через агентство по фильтрации спама, и они решили, что все PDF-файлы не вызывают подозрений. Эти письма были гарантированы, и конечный получатель получал раз в неделю письмо, в котором говорилось, что у него есть гарантированные письма. (Настройка один раз в неделю была явно установлена пользователем и сразу же забыта). Что-то подобное могло быть.
Что вам нужно сделать, так это сказать администраторам почты в этих доменах (и вашим пользователям, если применимо), что вы можете доставлять только почту, которая действительно приходит. Если он не поступает в ваши системы, вы ничего не можете с этим поделать, точка.
Мне, как администратору Domino или Exchange, десятки раз навязывали эту «проблему», и ответ всегда был один и тот же. Проблема на стороне отправителя (и видел ли я когда-нибудь таких отсталых) или где-то между вами и ними. В любом случае, это выходит из-под вашего контроля, и вы ничего не можете с этим поделать.
«Эй, [другой почтовый администратор], твое дерьмо сломано. Исправь» приходит на ум как шаблонный ответ, который я хотел бы давать каждый раз, когда он всплывает.
это происходит со всей почтой из определенных доменов? Если вы обратитесь к их ИТ-отделу, с каких IP-адресов они будут отправлять сообщения?
Если они всегда терпят неудачу, они должны иметь уведомление о сбое и почему. Попросите их переслать сообщение об ошибке в вашу общедоступную почту, чтобы вы могли увидеть уведомление об отказе.
Вы можете проверить, была ли даже попытка подключения, в журналах IIS, есть ли журнал SMTP. При необходимости увеличьте уровень ведения журнала. Ищите их IP.
Это также может быть проблемой брандмауэра на вашей стороне. Если можете, попробуйте посмотреть, можете ли вы просмотреть журналы. Убедитесь, что у вас есть последние обновления.
Я также видел, что причиной этой проблемы является плохое интернет-соединение. Выполните непрерывный пинг в течение 10 минут к своему интернет-провайдеру или другому сайту, который не возражает против теста. Высокая задержка или неудачные пакеты означают, что вам нужно поговорить с вашим интернет-провайдером о линии.
Наконец, если у вас есть ресурсы, настройте Linux-сервер для фильтрации спама. Подойдет виртуальная машина, работающая на другом компьютере, которая пересылает электронную почту на ваш сервер Exchange. Если это все еще происходит, значит, вы знаете, что это не ваш почтовый сервер, и получаете дополнительный уровень фильтрации ...
Попробуйте выполнить тест telnet для каждой записи MX. Ранее я сталкивался с подобной ситуацией, которая, как выяснилось, была вызвана комбинацией системы-отправителя, всегда использующей запись MX с более низким приоритетом, и системы, которая принимала доставки только на первичном сервере. Вторичные сообщения просто проглатывали, не передавая и не возвращая обратно.
В этом конкретном случае неисправной системой была MessageLabs, принадлежащая Symantec служба фильтрации спама, операторы которой утверждали, что их система действовала таким образом, потому что, как я цитирую, «только спамеры используют вторичные ресурсы». Единственное решение, доступное мне, заключалось в том, чтобы удалить все записи MX, кроме основной, так как заказчик желал продолжать использовать MessageLabs для фильтрации.
Журнал отслеживания сообщений полезен только для писем, которые попадают в Exchange, и, в частности, для писем, доставляемых в хранилище информации. Электронные письма, заблокированные фильтрацией получателя или отправителя, не будут отображаться в журнале отслеживания сообщений, но они будут отображаться в журнале SMTP. Вам необходимо включить регистрацию в службе SMTP на сервере Exchange, поскольку это «точка входа» для электронных писем, поступающих на ваш сервер Exchange. Электронные письма, заблокированные фильтрацией подключений, не будут отображаться в журнале SMTP, поэтому вам необходимо включить ведение журнала на вашем брандмауэре или маршрутизаторе, поскольку это «точка входа» для писем, поступающих в вашу сеть. Если нет записей в журнале отслеживания сообщений, журнале SMTP или журнале вашего брандмауэра / маршрутизатора, вы можете быть уверены, что рассматриваемые электронные письма не поступают в вашу сеть и / или на ваш сервер Exchange.
Затем вам нужно убедиться, что ваш общедоступный DNS правильный, а ваши NS, MX и связанные записи A верны и разрешаются правильно. Если в вашем DNS есть неправильная конфигурация, то это потенциальная точка отказа для внешних почтовых серверов, пытающихся отправить электронную почту в ваши домены. Если есть проблемы с вашим публичным DNS, это ваша проблема, и вам нужно ее исправить.
Если в вышеупомянутых журналах нет записей, а ваш общедоступный DNS настроен и работает правильно, тогда и только тогда вы можете с уверенностью сказать, что проблема не на вашей стороне.