Таким образом, реальное применение фильтрующей системы невозможно без использования набора политик, оговаривающих требуемый уровень защиты от спама. На самом примитивном уровне это все те же «белые» списки, но уже не отправителей, а получателей, например, для Postfix [6]. Но для построения разветвленной и согласованной системы политик, управляющих фильтрацией и доступом к электронной почте, конечно же, требуются специальные программные компоненты. Для того же Postfix их можно найти на странице [7].

Использование таких систем делает модель фильтрации не столь прямолинейной. Например, если применять policy-демоны на входе smtpd сервера Postfix, то можно проверять не только минимальный набор признаков smtp-соединения (хост, отправитель, получатель), но и SPF-тэги отправителя. Кроме того, такая компонента может отслеживать статистику соединений, что используется для построения политик greylist, т.е. разрешения доступа к почте только с определенного числа попыток отправителя.

Вот, теперь задумаемся, как можно совместить политики с выбранным методом размещения спам-фильтра.

Отказ в приеме

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

Контентная фильтрация

А вот тут получаем парадокс! Механизм самой контентной фильтрации в policy никак не задействуется. Политики применяются до исполнения процедуры фильтрации. Собственно, они ей чужды, поскольку в самом простом случае политики реализуются как исключения, построенные на все тех же «белых» или «черных» списках. В таких списках используются те же характеристики сообщения, что и выше – хост, отправитель, получатель. Но ведь резолюция контентного фильтра строится на основе сигнатуры, и если нельзя использовать такую сигнатуру в системе построения политики, то и получается, что политика в контентной фильтрации является внешней искусственной надстройкой. Да и как можно заранее указать сигнатуру уникального сообщения, если его прием еще только предполагается.

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