Вопросы безопасности в Lotus Notes и Domino 7

Контроль спама при помощи Domino 7

Разбить на страницы
Показывать лекцию целиком

В этой лекции рассматриваются новые и усовершенствованные возможности, имеющиеся в Domino 7, которые помогут вам справиться со все возрастающей проблемой почтового спама.

За более подробной информацией о спаме и Domino обращайтесь к пуб- ликации "Lotus Domino 6 spam Survival Guide for IBM @server", SG24-6930, по адресу http://www.redbooks.ibm.com/abstracts/sg246930.html

Если вам нужно создать для вашей организации фильтр спама, вы можете использовать функции Domino для управления почтой. Мы предлагаем в этой лекции обзор всех связанных с этим вопросом параметров конфигурации, а также подробно рассматриваем новые возможности, относящиеся к "белым спискам"Белый список – список благонадежных имен, противоположность "черному списку". Примеч. пер .. В некоторых случаях вы, возможно, захотите воспользоваться услугами сторонних производителей. Это может быть программное обеспечение, аппаратное обеспечение или услуги. Мы не включаем в эту книгу вопросы, связанные с использованием инструментов и услуг сторонних производителей.

Поскольку в Domino 7 появились "белые списки" для имен Domain Name System (DNS), мы включили в книгу информацию о том, как настроить DNS так, чтобы можно было применить ее для поиска благонадежных DNS-имен. Тема DNS заслуживает отдельной книги, но для наших целей мы используем лишь несколько шагов, связанных с ее работой, для чего не требуется (почти) предварительных знаний DNS. Мы применим для настройки необходимых файлов программное обеспечение DNS-сервера Microsoft и DNS Manager. Важно понимать, что в этих настройках не учитываются вопросы безопасности, связанные с обслуживанием DNS. Описываемые здесь "белые списки" DNS ориентированы на низкий и средний объем почтового трафика в полностью защищенной сети интранета. Помните, что доступ к "белым спискам" DNS нужен только вашему SMTP-серверу.

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

Фильтры спама – это не только техническая проблема: вам нужны политики, учитывающие все ваши почтовые нужды. За дополнительной информацией по этой теме обращайтесь к подразделу 8.3.1, "Почтовые политики и обучение пользователей".

8.1 SMTP

Понимание контроля спама начинается с понимания протокола Simple Mail Transfer Protocol (SMTP), а также присущих ему слабых мест. В примере 8.1 показано, как можно осуществлять взаимодействие с SMTP-сервером при помощи клиента Telnet и послать короткое, но полное с технической точки зрения и вполне корректное почтовое сообщение на этот сервер.

Строки, начинающиеся с >, являются командами от SMTP-сервера-отправителя . с именем dieter.stdi.com.

Строки, начинающиеся с <, являются ответами SMTP-сервера-получателя с именем whistler.groofty.com.

>Telnet whistler.groofty.com 25
<220 groofty.com ESMTP Service (Lotus Domino Release 7.0) ready at Thu, 3 Nov 20 05
>HELO dieter.stdi.com
<250 groofty.com Hello dieter.stdi.com ([9.33.85.84]), pleased to meet you
>MAIL FROM: <dstalder@stdi.com>
<250 dstalder@stdi.com... Sender OK
>RCPT TO: <system@whistler.groofty.com>
<250 system@whistler.groofty.com... Recipient OK
>DATA
<354 Start mail input; end with <CRLF>.<CRLF>
>From: dstalder@stdi.com
>Subject: Test SMTP Message
>Test line 1
>Test line 2
>.
<250 Message accepted for delivery
<221 groofty.com SMTP Service closing transmission channel

Итак, по примеру 8.1:

  • Когда соединение установлено, сервер Domino записывает информацию о соединении в файл журнала сервера и отвечает сообщением 220.
  • Команда HELO. Сервер-отправитель посылает приветствие, сообщая собственное имя хоста. Спамеры часто сообщают фальшивое имя. Сервер-получатель отвечает сообщением 250.
  • Команда MAIL FROM. Сервер-отправитель посылает e-mail-адрес отправителя. Спамеры почти всегда дают фальшивый адрес. Сервер Domino записывает эту информацию в файл журнала сервера (если logging level=verbose) и отвечает сообщением 250.
  • Команда RCPT TO. Сервер-отправитель посылает e-mail-адрес получателя (получателей). Сервер Domino Domino записывает эту информацию в файл журнала сервера (если logging level=verbose) и отвечает сообщением 250. Сообщение будет доставлено по всем существующим адресам получателей, указанным в этой команде.
  • Команда/блок DATA. Сервер-отправитель посылает заголовки и тело сообщения. Это собственно само сообщение, и оно может иметь несколько разных форматов. Важно понимать, что сервер-получатель не производит доставку по адресам, указанным в заголовках To, Cc и Bcc.
  • По завершении передачи прием блока DATA подтверждается сообщением 250. Сервер Domino записывает сообщение о завершении соединения в журнал сервера. В этот момент сообщение находится в файле MAIL.BOX сервера в ожидании доставки.
    •

    8.2 Технологии, используемые спамерами

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

    Приведенный в этом разделе список методов никоим образом не является полным. Чтобы быть в курсе современных спамерских технологий, вы можете начать с проекта Spamhaus: http://www.spamhaus.org

    Сбор e-mail-адресов

    Сбор e-mail адресов (harvesting) – это получение адресов с Web-сайтов, сайтов Usenet, директорий LDAP и любых других мест, где хранятся e-mail-адреса.

    Инструкции, которые вам предлагается выполнить, чтобы удалить свой адрес из списка рассылки, часто являются лишь методом проверки существования вашего адреса. Простого открытия сообщения может быть достаточно для проверки существования. Изображения в почтовом сообщении могут быть взяты со спамерского Web-сайта и могут содержать код для идентификации получателя.

    Проверка существования адреса

    Проверка существования адреса – это еще одна форма сбора адресов, в которой используются инструменты, проверяющие адрес путем соединения с SMTP-сервером. Эти инструменты не посылают почтовые сообщения. Они посылают команду RCPT TO и проверяют ответ сервера. В зависимости от ответа адрес принимается или отвергается. В примере 8.2 показаны 3 основных ответа: 250 Recipient OK (Пользователь существует), 550 No such user (Нет такого пользователя) и 554 Relay rejected (В передаче отказано).

    >Telnet whistler.groofty.com 25
<220 groofty.com ESMTP Service (Lotus Domino Release 7.0) ready at Thu, 3 Nov 20 05
>HELO spammer.stdi.com
<250 groofty.com Hello spammer.stdi.com ([9.33.85.84]), pleased to meet you

>MAIL FROM: <spammer@groofty.com>
<250 spammer@groofty.com... Sender OK

>RCPT TO: <albert@toronto.stdi.com>
<250 albert@toronto.stdi.com... Recipient OK

>RCPT TO: <bob@toronto.stdi.com>
<550 bob@toronto.stdi.com... No such user

>RCPT TO: <bob@ibm.com>
<554 Relay rejected for policy reasons.

>QUIT
<221 groofty.com SMTP Service closing transmission channel

    Никаких сообщений не посылается. Взаимодействие завершается до посылки блока DATA. В файле журнала сервера регистрируются установление соединения и разрыв соединения (с нулем сообщений). Если для уровня журналирования (Logging level) не будет установлено значение Verbose (Подробный), то нигде не будет никаких указаний на то, что выполнялась проверка почтовых адресов. При подробном журналировании в файл журнала сервера записываются команды MAIL FROM и RCPT TO. См. подраздел 8.5.10 "Уровень журналирования".

    Атаки на директории и угадывание имен

    По умолчанию Domino доставляет сообщения, применяя имя или фамилию пользователя, если они уникальны. Спамеры часто посылают письма, употребляя наиболее популярные имена, и надеются, что такие имена найдутся. Найти список 500 самых популярных имен можно за один щелчок мышкой. Попробуйте ввести в Google строки "имена детей" или "данные переписи" – и вы получите массу информации.

    Атаки на отказ в обслуживании (Denial-of-Service, DoS) перегружают ваш SMTP-сервер или сеть избыточным трафиком.

    Такой атаке может подвергнуться кто угодно, даже хорошо известные организации и правительственные органы. Например, вы инсталлировали сервер и не запретили ретрансляцию на SMTP-сервере. Операционная система, возможно, не имеет самых последних исправлений. В некоторых случаях атакующий может за несколько минут найти вашу систему и получить над ней контроль. Всего за несколько минут в очередь на передачу писем вашей системы могут быть загружены тысячи спамерских сообщений. При такой нагрузке система не сможет осуществлять свои обычные почтовые функции.

    Открытая ретрансляция (open relay)

    Ретрансляция – это нормальная функция SMTP, которая позволяет серверу принять сообщение и передать его другому серверу. Большая доля почтового спама распространяется через серверы-ретрансляторы, которые не проверяют, имеет ли отправитель право использовать их. Если ваш SMTP-сервер является открытым ретранслятором, который принимает почту и распространяет ее без аутентификации, спамеры могут использовать его для своих целей.

    Интернет-провайдеры, лояльные к спамерам

    Интернет-провайдеры (ISP) обеспечивают связь между континентами, между городами и в конечном счете связь с вашим домом и офисом. Большинство провайдеров Северной Америки и Европы имеют политики допустимого использования (acceptable use policies, AUP), согласно которым распространение больших объемов почты является нарушением, ведущим к завершению обслуживания, но бывают и исключения. Большинство спама исходит из Соединенных Штатов, однако Интернет позволяет спамерам выбирать провайдеров в любом месте мира. Очень часто американские спамеры используют серверы, предоставленные провайдерами других стран, где политики AUP не являются такими строгими.

    Подделка заголовка RECEIVED

    При маршрутизации сообщения SMTP-сервер-получатель добавляет в сообщение заголовок RECEIVED. В Domino эти заголовки хранятся в полях с именем RECEIVED почтового сообщения. Интернет-сообщение имеет как минимум один заголовок, RECEIVED (который был добавлен вашим собственным SMTP-сервером), а иногда намного больше. Эти заголовки обычно фальсифицируются спамерами, и их редко можно рассматривать как указание на реальный источник спамерских сообщений.

    В примере 8.3 показаны 3 заголовка. Первый заголовок (т. е. последний SMTP-сервер в пути маршрутизации) – это ваш собственный SMTP-сервер, и этой информации можно доверять. В данном примере IP-адресом сервера является 32.97.182.142, а имя – e2.ny.us.ibm.com. Этот адрес также используется для контроля входящих соединений и для проверки по "белым спискам" и "черным спискам" DNS-имен.

    "from e2.ny.us.ibm.com ([32.97.182.142]) by notes5.stdi.com with ESMTP id
2005092615444927-4653 ; Mon, 26 Sep 2005 15:44:49 -0400"

"from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com
(8.12.11/8.12.11) with ESMTP id j8QJkTDg009592 for <dstalder@stdi.com>; Mon, 26 Sep 2005
15:46:29 -0400"

"from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com
(8.12.10/NCO/VERS6.7) with ESMTP id j8QJkTEZ063346 for <dstalder@stdi.com>; Mon, 26 Sep
2005 15:46:29 -0400"
    Примечание. IP-адрес, указанный первым в заголовке RECEIVED, является IP-адресом, используемым для контроля входящих соединений и для проверки по "белым спискам" и "черным спискам" DNS-имен.

    Поддельные адреса и домены отправителя

    В поле адреса отправителя может стоять все, что угодно. Стандарт SMTP предъявляет очень мало требований, выходящих за рамки технической проверки формата сообщения, поэтому технических барьеров для фальсификации не существует. Спамеры используют это для того, чтобы представиться доверенным отправителем, например ibm.com. Когда вы откроете такое сообщение, вы можете обнаружить, что оно вовсе не от IBM. Существует две инициативы по вводу стандартов, которые будут решать эту проблему. Первая инициатива – DomainKeys использует что-то вроде цифровой подписи в почтовом сообщении. Другая инициатива – Sender Policy Framework (SPF) использует DNS для идентификации хоста-отправителя. За дополнительной информацией об этих предлагаемых стандартах обращайтесь . к разделу 8.7, "Будущее спама".

    Фишинг и фарминг

    Фишинг (phishing) стал популярен в начале 2004 г. Мошенники-фишеры пытаются убедить вас, что им нужно проверить кое-какую вашу персональную информацию (кредитную карту, банковский PIN-код, номер социального страхования и т. п.). Предоставленная ссылка ведет на сайт-ловушку, похожий на официальный Web-сайт организации, которой, по их мнению, вы доверяете. Вся информация, введенная ничего не подозревающим пользователем, применяется для преступных целей. За дополнительной информацией обращайтесь на сайт Anti-Phishing Working Group (APWG) по адресу http://www.antiphishing.org

    8.3 Как избежать спама

    Лучшее решение в борьбе против спама – это всячески избегать его. Если ваш почтовый адрес знают только самые близкие бизнес-партнеры, все должно быть в порядке. Вы будете точно знать, кто посылает сообщение, и сможете настроить конфигурацию так, чтобы принимать сообщения только из этих доменов. Но эта модель больше не работает. Однако существуют и другие способы защитить свои почтовые адреса.

    8.3.1 Почтовые политики и обучение пользователей

    Лучшие способы избежать спама – это обучение пользователей и реализация политик. Некоторые Web-сайты могут помочь вам определить политику. Хорошей отправной точкой будет следующий сайт: http://www.emailreplies.com

    Ключевыми вопросами для любой организации являются следующие:

  • Формат почтовых сообщений. Определите структуру почтового сообщения: приветствие, формат тела сообщения и подпись. Определите список рассылки: CopyTo и BCC.
  • Использование почтовой системы. Определите свой способ использования почтовой системы. Определите, как следует взаимодействовать с клиентами и поставщиками. Обозначьте действия при ответе на почтовые сообщения.
  • Что делать со спамом. Расскажите пользователям, как надо реагировать на спам. Опишите, куда следует сообщать о незаконных и оскорбительных письмах. В некоторых странах есть органы, куда можно сообщить о письмах с детской порнографией и криминальными намерениями. За подробностями обращайтесь к местным властям.
    •

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

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

    8.3.2 Препятствуйте сбору почтовых адресов

    Если ваш e-mail-адрес расположен на вашем сайте, вы будете получать спам.

    Слишком смелое утверждение? К сожалению, нет. Сбор почтовых адресов является очень популярным методом спамеров. Как узнать, был ли ваш сайт просканирован? Просмотрите журнал Web-сервера Domino, который содержит все клиентские запросы и запросы от служб индексирования. Это могут быть запросы от поисковой машины или от спамера, который извлекает только почтовые адреса и URL

    На рис. 8.1 показан пример, взятый из журнала Web-сервера Domino. Пришел запрос от адреса 66.249.65.81, который присвоен Google Inc (согласно данным WHOIS). В поле Browser Used (Использованный браузер) показано значение Googlebot/2.1. Наличие IP-этого адреса и данных о браузере является хорошим показателем того, что страница была получена поисковой машиной Google.

    (рис 8.1) Журнал Web-сервера Domino

    Когда поисковые машины сканируют ваш сайт, это хорошо. Если вы не хотите, чтобы ваш сайт индексировался, или вы хотите исключить часть сайта из индекса, создайте в корневой директории файл ROBOTS.TXT. Правильно работающие системы сканирования прочитают этот файл и пропустят страницы, указанные в нем. За дополнительной информацией обращайтесь по адресу http://www.robotstxt.org

    Решения для предотвращения сбора адресов

    В этом подразделе мы расскажем, как бороться со сбором адресов.

    Приложение Contact Us

    Создайте небольшое приложение Contact Us (Контактная информация), в котором пользователи могут заполнить небольшую форму, и примените его вместо размещения почтовых адресов на Web-сайте. Вместо полученных почтовых сообщений у вас будет база данных с комментариями. Вы сможете распространять эту информацию среди нужных людей и групп в вашей организации и организовывать рабочий процесс так, чтобы на все запросы вовремя давался ответ.

    Важно! В долгосрочной перспективе приложение типа Contact Us является единственным решением, которое сохранит ваш адрес от попадания к спамерам.

    Использование JavaScript для написания почтовых адресов

    Еще одним, потенциально не столь эффективным, решением является формирование e-mail-адресов при помощи JavaScript. Почтовый адрес находится не в исходном формате, а разделяется на несколько параметров JavaScript. В настоящее время это работает достаточно хорошо. Но помните, что превратить этот скрипт в e-mail-адрес может любой браузер. Если системы сбора адресов сейчас не переводят JavaScript в адреса, они смогут это делать в самом ближайшем будущем.

    В примере 8.4 показан образец строки JavaScript

    In HTML HEAD
  <script language="JavaScript" type="text/javascript">
  var ma;
  function gem(mu,md){
  ma=mu+'@'+md;
  document.write('<a href="mailto:' + ma + '">' + ma + '</a>');
  }
  </script>
In BODY
  <script language="JavaScript">
  gem("dstalder","stdi.com");
  </script>

    8.3.3 Открытая ретрансляция (open relay)

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

    Примечания. Существует 2 необходимых адреса – abuse и postmaster. Это обозначено в документе Technote 1106677, "Email Messages Addressed to "postmaster" or "abuse" are Being Delivered to the Domino Server Administrator". Такие сообщения доставляются администратору в соответствии с параметрами документа Server, если только эти адреса сами не сконфигурированы как получатели почты. Упомянутый документ можно увидеть по следующему адресу: http://www.ibm.com/support/docview.wss?uid=swg21106677

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

    Управление ретрансляцией

    На рис. 8.2 показаны описанные ниже параметры управления ретрансляцией.

  • Allow messages to be sent only to the following external internet domains (Разрешать сообщения в следующие внешние интернет-домены). Список всех интернет-доменов, для которых вы будете получать почту. Например, введите @stdi.com, если вы принимаете почту только для stdi.com. Введите stdi.com, если вы хотите принимать почту для домена stdi.com и всех его поддоменов (например, @mail.stdi.com, @ca.stdi.com).
  • Deny messages to be sent to the following external internet domains (Запрещать сообщения в следующие внешние интернет-домены).
    •  (рис 8.2) Управление ретрансляцией

    По умолчанию Domino ставит в это поле звездочку (*). Это запрещает ретранслировать сообщения в любой внешний интернет-домен.

    8.4 Обнаружение спама

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

    8.4.1 Атаки на директории

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

  • Атака невидима, но влияния нет. Если вы настроите сервер Domino так, чтобы он принимал почту, только если в ней указан пользователь, упоминаемый в Domino Directory (см. 8.5.4, "Контроль получателей, указанных во входящих сообщениях"), вы можете даже не узнать, что были атакованы. Но спамер может продолжать занимать потоки слушателя (listener threads), сделав систему недоступной для нормальной почты.
  • Множество задержанных (held) сообщений. Если вы настроили сервер Domino так, чтобы он хранил недоставленную почту, эти сообщения становятся задержанными (см. 8.5.9, "Удержание недоставленных сообщений").
  • Множество зависших (dead) сообщений. Если вы используете настройки по умолчанию, сообщения, которые не были доставлены, будут возвращаться отправителю (отчет о невозможности доставки). В большей части спама в качестве адресов отправителей используются несуществующие адреса. Когда сервер Domino отправляет уведомление о невозможности доставки, оказывается, что отправитель не существует. Когда адресат отсутствует, сообщение получает статус зависшего (dead message). И проблема даже не в том, что зависшие сообщения остаются в почтовом ящике. Прежде чем изменить статус сообщения, сервер Domino пытается послать уведомление о невозможности доставки. Это расходует системные ресурсы и может сделать сервер недоступным для важных почтовых сообщений.
    •

    Просматривая журнал сервера, вы можете обнаружить сообщение, у которого много получателей, из которых только один или два являются допустимыми. Если вы просмотрите задержанные сообщения в почтовом ящике сервера, вы, возможно, заметите, что некоторые из этих сообщений имеют одинаковые или сходные строки Subject (Тема) (пример 8.5).

    10/23/2005 09:58:01 AM SMTP Server: mx04.ca.mci.com (142.77.2.24) connected
10/23/2005 09:58:01 AM SMTP Server: Recipient: <carpenter@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chandler@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chapman@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cohen@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <conner@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cruz@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cummings@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniel@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniels@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dawson@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <delgado@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dennis@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <douglas@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <duncan@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dunn@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <ferguson@stdi.com>

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

    8.4.2 Фишинг и фарминг

    Терминами "фишинг" (phishing) и "фарминг" (pharming) называются почтовые сообщения, целью отправителя которых является кража персональной информации о получателе. В большинстве случаев отправитель выступает в роли представителя официальной организации, которому нужно проверить персональную информацию. Лучшей защитой афер от данного типа является обучение пользователей.

    За дополнительной информацией обращайтесь по адресу http://www.antiphishing.org

    8.5 Блокирование спама

    В этом разделе мы опишем методы блокирования спама.

    8.5.1 "Белые списки" и "черные списки"

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

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

    Для черных и белых списков существуют варианты – личный список (private) и список DNS. В личный список можно ввести доменное имя или IP-адрес.

    DNS-вариант черных списков не является новым, но личный черный список, а также личный белый список и белый список DNS являются новинкой версии 7.

    На рис. 8.3 показаны параметры черного списка DNS , белого списка DNS, лично- го черного списка и личного белого списка.

    (рис 8.3) Черный список DNS, белый список DNS, личный черный список и личный белый список

    В личном черном и белом списках, а также во всех других полях документа Server, в которые можно вводить имена хостов и IP-адреса, конкретные IP адреса должны заключаться в квадратные скобки, например [192.168.100.128]. Вы также можете указывать диапазоны адресов, например [192.168.100.128.255], а также можно использовать символы-шаблоны, например [192.168.128.144.*].

    Новая возможность Domino 7 позволяет вам вводить адреса в формате бесклассовой междоменной маршрутизации – Classless Inter-Domain Routing (CIDR), например [192.168.0/16]. При использовании этого формата нужно соблюдать осторожность, поскольку интерпретация данного формата в Domino несколько отличается от стандартной. Строка CIDR [207/8] должна быть эквивалентна [207.0/8], но Domino неверно интерпретирует строку [207/8], так что, если вам нужно указать весь диапазон адресов классов A, B или C, обязательно используйте в строках CIDR символы ".0".

    Данные поля могут сильно разрастаться, и прямой ввод в них адресов может способствовать таким ситуациям, когда объем данных в документе Server превышает общий предел размера буфера. Избежать этого можно, вводя в эти поля имена групп и указывая имена и адреса хостов (в тех же форматах) в этих группах.

    Упомянутые 4 варианта списков обрабатываются в такой последовательности:

  • Личный белый список.
  • Личный черный список.
  • Белый список DNS.
  • Черный список DNS.
    •

    Личный черный список и черный список DNS имеют следующие варианты: Log only (Только записать в журнал), Log and tag message (Записать в журнал и маркировать сообщение), Log and reject message (Записать в журнал и отклонить сообщение).

    Личный белый список и белый список DNS имеют следующие варианты: Silently skip blacklist filters (Без уведомлений пропускать фильтры черных списков), Log only (Только в журнал), Log and tag message (Записать в журнал и маркировать сообщение).

    При использовании варианта с маркированием в сообщение добавляется новое поле. При использовании черного списка добавляется поле $DNSBLSite, а при использовании белого списка – $DNSWLSite. При маркировании для белых и черных списков DNS в этом поле сохраняется URL. При маркировании для личных черных и белых списков в этом поле хранится значение PrivateWhitelist или PrivateBlacklist. Для обнаружения этих полей и выполнения соответствующих действий вы можете применять почтовые правила.

    При использовании варианта с журналом в файл журнала сервера, в раздел Mail Routing Events (События маршрутизации почты) добавляется запись. В примере 8.6 показаны эти 4 возможных варианта.

    SMTP Server: Remote host 192.168.1.221 (list.groofty.com) found in blacklist at
PrivateBlacklist
SMTP Server: Remote host 192.168.1.221 (groofty.com) found in blacklist at sbl.spamhaus.org
SMTP Server: Remote host stdi.com (192.168.1.221) found in whitelist at PrivateWhitelist
SMTP Server: Remote host list.stdi.com (192.168.1.221) found in whitelist at
query.bondedsender.org

    8.5.2 Контроль входящих соединений

    Весь контроль входящих соединений осуществляется на основе IP-адресов. Поля SMTP при проверке не используются. Данная проверка производится до того, как сервер получает команду MAIL FROM. На рис. 8.4 показаны параметры контроля входящих соединений.

    Примечание. Между SMTP-сервером Domino и Интернетом могут находиться фильтры вирусов, почтовые шлюзы или службы сторонних производителей. В этих случаях подключающийся IP-адрес всегда будет одним и тем же. (рис 8.4) Контроль входящих соединений

    Обратите внимание на следующие параметры:

  • Verify connecting hostname in DNS field (Проверять имя соединяющегося хоста . в поле DNS). Domino производит инвертированный поиск в DNS. Для домена в DNS должна существовать запись PTR. Эта запись связывает IP-адрес и имя хоста.Примечание. Записи PTR не являются обязательными для правильной маршрутизации данных в Интернете. Многие организации не хранят эти записи в DNS. При включении этой функции соблюдайте осторожность.
  • Allow connections only from the following SMTP internet hostnames/IP addresses (Разрешать соединения со следующими именами/IP-адресами SMTP) и Deny connections from the following SMTP internet hostnames/IP addresses (Запрещать соединения со следующими именами/IP-адресами SMTP). Указываются имена хостов и IP-адреса, которым разрешено или запрещено соединение. Когда вы вводите имя хоста, Domino производит инвертированный поиск соответствующего ему IP-адреса в DNS.Примечание. Эта функция сходна с личным белым списком, хотя и не столь гибкая, поскольку в ней нет опций маркирования и записи в журнал.

    • 8.5.3 Контроль отправителей входящих сообщений

    Весь контроль отправителей входящих сообщений выполняется на основе поля MAIL FROM заголовка SMTP.

    Примечание. Не все поля заголовка сохраняются в почтовом документе. Поле MAIL FROM заголовка SMTP сохраняется в файле журнала сервера и в журнале слежения за сообщениями. Адрес в поле MAIL FROM может отличаться от адреса отправителя в пользовательском почтовом файле.

    На рис. 8.5 показаны следующие параметры контроля отправителей входящих сообщений:

    (рис 8.5) Контроль отправителей входящих сообщений
  • Verify sender's domain in DNS (Проверять домен отправителя по DNS). Domino проверяет, существует ли домен, к которому принадлежит отправитель. Домен берется из заголовка MAIL FROM. В DNS должны содержаться корректные записи MX, CNAME или A.
  • Allow/Deny messages only from the following external addresses/domains (Разрешать/запрещать сообщения только со следующих внешних адресов/доменов). Введите адреса и домены. Система Domino сравнивает поле MAIL FROM заголовка сообщения с указанными здесь адресами и доменами.
    •

    8.5.4 Контроль получателей, указанных во входящих сообщениях

    Весь контроль получателей, указанных во входящих сообщениях, выполняется на основе поля RCPT TO заголовка SMTP.

    Примечание. Не все поля заголовка сохраняются в почтовом документе. Поле RCPT TO заголовка SMTP сохраняется в файле журнала сервера и в журнале слежения за сообщениями. Адрес в поле RCPT TO может отличаться от содержимого поля SendTo (или CC) в пользовательском почтовом файле.

    На рис. 8.6 показаны следующие параметры контроля получателей, указанных во входящих сообщениях:

  • Verify that local domain recipients exist in the Domino Directory (Проверять, содержатся ли получатели из локального домена internet в Domino Directory). Domino проверяет существование получателя. Адрес получателя берется из заголовка RCPT TO сообщения.(рис 8.6) Контроль получателей, указанных во входящих сообщениях
    •

    Аllow/Deny messages intended only for the following internet addresses (Разрешать/ Запрещать сообщения, предназначенные только для следующих интернет-адресов). Введите e-mail-адреса пользователей. Например, если вы введете адрес dstalder@stdi.com в поле Deny (Запретить), то запрещается доставка почты на адрес, совпадающий с указанным. Этот пользователь по-прежнему может получать почту с адреса dieter.stalder@stdi.com.

    8.5.5 Правила сервера

    В правила сервера теперь входят маркеры BlackList и WhiteList, которые располагаются в подразделе Conditions and Stop Processing (Условия и останов обработки) раздела Actions (Действия). Для черного списка читается поле $DNSBLSite, а для белого списка читается поле $DNSWLSite. Сервер Domino сохраняет здесь URL сайта черного или белого списка DNS или строки PrivateBlacklist или PrivateWhitelist.

    На рис. 8.7 администратор использует новое правило останова обработки (Stop Processing), если сообщение помечено как входящее в черный или белый список. Сообщение может быть обработано согласно пользовательским почтовым правилам, и окончательно решение остается за пользователем.

    (рис 8.7) Правила сервера

    В правила сервера входят следующие условия и действия:

  • условия: sender (отправитель), subject (тема), body (тело), importance (важность), delivery priority (приоритет доставки), To (Кому), CC (Копия), BCC (Скрытая копия), To or CC (Кому или копия), body or subject (Тело или тема), internet domain (Интернет-домен), size (in bytes) (размер в байтах), all documents (все документы), any attachment name (любое имя вложения), number of attachments (число вложений), form (форма), recipient count (количество получателей), any recipient (любой получатель), blacklist tag (маркер черного списка), whitelist tag (маркер белого списка);
  • действия: journal this message (записать в журнал), move to database (поместить в базу данных), don’t accept message (не принимать сообщение), don’t deliver message (не доставлять сообщение), change routing state (изменить статус маршрутизации), stop processing (остановить обработку).
    •

    8.5.6 Правила почтового файла

    В правила почтового файла теперь входят маркеры BlackList и WhiteList, которые располагаются в подразделе Conditions and Stop Processing (Условия и останов обработки) раздела Actions (Действия). Для черного списка читается поле $DNSBLSite, . а для белого списка читается поле $DNSWLSite (рис. 8.8).

    В правила почтового файла входят следующие условия и действия:

  • условия: sender (отправитель), subject (тема), body (тело), importance (важность), delivery priority (приоритет доставки), Тo (Кому), СС (Копия), bcc (Скрытая копия), Тo or СС (Кому или копия), body or subject (Тело или тема), internet domain (Интернет-домен), size (in bytes) (размер в байтах), form (форма), blacklist tag (маркер черного списка), whitelist tag (маркер белого списка), all documents (все документы);
  • действия: move to folder (переместить в папку), copy to folder (скопировать в пап- ку), send copy to (послать копию), set expire date, change importance to, stop processing, Delete (don't accept message).
    •  (рис 8.8) Правила почтовых файлов

    8.5.7 Поиск адресов

    Поиск адресов определяет, каким образом e-mail-адрес соответствует всем вариантам имен в Domino.

    Когда Domino выполняет разрешение адреса получателя, допускаются любые комбинации имен из представления $Users в Domino Directory. Вы можете получить e-mail по одному имени, по одной фамилии и по любой комбинации, указанной в поле User name (Имя пользователя) документа Person. Чтобы не получать спам, рассылаемый по случайным именам и случайным фамилиям, укажите опцию Fullname only (Только полное имя) в поле Address lookup (Поиск адреса), как это показано на рис. 8.9.

    Вам нужно внести в поле User name (Имя пользователя) все допустимые почтовые адреса. На рис. 8.10 приводится пример.

    Если почтовый интернет-адрес не соответствует в точности одному из вариантов в представлении $Users, сообщение отбрасывается с предупреждением "User not found in Domino Directory" (Пользователь не найден в Domino Directory).

    За дополнительной информацией обращайтесь к документу Technote 1090405, "How to Stop Incoming Mail Addressed to Just the Last Name" и к документу Technote 1192804, "SMTP Mail Is Received by User in Spite of User's Different Internet Address in Person Document".

    (рис 8.10) Параметры поиска адреса(рис 8.9) Документ Person

    8.5.8 Только основная директория

    В большинстве систем интернет-почта принимается только для получателей, упомянутых в основной директории (primary directory. Если у вас настроена база Directory Assistance, то в почтовой интернет-маршрутизации также учитываются вторичные директории.

    (рис 8.11) Ограничить поиск имен только главной директорией

    Укажите в поле Restrict name lookups to primary directory only (Ограничить поиск имен только главной директорией) значение Enabled (Включено), как показано на рис. 8.11.

    8.5.9 Удержание сообщений, которые невозможно доставить

    (Параметр Hold undeliverable messages.) Удерживаются любые сообщения, даже сообщения Notes. Система Domino не делает различий между пользователями, которые должны получить отчет о невозможности доставки или спамерским сообщением несуществующему пользователю. Различие состоит в том, что пользователь хочет получить отчет в случае невозможности доставки, чтобы можно было отреагировать на ошибку. На рис. 8.11 показана данная возможность.

    8.5.10 Уровень журналирования (Logging level)

    Возможно, вы захотите узнать, почему уровень журналирования (Logging level) рассматривается в рамках темы, связанной с безопасностью. Ответ прост: Domino записывает содержимое заголовков MAIL FROM и RCPT TO в файл журнала сервера. Во многих случаях это единственное место, где вы можете проследить пересылку интернет-сообщения. Помните, что значения в полях адреса в заголовке сообщения не обязаны совпадать с адресами в теле сообщения. Если выбрать для уровня журналирования вариант Verbose (Подробный), то вы увидите все поля адресов из заголовка сообщения. Данный параметр показан на рис. 8.11.

    Примечание. Когда SMTP-сервер связывается с Domino, в заданной последовательности происходят (или не происходят) определенные события. Этот порядок частично определяется правилами протокола SMTP, а частично – параметрами конфигурации сервера. В этом подразделе описывается последовательность событий, а также параметры конфигурации, которые их определяют.
  • Контроль входящих SMTP-соединений: приветствие:
  • Обнаруживается входящее соединение. Информация записывается в файл журнала сервера.
  • Инвертированный поиск в DNS. Если активизированы параметры контроля входящих соединений.
  • Контроль соединения:
  • Проверить существование хоста в DNS. Контроль входящих соединений > параметр verify connecting host name in DNS (Проверять имя соединяющегося хоста в DNS).
  • Разрешить/запретить. Контроль входящих соединений > параметр allow/deny. connections only from the following SMTP Internet host names/IP addresses (Разрешать/запрещать сообщения только со следующих внешних адресов/доменов).
    •
  • Проверка доступности ретрансляций. Авторизованный пользователь (или сервер), у которого проверили имя и пароль с помощью команды AUTH может проводить ретрансляцию.
  • Фильтры: белые и черные списки:
  • личный белый список
  • личный черный список
  • белый список DNS
  • черный список DNS
  • Послать приветствие. Посылается приветствие.
  • Контроль входящих SMTP-полей: MAIL:
  • Контроль отправителя:
  • Verify sender's domain in DNS (Проверять домен отправителя по DNS). Контроль отправителей входящих сообщений.
  • Разрешить/запретить. Контроль отправителей входящих сообщений
  • Реализация:
  • контроля отправителя;
  • контроля соединения;
  • фильтры DNSBL: отвергнуть сообщение.
  • Контроль входящих SMTP-полей: RCPT.
  • Обработать адрес получателя. Поле RCPT TO в заголовке сообщения.
  • контроль получателя:
  • разрешить/запретить;
  • Verify that local domain recipients (Проверять, существуют ли получатели из локального домена).
  • Реализация:
  • контроля получателя;
  • контроля ретрансляций.
  • Контроль входящих SMTP-полей: DATA.
  • фильтр DNSBL;
  • системные почтовые правила;
  • поместить сообщение в MAILBOX.
    •

    8.6 Изучение стратегий применения возможностей версии 7

    Какие параметры конфигурации будут наиболее эффективными в вашем случае? Четкого ответа на этот вопрос не существует. Вы должны знать, как почта приходит на ваш сервер Domino. Если между сервером Domino и Интернетом находится шлюз, вы не можете использовать контроль соединений или черные и белые списки DNS. IP-адрес соединяющейся с вами машины всегда будет представлять собой IP-адрес шлюза.

    Сведем вместе все параметры конфигурации в двух сценариях – сценарии отбрасывания всего спама и сценарии приема всего спама на сервер. Поскольку в версии 7 появились белые списки, мы рассмотрим, как вы можете работать со своим собственным белым и черным списком DNS.

    8.6.1 Принимать весь спам или отклонять весь спам?

    Существует ряд ситуаций, когда прием всего спама (или, что лучше, всей почты) на сервер является наилучшим решением. Одной из ситуаций является конфигурация, в которой сервер Domino не получает напрямую почту из Интернета. Например, у вас может быть резервный SMTP-сервер, предоставленный вам интернет-провайдером, или SMTP-сервер провайдера или сервер-шлюз внутри организации. Во всех этих случаях отклонение почтового сообщения не решает проблему спама, а лишь переносит ответственность за решение данной проблемы в другое место.

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

    Существует ряд причин, по которым нужно отклонять весь спам. В данном случае у вас будет очень мало зависших (dead) сообщений (или их не будет совсем) и вы улучшите сетевую пропускную способность, поскольку тело сообщения передаваться не будет.

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

    Рассмотрим следующий список параметров:

  • Inbound intended recipients controls (Контроль получателей, указанных во входящем сообщении). Этот параметр очень эффективен для контроля входящего потока сообщений, которые имеют неправильный адрес. Сервер Domino завершит соединение, прежде чем будет передано тело сообщения, что позволит сэкономить сетевые ресурсы и освободить потоки для приема. Помните, что данный параметр имеет более высокий приоритет, чем белый список. Короче говоря, если получатель отсутствует в Domino Directory, сообщение будет отклонено (см. 8.5.4, "Контроль получателей, указанных во входящих сообщениях"). Этот параметр не уменьшает объем спама, получаемого отдельным пользователем. Это административная опция.Примечание. При включении параметра Inbound intended recipients controls (Контроль получателей, указанных во входящем сообщении) почтовый адрес проверяется по полю RCPT TO. Сервер SMTP по-прежнему будет отвечать сообщениями "250...Recipient OK" и "550...No such user" на запросы спамерских инструментов сбора почтовых адресов.
  • Hold undeliverable messages (Задерживать сообщения, которые невозможно доставить). По умолчанию данный параметр отключен (Disabled). Если вы не хотите, чтобы сообщения, которые не были доставлены, возвращались на адрес отправителя, включите этот параметр (Enabled). Помните, что задерживаются все сообщения, даже те, которые посылаются вашими пользователями. Вам нужно часто проверять файл MAILBOX на сервере и либо освобождать задержанные сообщения, либо удалять их (см. 8.5.9, "Удержание сообщений, которые невозможно доставить"). Этот параметр не уменьшает объем спама, получаемого отдельным пользователем. Это административная опция.
  • Address lookup (Поиск адресов). По умолчанию указывается значение Fullname and Local Part (Полное имя и локальный элемент). Чтобы доставка сообщений не производилась по одному имени или одной фамилии, укажите вариант Fullname only (Только полное имя). Если вы допускаете прием писем из нескольких почтовых доменов, внесите в документы Person разные почтовые адреса (см. 8.5.7, "Поиск адресов"). Этот параметр уменьшает объем почты, посылаемой пользователям, поскольку в письмах должен быть точный формат адреса.
  • Белый и черный список. Выберите поставщика черного списка, удовлетворяющего вашим требованиям. Начните с опции Log and tag (Записать в журнал и маркировать), а затем, после изучения результатов, переходите на Log and reject message (Записать в журнал и отклонить сообщение). Этот параметр может уменьшить число сообщений, получаемых пользователями.
    •

    Настройте белый список, указав в нем домены своих заказчиков. Обучайте пользователей созданию правил почтовых файлов с маркерами белых списков. Этот параметр может улучшить качество доставляемой почты.

  • Личный черный/белый список или контроль соединений? Вы можете вводить доменное имя (или IP-адрес) в любой из этих параметров. Различие в результате. Черные и белые списки позволяют вам промаркировать сообщение. Контроль соединений может лишь принимать или отвергать. Для тестирования параметра вы можете использовать личный черный список с опцией Log and tag (Записать в журнал и маркировать). Если результат вас удовлетворяет, вы можете скопировать доменное имя (или IP-адрес) в раздел Connection Control (Контроль соединений).
  • Правила сервера. Просмотрите существующие правила и дополните действия новой опцией Stop Processing (Остановить обработку). Эта опция полезна для прекращения проверки по правилу, если наблюдается совпадение. Все остальные проверки завершаются, и это позволяет улучшить производительность сервера.
    •

    8.6.2 Настройка собственного белого списка DNS

    C технической точки зрения черные и белые списки DNS работают идентично. SMTP-сервер посылает запрос, и DNS возвращает ответ "Not-Found" (Не найден) или найденный IP-адрес. В случае черных и белых списков DNS возвращается обычно адрес 127.0.0.1 (loopback), но Domino не делает различий между возвращаемыми адресами, любой адрес считается совпадающим.

    Если вы хотите настроить свой собственный белый список DNS, вам нужно собрать IP-адреса ваших отправителей, которые вы хотите включить в белый список. Эта задача не сводится к поиску домена и вводу соответствующего IP-адреса. В настоящее время нет общепринятого стандарта, который требовал бы, чтобы в DNS была запись, относящаяся к SMTP-серверу-отправителю. Помните, что SMTP-сервер-отправитель организации не обязан быть тем же самым, что и SMTP-сервер-получатель, и часто они действительно не совпадают, поэтому зарегистрированные записи Mail Exchanger (MX), относящиеся к домену, не обязательно будут теми самыми, которые вы хотите внести в белый список. Единственным доступным для вас источником будет файл журнала сервера, где IP-адрес записывается в момент установления и разрыва соединения (пример 8.7).

    SMTP Server: mail2.kai-shin.com (9.33.85.111) connected
...
SMTP Server: mail2.kai-shin.com (9.33.85.111) disconnected. 1 message[s] received

    Следующий этап – это добавление IP-адреса в белый список DNS.

    Как работает поиск DNS?

    Поиск DNS для черных и белых списков, а также для других видов запросов работает, по сути, одинаково. DNS-клиент (т. е. ваш SMTP-сервер) вызывает DNS-сервер, сконфигурированный в вашей операционной системе. В Microsoft Windows настройка DNS является частью сетевой конфигурации.

    Рассмотрим следующие моменты:

  • Отправка почты. Когда SMTP-серверу требуется IP-адрес домена, он выполняет стандартный запрос к DNS, запрашивая запись MX (записи MX (mail exchange) – это записи для обмена почтой, которые относятся к приему почты). DNS-сервер в ответ посылает все записи MX и связанные с ними записи об адресах. SMTP-сервер выбирает запись с наибольшим приоритетом и запускает передачу почты.
  • Получение почты. По умолчанию ваш SMTP-сервер принимает почту для вашего домена без запросов к DNS. Поиск в DNS можно запустить с помощью нескольких параметров конфигурации:
  • если ввести имя хоста в Relay and Connection Controls (Контроль ретрансляции и соединений), SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • включение черного и белого списка DNS;
  • если ввести имя хоста в личный черный или белый список, SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • если включить (Enabled) параметр Verify connecting hostname in DNS (Проверять по DNS имя соединяющегося хоста), SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • если включить параметр Verify sender’s domain in DNS (Проверять домен отправителя по DNS), SMTP-сервер будет выполнять поиск имени (перевод имени в IP-адрес).
    •
  • Поиск по черному/белому списку DNS. Когда SMTP-сервер производит поиск, он проверяет, указан ли отправитель в каком-нибудь черном или белом списке. Сервер выполняет запрос, указав IP-адрес. Если вы сконфигурировали белый список с именем white.stdi.com, а IP-адрес соединяющегося сервера 192.168.1.217, то SMTP-сервер отправляет прямой поисковый запрос (перевод имени в IP-адрес). Формат запроса такой: 217.2.168.192.white.stdi.com (обратите внимание на инвертированный IP-адрес). DNS отвечает сообщением "No such name" (Нет такого имени) или соответствующим IP-адресом. Обычно IP-адрес будет 127.0.0.1 (т. е. loopback).
  • Поиск по личному черному/белому списку. Если SMTP-серверу нужно сравнить отправителя с именем хоста, указанным в белом или черном списке, он сначала должен преобразовать IP-адрес отправителя в имя хоста. Сервер выполняет запрос для получения имени, соответствующего IP-адресу (запись PTR или инвертированный поиск). DNS-сервер в ответ посылает имя хоста, но не имя домена. Далее имя хоста сравнивается с личным белым или черным списком и сообщение помечается, если обнаруживается совпадение. Помните, что не для всех серверов в DNS существуют PTR-записи.

    • Настройка сервера DNS как белого или черного списка

    В качестве белого или черного списка DNS вы можете использовать любой сервер DNS. Запросы к белому или черному списку DNS представляют собой стандартные DNS-запросы. В нашем примере показан DNS-сервер Microsoft. Программное обеспечение для управления DNS от Microsoft не оптимизировано для работы с белыми списками, но DNS-сервер прекрасно работает в этом качестве, если записи добавляются вручную. Еще один вариант DNS-сервера – это BIND от Internet Systems Consortium. Вы можете найти программное обеспечение для работы с DNS для многих платформ Microsoft Windows и UNIX®. За дополнительной информацией обращайтесь по адресу http://www.isc.org

    Если вы планируете, что белый список DNS будет работать с большими по объему запросами, вам следует обратиться к следующим Web-сайтам: http://www.corpit.ru/mjt/rbldnsd.html http://cr.yp.to/djbdns.html

    Оба эти продукта предназначены для работы с большими черными (или белыми) списками.

    Важно! Если вы не знакомы с основами работы DNS, координируйте свою работу с администратором сети. Вам нужен правильно сконфигурированный файл зоны.

    В нашем примере мы создаем самостоятельный DNS-сервер, который работает только как DNS-сервер белого списка (white.stdi.com). Для правильной работы в родительском домене (stdi.com) нужно упомянуть о данном поддомене при помощи записи name server (NS). В DNS-сервере Microsoft для этого предназначена опция New Delegation. При альтернативном варианте, когда используется единственный DNS-сервер, мы можем добавлять эти записи в файл зоны stdi.com или можем создать поддомен на том же сервере.

    Настройка и конфигурирование DNS-сервера Microsoft

    В приведенных здесь примерах мы используем Microsoft Windows 2000 Server. Мы сконфигурировали Windows 2000 Server как самостоятельный сервер и инсталлировали программное обеспечение DNS-сервера.

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

    (рис 8.12) Microsoft DNS Manager

    Выполните следующие шаги:

  • Запустите DNS Manager.
  • Первая задача – это создание зоны. Зона связана с доменами и поддоменами. В нашем случае мы используем домен white.stdi.com как белый список DNS (рис. 8.12). Для создания зоны:
  • Выберите вариант DNS Standard primary (Стандартный главный), как показано на рис 8.13(рис 8.13) Конфигурирование DNS-сервера Microsoft: часть 1
  • Выберите пункт Forward lookup zone (Зона прямого поиска), как показано на рис 8.14(рис 8.14) Конфигурирование DNS-сервера Microsoft: часть 2
  • Введите имя зоны, как показано на рис 8.15(рис 8.15) Конфигурирование DNS-сервера Microsoft: часть 3
  • Примите заданное по умолчанию имя файла зоны, как показано на рис 8.16(рис 8.16) Конфигурирование DNS-сервера Microsoft: часть 4
    •  На этом этапе система подтвердит ваши ответы, и теперь все готово к инициализации DNS (рис 8.17(рис 8.17) Конфигурирование DNS-сервера Microsoft: часть 5
  • Первый шаг – это создание записи-заполнителя в конфигурационном файле DNS. Этот заполнитель упрощает первые изменения, вносимые вручную, но он не является необходимым для правильной работы. Итак, чтобы создать заполнитель:
  • Сделайте двойной щелчок по созданной DNS, чтобы обновить записи в правой части окна. Затем щелкните правой кнопкой мыши по имени домена и выберите пункт меню New Host (Новый хост), как показано на рис 8.18(рис 8.18) Конфигурирование DNS-сервера Microsoft: часть 6
  • Укажите имя домена. Введите IP-адрес 127.0.0.1? как показано на рис 8.19(рис 8.19) Конфигурирование DNS-сервера Microsoft: часть 7

    • Прежде чем мы выйдем из DNS Manager, выделите имя сервера и выберите пункт Update Server Data Files (Обновить файлы данных сервера), как показано на рис. 8.20.

    (рис 8.20) Конфигурирование DNS-сервера Microsoft: часть 8

    Выйдите из программы. С этого момента мы будем вносить изменения в файл конфигурации DNS вручную.

    Обновление файла зоны

    Откройте файл конфигурации DNS, расположенный в папке \winnt\system32\dns. Имя файла будет то, которое мы выбрали для него выше, в шаге d. Файл будет выглядеть примерно так, как показано в примере 8.8.

    ;
; Database file white.stdi.com.dns for white.stdi.com zone.
; Zone version: 4
;
@    IN SOA white.stdi.com. admin.white.stdi.com. (
     4;      serial number
     900;    refresh
     600;    retry
     86400;  expire
     3600);  minimum TTL
;
; Zone NS records
;
@    NS white.stdi.com.
;
; Zone records
;
first A 127.0.0.1

    Мы создали адресную запись first. Эта запись будет служить нам шаблоном для добавления записей белого списка.

    В следующем примере мы добавляем в белый список DNS два IP-адреса (пример 8.9).

    ...
;
; Zone records
;
first           A   127.0.0.1
2.1.168.192     A   127.0.0.1
4.156.176.207   A   127.0.0.1

    Помните, что, добавляя IP-адреса в файл зоны, их необходимо инвертировать. IP-адрес 192.168.1.2 превращается в 2.1.168.192

    Как узнать, будет ли DNS работать правильно? Используйте команду nslookup для отправки запроса к DNS, как показано в примере 8.10. Команда nslookup связывается с только что сконфигурированной DNS.

    C:\>nslookup
Default Server: cache02.ca-dns.net
Address: 142.77.2.36

> set root=192.168.1.147
> root
Default Server: [192.168.1.147]
Address: 192.168.1.147

> first.white.stdi.com
Server: [192.168.1.147]
Address: 192.168.1.147

Name: first.white.stdi.com
Address: 127.0.0.1

> 2.1.168.192.white.stdi.com
Server: [192.168.1.147]
Address: 192.168.1.147

Name: 2.1.168.192.white.stdi.com
Address: 127.0.0.1

>exit

    Первый этап – это проверка того, что SMTP-сервер использует именно то имя или адрес, которые возвращает команда nslookup. Вы можете изменить DNS при помощи команды set root. Вы можете проверить соединение, используя команду root.

    Введите имя, соответствующее адресу-заполнителю (в нашем примере – first.white.stdi.com). Сервер в ответ вернет IP-адрес 127.0.0.1. Проверьте все прочие адреса. Ответ должен быть тот же самый.

    8.7 Будущее спама

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

  • Протокол Sender Policy Framework (SPF) использует существующую систему DNS для хранения списка серверов, имеющих право посылать почту в данный домен. Когда SMTP-сервер получает сообщение, он использует для подтверждения иден- тичности сервера-отправителя простое сравнение IP-адреса отправителя с пере- численными в DNS IP-адресами. За подробностями обращайтесь по адресу http://www.openspf.org
  • Протокол DomainKeys использует две проверки. Во-первых, отправитель должен пройти аутентификацию. Во-вторых, сообщение должно пройти оценивающую систему. Система оценки предназначена для того, чтобы предотвращать или за- медлять распространение больших объемов почты. За подробностями обращайтесь на следующий сайт, где нужно перейти к пункту DomainKeys: http://antispam.yahoo.com
    •

    Система DomainKeys более сложна, и для ее принятия потребуется больше времени. SPF, напротив, уже применяется. Любой пользователь может опубликовать в DNS запись, соответствующую стандарту SPF, без обновления программного обеспечения. Поскольку это достаточно просто, крупные провайдеры уже используют эту возможность. Возможно, что оба эти стандарта будут взяты на вооружение.

    Страницы:

    В этой лекции рассматриваются новые и усовершенствованные возможности, имеющиеся в Domino 7, которые помогут вам справиться со все возрастающей проблемой почтового спама.

    За более подробной информацией о спаме и Domino обращайтесь к пуб- ликации "Lotus Domino 6 spam Survival Guide for IBM @server", SG24-6930, по адресу http://www.redbooks.ibm.com/abstracts/sg246930.html

    Если вам нужно создать для вашей организации фильтр спама, вы можете использовать функции Domino для управления почтой. Мы предлагаем в этой лекции обзор всех связанных с этим вопросом параметров конфигурации, а также подробно рассматриваем новые возможности, относящиеся к "белым спискам"Белый список – список благонадежных имен, противоположность "черному списку". Примеч. пер .. В некоторых случаях вы, возможно, захотите воспользоваться услугами сторонних производителей. Это может быть программное обеспечение, аппаратное обеспечение или услуги. Мы не включаем в эту книгу вопросы, связанные с использованием инструментов и услуг сторонних производителей.

    Поскольку в Domino 7 появились "белые списки" для имен Domain Name System (DNS), мы включили в книгу информацию о том, как настроить DNS так, чтобы можно было применить ее для поиска благонадежных DNS-имен. Тема DNS заслуживает отдельной книги, но для наших целей мы используем лишь несколько шагов, связанных с ее работой, для чего не требуется (почти) предварительных знаний DNS. Мы применим для настройки необходимых файлов программное обеспечение DNS-сервера Microsoft и DNS Manager. Важно понимать, что в этих настройках не учитываются вопросы безопасности, связанные с обслуживанием DNS. Описываемые здесь "белые списки" DNS ориентированы на низкий и средний объем почтового трафика в полностью защищенной сети интранета. Помните, что доступ к "белым спискам" DNS нужен только вашему SMTP-серверу.

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

    Фильтры спама – это не только техническая проблема: вам нужны политики, учитывающие все ваши почтовые нужды. За дополнительной информацией по этой теме обращайтесь к подразделу 8.3.1, "Почтовые политики и обучение пользователей".

    8.1 SMTP

    Понимание контроля спама начинается с понимания протокола Simple Mail Transfer Protocol (SMTP), а также присущих ему слабых мест. В примере 8.1 показано, как можно осуществлять взаимодействие с SMTP-сервером при помощи клиента Telnet и послать короткое, но полное с технической точки зрения и вполне корректное почтовое сообщение на этот сервер.

    Строки, начинающиеся с >, являются командами от SMTP-сервера-отправителя . с именем dieter.stdi.com.

    Строки, начинающиеся с <, являются ответами SMTP-сервера-получателя с именем whistler.groofty.com.

    >Telnet whistler.groofty.com 25
<220 groofty.com ESMTP Service (Lotus Domino Release 7.0) ready at Thu, 3 Nov 20 05
>HELO dieter.stdi.com
<250 groofty.com Hello dieter.stdi.com ([9.33.85.84]), pleased to meet you
>MAIL FROM: <dstalder@stdi.com>
<250 dstalder@stdi.com... Sender OK
>RCPT TO: <system@whistler.groofty.com>
<250 system@whistler.groofty.com... Recipient OK
>DATA
<354 Start mail input; end with <CRLF>.<CRLF>
>From: dstalder@stdi.com
>Subject: Test SMTP Message
>Test line 1
>Test line 2
>.
<250 Message accepted for delivery
<221 groofty.com SMTP Service closing transmission channel

    Итак, по примеру 8.1:

  • Когда соединение установлено, сервер Domino записывает информацию о соединении в файл журнала сервера и отвечает сообщением 220.
  • Команда HELO. Сервер-отправитель посылает приветствие, сообщая собственное имя хоста. Спамеры часто сообщают фальшивое имя. Сервер-получатель отвечает сообщением 250.
  • Команда MAIL FROM. Сервер-отправитель посылает e-mail-адрес отправителя. Спамеры почти всегда дают фальшивый адрес. Сервер Domino записывает эту информацию в файл журнала сервера (если logging level=verbose) и отвечает сообщением 250.
  • Команда RCPT TO. Сервер-отправитель посылает e-mail-адрес получателя (получателей). Сервер Domino Domino записывает эту информацию в файл журнала сервера (если logging level=verbose) и отвечает сообщением 250. Сообщение будет доставлено по всем существующим адресам получателей, указанным в этой команде.
  • Команда/блок DATA. Сервер-отправитель посылает заголовки и тело сообщения. Это собственно само сообщение, и оно может иметь несколько разных форматов. Важно понимать, что сервер-получатель не производит доставку по адресам, указанным в заголовках To, Cc и Bcc.
  • По завершении передачи прием блока DATA подтверждается сообщением 250. Сервер Domino записывает сообщение о завершении соединения в журнал сервера. В этот момент сообщение находится в файле MAIL.BOX сервера в ожидании доставки.
    •

    8.2 Технологии, используемые спамерами

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

    Приведенный в этом разделе список методов никоим образом не является полным. Чтобы быть в курсе современных спамерских технологий, вы можете начать с проекта Spamhaus: http://www.spamhaus.org

    Сбор e-mail-адресов

    Сбор e-mail адресов (harvesting) – это получение адресов с Web-сайтов, сайтов Usenet, директорий LDAP и любых других мест, где хранятся e-mail-адреса.

    Инструкции, которые вам предлагается выполнить, чтобы удалить свой адрес из списка рассылки, часто являются лишь методом проверки существования вашего адреса. Простого открытия сообщения может быть достаточно для проверки существования. Изображения в почтовом сообщении могут быть взяты со спамерского Web-сайта и могут содержать код для идентификации получателя.

    Проверка существования адреса

    Проверка существования адреса – это еще одна форма сбора адресов, в которой используются инструменты, проверяющие адрес путем соединения с SMTP-сервером. Эти инструменты не посылают почтовые сообщения. Они посылают команду RCPT TO и проверяют ответ сервера. В зависимости от ответа адрес принимается или отвергается. В примере 8.2 показаны 3 основных ответа: 250 Recipient OK (Пользователь существует), 550 No such user (Нет такого пользователя) и 554 Relay rejected (В передаче отказано).

    >Telnet whistler.groofty.com 25
<220 groofty.com ESMTP Service (Lotus Domino Release 7.0) ready at Thu, 3 Nov 20 05
>HELO spammer.stdi.com
<250 groofty.com Hello spammer.stdi.com ([9.33.85.84]), pleased to meet you

>MAIL FROM: <spammer@groofty.com>
<250 spammer@groofty.com... Sender OK

>RCPT TO: <albert@toronto.stdi.com>
<250 albert@toronto.stdi.com... Recipient OK

>RCPT TO: <bob@toronto.stdi.com>
<550 bob@toronto.stdi.com... No such user

>RCPT TO: <bob@ibm.com>
<554 Relay rejected for policy reasons.

>QUIT
<221 groofty.com SMTP Service closing transmission channel

    Никаких сообщений не посылается. Взаимодействие завершается до посылки блока DATA. В файле журнала сервера регистрируются установление соединения и разрыв соединения (с нулем сообщений). Если для уровня журналирования (Logging level) не будет установлено значение Verbose (Подробный), то нигде не будет никаких указаний на то, что выполнялась проверка почтовых адресов. При подробном журналировании в файл журнала сервера записываются команды MAIL FROM и RCPT TO. См. подраздел 8.5.10 "Уровень журналирования".

    Атаки на директории и угадывание имен

    По умолчанию Domino доставляет сообщения, применяя имя или фамилию пользователя, если они уникальны. Спамеры часто посылают письма, употребляя наиболее популярные имена, и надеются, что такие имена найдутся. Найти список 500 самых популярных имен можно за один щелчок мышкой. Попробуйте ввести в Google строки "имена детей" или "данные переписи" – и вы получите массу информации.

    Атаки на отказ в обслуживании (Denial-of-Service, DoS) перегружают ваш SMTP-сервер или сеть избыточным трафиком.

    Такой атаке может подвергнуться кто угодно, даже хорошо известные организации и правительственные органы. Например, вы инсталлировали сервер и не запретили ретрансляцию на SMTP-сервере. Операционная система, возможно, не имеет самых последних исправлений. В некоторых случаях атакующий может за несколько минут найти вашу систему и получить над ней контроль. Всего за несколько минут в очередь на передачу писем вашей системы могут быть загружены тысячи спамерских сообщений. При такой нагрузке система не сможет осуществлять свои обычные почтовые функции.

    Открытая ретрансляция (open relay)

    Ретрансляция – это нормальная функция SMTP, которая позволяет серверу принять сообщение и передать его другому серверу. Большая доля почтового спама распространяется через серверы-ретрансляторы, которые не проверяют, имеет ли отправитель право использовать их. Если ваш SMTP-сервер является открытым ретранслятором, который принимает почту и распространяет ее без аутентификации, спамеры могут использовать его для своих целей.

    Интернет-провайдеры, лояльные к спамерам

    Интернет-провайдеры (ISP) обеспечивают связь между континентами, между городами и в конечном счете связь с вашим домом и офисом. Большинство провайдеров Северной Америки и Европы имеют политики допустимого использования (acceptable use policies, AUP), согласно которым распространение больших объемов почты является нарушением, ведущим к завершению обслуживания, но бывают и исключения. Большинство спама исходит из Соединенных Штатов, однако Интернет позволяет спамерам выбирать провайдеров в любом месте мира. Очень часто американские спамеры используют серверы, предоставленные провайдерами других стран, где политики AUP не являются такими строгими.

    Подделка заголовка RECEIVED

    При маршрутизации сообщения SMTP-сервер-получатель добавляет в сообщение заголовок RECEIVED. В Domino эти заголовки хранятся в полях с именем RECEIVED почтового сообщения. Интернет-сообщение имеет как минимум один заголовок, RECEIVED (который был добавлен вашим собственным SMTP-сервером), а иногда намного больше. Эти заголовки обычно фальсифицируются спамерами, и их редко можно рассматривать как указание на реальный источник спамерских сообщений.

    В примере 8.3 показаны 3 заголовка. Первый заголовок (т. е. последний SMTP-сервер в пути маршрутизации) – это ваш собственный SMTP-сервер, и этой информации можно доверять. В данном примере IP-адресом сервера является 32.97.182.142, а имя – e2.ny.us.ibm.com. Этот адрес также используется для контроля входящих соединений и для проверки по "белым спискам" и "черным спискам" DNS-имен.

    "from e2.ny.us.ibm.com ([32.97.182.142]) by notes5.stdi.com with ESMTP id
2005092615444927-4653 ; Mon, 26 Sep 2005 15:44:49 -0400"

"from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com
(8.12.11/8.12.11) with ESMTP id j8QJkTDg009592 for <dstalder@stdi.com>; Mon, 26 Sep 2005
15:46:29 -0400"

"from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com
(8.12.10/NCO/VERS6.7) with ESMTP id j8QJkTEZ063346 for <dstalder@stdi.com>; Mon, 26 Sep
2005 15:46:29 -0400"
    Примечание. IP-адрес, указанный первым в заголовке RECEIVED, является IP-адресом, используемым для контроля входящих соединений и для проверки по "белым спискам" и "черным спискам" DNS-имен.

    Поддельные адреса и домены отправителя

    В поле адреса отправителя может стоять все, что угодно. Стандарт SMTP предъявляет очень мало требований, выходящих за рамки технической проверки формата сообщения, поэтому технических барьеров для фальсификации не существует. Спамеры используют это для того, чтобы представиться доверенным отправителем, например ibm.com. Когда вы откроете такое сообщение, вы можете обнаружить, что оно вовсе не от IBM. Существует две инициативы по вводу стандартов, которые будут решать эту проблему. Первая инициатива – DomainKeys использует что-то вроде цифровой подписи в почтовом сообщении. Другая инициатива – Sender Policy Framework (SPF) использует DNS для идентификации хоста-отправителя. За дополнительной информацией об этих предлагаемых стандартах обращайтесь . к разделу 8.7, "Будущее спама".

    Фишинг и фарминг

    Фишинг (phishing) стал популярен в начале 2004 г. Мошенники-фишеры пытаются убедить вас, что им нужно проверить кое-какую вашу персональную информацию (кредитную карту, банковский PIN-код, номер социального страхования и т. п.). Предоставленная ссылка ведет на сайт-ловушку, похожий на официальный Web-сайт организации, которой, по их мнению, вы доверяете. Вся информация, введенная ничего не подозревающим пользователем, применяется для преступных целей. За дополнительной информацией обращайтесь на сайт Anti-Phishing Working Group (APWG) по адресу http://www.antiphishing.org

    8.3 Как избежать спама

    Лучшее решение в борьбе против спама – это всячески избегать его. Если ваш почтовый адрес знают только самые близкие бизнес-партнеры, все должно быть в порядке. Вы будете точно знать, кто посылает сообщение, и сможете настроить конфигурацию так, чтобы принимать сообщения только из этих доменов. Но эта модель больше не работает. Однако существуют и другие способы защитить свои почтовые адреса.

    8.3.1 Почтовые политики и обучение пользователей

    Лучшие способы избежать спама – это обучение пользователей и реализация политик. Некоторые Web-сайты могут помочь вам определить политику. Хорошей отправной точкой будет следующий сайт: http://www.emailreplies.com

    Ключевыми вопросами для любой организации являются следующие:

  • Формат почтовых сообщений. Определите структуру почтового сообщения: приветствие, формат тела сообщения и подпись. Определите список рассылки: CopyTo и BCC.
  • Использование почтовой системы. Определите свой способ использования почтовой системы. Определите, как следует взаимодействовать с клиентами и поставщиками. Обозначьте действия при ответе на почтовые сообщения.
  • Что делать со спамом. Расскажите пользователям, как надо реагировать на спам. Опишите, куда следует сообщать о незаконных и оскорбительных письмах. В некоторых странах есть органы, куда можно сообщить о письмах с детской порнографией и криминальными намерениями. За подробностями обращайтесь к местным властям.
    •

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

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

    8.3.2 Препятствуйте сбору почтовых адресов

    Если ваш e-mail-адрес расположен на вашем сайте, вы будете получать спам.

    Слишком смелое утверждение? К сожалению, нет. Сбор почтовых адресов является очень популярным методом спамеров. Как узнать, был ли ваш сайт просканирован? Просмотрите журнал Web-сервера Domino, который содержит все клиентские запросы и запросы от служб индексирования. Это могут быть запросы от поисковой машины или от спамера, который извлекает только почтовые адреса и URL

    На рис. 8.1 показан пример, взятый из журнала Web-сервера Domino. Пришел запрос от адреса 66.249.65.81, который присвоен Google Inc (согласно данным WHOIS). В поле Browser Used (Использованный браузер) показано значение Googlebot/2.1. Наличие IP-этого адреса и данных о браузере является хорошим показателем того, что страница была получена поисковой машиной Google.

    (рис 8.1) Журнал Web-сервера Domino

    Когда поисковые машины сканируют ваш сайт, это хорошо. Если вы не хотите, чтобы ваш сайт индексировался, или вы хотите исключить часть сайта из индекса, создайте в корневой директории файл ROBOTS.TXT. Правильно работающие системы сканирования прочитают этот файл и пропустят страницы, указанные в нем. За дополнительной информацией обращайтесь по адресу http://www.robotstxt.org

    Решения для предотвращения сбора адресов

    В этом подразделе мы расскажем, как бороться со сбором адресов.

    Приложение Contact Us

    Создайте небольшое приложение Contact Us (Контактная информация), в котором пользователи могут заполнить небольшую форму, и примените его вместо размещения почтовых адресов на Web-сайте. Вместо полученных почтовых сообщений у вас будет база данных с комментариями. Вы сможете распространять эту информацию среди нужных людей и групп в вашей организации и организовывать рабочий процесс так, чтобы на все запросы вовремя давался ответ.

    Важно! В долгосрочной перспективе приложение типа Contact Us является единственным решением, которое сохранит ваш адрес от попадания к спамерам.

    Использование JavaScript для написания почтовых адресов

    Еще одним, потенциально не столь эффективным, решением является формирование e-mail-адресов при помощи JavaScript. Почтовый адрес находится не в исходном формате, а разделяется на несколько параметров JavaScript. В настоящее время это работает достаточно хорошо. Но помните, что превратить этот скрипт в e-mail-адрес может любой браузер. Если системы сбора адресов сейчас не переводят JavaScript в адреса, они смогут это делать в самом ближайшем будущем.

    В примере 8.4 показан образец строки JavaScript

    In HTML HEAD
  <script language="JavaScript" type="text/javascript">
  var ma;
  function gem(mu,md){
  ma=mu+'@'+md;
  document.write('<a href="mailto:' + ma + '">' + ma + '</a>');
  }
  </script>
In BODY
  <script language="JavaScript">
  gem("dstalder","stdi.com");
  </script>

    8.3.3 Открытая ретрансляция (open relay)

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

    Примечания. Существует 2 необходимых адреса – abuse и postmaster. Это обозначено в документе Technote 1106677, "Email Messages Addressed to "postmaster" or "abuse" are Being Delivered to the Domino Server Administrator". Такие сообщения доставляются администратору в соответствии с параметрами документа Server, если только эти адреса сами не сконфигурированы как получатели почты. Упомянутый документ можно увидеть по следующему адресу: http://www.ibm.com/support/docview.wss?uid=swg21106677

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

    Управление ретрансляцией

    На рис. 8.2 показаны описанные ниже параметры управления ретрансляцией.

  • Allow messages to be sent only to the following external internet domains (Разрешать сообщения в следующие внешние интернет-домены). Список всех интернет-доменов, для которых вы будете получать почту. Например, введите @stdi.com, если вы принимаете почту только для stdi.com. Введите stdi.com, если вы хотите принимать почту для домена stdi.com и всех его поддоменов (например, @mail.stdi.com, @ca.stdi.com).
  • Deny messages to be sent to the following external internet domains (Запрещать сообщения в следующие внешние интернет-домены).
    •  (рис 8.2) Управление ретрансляцией

    По умолчанию Domino ставит в это поле звездочку (*). Это запрещает ретранслировать сообщения в любой внешний интернет-домен.

    8.4 Обнаружение спама

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

    8.4.1 Атаки на директории

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

  • Атака невидима, но влияния нет. Если вы настроите сервер Domino так, чтобы он принимал почту, только если в ней указан пользователь, упоминаемый в Domino Directory (см. 8.5.4, "Контроль получателей, указанных во входящих сообщениях"), вы можете даже не узнать, что были атакованы. Но спамер может продолжать занимать потоки слушателя (listener threads), сделав систему недоступной для нормальной почты.
  • Множество задержанных (held) сообщений. Если вы настроили сервер Domino так, чтобы он хранил недоставленную почту, эти сообщения становятся задержанными (см. 8.5.9, "Удержание недоставленных сообщений").
  • Множество зависших (dead) сообщений. Если вы используете настройки по умолчанию, сообщения, которые не были доставлены, будут возвращаться отправителю (отчет о невозможности доставки). В большей части спама в качестве адресов отправителей используются несуществующие адреса. Когда сервер Domino отправляет уведомление о невозможности доставки, оказывается, что отправитель не существует. Когда адресат отсутствует, сообщение получает статус зависшего (dead message). И проблема даже не в том, что зависшие сообщения остаются в почтовом ящике. Прежде чем изменить статус сообщения, сервер Domino пытается послать уведомление о невозможности доставки. Это расходует системные ресурсы и может сделать сервер недоступным для важных почтовых сообщений.
    •

    Просматривая журнал сервера, вы можете обнаружить сообщение, у которого много получателей, из которых только один или два являются допустимыми. Если вы просмотрите задержанные сообщения в почтовом ящике сервера, вы, возможно, заметите, что некоторые из этих сообщений имеют одинаковые или сходные строки Subject (Тема) (пример 8.5).

    10/23/2005 09:58:01 AM SMTP Server: mx04.ca.mci.com (142.77.2.24) connected
10/23/2005 09:58:01 AM SMTP Server: Recipient: <carpenter@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chandler@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <chapman@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cohen@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <conner@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cruz@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <cummings@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniel@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <daniels@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dawson@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <delgado@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dennis@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <douglas@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <duncan@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <dunn@stdi.com>
10/23/2005 09:58:01 AM SMTP Server: Recipient: <ferguson@stdi.com>

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

    8.4.2 Фишинг и фарминг

    Терминами "фишинг" (phishing) и "фарминг" (pharming) называются почтовые сообщения, целью отправителя которых является кража персональной информации о получателе. В большинстве случаев отправитель выступает в роли представителя официальной организации, которому нужно проверить персональную информацию. Лучшей защитой афер от данного типа является обучение пользователей.

    За дополнительной информацией обращайтесь по адресу http://www.antiphishing.org

    8.5 Блокирование спама

    В этом разделе мы опишем методы блокирования спама.

    8.5.1 "Белые списки" и "черные списки"

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

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

    Для черных и белых списков существуют варианты – личный список (private) и список DNS. В личный список можно ввести доменное имя или IP-адрес.

    DNS-вариант черных списков не является новым, но личный черный список, а также личный белый список и белый список DNS являются новинкой версии 7.

    На рис. 8.3 показаны параметры черного списка DNS , белого списка DNS, лично- го черного списка и личного белого списка.

    (рис 8.3) Черный список DNS, белый список DNS, личный черный список и личный белый список

    В личном черном и белом списках, а также во всех других полях документа Server, в которые можно вводить имена хостов и IP-адреса, конкретные IP адреса должны заключаться в квадратные скобки, например [192.168.100.128]. Вы также можете указывать диапазоны адресов, например [192.168.100.128.255], а также можно использовать символы-шаблоны, например [192.168.128.144.*].

    Новая возможность Domino 7 позволяет вам вводить адреса в формате бесклассовой междоменной маршрутизации – Classless Inter-Domain Routing (CIDR), например [192.168.0/16]. При использовании этого формата нужно соблюдать осторожность, поскольку интерпретация данного формата в Domino несколько отличается от стандартной. Строка CIDR [207/8] должна быть эквивалентна [207.0/8], но Domino неверно интерпретирует строку [207/8], так что, если вам нужно указать весь диапазон адресов классов A, B или C, обязательно используйте в строках CIDR символы ".0".

    Данные поля могут сильно разрастаться, и прямой ввод в них адресов может способствовать таким ситуациям, когда объем данных в документе Server превышает общий предел размера буфера. Избежать этого можно, вводя в эти поля имена групп и указывая имена и адреса хостов (в тех же форматах) в этих группах.

    Упомянутые 4 варианта списков обрабатываются в такой последовательности:

  • Личный белый список.
  • Личный черный список.
  • Белый список DNS.
  • Черный список DNS.
    •

    Личный черный список и черный список DNS имеют следующие варианты: Log only (Только записать в журнал), Log and tag message (Записать в журнал и маркировать сообщение), Log and reject message (Записать в журнал и отклонить сообщение).

    Личный белый список и белый список DNS имеют следующие варианты: Silently skip blacklist filters (Без уведомлений пропускать фильтры черных списков), Log only (Только в журнал), Log and tag message (Записать в журнал и маркировать сообщение).

    При использовании варианта с маркированием в сообщение добавляется новое поле. При использовании черного списка добавляется поле $DNSBLSite, а при использовании белого списка – $DNSWLSite. При маркировании для белых и черных списков DNS в этом поле сохраняется URL. При маркировании для личных черных и белых списков в этом поле хранится значение PrivateWhitelist или PrivateBlacklist. Для обнаружения этих полей и выполнения соответствующих действий вы можете применять почтовые правила.

    При использовании варианта с журналом в файл журнала сервера, в раздел Mail Routing Events (События маршрутизации почты) добавляется запись. В примере 8.6 показаны эти 4 возможных варианта.

    SMTP Server: Remote host 192.168.1.221 (list.groofty.com) found in blacklist at
PrivateBlacklist
SMTP Server: Remote host 192.168.1.221 (groofty.com) found in blacklist at sbl.spamhaus.org
SMTP Server: Remote host stdi.com (192.168.1.221) found in whitelist at PrivateWhitelist
SMTP Server: Remote host list.stdi.com (192.168.1.221) found in whitelist at
query.bondedsender.org

    8.5.2 Контроль входящих соединений

    Весь контроль входящих соединений осуществляется на основе IP-адресов. Поля SMTP при проверке не используются. Данная проверка производится до того, как сервер получает команду MAIL FROM. На рис. 8.4 показаны параметры контроля входящих соединений.

    Примечание. Между SMTP-сервером Domino и Интернетом могут находиться фильтры вирусов, почтовые шлюзы или службы сторонних производителей. В этих случаях подключающийся IP-адрес всегда будет одним и тем же. (рис 8.4) Контроль входящих соединений

    Обратите внимание на следующие параметры:

  • Verify connecting hostname in DNS field (Проверять имя соединяющегося хоста . в поле DNS). Domino производит инвертированный поиск в DNS. Для домена в DNS должна существовать запись PTR. Эта запись связывает IP-адрес и имя хоста.Примечание. Записи PTR не являются обязательными для правильной маршрутизации данных в Интернете. Многие организации не хранят эти записи в DNS. При включении этой функции соблюдайте осторожность.
  • Allow connections only from the following SMTP internet hostnames/IP addresses (Разрешать соединения со следующими именами/IP-адресами SMTP) и Deny connections from the following SMTP internet hostnames/IP addresses (Запрещать соединения со следующими именами/IP-адресами SMTP). Указываются имена хостов и IP-адреса, которым разрешено или запрещено соединение. Когда вы вводите имя хоста, Domino производит инвертированный поиск соответствующего ему IP-адреса в DNS.Примечание. Эта функция сходна с личным белым списком, хотя и не столь гибкая, поскольку в ней нет опций маркирования и записи в журнал.

    • 8.5.3 Контроль отправителей входящих сообщений

    Весь контроль отправителей входящих сообщений выполняется на основе поля MAIL FROM заголовка SMTP.

    Примечание. Не все поля заголовка сохраняются в почтовом документе. Поле MAIL FROM заголовка SMTP сохраняется в файле журнала сервера и в журнале слежения за сообщениями. Адрес в поле MAIL FROM может отличаться от адреса отправителя в пользовательском почтовом файле.

    На рис. 8.5 показаны следующие параметры контроля отправителей входящих сообщений:

    (рис 8.5) Контроль отправителей входящих сообщений
  • Verify sender's domain in DNS (Проверять домен отправителя по DNS). Domino проверяет, существует ли домен, к которому принадлежит отправитель. Домен берется из заголовка MAIL FROM. В DNS должны содержаться корректные записи MX, CNAME или A.
  • Allow/Deny messages only from the following external addresses/domains (Разрешать/запрещать сообщения только со следующих внешних адресов/доменов). Введите адреса и домены. Система Domino сравнивает поле MAIL FROM заголовка сообщения с указанными здесь адресами и доменами.
    •

    8.5.4 Контроль получателей, указанных во входящих сообщениях

    Весь контроль получателей, указанных во входящих сообщениях, выполняется на основе поля RCPT TO заголовка SMTP.

    Примечание. Не все поля заголовка сохраняются в почтовом документе. Поле RCPT TO заголовка SMTP сохраняется в файле журнала сервера и в журнале слежения за сообщениями. Адрес в поле RCPT TO может отличаться от содержимого поля SendTo (или CC) в пользовательском почтовом файле.

    На рис. 8.6 показаны следующие параметры контроля получателей, указанных во входящих сообщениях:

  • Verify that local domain recipients exist in the Domino Directory (Проверять, содержатся ли получатели из локального домена internet в Domino Directory). Domino проверяет существование получателя. Адрес получателя берется из заголовка RCPT TO сообщения.(рис 8.6) Контроль получателей, указанных во входящих сообщениях
    •

    Аllow/Deny messages intended only for the following internet addresses (Разрешать/ Запрещать сообщения, предназначенные только для следующих интернет-адресов). Введите e-mail-адреса пользователей. Например, если вы введете адрес dstalder@stdi.com в поле Deny (Запретить), то запрещается доставка почты на адрес, совпадающий с указанным. Этот пользователь по-прежнему может получать почту с адреса dieter.stalder@stdi.com.

    8.5.5 Правила сервера

    В правила сервера теперь входят маркеры BlackList и WhiteList, которые располагаются в подразделе Conditions and Stop Processing (Условия и останов обработки) раздела Actions (Действия). Для черного списка читается поле $DNSBLSite, а для белого списка читается поле $DNSWLSite. Сервер Domino сохраняет здесь URL сайта черного или белого списка DNS или строки PrivateBlacklist или PrivateWhitelist.

    На рис. 8.7 администратор использует новое правило останова обработки (Stop Processing), если сообщение помечено как входящее в черный или белый список. Сообщение может быть обработано согласно пользовательским почтовым правилам, и окончательно решение остается за пользователем.

    (рис 8.7) Правила сервера

    В правила сервера входят следующие условия и действия:

  • условия: sender (отправитель), subject (тема), body (тело), importance (важность), delivery priority (приоритет доставки), To (Кому), CC (Копия), BCC (Скрытая копия), To or CC (Кому или копия), body or subject (Тело или тема), internet domain (Интернет-домен), size (in bytes) (размер в байтах), all documents (все документы), any attachment name (любое имя вложения), number of attachments (число вложений), form (форма), recipient count (количество получателей), any recipient (любой получатель), blacklist tag (маркер черного списка), whitelist tag (маркер белого списка);
  • действия: journal this message (записать в журнал), move to database (поместить в базу данных), don’t accept message (не принимать сообщение), don’t deliver message (не доставлять сообщение), change routing state (изменить статус маршрутизации), stop processing (остановить обработку).
    •

    8.5.6 Правила почтового файла

    В правила почтового файла теперь входят маркеры BlackList и WhiteList, которые располагаются в подразделе Conditions and Stop Processing (Условия и останов обработки) раздела Actions (Действия). Для черного списка читается поле $DNSBLSite, . а для белого списка читается поле $DNSWLSite (рис. 8.8).

    В правила почтового файла входят следующие условия и действия:

  • условия: sender (отправитель), subject (тема), body (тело), importance (важность), delivery priority (приоритет доставки), Тo (Кому), СС (Копия), bcc (Скрытая копия), Тo or СС (Кому или копия), body or subject (Тело или тема), internet domain (Интернет-домен), size (in bytes) (размер в байтах), form (форма), blacklist tag (маркер черного списка), whitelist tag (маркер белого списка), all documents (все документы);
  • действия: move to folder (переместить в папку), copy to folder (скопировать в пап- ку), send copy to (послать копию), set expire date, change importance to, stop processing, Delete (don't accept message).
    •  (рис 8.8) Правила почтовых файлов

    8.5.7 Поиск адресов

    Поиск адресов определяет, каким образом e-mail-адрес соответствует всем вариантам имен в Domino.

    Когда Domino выполняет разрешение адреса получателя, допускаются любые комбинации имен из представления $Users в Domino Directory. Вы можете получить e-mail по одному имени, по одной фамилии и по любой комбинации, указанной в поле User name (Имя пользователя) документа Person. Чтобы не получать спам, рассылаемый по случайным именам и случайным фамилиям, укажите опцию Fullname only (Только полное имя) в поле Address lookup (Поиск адреса), как это показано на рис. 8.9.

    Вам нужно внести в поле User name (Имя пользователя) все допустимые почтовые адреса. На рис. 8.10 приводится пример.

    Если почтовый интернет-адрес не соответствует в точности одному из вариантов в представлении $Users, сообщение отбрасывается с предупреждением "User not found in Domino Directory" (Пользователь не найден в Domino Directory).

    За дополнительной информацией обращайтесь к документу Technote 1090405, "How to Stop Incoming Mail Addressed to Just the Last Name" и к документу Technote 1192804, "SMTP Mail Is Received by User in Spite of User's Different Internet Address in Person Document".

    (рис 8.10) Параметры поиска адреса(рис 8.9) Документ Person

    8.5.8 Только основная директория

    В большинстве систем интернет-почта принимается только для получателей, упомянутых в основной директории (primary directory. Если у вас настроена база Directory Assistance, то в почтовой интернет-маршрутизации также учитываются вторичные директории.

    (рис 8.11) Ограничить поиск имен только главной директорией

    Укажите в поле Restrict name lookups to primary directory only (Ограничить поиск имен только главной директорией) значение Enabled (Включено), как показано на рис. 8.11.

    8.5.9 Удержание сообщений, которые невозможно доставить

    (Параметр Hold undeliverable messages.) Удерживаются любые сообщения, даже сообщения Notes. Система Domino не делает различий между пользователями, которые должны получить отчет о невозможности доставки или спамерским сообщением несуществующему пользователю. Различие состоит в том, что пользователь хочет получить отчет в случае невозможности доставки, чтобы можно было отреагировать на ошибку. На рис. 8.11 показана данная возможность.

    8.5.10 Уровень журналирования (Logging level)

    Возможно, вы захотите узнать, почему уровень журналирования (Logging level) рассматривается в рамках темы, связанной с безопасностью. Ответ прост: Domino записывает содержимое заголовков MAIL FROM и RCPT TO в файл журнала сервера. Во многих случаях это единственное место, где вы можете проследить пересылку интернет-сообщения. Помните, что значения в полях адреса в заголовке сообщения не обязаны совпадать с адресами в теле сообщения. Если выбрать для уровня журналирования вариант Verbose (Подробный), то вы увидите все поля адресов из заголовка сообщения. Данный параметр показан на рис. 8.11.

    Примечание. Когда SMTP-сервер связывается с Domino, в заданной последовательности происходят (или не происходят) определенные события. Этот порядок частично определяется правилами протокола SMTP, а частично – параметрами конфигурации сервера. В этом подразделе описывается последовательность событий, а также параметры конфигурации, которые их определяют.
  • Контроль входящих SMTP-соединений: приветствие:
  • Обнаруживается входящее соединение. Информация записывается в файл журнала сервера.
  • Инвертированный поиск в DNS. Если активизированы параметры контроля входящих соединений.
  • Контроль соединения:
  • Проверить существование хоста в DNS. Контроль входящих соединений > параметр verify connecting host name in DNS (Проверять имя соединяющегося хоста в DNS).
  • Разрешить/запретить. Контроль входящих соединений > параметр allow/deny. connections only from the following SMTP Internet host names/IP addresses (Разрешать/запрещать сообщения только со следующих внешних адресов/доменов).
    •
  • Проверка доступности ретрансляций. Авторизованный пользователь (или сервер), у которого проверили имя и пароль с помощью команды AUTH может проводить ретрансляцию.
  • Фильтры: белые и черные списки:
  • личный белый список
  • личный черный список
  • белый список DNS
  • черный список DNS
  • Послать приветствие. Посылается приветствие.
  • Контроль входящих SMTP-полей: MAIL:
  • Контроль отправителя:
  • Verify sender's domain in DNS (Проверять домен отправителя по DNS). Контроль отправителей входящих сообщений.
  • Разрешить/запретить. Контроль отправителей входящих сообщений
  • Реализация:
  • контроля отправителя;
  • контроля соединения;
  • фильтры DNSBL: отвергнуть сообщение.
  • Контроль входящих SMTP-полей: RCPT.
  • Обработать адрес получателя. Поле RCPT TO в заголовке сообщения.
  • контроль получателя:
  • разрешить/запретить;
  • Verify that local domain recipients (Проверять, существуют ли получатели из локального домена).
  • Реализация:
  • контроля получателя;
  • контроля ретрансляций.
  • Контроль входящих SMTP-полей: DATA.
  • фильтр DNSBL;
  • системные почтовые правила;
  • поместить сообщение в MAILBOX.
    •

    8.6 Изучение стратегий применения возможностей версии 7

    Какие параметры конфигурации будут наиболее эффективными в вашем случае? Четкого ответа на этот вопрос не существует. Вы должны знать, как почта приходит на ваш сервер Domino. Если между сервером Domino и Интернетом находится шлюз, вы не можете использовать контроль соединений или черные и белые списки DNS. IP-адрес соединяющейся с вами машины всегда будет представлять собой IP-адрес шлюза.

    Сведем вместе все параметры конфигурации в двух сценариях – сценарии отбрасывания всего спама и сценарии приема всего спама на сервер. Поскольку в версии 7 появились белые списки, мы рассмотрим, как вы можете работать со своим собственным белым и черным списком DNS.

    8.6.1 Принимать весь спам или отклонять весь спам?

    Существует ряд ситуаций, когда прием всего спама (или, что лучше, всей почты) на сервер является наилучшим решением. Одной из ситуаций является конфигурация, в которой сервер Domino не получает напрямую почту из Интернета. Например, у вас может быть резервный SMTP-сервер, предоставленный вам интернет-провайдером, или SMTP-сервер провайдера или сервер-шлюз внутри организации. Во всех этих случаях отклонение почтового сообщения не решает проблему спама, а лишь переносит ответственность за решение данной проблемы в другое место.

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

    Существует ряд причин, по которым нужно отклонять весь спам. В данном случае у вас будет очень мало зависших (dead) сообщений (или их не будет совсем) и вы улучшите сетевую пропускную способность, поскольку тело сообщения передаваться не будет.

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

    Рассмотрим следующий список параметров:

  • Inbound intended recipients controls (Контроль получателей, указанных во входящем сообщении). Этот параметр очень эффективен для контроля входящего потока сообщений, которые имеют неправильный адрес. Сервер Domino завершит соединение, прежде чем будет передано тело сообщения, что позволит сэкономить сетевые ресурсы и освободить потоки для приема. Помните, что данный параметр имеет более высокий приоритет, чем белый список. Короче говоря, если получатель отсутствует в Domino Directory, сообщение будет отклонено (см. 8.5.4, "Контроль получателей, указанных во входящих сообщениях"). Этот параметр не уменьшает объем спама, получаемого отдельным пользователем. Это административная опция.Примечание. При включении параметра Inbound intended recipients controls (Контроль получателей, указанных во входящем сообщении) почтовый адрес проверяется по полю RCPT TO. Сервер SMTP по-прежнему будет отвечать сообщениями "250...Recipient OK" и "550...No such user" на запросы спамерских инструментов сбора почтовых адресов.
  • Hold undeliverable messages (Задерживать сообщения, которые невозможно доставить). По умолчанию данный параметр отключен (Disabled). Если вы не хотите, чтобы сообщения, которые не были доставлены, возвращались на адрес отправителя, включите этот параметр (Enabled). Помните, что задерживаются все сообщения, даже те, которые посылаются вашими пользователями. Вам нужно часто проверять файл MAILBOX на сервере и либо освобождать задержанные сообщения, либо удалять их (см. 8.5.9, "Удержание сообщений, которые невозможно доставить"). Этот параметр не уменьшает объем спама, получаемого отдельным пользователем. Это административная опция.
  • Address lookup (Поиск адресов). По умолчанию указывается значение Fullname and Local Part (Полное имя и локальный элемент). Чтобы доставка сообщений не производилась по одному имени или одной фамилии, укажите вариант Fullname only (Только полное имя). Если вы допускаете прием писем из нескольких почтовых доменов, внесите в документы Person разные почтовые адреса (см. 8.5.7, "Поиск адресов"). Этот параметр уменьшает объем почты, посылаемой пользователям, поскольку в письмах должен быть точный формат адреса.
  • Белый и черный список. Выберите поставщика черного списка, удовлетворяющего вашим требованиям. Начните с опции Log and tag (Записать в журнал и маркировать), а затем, после изучения результатов, переходите на Log and reject message (Записать в журнал и отклонить сообщение). Этот параметр может уменьшить число сообщений, получаемых пользователями.
    •

    Настройте белый список, указав в нем домены своих заказчиков. Обучайте пользователей созданию правил почтовых файлов с маркерами белых списков. Этот параметр может улучшить качество доставляемой почты.

  • Личный черный/белый список или контроль соединений? Вы можете вводить доменное имя (или IP-адрес) в любой из этих параметров. Различие в результате. Черные и белые списки позволяют вам промаркировать сообщение. Контроль соединений может лишь принимать или отвергать. Для тестирования параметра вы можете использовать личный черный список с опцией Log and tag (Записать в журнал и маркировать). Если результат вас удовлетворяет, вы можете скопировать доменное имя (или IP-адрес) в раздел Connection Control (Контроль соединений).
  • Правила сервера. Просмотрите существующие правила и дополните действия новой опцией Stop Processing (Остановить обработку). Эта опция полезна для прекращения проверки по правилу, если наблюдается совпадение. Все остальные проверки завершаются, и это позволяет улучшить производительность сервера.
    •

    8.6.2 Настройка собственного белого списка DNS

    C технической точки зрения черные и белые списки DNS работают идентично. SMTP-сервер посылает запрос, и DNS возвращает ответ "Not-Found" (Не найден) или найденный IP-адрес. В случае черных и белых списков DNS возвращается обычно адрес 127.0.0.1 (loopback), но Domino не делает различий между возвращаемыми адресами, любой адрес считается совпадающим.

    Если вы хотите настроить свой собственный белый список DNS, вам нужно собрать IP-адреса ваших отправителей, которые вы хотите включить в белый список. Эта задача не сводится к поиску домена и вводу соответствующего IP-адреса. В настоящее время нет общепринятого стандарта, который требовал бы, чтобы в DNS была запись, относящаяся к SMTP-серверу-отправителю. Помните, что SMTP-сервер-отправитель организации не обязан быть тем же самым, что и SMTP-сервер-получатель, и часто они действительно не совпадают, поэтому зарегистрированные записи Mail Exchanger (MX), относящиеся к домену, не обязательно будут теми самыми, которые вы хотите внести в белый список. Единственным доступным для вас источником будет файл журнала сервера, где IP-адрес записывается в момент установления и разрыва соединения (пример 8.7).

    SMTP Server: mail2.kai-shin.com (9.33.85.111) connected
...
SMTP Server: mail2.kai-shin.com (9.33.85.111) disconnected. 1 message[s] received

    Следующий этап – это добавление IP-адреса в белый список DNS.

    Как работает поиск DNS?

    Поиск DNS для черных и белых списков, а также для других видов запросов работает, по сути, одинаково. DNS-клиент (т. е. ваш SMTP-сервер) вызывает DNS-сервер, сконфигурированный в вашей операционной системе. В Microsoft Windows настройка DNS является частью сетевой конфигурации.

    Рассмотрим следующие моменты:

  • Отправка почты. Когда SMTP-серверу требуется IP-адрес домена, он выполняет стандартный запрос к DNS, запрашивая запись MX (записи MX (mail exchange) – это записи для обмена почтой, которые относятся к приему почты). DNS-сервер в ответ посылает все записи MX и связанные с ними записи об адресах. SMTP-сервер выбирает запись с наибольшим приоритетом и запускает передачу почты.
  • Получение почты. По умолчанию ваш SMTP-сервер принимает почту для вашего домена без запросов к DNS. Поиск в DNS можно запустить с помощью нескольких параметров конфигурации:
  • если ввести имя хоста в Relay and Connection Controls (Контроль ретрансляции и соединений), SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • включение черного и белого списка DNS;
  • если ввести имя хоста в личный черный или белый список, SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • если включить (Enabled) параметр Verify connecting hostname in DNS (Проверять по DNS имя соединяющегося хоста), SMTP-сервер будет выполнять инвертированный поиск (перевод IP-адреса в имя хоста);
  • если включить параметр Verify sender’s domain in DNS (Проверять домен отправителя по DNS), SMTP-сервер будет выполнять поиск имени (перевод имени в IP-адрес).
    •
  • Поиск по черному/белому списку DNS. Когда SMTP-сервер производит поиск, он проверяет, указан ли отправитель в каком-нибудь черном или белом списке. Сервер выполняет запрос, указав IP-адрес. Если вы сконфигурировали белый список с именем white.stdi.com, а IP-адрес соединяющегося сервера 192.168.1.217, то SMTP-сервер отправляет прямой поисковый запрос (перевод имени в IP-адрес). Формат запроса такой: 217.2.168.192.white.stdi.com (обратите внимание на инвертированный IP-адрес). DNS отвечает сообщением "No such name" (Нет такого имени) или соответствующим IP-адресом. Обычно IP-адрес будет 127.0.0.1 (т. е. loopback).
  • Поиск по личному черному/белому списку. Если SMTP-серверу нужно сравнить отправителя с именем хоста, указанным в белом или черном списке, он сначала должен преобразовать IP-адрес отправителя в имя хоста. Сервер выполняет запрос для получения имени, соответствующего IP-адресу (запись PTR или инвертированный поиск). DNS-сервер в ответ посылает имя хоста, но не имя домена. Далее имя хоста сравнивается с личным белым или черным списком и сообщение помечается, если обнаруживается совпадение. Помните, что не для всех серверов в DNS существуют PTR-записи.

    • Настройка сервера DNS как белого или черного списка

    В качестве белого или черного списка DNS вы можете использовать любой сервер DNS. Запросы к белому или черному списку DNS представляют собой стандартные DNS-запросы. В нашем примере показан DNS-сервер Microsoft. Программное обеспечение для управления DNS от Microsoft не оптимизировано для работы с белыми списками, но DNS-сервер прекрасно работает в этом качестве, если записи добавляются вручную. Еще один вариант DNS-сервера – это BIND от Internet Systems Consortium. Вы можете найти программное обеспечение для работы с DNS для многих платформ Microsoft Windows и UNIX®. За дополнительной информацией обращайтесь по адресу http://www.isc.org

    Если вы планируете, что белый список DNS будет работать с большими по объему запросами, вам следует обратиться к следующим Web-сайтам: http://www.corpit.ru/mjt/rbldnsd.html http://cr.yp.to/djbdns.html

    Оба эти продукта предназначены для работы с большими черными (или белыми) списками.

    Важно! Если вы не знакомы с основами работы DNS, координируйте свою работу с администратором сети. Вам нужен правильно сконфигурированный файл зоны.

    В нашем примере мы создаем самостоятельный DNS-сервер, который работает только как DNS-сервер белого списка (white.stdi.com). Для правильной работы в родительском домене (stdi.com) нужно упомянуть о данном поддомене при помощи записи name server (NS). В DNS-сервере Microsoft для этого предназначена опция New Delegation. При альтернативном варианте, когда используется единственный DNS-сервер, мы можем добавлять эти записи в файл зоны stdi.com или можем создать поддомен на том же сервере.

    Настройка и конфигурирование DNS-сервера Microsoft

    В приведенных здесь примерах мы используем Microsoft Windows 2000 Server. Мы сконфигурировали Windows 2000 Server как самостоятельный сервер и инсталлировали программное обеспечение DNS-сервера.

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

    (рис 8.12) Microsoft DNS Manager

    Выполните следующие шаги:

  • Запустите DNS Manager.
  • Первая задача – это создание зоны. Зона связана с доменами и поддоменами. В нашем случае мы используем домен white.stdi.com как белый список DNS (рис. 8.12). Для создания зоны:
  • Выберите вариант DNS Standard primary (Стандартный главный), как показано на рис 8.13(рис 8.13) Конфигурирование DNS-сервера Microsoft: часть 1
  • Выберите пункт Forward lookup zone (Зона прямого поиска), как показано на рис 8.14(рис 8.14) Конфигурирование DNS-сервера Microsoft: часть 2
  • Введите имя зоны, как показано на рис 8.15(рис 8.15) Конфигурирование DNS-сервера Microsoft: часть 3
  • Примите заданное по умолчанию имя файла зоны, как показано на рис 8.16(рис 8.16) Конфигурирование DNS-сервера Microsoft: часть 4
    •  На этом этапе система подтвердит ваши ответы, и теперь все готово к инициализации DNS (рис 8.17(рис 8.17) Конфигурирование DNS-сервера Microsoft: часть 5
  • Первый шаг – это создание записи-заполнителя в конфигурационном файле DNS. Этот заполнитель упрощает первые изменения, вносимые вручную, но он не является необходимым для правильной работы. Итак, чтобы создать заполнитель:
  • Сделайте двойной щелчок по созданной DNS, чтобы обновить записи в правой части окна. Затем щелкните правой кнопкой мыши по имени домена и выберите пункт меню New Host (Новый хост), как показано на рис 8.18(рис 8.18) Конфигурирование DNS-сервера Microsoft: часть 6
  • Укажите имя домена. Введите IP-адрес 127.0.0.1? как показано на рис 8.19(рис 8.19) Конфигурирование DNS-сервера Microsoft: часть 7

    • Прежде чем мы выйдем из DNS Manager, выделите имя сервера и выберите пункт Update Server Data Files (Обновить файлы данных сервера), как показано на рис. 8.20.

    (рис 8.20) Конфигурирование DNS-сервера Microsoft: часть 8

    Выйдите из программы. С этого момента мы будем вносить изменения в файл конфигурации DNS вручную.

    Обновление файла зоны

    Откройте файл конфигурации DNS, расположенный в папке \winnt\system32\dns. Имя файла будет то, которое мы выбрали для него выше, в шаге d. Файл будет выглядеть примерно так, как показано в примере 8.8.

    ;
; Database file white.stdi.com.dns for white.stdi.com zone.
; Zone version: 4
;
@    IN SOA white.stdi.com. admin.white.stdi.com. (
     4;      serial number
     900;    refresh
     600;    retry
     86400;  expire
     3600);  minimum TTL
;
; Zone NS records
;
@    NS white.stdi.com.
;
; Zone records
;
first A 127.0.0.1

    Мы создали адресную запись first. Эта запись будет служить нам шаблоном для добавления записей белого списка.

    В следующем примере мы добавляем в белый список DNS два IP-адреса (пример 8.9).

    ...
;
; Zone records
;
first           A   127.0.0.1
2.1.168.192     A   127.0.0.1
4.156.176.207   A   127.0.0.1

    Помните, что, добавляя IP-адреса в файл зоны, их необходимо инвертировать. IP-адрес 192.168.1.2 превращается в 2.1.168.192

    Как узнать, будет ли DNS работать правильно? Используйте команду nslookup для отправки запроса к DNS, как показано в примере 8.10. Команда nslookup связывается с только что сконфигурированной DNS.

    C:\>nslookup
Default Server: cache02.ca-dns.net
Address: 142.77.2.36

> set root=192.168.1.147
> root
Default Server: [192.168.1.147]
Address: 192.168.1.147

> first.white.stdi.com
Server: [192.168.1.147]
Address: 192.168.1.147

Name: first.white.stdi.com
Address: 127.0.0.1

> 2.1.168.192.white.stdi.com
Server: [192.168.1.147]
Address: 192.168.1.147

Name: 2.1.168.192.white.stdi.com
Address: 127.0.0.1

>exit

    Первый этап – это проверка того, что SMTP-сервер использует именно то имя или адрес, которые возвращает команда nslookup. Вы можете изменить DNS при помощи команды set root. Вы можете проверить соединение, используя команду root.

    Введите имя, соответствующее адресу-заполнителю (в нашем примере – first.white.stdi.com). Сервер в ответ вернет IP-адрес 127.0.0.1. Проверьте все прочие адреса. Ответ должен быть тот же самый.

    8.7 Будущее спама

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

  • Протокол Sender Policy Framework (SPF) использует существующую систему DNS для хранения списка серверов, имеющих право посылать почту в данный домен. Когда SMTP-сервер получает сообщение, он использует для подтверждения иден- тичности сервера-отправителя простое сравнение IP-адреса отправителя с пере- численными в DNS IP-адресами. За подробностями обращайтесь по адресу http://www.openspf.org
  • Протокол DomainKeys использует две проверки. Во-первых, отправитель должен пройти аутентификацию. Во-вторых, сообщение должно пройти оценивающую систему. Система оценки предназначена для того, чтобы предотвращать или за- медлять распространение больших объемов почты. За подробностями обращайтесь на следующий сайт, где нужно перейти к пункту DomainKeys: http://antispam.yahoo.com
    •

    Система DomainKeys более сложна, и для ее принятия потребуется больше времени. SPF, напротив, уже применяется. Любой пользователь может опубликовать в DNS запись, соответствующую стандарту SPF, без обновления программного обеспечения. Поскольку это достаточно просто, крупные провайдеры уже используют эту возможность. Возможно, что оба эти стандарта будут взяты на вооружение.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^