Sender whitelist (белый список) отправителей для Exchange 2003
Обратите внимание на дополнения к этой статье, разрешающие возникшие проблемы с linkd.
Борьба со спамом, как правило, приводит к необходимости ведения белых списков. Причём не только по ip адресам. Приведу в пример ситуацию, которую сегодня пришлось решать. Имеем домен отправителя @domain.de. Домен обслуживается на серверах “ведущего телекома Германии”. Однако, при этом спамеры успешно используют почтовый сервис этого провайдера для рассылки спама. Как результат – его серверы постоянно влетают в DNSBL (заслуженно). SPF они не публикуют, поэтому определить ip их адресов достоверно, чтобы прописать в белый список по ip адресам, не представляется возможным.
Да и не возникает желания принимать от них всю почту, спама идёт до чёрта. Итого, есть желание обеспечить приём почты с этих серверов только в том случае, если в MAIL FROM мы видим интересующие нас адреса. Другими словами, хотим организовать белый список отправителей на Exchange 2003.
Сам Exchange нам такой возможности не предоставляет. Он предоставляет нам только чёрный список отправителей. Однако, есть обходное решение для exchange 2003. Сделаю акцент на тонкостях, которые не указаны в этом рецепте.
-
Проверим, где у нас на самом деле для интересующего нас сервиса SMTP находятся папки pickup, filter и так далее. Для этого, естественно, воспользуемся IIS Metabase Explorer. Видим три параметра, которые помогут нам в этом: QueueDirectory, PickUpDirectory, BadMailDirectory.
Также уточнить значение этих параметров можем через powershell:$SMTPServiceIndex = 1 $SMTPServerSettings = Get-WmiObject ` -namespace "root\MicrosoftIISv2" ` -class IIsSmtpServerSetting ` -filter ("Name='SmtpSvc/$($SMTPServiceIndex)'") $SMTPServerSettings.QueueDirectory $SMTPServerSettings.PickUpDirectory $SMTPServerSettings.BadMailDirectory
-
Смущает тот факт, что параметра FilterDirectory нет (или какого-либо аналогичного). Как только мы активируем архивацию сообщений от контрагентов из чёрного списка, сообщения (файлы) будут размещены в каталоге Filter. Каталог по умолчанию создаётся в родительском каталоге QueueDirectory.
P.S. Про архивацию и разбор спама также можно почитать здесь. -
Нет смысла менять значение параметра PickupDirectory в метабазе. Это значение сбрасывается в исходное при остановке сервиса SMTP. Если его и менять, то в AD через ADSI. В данном случае метабаза IIS вторична. Итак, в нашем случае мы изменим местоположение PickUpDirectory на “D:\mailroot\vsi 1\PickUp” через оснастку ADSI (параметр msExchSmtpPickupDirectory).
-
Перезапускаем SMTP сервис.
-
Проверяем метабазу IIS. Параметр PickupDirectory должен получить то значение, которое мы и хотели – не на системном диске.
-
Теперь создаём “папку”, в которую будем сохранять “отфильтрованные” сообщения от контрагентов из белого (бывшего чёрного) списка:
cd /d "d:\mailroot\vsi 1" linkd filter pickup
Мы создали не папку, а NTFS junction point. Следует понимать, что теперь pickUp и Filter – один и тот же ресурс. -
Перезапускаем SMTP сервис.
На этом всё, собственно говоря. Теперь письма от контрагентов из указанного списка, минуя DNSBL (до них дело просто не дошло) попадает в папку flter, она же – pickup, откуда уже возвращается в очередь SMTP, но уже как локальное письмо, к которому уже, естественно, DNSBL уже применены быть не могут. И – письмо доставлено!
Вот такой вот белый список отправителей для Exchange 2003. Позднее добавлю скрипт, обеспечивающий загрузку списка из файла и его выгрузку в файл.
Отзывы » (3)
RSS комментарии
Обратная ссылка
Нашёл ещё одну любопытную статью на эту тему.
Возникли проблемы. Если связать папки filter и pickup с помощью linkd, сообщения от отправителей из нашего «белого списка» просто не доходят, точнее — не доходят сообщения с объёмом более определённого порогового значения. Если же оставить эти папки разными и «перекладывать» сообщения в pickup иным способом — всё работает замечательно. Причина подобного поведения на текущий момент мне не ясна. Ищу обходные пути.
Обходной путь найден!