Exchange 2003 недоставка почты (NDR), активность спама? события 7002 и 7004
Windows Server 2003 для малого бизнеса с пакетом обновления 2 (SP2)
Версия Exchange 6.5 (сборка 7638.2: пакет обновления 2)
Этой сетью пренебрегали, и у нее были проблемы с электронной почтой в течение многих лет, и она была во многих черных списках. Меня вызвали после того, как сервер в конце концов потерпел крах... Я снова включил и запустил сервер, но проблемы с электронной почтой сохраняются.
Доставка исходящей почты носит спорадический характер. Иногда почта проходит, иногда отчет о задержанной доставке генерируется через день или более, а иногда кажется, что он проходит, но получатель никогда не получает его.
Не уверен, что спаммеры успешно используют сервер в качестве ретранслятора (см. Записи о событиях ниже после включения максимальной регистрации SMTP)...
- Пользовательские ПК, зараженные вирусами и сервером, были занесены в черный список на многих сайтах (я использовал mxtoolbox.com)
- Я очистил все компьютеры и изменил все пароли (включая администратора)
- Я запросил удаление из всех черных списков - большинство удалило листинг, некоторые занимают больше времени.
Я установил записи указателей rDNS с ISP (Comcast) - это было одной из причин некоторых из черных списков.
Я проверил, что это не открытое реле с использованием telnet, как описано здесь:
www.amset.info/exchange/smtp-openrelay.aspЯ последовал совету статьи Spamhaus & Microsoft, чтобы включить максимальное ведение журнала SMTP. http://www.spamhaus.org/faq/answers.lasso?section=isp%20spam%20issues
который направил меня к статье Microsoft KB 895853, в частности, части 2/3 под названием:
"Если пересылка почты происходит из учетной записи на компьютере Exchange, который не настроен как открытый ретранслятор".
Журнал событий приложения заполняется этим видом деятельности (ошибки с кодом 7002, 7002 и 3018):
Тип события: ошибка
Источник события: MSExchangeTransport
Категория события: протокол SMTP
Код события: 7004
Дата: 18.01.2011
Время: 7:33:29
Пользователь: N/A
Компьютер-сервер
Описание:
Это журнал ошибок протокола SMTP для идентификатора виртуального сервера 1, соединение № 621. Удаленный хост "212.52.84.180" ответил на команду SMTP "rcpt" с "550 #5.1.0 Адрес отклонен brickkk@libero.it ". Полная отправленная команда была "RCPT TO: ". Это может вызвать сбой соединения.
и это:
Тип события: Предупреждение
Источник события: MSExchangeTransport
Категория события: протокол SMTP
Код события: 7002
Дата: 18.01.2011
Время: 7:33:29
Пользователь: N/A
Компьютер-сервер
Описание:
Это журнал предупреждений протокола SMTP для идентификатора виртуального сервера 1, соединение № 620. Удаленный хост "212.52.84.170" ответил на команду SMTP "rcpt": "452 Слишком много получателей получили в этот час". Полная отправленная команда была "RCPT TO: ". Это может привести к сбою соединения.
или вариант:
Тип события: Предупреждение
Источник события: MSExchangeTransport
Категория события: протокол SMTP
Код события: 7002
Дата: 18.01.2011
Время: 8:39:21
Пользователь: N/A
Компьютер-сервер
Описание:
Это журнал предупреждений протокола SMTP для идентификатора виртуального сервера 1, соединение № 661. Удаленный хост "82.57.200.133" ответил на команду SMTP "rcpt" со словами "421 Служба недоступна - слишком занят". Полная отправленная команда была "RCPT TO: ". Это может привести к сбою соединения.
также
Тип события: ошибка
Источник события: MSExchangeTransport
Категория события: НДР
Код события: 3018 Дата: 18.01.2011
Время: 9:49:37
Пользователь: N/A
Компьютер-сервер
Описание:
Отчет о недоставке с кодом состояния 5.4.0 был сгенерирован для получателя rfc822;denis.winckell@lalibero.it (Message-ID).
Причины: это сообщение указывает на проблему DNS или проблему конфигурации IP-адреса.
Решение. Проверьте DNS с помощью nslookup или dnsq. Убедитесь, что IP-адрес в буквальном формате IPv4.
Данные:
0000: ef 02 04 c0...
Будем весьма благодарны за любые рекомендации и / или предложения и / или тесты для выполнения.
1 ответ
Чтобы это исправить, получите новый IP-адрес для вашего сервера исходящей почты как можно скорее. Не забудьте также переназначить обратный DNS для IP-адреса. Также продолжайте удаление из черного списка. Если вы не можете получить внешний IP-адрес, рассмотрите стороннюю службу фильтрации почты или шлюз.
Как следствие, не отправляйте почту напрямую из exchange в Интернет. Если возможно, добавьте дополнительный почтовый шлюз, который позволит вам лучше управлять исходящей электронной почтой. Вы можете настроить это очень легко, если у вас есть небольшой опыт работы с Linux, а также вы можете вести хороший учет того, кто для чего использует ваш почтовый сервер. Вы также можете сделать это, включив протокол SMTP на виртуальном сервере SMTP взамен, но я считаю, что даже этот журнал немного затруднит получение точных измерений.
Если вы не можете использовать шлюз, даже если в качестве временной меры используется внешний поставщик, такой как postini или лаборатория сообщений. http://www.google.com/postini/index.html