Корпоративная почтовая система на базе высокодоступного кластера

- qmgr поддерживает маленькую очередь active, в которой ожидают отправки буквально несколько сообщений. Эта очередь фактически выполняет роль небольшого окна для потенциально бoльших очередей  incoming и  deferred, предотвращая нехватку памяти qmgr при большой загруженности;

- если Postfix не может незамедлительно доставить сообщение, то qmgr помещает его в очередь  deferred. Хранение временно недоставимых сообщений в отдельной очереди гарантирует, что нормальный доступ к очереди не будет тормозиться большим объемом почты, обработка которой не завершена.

qmgr использует демоны bounce и error для отказа в доставке сообщений тем получателям, сведения о которых содержатся в таблице relocated с данными о пользователях и доменах, более не существующих в системе.

Демон proxymap предоставляет доступ (только на чтение) для клиентских процессов Postfix к картам. За счет совместного использования одной открытой карты многими демонами Postfix proxymap обходит ограничения, налагаемые chroot, и уменьшает количество открытых поисковых таблиц.

Процесс spawn по запросу создает не-Postfix процессы. Он занимается прослушиванием порта TCP, сокета домена UNIX1 или FIFO-очереди стандартного потока ввода, вывода и ошибок. В этой книге будет описан только один пример использования spawn: для внешней системы фильтрации сообщений по содержанию тела сообщения.

Демон  local отвечает за доставку в локальные почтовые ящики. Postfix-демон  local может записывать данные в почтовые ящики форматов mbox и Maildir. Кроме того, local может обращаться за данными в формате Sendmail к базам данных alias и пользовательским файлам .forward.

Демон  virtual, который иногда называют  виртуальным агентом доставки, – это упрощенный вариант local, осуществляющий доставку только в почтовые ящики. Это самый надежный агент доставки Postfix; он не выполняет подстановок по файлам alias и .forward. Этот агент доставки может доставлять почту для нескольких доменов, что делает его особенно удобным для поддержки ряда небольших доменов на одной машине (это так называемый POP-тостер1) без настройки отдельной почтовой системы для каждого домена или интерактивного доступа пользователей к системе.

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

Демон  lmtp взаимодействует с локальным и удаленным серверами почтовых ящиков по протоколу LMTP2 (Local Mail Delivery Protocol), который определен в RFC 2033. Часто используется совместно с сервером Cyrus IMAP. Преимущество использования клиента lmtp заключается в том, что управлением очередями занимается Postfix и одна Postfix-машина может по протоколу LMTP обслуживать много серверов почтовых ящиков (на которых должны работать демоны LMTP). Обратное также верно: несколько Postfix-машин могут обслуживать один сервер почтовых ящиков по LMTP. На таких серверах почтовых ящиков может, например, работать Cyrus IMAP.

Демон pipe обеспечивает клиентский интерфейс для исходящих соединений к другим почтовым транспортным механизмам. Он вызывает программы с параметрами и отправляет тело сообщения по каналу (pipe) на их стандартный ввод.

Демон  pickup забирает сообщения, помещенные в очередь  maildrop локальной клиентской программой отправки почты. После выполнения ряда проверок pickup передает сообщения демону cleanup.

Демон  smtpd обеспечивает взаимодействие с сетевыми почтовыми клиентами, отправляющими сообщения через Postfix по SMTP. Демон smtpd проводит ряд проверок для защиты остальной части системы Postfix. Его можно настроить так, чтобы он занимался проверкой входящей почты на спам (локальные или сетевые черные списки, поиск в DNS, другие клиентские запросы и т. д.). smtpd передает сообщение демону cleanup.

Демон  cleanup реализует последний этап обработки новых сообщений. Он добавляет недостающие заголовки, корректирует преобразование адреса и (если надо) извлекает адреса получателей из заголовков сообщений. Демон cleanup помещает результат в очередь incoming, затем уведомляет диспетчер очередей о прибытии нового сообщения.

sendmail – это команда Postfix, которая подменяет собой MTA Sendmail Эрика Оллмана (Eric Allman). Ее задача заключается в предоставлении совместимого с Sendmail интерфейса для приложений, способных только вызывать /usr/sbin/sendmail. Она взаимодействует с программой postdrop для помещения сообщений в очередь maildrop, откуда их заберет pickup.

Демон qmqpd - QMQP-сервер Postfix реализует протокол QMQP (Quick Mail Queuing Protocol – быстрый протокол постановки почтовых сообщений в очередь) с целью обеспечения совместимости Postfix с qmail и диспетчером списков ezmlm.

Демон anvil – это предварительная защита от атак типа «отказ в обслуживании», при которых клиенты засыпают SMTP-сервер огромным количеством одновременных или последовательных попыток соединения. В нем предусмотрена возможность отмены ограничений для авторизованных клиентов.

Процессы и очереди взаимодействуют друг с другом. На рисунке 2.4 представлено взаимодействие демонов трех типов: ручной ввод, очереди и процессы.

Система построена на использовании нескольких полурезидентных программ. Каждая из них в соответствии с философией UNIX выполняет только одну задачу, но делает это хорошо. На рисунке 2.5 представлена подробная схема работы Postfix, включая процессы и очереди. По ней можно проследить направление движения приема и отправки почты.

Рисунок 2.4 – Отношения между демонами Postfix

Рисунок 2.5 – Схема работы Postfix

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

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

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

­         использование наименьших привилегий. Postfix может быть легко ограничен с помощью chroot и работать от имени самого бесправного пользователя;

­         ни одна из служебных программ не использует set-uid бит;

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

­         все данные, приходящие из внешних источников по умолчанию, считаются потенциально опасными, поэтому должны быть проверены и отфильтрованы жесточайшим образом;

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

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

2.2.3 Подсистема обработки входящих сообщений

Во главе всего стоит демон master, который обычно запускается командой postfix при старте системы и работает постоянно до тех пор, пока действует почтовая система. Этот супердемон отвечает за запуск по требованию всех остальных демонов и перезапуск тех из них, которые преждевременно завершили свою работу из-за каких-либо проблем. В его обязанности также входит следить, чтобы количество дочерних процессов не превышало ограничения установленных в файле master.cf, и чтобы каждый из них жил не дольше, чем определено настройками почтовой системы. Далее под термином процесс имеется ввиду демон (демонизированные процессы в отличие от обычных процессов никогда не завершаются самостоятельно, а лишь по приказу от master). Если те или иные процессы простаивают из-за отсутствия работы, то по истечении определенного тайм-аута они будут принудительно завершены в целях экономии памяти. Между собой все они общаются либо с помощью UNIX-сокетов, либо через FIFO. Все каналы обмена находятся в специально защищенной директории. Несмотря на такие предосторожности, все данные, получаемые от разных подсистем самого Postfix и внешних сущностей, обязательно подвергаются добавочным проверкам.

Получение писем обычно происходит через сетевое соединение. Первым делом их получает SMTP-демон. Если администратор включил соответствующую возможность, то сначала будет произведена проверка, не попадает ли письмо под ограничения UCE-фильтрации. UCE (unsolicited commercial email) – невостребованная коммерческая почта, или, проще говоря, спам. Для борьбы с ним можно применять следующие меры:

­         фильтрация по служебным заголовкам или телу сообщений;

­         ограничения IP-адресов и имен хостов клиентов, которым разрешено отправлять почту через нашу систему;

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

­         требование использовать почтовые адреса, полностью соответствующие стандарту RFC 821;

­         ограничения, накладываемые на почтовый адрес отправителя и получателя сообщения;

­         проверка IP-адреса отправителя по черному списку RBL (Realtime Black List).

После этого с полученным письмом начинает работать процесс cleanup, занимающийся его зачисткой. Он проводит первоначальные проверки на правильность оформления и формат входящего сообщения, позволяя защитить остальную систему от многих атак, рассчитанных на переполнение буфера. В случае необходимости добавляет в письмо недостающие служебные заголовки и с помощью процесса по имени trivial-rewrite приводит адреса к виду: пользователь@поддомен.домен. В postfix пока нет полноценного языка, позволяющего гибко управлять процессом переписывания адресов, поэтому вместо него используются служебные таблицы canonical и virtual для хранения правил, управляющих перезаписью.

После такой обработки письмо сохраняется на диск в формате файла почтовой очереди и кладется в директорию, где хранится очередь incoming, обычно это директория /var/spool/postfix/incoming/. Эта очередь используется только для обработки входящих сообщений. Затем процесс cleanup уведомляет процесс queue manager, управляющий всеми очередями о прибытии новой почты.

Следующий случай – письмо, отправленное из локальной системы с помощью какого-либо скрипта или, например, с помощью вот такой команды:

$ echo "mail text" | mail tigrisha@unreal.net -s "test subject"

Во многих UNIX-системах в качестве почтовой программы и по сей день традиционно используется sendmail. Соответственно большинство скриптов, написанных ранее и используемых сейчас априори, считает, что в системе установлена именно эта разновидность почтового сервера. Чтобы не разрушить совместимость с огромным количеством программного обеспечения при переходе к использованию Postfix, в систему вместе с прочими файлами устанавливается программа, заменяющая sendmail. Таким образом, получается, что команда mail передает письмо программе sendmail, установленной Postfix, а та в свою очередь вызывает привилегированную программу postdrop. Ну а последняя уже кладет файлы с письмами в служебную директорию maildrop, которая обычно находится в /var/spool/postfix/maildrop/. Затем письмо подхватывает процесс pickup и аналогично SMTP-демону проверяет соответствие послания установленным форматам, в результате чего письмо попадает в лапы свободному на данный момент процессу cleanup. В случае если письмо не поддается коррекции, то оно немедленно уничтожается. Стоит отметить, что отправитель не получит никаких извещений о данном факте. Если же ничего аномального не было найдено, то сообщение беспрепятственно попадет в очередь incoming, а queue manager, как обычно, получит сигнал о появлении новых писем.

Новая почта также может появиться в случае, если письмо невозможно доставить адресату и настройки системы диктуют в данном случае отправлять оповещения отправителю. При таком повороте событий процесс bounce или defer генерирует письмо с извещением о проблеме. Адресовано оно отправителю первоначального сообщения. Другим источником возникновения писем может быть настройка Postfix, заставляющая его отправлять администратору уведомления в случае проблем c SMTP или нарушения тех или иных политик, которые продиктованы настройками почтовой системы. Соответственно в обоих случаях, чтобы доставить письмо адресату, приходится, как обычно, отдать его процессу cleanup и затем отправить в очередь incoming.

2.2.4 Подсистема доставки почтовых сообщений

После того как письма появляются внутри почтовой системы, все, что находится в очереди incoming, нужно доставить получателям. Давайте посмотрим, как это происходит. Получив от cleanup уведомление о поступлении новой почты демон queue manager, управляющий очередями, перекладывает письмо в очередь active. Кстати, стоит заметить, что эта очередь очень маленького размера. В ней может находиться всего лишь несколько писем, которые в данный момент находятся в процессе доставки. Сделано это по двум причинам. Во-первых, для того чтобы при большой нагрузке менеджер очередей не потреблял слишком много памяти. Вторая причина состоит в том, что в случае, когда принимающая сторона не в состоянии получать письма с той скоростью, с которой Postfix старается их передать, приходится притормозить скорость отправки. С малой очередью это делать гораздо проще. Положив письмо в очередь active, демон queue manager создает запрос к процессу trivial-rewrite, с помощью которого удается определить точку назначения сообщения. В ответ можно будет лишь узнать, локальный ли получатель или он живет на удаленной системе. Добавочную информацию о маршрутизации почты можно получить из файла transport. В зависимости от полученных данных queue manager входит в контакт с одним из следующих агентов доставки: