Так вот, в один прекрасный день, я смотрю, у меня в Junk примерно 300 сообщений.  Выглядят они вот так.

Уж какой в этом сакральный смысл я не знаю, одно или два сообщения содержали опасные аттачи и были вырезаны антивирусом. Тело текста plain. Рассылка похоже шла из вирусной сети,  все хосты разные. На рабочий емейл такое не прошло бы, т.к. у отправляющих хостов нет реверсной записи и скорее всего они в DNS Black lists, но поскольку шло через провайдера, то принималось все.

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

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

• Common white sender’s list in Junk e-mail filter
• Как избежать попадания писем в Junk? Весь секрет в X-MS-Exchange-Organization-SCL: -1
• RBL в действии.
• Новый инструмент от Микрософт
• Практическое использование транспортных правил в Microsoft Exchange Server 2007/2010

AOL всегда отличался радикальными и жесткими мерами, по отношению к отправителям сообщений из Интернет, поэтому я как увидел адрес получателя, то аж крикнул: "Это же АОЛ!". Они довольно жестко обращаются с отправителями

В нашем случае  NDR выглядел так:

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:

   myni71@aol.com

    SMTP error from remote mailer after initial connection:

    host mailin-04.mx.aol.com [64.12.138.161]: 554 5.7.1 :

    (RLY:B1) http://postmaster.info.aol.com/errors/554rlyb1.html

По ссылке AOL предоставил расширенное описание ошибки

RLY Blocks  554 RLY:B1

This error message is a dynamic block on our system. Dynamic blocks are placed on an IP address when the IP's statistics break our threshold. These are automated blocks that are removed by the system within 24 hours once the complaints are again below the threshold.

Что же произошло на самом деле? Все очень просто. По каким-то причинам отправляющий SMTP сервер mail.ru попал в блок лист серверов AOL.com. Все бы ничего, если бы можно было просто удалить сервер из этого блок листа. В нашем же случае хост может быть удален в течении 24 часов, да форму заполнять на удаление не очень просто. А что вот делать моей жене? Ждать 24 часа? Пришлось отправить с другого адреса, а что делать, если бы это была бизнес почта. Тоже ждать 24 часа?

В общем я никогда не был фанатом AOL и похоже не буду.

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

• Проблемный AOL или как не нужно защищаться от спама.
• 550 We do not accept mail from dynamic IPs. Что делать?
• Forward сообщений на внешний адрес или чудеса Categorizer.
• Про Аленушку, которая ждет письмо и MAIL FROM:<> SIZE=
• Проблемы с rbl.majordomo.ru

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня Саша Станкевич попросил опубликовать пост для того, чтобы собрать фидбек от российского сообщества о добавлении новых функций в ForeFront или Exchange для борьбы со спамом.  Этот пост разметили еще Олег и Илья. Надеюсь что в комментариях мы соберем много отзывов, они будут отправлены в Микрософт разработчикам и нас услышат. Пока речь идет о добавлении функции грейлист в продукты Микрософт и динамических белых списков о которых Саша написал ниже. 

Сашин пост без изменений:

Как-то давно я предложил одну идею, направленную на борьбу со Spam’ом. Я рассказал о ней Паше Нагаеву, Олегу Крылову и другим ребятам, занимающимся системами обмена сообщений. Они выслушали меня, подискутировали, согласились, что идея имеет рационально зерно и… И на этом, можно сказать, всё и остановилось .

Но меня, всё время, никак не оставляло то, что идея не имеет практической реализации. На TechEd 2008 в Барселоне я познакомился (а точнее меня познакомил Паша Нагаев) с Александром Николаевым. Александр уже давно живёт в Америке и является Product Manager’ом ForeFront’а. Так вот, как это обычно и бывает, я хотел связаться с Александром, дабы обсудить с ним мою идею, но всё время откладывал это в долгий ящик. Но случилось неожиданное – Александр посетил наши IT-посиделки и это дало мне тот самый толчок, которого мне так не хватало! Мало того – в кои-то веки я лично пишу об этом в блоге, хоть и не своём .

Ну что ж, достаточно интриги и буду ближе к делу. Моя идея состоит в формировании белых списков, но вся прелесть в том, что эти списки динамические! В общих чертах, как я предлагаю этого достичь:

1. Например, в Outlook’е пользователь добавляет в список надёжных отправителей домен «microsoft.com»:

2. Принимающий сервер запрашивает SPF-запись данного домена: v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4:131.107.115.212 ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all

3. В белый список заносятся все адреса из данной SPF-записи.

Причём, за сроком жизни данных адресов в белом списке будет отвечать логика DNS’а. То есть, когда срок жизни данной записи истечёт, она будет повторно запрошена, а из белого списка будут удалены или добавлены те адреса, которые были удалены или добавлены в SPF-запись.

Таким образом, мы избавляемся от рутинной работы по слежению за адресами отправляющих серверов тех отправителей, которым мы доверяем – они сами формируют наш белый список!

Выигрыш от данного механизма я вижу в следующем:

1. При использовании GreyListing’а мы можем совместить мощь данной технологии по отшибу Spam’а и убрать её главный минус – задержки в доставке.

2. Какой бы ни была технология определения Spam’а, она никогда не сможет на 100% определить является письмо легитимным или нет. Таким образом, мы можем потерять письмо от доверенного отправителя. Но если сервер такого отправителя будет у нас в белом списке, то такой потери не произойдёт.

3. Ну и наконец, дать ещё больший стимул для использования Sender-ID, то есть тех самых SPF-записей .

В общем говоря, я связался с Александром по данному вопросу, вчера мы его обсудили голосом и моя идея ему приглянулась . Но дабы сделать решение о её реализации ему необходимо собрать обратную связь от сообщества о её потенциальном применении. С этой целью я и пишу данный (крайне редкий) пост – как вы думаете, на сколько лично вам был бы полезен или даже необходим этот функционал? Если тема вызовет у вас большой интерес, можем более подробно её обсудить на одной из наших встреч «Разговоры об IT» …

P. S. Так же в разговоре Александр упомянул, что они полностью не отказались от идеи GreyListing’а .

Вот что я думаю:

Идея с одной стороны хороша, но она основывается на технологии Sender-ID. Бонус в том, что  IP адреса  собираются сразу в список, а не обрабатываются динамически. Т.е проверка осуществляется на локальном компьютере, а не запросом в Интернет. Но с этим с этим возникают новые проблемы:

1. Нарушается актуальность списков. SPF может измениться и как это отслеживать?

2. При больших объемах сообщений списки будут очень большими, проверка будет очень долгой и ресурсов будет тратится на это много.

Преимущество от использования будет только в скорости обработки входящих сообщений и уменьшение задержек грейлиста. На эффективности распознавания спама это никак не скажется.

Мне кажется эта технология должна быть частью реализации грейлиста.

Опять же, зарегистрирую я на себя домен spamsender.ru, пропишу SPF и буду рассылать спам. Эта технология не поможет.

В каждой технологии есть плюсы и минусы, но Микрософту эту мысль “скормить” нужно, т.к. она действительно может быть полезна или они воспользуются ей, как частью какой-то антиспам технологии.

Саше по любому спасибо за пост.
Похожие посты:

• Комментарии по вчерашней встрече c Александром Николаевым о Microsoft Forefront Protection 2010 for Exchange Server
• Ориентировочный график выпуска программных продуктов Микрософт на 2007 год
• Поговорим о greylisting?
• Sender ID и RBL, как базовые средства защиты от спама.
• TechEd IT Forum 2007. Барселона

Читал я тут на днях Интернет, много думал … и вычитал, что дескать MailSecurity у GFI полная ерунда.  И вспомнилась мне одна давняя история про этот MailSecurity, после которой наша компания купила сей продукт, правда потом от него отказались. Но аргумент для покупки был отличный.  Дело было так…

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

       В свое время я наткнулся на любопытный тест на сайте GFI. Заключается он в том, что Вы получаете штук 20 сообщеьний с различными эксплойтами и вирусами. Вернее они все безопасны, только после прочтения сообщений у Вас вдруг запускается notepad с каким-нибудь текстовым файлом.

         После того,  как я увидел у себя на экране парочку несанкционированных действий, то мы купили у GFI MailSecurity, который нам эти гадости вырезал. Правда он еще и русский текст корежил, но это ерунда, мы нашли другие решения и забыли про GFI MailSecurity.

Сегодня я протестировал свою систему опять. Писем пришло много, все гадости были вырезаны или  заблокированы. Что же приятно. Если интересно, протестируйте свою  почтовую систему. Много notepadов откроется?

           Хотя есть у меня подозрение, что все эти эксплойты были основаны на дырках в IE и Outlook старых версий. В последних версиях программного обеспечения дырок меньше или просто GFI про них пока не знает

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

• Заставляем Read Receipt работать как надо.
• Microsoft повышает быстродействие Outlook
• Тайм менеджмент.
• Outlook 2007 говорит "НЕТ" скриптам и формам
• Шифрование сообщений в Outlook и «mail.ru»

Причиной проблемы является то, что принимающий сервер распознал IP вашего сервера, как динамический. Причин этому может быть несколько:

• у вашего SMTP сервера нет PTR записи

• ваш SMTP сервер в HELO/EHLO представляется, как adsl-01.mydomain.ru.  Вместо adsl может быть dsl, dynamic и т.д

• IP вашего SMTP сервера принадлежит глобальному списку динамических адресов — DNSBL, разновидность RBL

Для того, чтобы этой ошибки не возникало, необходимо еще раз проверить:

• наличие PTR записи для IP вашего SMTP сервера
• что ваш SMTP сервер представляется своим внешним FQDN
• IP вашего сервера не находится в глобальной базе динамических адресов

Первых две настройки можно проверить тут в разделе “E_mail valid”, третью в по адресу: http://www.robtex.com/rbl/

Помните, что возникновение данной проблемы  — это проблема неправильной настройки DNS, SMTP сервера или конфигурации сети. 

Удачи вам и пусть подобных проблем никогда не возникает!

WIKI о протоколе SMTP
FAQ по настройке DNS для почтового сервера
VIDEO:Разговоры об ИТ. Выпуск 13. Решение проблем внешних SMTP серверов. Pavel Nagaev

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

• 504 Need to authenticate first
• Forward сообщений на внешний адрес или чудеса Categorizer.
• Проблемы с rbl.majordomo.ru
• Exchange и 451+4.7.1+Greylisting+in+action,+please+come+back+in+00:05:00
• NDR и #4.7.1 smtp;451 4.7.1 Temporarily rejected. Try again later

Как обычно, в среду пройдет еженедельный вебкаст «ExchangeRUS—Разговоры об ИТ», где ИТ-cпециалисты со всей России будут обсуждать текущие проблемы.
Тема доклада — «Диагностика проблем внешних SMTP серверов». Я расскажу о проблемах внешних SMTP серверов, с которыми приходится сталкиваться администраторам электронной почты, как эти проблемы диагностировать, какими инструментами пользоваться и как решать.

Приходите, мне кажется, что доклад будет интересным любому ИТ-специалисту, работающему с электронной почтой. Тема доклада не привязана к MS Exchange, скорее это общая информация по работе с SMTP.

После доклада я буду отвечать на вопросы по Exchange, Вася Гусев по PoSh, Саша Станкевич по Windows.

Если у вас есть тема и Вы хотели бы о ней рассказать, то, пожалуйста, напишите об этом в комментариях.

В случае возникновении каких-либо технических проблем с LiveMeeting мы будем писать об их устранении в комментах к этому посту.

ВХОД в LiveMeeting
(начнет работать за 30 мин до встречи)

Для участия нужна гарнитура(наушники+микрофон), Интернет и клиент Live Meeting 2007(15Mb).

Скачать запись встречи можно ниже.

VIDEO:Разговоры об ИТ. Выпуск 13. Решение проблем внешних SMTP серверов. Pavel Nagaev (886) - 17.99 MB

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

• Вебкаст «Разговоры об ИТ» состоится 4 июня 2008 (среда) с 21:00 до 23:00(MSK)
• Вебкаст «Разговоры об ИТ» состоится 18 июня 2008 (среда) с 21:00 до 23:00 (MSK). Тема «Использование Outlook»
• Вебкаст "Разговоры об ИТ" состоится 30 апреля(среда) с 21:00 до 23:00(MSK)
• Вебкаст "Разговоры об ИТ" состоится 7 мая(среда) с 21:00-23:00(MSK)
• 23 апреля(среда) с 21:00-23:00(MSK) пройдет очередной вебкаст "ExchangeRUS— Разговоры об ИТ"

В Microsoft Exchange Server существует несколько сценариев отправки сообщений:

• Отправка от своего Primary e-mail адреса
• Отправка от своего Secondary e-mail адреса
• Отправка от имени другого пользователя организации Exchange
• Отправка от имени группы
• Отправка от имени Public Folder
• Отправка от имени зайчика.

      Я напишу только о первых двух вариантах.

         Рассмотрим следующий сценарий: «Cотруднице отдела кадров Маше Голубовой с адресом  Masha@еxchаngеRUS.ru  необходимо  обрабатывать резюме приходящие на адрес ok@еxchаngеRUS.ru.  А также в ее обязанности входит отправка подтверждения о получении резюме с адреса ok@еxchаngеRUS.ru  Руководство не хочет, чтобы уведомления отправлялись с основного адреса Маши.» 

        Существует несколько способов реализации этого сценария — через Public folders, переадресацию, Shared Mailbox, Sharepoint.

        Давайте выберем самое простое решение — добавление пользователю Маше второго SMTP адреса ok@еxchаngеRUS.ru. Тогда вместе со своей основной почтой она будет получать резюме и настроив правило, сортировать их по папкам.

        Вопрос в том, как отправлять уведомления с адреса ok@еxchаngеRUS.ru?

        По умолчанию Microsoft Exchange Server отправляет письмо от Primary e-mail address и стандартными средствами отправить письмо с адреса ok@еxchаngеRUS.ru нельзя(SendAs на доп.mailbox не рассматривается). Существуют плагины к Outlook, которые позволяют это делать, но у меня четкая позиция, что плагины в большой или даже средней компании — это великое зло, начиная от их распространения на клиентов и заканчивая глюками с другими плагинами и приложениями. Проходили уже.

        Одним из решений является отправка сообщения по SMTP от имени… впрочем от любого имени. Как известно, протокол SMTP не проверяет отправителя, поэтому можно вписать любой адрес, правда если письмо попадет в спам на принимающем сервере…, но это уже другая история:-)

         Для этого настраивается дополнительная учетная запись у Маши в Outlook для отправки по протоколу SMTP с адреса ok@еxchаngеRUS.ru

        Необходимо запустить Outlook 2007 и в меню Tools\Accounts Settings\E-mail  нажать кнопку «New…» , затем «Next», выбрать «Manually conf…» и нажать «Next» два раза.  Затем заполнить форму для подключения к серверу Microsoft Exchange по SMTP.

        Хочу заметить, что поскольку почтового ящика OK не существует, то забирать почту по POP3 просто неоткуда. Поэтому имя входящего сервера  «noname», это просто текстовая строчка. В качестве smtp сервера используется корпоративный SMTP сервер на который Маше нужно авторизовываться, чтобы была возможность отправки почты наружу.

Итак, после создания новой учетной записи мы видим следующее:

       Первая — это основное (по умолчанию) подключение к Microsoft Exchange серверу по  протоколу MAPI, два остальных — это подключения по протоколу POP3/SMTP.  Последняя запись нужна Маше для отправки писем своему приятелю.

       У Маши после создания нового письма есть выбор записи от имени которой будет осуществляться отправка. По умолчанию все письма будут уходить с адреса Masha@exchangerus.ru. Для отправки с  адреса  отдела кадров нужно выбрать списка адрес ok@еxchаngеRUS.ru

Примерно это будет выглядеть так.

На картинке хорошо видно, через какую учетную запись будет отправлено сообщение.

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

Попробуйте и Вы, а мне напишите в комментарии, что понравилось, а что нет.

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

• Отправка писем в Microsoft Exchange server от имени группы
• Как мы с Сашей Трофимовым боролись с зомби в Exchange 2007
• Назад в прошлое, управляем Exchange 2003 из Vista. Эх, Микрософт
• Forward сообщений на внешний адрес или чудеса Categorizer.
• Вышел Update Rollup 5 for Exchange Server 2007 SP1

Я очень не люблю говорить на тему поддержки клиентских протоколов POP3/IMAP4 в Exchange 2007, т.к. считаю эти технологии вчерашним днем. Но есть хороший аргумент для их успешного существования — это деньги, вернее возможность создавать дешевые решения на их основе. Только вот Outlook Express и Windows Mail не хотят работать с Exchange  2007. Немного почитав Интернет и поэкспериментировав, я нашел решение этой проблемы.

        Итак, все просто. POP3/IMAP4 — протоколы для получения сообщений на клиента. Outlook Express/Windows Mail  — это бесплатные клиентские приложения к XP/Vista соответственно, с помощью которых можно работать с Exchange и здорово экономить на покупке платных клиентов, например Microsoft Outlook.

       SMTP- это протокол передачи сообщений, который используется клиентами Exchange. Вообще принято разносить анонимный и авторизованный SMTP серверы. Анонимный предназначен для приема писем из Интернет, авторизованный  — от ваших пользователей сети. Разделение обычно осуществляется обычно по IP адресам или портам.

       В Exchange 2007 за прием сообщений по SMTP отвечают два, созданных по умолчанию, коннектора. Один работает по 25 порту и предназначен для приема почты из Интернет, второй по 587 порту и предназначен для отправки сообщений  по шифрованному каналу. Беда в том, что Outlook Express в Windows XP SP2 и Windows 2003 SP1, а также Windows Mail в Vista, не могут отправлять сообщения на порты, отличные от 25го.

Что же делать? Все просто, Microsoft выпустила несколько патчей, которые нужно скачать и установить по ссылке ниже. Проверено на XP, работает

A mail program cannot connect to an Exchange Server 2007 server by using SSL over SMTP port 587

Полезные ссылки:

Как конфигурировать IMAP4 и POP3 в Exchange 2007

p.s. Интересно, включен ли этот хотфикс в SP3 для XP и SP1 для Vista? Если у кого будет возможность проверить — напишите.

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

• Отправка писем в Microsoft Exchange server с Secondary SMTP адреса
• Microsoft предоставил возможность попробовать Exchange 2007 бесплатно.
• Высокая доступность транспорта в Exchange 2007
• 550 We do not accept mail from dynamic IPs. Что делать?
• Учетная запись Administrator не работает с POP3/IMAP4 в Exchange 2007

Пользователь на сервере Exchange 2003 отправляет e-mail с Pavel@mydomain.ru на JR@externalcompany.com.

Ему почти сразу возвращается отбой:

Your message did not reach some or all of the intended recipients.

      Subject:         Hotel room
      Sent:               30.04.2008 10:24
The following recipient(s) cannot be reached:

JR@externalcompany.com on 30.04.2008 10:26
            You do not have permission to send to this recipient.  For assistance, contact your system administrator.
            <myserver.mydomain.ru #4.7.1 smtp;451 4.7.1 Temporarily rejected. Try again later.>

        Все бы ничего, но только какого черта код ошибки 4.7.1? Я всегда считал, что   сервер будет пытаться отправить сообщение в течение двух дней согласно установленных интервалов и если сообщение не может быть доставлено, то пришлет NDR. В этом случае может быть код временной ошибки, но отбой пришел в течение 5 минут.

Вопрос, почему отбой пришел не с ошибкой 5.7.1, а 4.7.1. Смотрим логи.

06:24:19 220+mailf01.externalcompany.com+Microsoft+ESMTP+MAIL+Service, 0
06:24:19 EHLO myserver.mydomain.ru 0
06:24:19 250-mailf01.externalcompany.com+Hello+[81.211.51.161] 0
06:24:19 MAIL FROM:<Pavel@mydomain.ru>+SIZE=10634 0
06:24:20 250+2.1.0+Pavel@mydomain.ru….Sender+OK 0
06:24:20 RCPT TO:<JR@externalcompany.com> 0
06:24:20 451+4.7.1+Temporarily+rejected.+Try+again+later. 0
06:24:20 RSET — 0
06:24:20 250+2.0.0+Resetting 0

        По логам видно, что принимающий сервер отбил с временной ошибкой 4.7.1+Temporarily+rejected. В наше время Greylistingа это вполне нормальная ситуация, только обычно об этом пишут в отбое.

        В следующем куске лога видно, что через 1:23 мой сервер возобновил попытку отправки. Тоже странно, Glitch interval должен быть 60 сек, а не 123сек, но это отдельная история. Так вот,  во второй попытке видно, что отбой 5.7.1 идет после BDAT, значит, на этот раз отбил какой-то Content filter по причине содержимого письма.

06:25:43 220+mailf01.externalcompany.com+Microsoft+ESMTP+MAIL+Service, 0
06:25:43 EHLO myserver.mydomain.ru 0
06:25:43 250-mailf01.externalcompany.com+Hello+[81.211.51.161] 0
06:25:43 MAIL FROM:<Pavel@mydomain.ru>+SIZE=10634 0
06:25:43 250+2.1.0+Pavel@mydomain.ru….Sender+OK 0
06:25:43 RCPT TO:<JR@externalcompany.com> 0
06:25:44 250+2.1.5+JR@externalcompany.com+ 0
06:25:44 BDAT 10634+LAST 0
06:25:44 550+5.7.1+Message+rejected. 0
06:25:44 QUIT — 0

        После этого мой сервер генерит NDR, но только внимание!!! Вместо того, чтобы поставить в NDR ошибку 550+5.7.1+Message+rejected,  он ставит 451+4.7.1+Temporarily+rejected.+Try+again+later.
Почему — непонятно.

       Если есть идеи, напишите, подумаем вместе. Сваливать это на глюк Exchange 2003 совсем не хочется.

       Я гонял телнетом принимающий сервер, у него действительно стоит какой-то фильтр, который отбивает на минуту все входящие соединения с временной ошибкой 4.7.1.

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

• 504 Need to authenticate first
• Про Аленушку, которая ждет письмо и MAIL FROM:<> SIZE=
• Проблемы с rbl.majordomo.ru
• Exchange и 451+4.7.1+Greylisting+in+action,+please+come+back+in+00:05:00
• Exchange 2007, не работает проверка получателей в AD?