Ситуация и правда неприятная. Возникает она по следующим причинам:

               1. на сервере получателя настроена слишком жесткая политика безопасности. Например проверяется наличие MX или  делается проверка работоспособности вашего сервера Callback, а записей в их DNS о вашем сервере нет

               2. проблема с конфигурацией DNS у вашего провайдера

               3. проблема с конфигурацией сети вашего провайдера, сети  с сервером получателя просто нет

Из перечисленного списка явно видно, что проблемы у провайдера или на сервере получателя. Можно написать им письма, позвонить. Пока они подключат инженеров, пока разберутся пройдет время. А письмо нужно отправить срочно. Что делать? Все просто, вам нужен релей — почтовый сервер у другого провайдера, который открыт только для вашего сервера. Назревает вопрос, а где его взять? Все просто, есть несколько способов:

               1. в больших и распределенных по городам компаниях всегда можно отправить почту в определенный домен или на определенный сервер через ваш почтовый сервер в другом городе

               2. купить дешевый VDS на Linux у какого-нибудь провайдера и запускать почту через него для проблемных доменов. Я пользуюсь хостингом TinyVDS, цена вопроса 9$ в месяц.  Учитывая то, что на сервере можно хранить ваш вебсайт, файлы, проводить независимые тесты с командной строки. 

               3. договориться с кем-нибудь из знакомых админов и разрешить релеи для ваших серверов для отправки почты в проблемные домены.

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

Напишите пожалуйста в комментариях о том, были ли у вас подобные проблемы и как вы выходили из ситуации.

Похожие посты:

• Linux, Sharepoint и диаграммы
• Реалии лицензирования.
• Пятничный пост про тупизм пользователей и Outlook.
• Время перемен: MS Exchange значительно уступает почтовым системам на базе Postfix + SugarCRM
• Год 2006. Итоги.

1. Создание копий всех входящие и исходящие сообщения с определенного домена/адреса в специальный ящик

               a. Начальник хочет просматривать получаемую или отправляемую корреспонденцию

               b. Ведение архива переписки опреленного отдела в компании

2. Запрет прима сообщений от определенных доменов/адресов

               a. Удаление сообщений от сервисов, запрещенных в компании — одноклассников, в контакте или ненужных рассылок

               b. Блокировка спама от компаний, у которых email постоянный, но IP адреса серверов меняются

3. Удаление сообщений извне, содержащих нецензурные выражения

               a. Очень часто приходят сообщения, содержащие от 3 до 5 нецензурных слов и ссылку

4. Установка SCL для сообщений

               a. Например, KAS на postfix или ORF метия спам в заголовке и если транспортное правило поставит SCL -7, то сообщение попадет в Junk email в Outlook

               b. Существуют белые сервисы, которые отправляют нужные сообщения и Outlook их постоянно помещает в Junk, чтобы этого не было, нужно SCL присвоить значение "-1"

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

6. Установка кастомных хедеров для дальнейшей обработке клиентскими правилами в Outlook

Наверняка существуют и другие сценарии использования, пожалуйста, расскажите о них в комментариях.

p.s. у транспортных правил есть один очень серьезный минус, который расстраивает меня очень сильно — убогость регулярных выражений. К сожалению они очень простые и приходится создавать множество записей, вместо одной

Спасибо Паше Дугаеву, Мише Шмакову и Стасу Булдакову за участие в обсуждении материала.

Похожие посты:

• Как избежать попадания писем в Junk? Весь секрет в X-MS-Exchange-Organization-SCL: -1
• Common white sender’s list in Junk e-mail filter
• Новый инструмент от Микрософт
• Время перемен: MS Exchange значительно уступает почтовым системам на базе Postfix + SugarCRM
• Вышел Rollup 1 for Exchange Server 2010 SP1

Частенько на форумах по Exchange 2007 звучит вопрос о переполненности очередей сообщениями в домены со странными именами. Если очередь очистить, то эти сообщения появляются вновь. Релей вроде закрыт, но сообщений в очередях огромное количество. Откуда взялись эти сообщения? Пользователи их явно не отправляли. Что делать?

           Давайте рассмотрим как происходит разбор адреса получателя принимающим сервером? Обычно система проверяет существование адреса получателя  и если его нет, то в SMTP сессии генерируется отбой «5.1.1 User unknown». Exchange же долгое время не умел этого делать, но с версии 2003(? я могу ошибаться) он научился проверять получателей в Active Directory(Filter recipients who are not in the directory) и генерировать отбой в SMTP сессии. Если же проверку в AD не включать, то сообщение будет полностью принято и отправителю будет сгенерирован NDR. А если адреса отправителя не существует или это адрес не имеет никакого отношения к реальному отправителю? Тогда это сообщение повиснет в очереди, а smtp сервер будет его пытаться доставить несуществующему получателю на несуществующий сервер. Подобных ситуаций нужно избегать.

Как проверить, проверяет ли ваш сервер получателей в AD? Используем telnet.

>C:\telnet ваш_сервер.ru 25
<220 myserver.exchangerus.ru Microsoft ESMTP MAIL Service ready at Fri, 15 Aug 2008

>mail from:pavel.nagaev@test.com   (адрес отправителя не важен)
<250 2.1.0 Sender OK

>rcpt to:nonexistentuser@exchangerus.ru
<250 2.1.5 Recipient OK

Вот тут внимание. Если ваш сервер выдает “250 2.1.5 Recipient OK”, но пользователя nonexistentuser@exchangerus.ru в вашем домене exchangerus.ru — нет, то это значит что никакой проверки в AD не выполняется и ваш сервер “всасывает” все сообщения для вашего домена, а потом будет пытаться отослать NDR.
После включения проверки в AD две последние строки будут выглядеть так:

>rcpt to:nonexistentuser@exchangerus.ru
<550 5.1.1 User unknown

          В Exchange 2007 проверка получателей в AD включена на Edge сервере. А если у Вас нет EDGE сервера, а только HUB сервер, что тогда? Транспортные агенты можно установить и на HUB сервер и они будут работать, но с некоторыми ограничениями.

Проверка получателей в AD включается следующей командой:

Set-RecipientFilterConfig -RecipientValidationEnabled:$true

         Заработало? Cкорее всего да. В моем случае не заработало, т.к. у меня AcceptedDomain создавался, как ExternalRelay, а для него значение AddressBookEnabled установлено в $false и при изменении на Authorative значение не изменилось. Поэтому пришлось включить AddressBookEnabled на  обслуживаемых доменах вручную.

AddressBookEnabled  - этот параметр используется для разрешения фильтрации получателей в роли пограничного транспортного сервера, принимающей почту для принятого домена.

Get-AcceptedDomain | select Name,DomainType,AddressBookEnabled

Если параметр AddressBookEnabled  стоит в False, то нужно его установить в True, например так.

Get-AcceptedDomain | set-AcceptedDomain –AddressBookEnabled:$true

            Потом проверяйте с помощью telnet, как я описал выше. Вы должны получить «550 5.1.1 User unknown» для не существующего адреса в вашем домене и количество писем в очередях значительно сократится. А то сейчас мода на отключение NDR на серверах Жуть какая

Похожие посты:

• Проблемы с rbl.majordomo.ru
• NDR и #4.7.1 smtp;451 4.7.1 Temporarily rejected. Try again later
• Как мы с Сашей Трофимовым боролись с зомби в Exchange 2007
• Про Аленушку, которая ждет письмо и MAIL FROM:<> SIZE=
• Как уберечься от спама? Фигня это, нельзя от него уберечься