Почтовый сервер на основе реляционной СУБД. Оцените преимущества!

Евгений Прокопьев

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

Одним из малоизвестных, но очень эффективных инструментов для построения сложных и масштабируемых почтовых систем является DBMail – комплекс программ для UNIX-подобных систем, позволяющий использовать реляционные СУБД в качестве серверного хранилища почтовых сообщений вместо традиционных mbox, Maildir и прочих текстовых хранилищ. Используя DBMail, можно добиться:

n  Более высокой производительности по сравнению с файловыми хранилищами – реляционные СУБД гораздо лучше приспособлены к обработке больших объемов структурированных данных, чем любой парсер текстовых файлов.

n  Большей гибкости при обработке и анализе корреспонденции – возможности SQL опять-таки несоизмеримы с тем, что можно сделать, обрабатывая mbox или Maildir различными самописными скриптами на Perl/Python/Ruby для извлечения какой-либо статистики.

При этом администратор почтовой системы может задействовать различные механизмы, предоставляемые СУБД (при условии, что выбранная им СУБД это позволяет), например:

n  Кластеризация – механизм, с помощью которого можно разместить СУБД на нескольких компьютерах (узлах кластера) с доступом к единой БД.

n  Репликация – возможность автоматического переноса сообщений из одной БД в другую, создания консолидированной БД из разных источников и т. д.

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

n  Отказоустойчивость и балансировка нагрузки с автоматическим переключением на резервный сервер при отказе основного.

n  Резервное копирование – горячее (без необходимости останавливать почтовый сервер, чтобы не получить поврежденное хранилище сообщений) и инкрементальное (копирование изменений вместо копирования всего хранилища).

n  Дополнительная логика обработки почты, построенную на триггерах, представлениях и т. д.

Похоже на голубую мечту сисадмина. Конечно, не все так замечательно: в DBMail пока отсутствуют некоторые возможности более распространенных и развитых почтовых систем (например, аутентификация с помощью SASL, встроенная поддержка SSL/TLS, механизм фильтрации почтовых сообщений, аналогичный Sieve – это первое, что приходит в голову), но реализовать их проще (и работы над реализацией многих недостающих возможностей ведутся), чем добавить описанные выше возможности к традиционным почтовым системам.

DBMail – продукт нидерландской компании IC&S, в котором также есть вклад большого числа независимых разработчиков из разных стран. Он распространяется по лицензии GPL, кроме того, IC&S предлагает платную поддержку.

Архитектура

В дальнейшем я предполагаю, что вы знакомы с общими принципами построения почтовых систем, и термины MTA, MDA и MUA вас не пугают. Если это не так, то всю необходимую информацию вы можете найти в моей статье «Круговорот почты в сети, или Архитектура современных почтовых систем», опубликованной в предыдущем номере журнала. Принципиальная схема работы DBMail, которую нарисовал Wolfram A. Kraushaar, вдохновленный примером Postfix big picture, выглядит так (см. рис. 1).

Рисунок 1. DBMail big picture

Теперь небольшой комментарий к изображению. В основе DBMail лежит реляционная БД – хранилище учетных записей пользователей, почтовых ящиков, сообщений и прочей вспомогательной информации. Также в состав DBMail входят две категории MDA:

n  Предназначенные для доставки сообщений от MTA в хранилище.

n  Предназначенные для доставки MUA из хранилища.

К первым относятся:

n  dbmail-smtp – исполняемый файл, использующий pipe-интерфейс: читает почтовое сообщение от MTA со стандарного входа (stdin) и сохраняет его в БД. Таким образом, на каждое входящее сообщение создается отдельный процесс UNIX и подключение к СУБД.

n  dbmail-lmtpd – UNIX-демон, принимающий клиентские подключения через UNIX-сокет или TCP-сокет. Для приема почтовых сообщений используется протокол LMTP. На каждое входящее сообщение MTA создает только клиентский сокет, необходимое количество процессов и подключений к БД создается заранее. Таким образом, этот вариант обеспечивает лучшую производительность при высокой нагрузке, но при низкой он потребляет больше системных ресурсов, чем необходимо.