 |
|
|
|
Почтовый сервер на основе реляционной СУБД. Оцените преимущества!
Почтовый сервер на основе реляционной СУБД Большинство почтовых систем в качестве хранилища сообщений до сих пор используют различные текстовые форматы. Сегодня мы построим почтовый сервер на основе реляционной СУБД и посмотрим, какие преимущества нам это даст. Одним из малоизвестных, но очень эффективных инструментов для построения сложных и масштабируемых почтовых систем является DBMail – комплекс программ для UNIX-подобных систем, позволяющий использовать реляционные СУБД в качестве серверного хранилища почтовых сообщений вместо традиционных mbox, Maildir и прочих текстовых хранилищ. Используя DBMail, можно добиться:
При этом администратор почтовой системы может задействовать различные механизмы, предоставляемые СУБД (при условии, что выбранная им СУБД это позволяет), например:
Похоже на голубую мечту сисадмина. Конечно, не все так замечательно: в 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:
К первым относятся:
Ко вторым относятся:
Кроме того, в состав DBMail входят следующие вспомогательные утилиты:
Общая часть функциональности всех рассматриваемых исполняемых файлов реализована в разделяемых библиотеках: libdbmail, libauthdbmail, libsortdbmail и lib[rdms-name]dbmail. В настоящее время тип поддерживаемой СУБД жестко определяется на этапе ./configure, причем указать можно только одну СУБД. В будущем планируется реализовать динамическую подгрузку модулей для работы с различными СУБД, описываемую в конфигурационном файле, – это должно упростить создание и поддержку пакетов DBMail для различных дистрибутивов Linux. В качестве СУБД в настоящее время поддерживаются только PostgreSQL и MySQL, кроме того, в текущей нестабильной версии появилась поддержка SQLite. Однако реализованный в DBMail уровень абстракции для доступа к БД позволяет добавлять поддержку других СУБД без внесения каких-либо изменений в основной код, отвечающий за логику обработки почтовых сообщений. Установка и настройка Последней стабильной версией DBMail является 2.0.7, а нестабильной – 2.1.3. Обе можно загрузить с http://www.dbmail.org, кроме того, самый свежий вариант можно выгрузить из CVN. Для FreeBSD, Debian Linux и Gentoo Linux существуют готовые порты/пакеты DBMail, для прочих систем предлагается следующая стандартная процедура установки: # ./configure –-with-pgsql (либо -–with-mysql) # make # make install Я использую ALT Linux и считаю этот способ приемлемым только на тестовых машинах, а для использования на рабочих серверах предпочитаю собирать любое ПО, отсутствующее в дистрибутиве, в пакеты и помещать в собственный репозитарий. Соответственно, установка DBMail в этом случае сведется к: # apt-get install dbmail Бинарный RPM-пакет и пакет с исходниками DBMail для ALT Linux желающие могут загрузить из коллекции бэкпортов для ALT Linux 2.4 Master (http://backports.altlinux.ru). Пользователям прочих дистрибутивов Linux или других UNIX-систем предлагается на выбор установить DBMail стандартным образом или собрать пакет для своей системы. Мы будем настраивать DBMail в связке с Postfix (в качестве MTA) и PostgreSQL (в качестве СУБД – c поддержкой PostgreSQL собран пакет для ALT Linux) – предполагается, что они уже установлены, настроены и работают. Для начала сначала создадим БД и пользователя (имеется в виду не системный пользователь, а пользователь СУБД PostgreSQL)– владельца этой БД: # createuser -s -U postgres dbmail # createdb -U dbmail dbmail # psql -U dbmail dbmail < /usr/share/doc/dbmail-2.0.7/sql/postgresql/create_tables.pgsql Затем создадим конфигурационный файл /etc/dbmail.conf со следующим содержимым (или слегка отредактируем уже существующий): [DBMAIL] host=localhost sqlport=5432 sqlsocket= user=dbmail pass=dbmailpwd db=dbmail postmaster=postmaster@mydomain.com trace_level=2 [SMTP] sendmail=/usr/sbin/sendmail auto_notify=no auto_reply=no trace_level=2 [LMTP] effective_user=mail effective_group=mail bindip=* port=24 nchildren=10 maxchildren=10 minsparechildren=2 maxsparechildren=4 maxconnects=10000 timeout=300 resolve_ip=yes trace_level=2 max_errors=500 [POP] effective_user=mail effective_group=mail bindip=* port=110 nchildren=10 maxchildren=10 minsparechildren=2 maxsparechildren=4 maxconnects=10000 timeout=300 resolve_ip=yes pop_before_smtp=no trace_level=2 [IMAP] effective_user=mail effective_group=mail bindip=* port=143 nchildren=10 maxchildren=10 minsparechildren=2 maxsparechildren=4 maxconnects=10000 timeout=4000 resolve_ip=yes imap_before_smtp=no trace_level=2 Небольшой комментарий к содержимому конфигурационного файла. Он состоит из следующих секций:
Пример конфигурационного файла, поставляемого в комплекте с DBMail, содержит поясняющие комментарии для большинства настраиваемых параметров. Теперь необходимо настроить механизм взаимодействия с Postfix. Как уже было сказано, таких механизмов два: pipe-интерфейс и LMTP. В первом случае потребуется в файле /etc/postfix/master.cf описать следующий транспорт: dbmail-smtp unix - n n - - pipe flags= user=mail:mail argv=/usr/sbin/dbmail-smtp -d ${recipient} -r ${sender} А затем задействовать этот транспорт в /etc/postfix/main.cf: mailbox_transport = dbmail-smtp: Описание транспорта LMTP будет выглядеть так: dbmail-lmtp unix - - n - - lmtp Или так (если требуется большая детализация в логах): dbmail-lmtp unix - - n - - lmtp -v Или так (если имена некоторых доменов назначения входящих почтовых сообщений не описаны в DNS): dbmail-lmtp unix - - n - - lmtp -o disable_dns_lookups=yes Во всех этих случаях новый транспорт нужно будет задействовать следующим образом: mailbox_transport = dbmail-lmtp:localhost:24 Разумеется, можно задействовать доставку почтовых сообщений в хранилище DBMail только для определенных доменов, но это уже не имеет никакого отношения к DBMail и настраивается исключительно средствами Postfix. Кроме того, необходимо поставить Postfix в известность о тех почтовых ящиках, для которых он должен принимать сообщения. Создадим для этого файл /etc/postfix/dbmail-mailboxes.cf со следующим содержимым: user = dbmail password = dbmailpwd hosts = localhost dbname = dbmail table = dbmail_aliases select_field = alias where_field = alias И задействуем его в /etc/postfix/main.cf: local_recipient_maps = pgsql:/etc/postfix/dbmail-mailboxes.cf $alias_maps Для того чтобы это работало, Postfix должен быть собран с поддержкой PostgreSQL. В Debian и ALT Linux (возможно, не только в них) поддержка PostgreSQL в Postfix вынесена в пакет postfix-pgsql, который необходимо доустановить, если он еще не установлен. Пользователи прочих дистрибутивов Linux или других UNIX-систем, в которых Postfix собран без поддержки PostgreSQL, либо вообще отсутствует, могут перед компиляцией включить его самостоятельно, указав ключ -DHAS_PGSQL и пути к соответствующим заголовкам и библиотекам: # make tidy # make -f Makefile.init makefiles \ 'CCARGS=-DHAS_PGSQL -I/usr/local/include/pgsql' \ 'AUXLIBS=-L/usr/local/lib -lpq' # make Наконец, последний штрих – ежедневные плановые работы по очистке БД от удаленных записей и проверке корректности БД. Их будет выполнять файл /etc/cron.daily/dbmail-clean со следующим содержимым: #!/bin/sh /usr/sbin/dbmail-util -cturpd -l 24h -qq Теперь можно запустить демоны dbmail-lmtpd (в том случае, если для доставки мы планируем использовать LMTP), dbmail-imapd и dbmail-pop3d (можно запустить только тот, который будет использоваться для извлечения почты из хранилища, если он будет один). В пакет для ALT Linux включены соответствующие стартовые скрипты, которые могут быть вызваны вручную с помощью service или настроены на автоматическое выполнение при загрузке с помощью chkconfig/ntsysv. Если для вашей ОС или вашего дистрибутива Linux таких скриптов нет, вам придется настроить автозапуск вручную. На этом настройку связки Postfix + DBMail + PostgreSQL можно считать законченной. Создадим тестового пользователя почтовой системы следующим образом: # dbmail-users -a test -w testpwd -s test@mydomain.com
В этом примере с помощью параметра -a указывается имя пользователя, с помощью -w – пароль, а с помощью s – почтовый ящик, принадлежащий пользователю (у одного пользователя их может быть несколько). Отправим созданному пользователю тестовое письмо: # echo hello | mail -s «Test Message» test@mydomain.com В логах мы должны увидеть нечто вроде:
Это значит, что письмо успешно доставлено. Попытаемся получить его по протоколу POP3, чтобы удостовериться в том, что это действительно так: # telnet localhost 110
Итак, DBMail настроен и в первом приближении работает именно так, как нам нужно. Внутреннее устройство хранилища DBMail После удачного запуска DBMail имеет смысл взглянуть на устройство его хранилища более внимательно. Уже знакомый нам по «DBMail big picture» Wolfram A. Kraushaar нарисовал ER (Entity-Relationship) модель БД DBMail, смотрите рис. 2.
Рисунок 2. DBMail Entity-Relationship Model Теперь краткое пояснение. Центральной таблицей является dbmail_users, в которой хранится вся информация о пользователях: их имена, пароли, текущий и максимальный размер всех почтовых ящиков, а также дата и время последнего подключения. Каждому пользователю могут соответствовать один или несколько почтовых адресов из таблицы dbmail_aliases. Впрочем, с помощью алиасов в DBMail можно также пересылать сообщения другим адресатам или передавать внешним программам на стандартный вход (stdin) для дальнейшей обработки. Каждому пользователю принадлежит один или несколько почтовых ящиков (каталогов IMAP) из таблицы dbmail_mailboxes, по умолчанию доставка осуществляется в ящик по имени INBOX. Кроме владельца, с ящиком могут работать и другие пользователи (такие ящики называются shared folders) – они описаны в таблице dbmail_subscription, соответствующие права доступа описаны в таблице dbmail_acl. В каждом ящике хранятся сообщения, IMAP-флаги сообщений находятся в таблице dbmail_messages, а содержимое сообщений разбивается на блоки не больше 512 Кб и располагается в таблице dbmail_messageblks – каждый блок в отдельной записи. Для увеличения производительности размер и дата получения сообщения вынесены в отдельную таблицу dbmail_physmessage. Таблицы dbmail_auto_replies и dbmail_auto_notifications используются для автоматической отправки ответов и уведомлений, а таблица dbmail_pbsp – для POP/IMAP-before-SMTP (механизма, аналогичного SMTP-авторизации, но менее распространенного и менее надежного). Довольно неудобным обстоятельством является то, что все заголовки каждого сообщения целиком хранятся в одной строке таблицы dbmail_messageblks – у таких строк значение поля is_header = 1. В нестабильной версии DBMail заголовки вынесены в отдельную таблицу, и для каждого выделена собственная запись. Однако вместо того чтобы ждать выхода новой ветки DBMail или использовать нестабильную, мы можем реализовать эту функциональность самостоятельно средствами PostgreSQL. Воспользуемся тем, что PostgreSQL позволяет создавать функции на языке PL/Python и богатыми возможностями Python в области обработки почтовых сообщений (разумеется, этот выбор субъективен: желающие могут реализовать аналогичную функциональность на PL/PgSQL, PL/Perl, PL/Tcl или даже на С). Сначала включим поддержку PL/Python для выбранной БД: # createlang -U dbmail plpythonu dbmail Для того чтобы эта команда выполнилась, PostgreSQL необходимо собрать с поддержкой PL/Python. В ALT Linux поддержка PL/Python вынесена в пакет postgresql-python, который необходимо доустановить, если он еще не установлен. Кроме того, в ALT Linux PostgreSQL выполняется в chroot-окружении, поэтому нужно проследить за тем, чтобы все модули Python, которыми мы собираемся воспользоваться, находились там же. Проще всего будет полностью перенести каталог /usr/lib/python2.3/ в /var/lib/pgsql-root/usr/lib, а правильнее будет делать это не регулярно при необходимости установить или удалить некоторые модули Python, а один раз описать необходимую последовательность действий в скрипте /etc/chroot.d/postgresql.lib. Теперь создадим и протестируем функцию, которая будет извлекать нужный нам заголовок почтового сообщения: # psql -U dbmail dbmail dbmail=# create function mailheader(varchar, varchar) returns varchar as $$ dbmail$# import email.Parser dbmail$# parser = email.Parser.Parser() dbmail$# message = parser.parsestr(args[0]) dbmail$# return message.get(args[1]) dbmail$# $$ language plpythonu;
dbmail=# select mailheader(messageblk, "To") from dbmail_messageblks where is_header=1;
Для того чтобы оценить возможности этого механизма, у нас слишком маленькая БД. Конечно, можно написать скрипт, генерирующий множество почтовых сообщений, но мы поступим иначе. Допустим, что у нас уже есть архив списка рассылки DBMail-Users в формате Maildir. С помощью MUA создадим IMAP-каталог, а затем с помощью скрипта mailbox2dbmail импортируем в него все сообщения из архива: # /usr/share/doc/dbmail-2.0.7/contrib/mailbox2dbmail/mailbox2dbmail -u test -t maildir -m maillist/ -b INBOX/DBMail-Users -p /usr/sbin/dbmail-smtp
Теперь можно провести анализ содержимого IMAP-каталога: # psql -U dbmail dbmail dbmail=# select user_idnr, userid from dbmail_users;
dbmail=# select mailbox_idnr, owner_idnr, name from dbmail_mailboxes where owner_idnr = 3;
dbmail=# select mailheader(messageblk, 'User-Agent'), count(*) dbmail=# from dbmail_messages inner join dbmail_messageblks dbmail-# on dbmail_messages.physmessage_id = dbmail_messageblks.physmessage_id dbmail-# where mailbox_idnr = 4 and is_header = 1 dbmail-# group by 1 dbmail-# order by 2 desc;
Итак, мы получили распределение сообщений в списке рассылки по MUA (точнее, по заголовку User-Agent). Запрос выполнился не слишком быстро, что и не удивительно: для каждой строки пришлось вызывать функцию разбора содержимого. Чтобы уменьшить время выполнения, можно создать триггер на вставку записей с сообщениями и сохранять результаты mailheader в отдельную проиндексированную таблицу. Тем самым за счет уменьшения времени анализа сообщений мы получим увеличение времени, затрачиваемого на добавление сообщений, – что важнее, решать администратору почтовой системы. Впрочем, здесь из области администрирования почтового сервера мы переходим в область администрирования баз данных вообще и администрирования PostgreSQL в частности – последнему посвящен цикл статей Сергея Супрунова, уже публиковавшийся в нашем журнале. Shared folders Трудно представить себе полноценный IMAP-сервер без поддержки механизма shared folders, обеспечивающего совместный доступ различных пользователей к общим каталогам с сообщениями. В DBMail поддерживаются:
Как мы уже выяснили, универсальный инструмент администратора DBMail – это SQL-консоль выбранной им СУБД. Создадим системный общий каталог News и предоставим доступ к нему пользователю test с помощью этого инструмента. Сначала необходимо создать пользователя с именем __public__. Мы уже создавали пользователя test с помощью dbmail-users, сделаем теперь то же самое средствами SQL: # psql -U dbmail dbmail dbmail=# insert into dbmail_users (userid, passwd) dbmail-# values ("__public__", "abracadabra");
dbmail=# select user_idnr from dbmail_users where userid="__public__";
Теперь создадим каталог News, владельцем которого будет пользователь __public__: # psql -U dbmail dbmail dbmail=# insert into dbmail_mailboxes dbmail=# (owner_idnr, name, seen_flag, answered_flag, deleted_flag, flagged_flag, dbmail=# recent_flag, draft_flag, no_inferiors, no_select, permission) dbmail-# values (5, 'News', 1, 1, 1, 1, 1, 1, 0, 0, 2);
dbmail=# select mailbox_idnr from dbmail_mailboxes where name="News";
А теперь опишем права доступа для пользователя test к этому каталогу: # psql -U dbmail dbmail dbmail=# select user_idnr from dbmail_users where userid="test";
dbmail=# insert into dbmail_acl dbmail=# (user_id, mailbox_id, lookup_flag, read_flag, seen_flag, write_flag, dbmail=# insert_flag, post_flag, create_flag, delete_flag, administer_flag) dbmail-# values (3, 7, 1, 1, 1, 1, 1, 1, 1, 1, 1);
Все, пользователю test осталось только подписаться на каталог #Public/News средствами своего MUA. Впрочем, и это тоже можно выполнить средствами SQL: # psql -U dbmail dbmail dbmail=# select user_idnr from dbmail_users where userid="test";
dbmail=# select mailbox_idnr from dbmail_mailboxes where name="News";
dbmail=# insert into dbmail_subscription values (3, 7);
Возможности перенаправления почты Мы не станем рассматривать эти возможности так же детально, как и shared folders, т.к. общий принцип администрирования DBMail уже понятен. Упомянем только таблицы, принимающие участие в перенаправлении почты:
Использование описанных механизмов требует аккуратного подхода, иначе очень легко получить зацикливание почты. Так я по невнимательности указал для почтового пользователя в качестве адреса для уведомлений один из его же алиасов. После этого вместо одного письма пользователь получил около 500 сообщений в течение нескольких секунд на машине с довольно скромной аппаратной конфигурацией. Прекращать это безобразие пришлось вручную с помощью инструмента postsuper из комплекта Postfix. Прочие возможности DBMail К числу прочих возможностей почтового сервера, часто востребованных администраторами, относятся:
Кроме того, DBMail не обошелся без GUI-конфигуратора DbMail Administrator (DBMA), написанного на Perl и ориентированного на веб. Он доступен на http://library.mobrien.com/dbmailadministrator и выглядит так (см. рис. 3).
Рисунок 3. DbMail Administrator Есть еще один веб-интерфейс к DBMail – swiftMail (http://www.obfuscatedcode.com/swiftmail/trac), написанный на PHP. Его можно было бы отнести к классу webmail-приложений, если бы не одна особенность: для чтения почты используется не POP3/IMAP, а прямой доступ к БД DBMail. В настоящее время доступна альфа-версия swiftMail, поддерживающая только MySQL. Поддержка PostgreSQL обещается в ближайшем будущем. Фильтрация почтовых сообщений средствами DBMail Общеизвестным преимуществом IMAP является то, что почтовый пользователь может работать со своей и общей корреспонденцией с разных рабочих мест с помощью совершенно различных MUA: как традиционных, так и ориентированных на веб. Это означает, что правила, в соответствии с которыми сообщения распределяются по каталогам IMAP, должны определяться не на уровне MUA, а на уровне MDA. В настоящее время в DBMail отсутствуют штатные способы решения этой задачи. В будущих версиях планируется использование специализированного языка программирования для фильтрации почтовых сообщений Sieve (описан в RFC 3028, активно используется в Cyrus IMAP), код поддержки Sieve даже есть в текущей стабильной версии, но он не завершен и недостаточно протестирован, поэтому при компиляции по умолчанию поддержка Sieve отключена. Кроме того, для большинства случаев Sieve является слишком мощным инструментом. Сформулируем, что нам требуется от простейшего механизма фильтрации почтовых сообщений:
А теперь перечислим те способы решения задачи, которые пришли мне в голову:
Сравним их (см. таблицу 1). После недолгих раздумий выбор был сделан в пользу последнего варианта. Самым трудным оказалось не реализовать нужную функциональность, а найти место в коде, куда ее необходимо вставить, не нарушив при этом работоспособности всего остального. Решение задачи сильно упростило то, что в DBMail хорошо организовано ведение логов. Для каждого демона в конфигурационном файле можно задать уровень отладки (параметр trace_level), определяющий степень детализации выводимых отладочных сообщений. Таблица 1. Способы фильтрации почтовых сообщений средствами DBMail
При максимальном уровне отладки (trace_level=5 в секции LMTP) во время доставки сообщения в логах можно увидеть очень много сообщений, но наиболее интересным является следующий фрагмент:
Похоже, что именно здесь и происходит сохранение сообщения. Код, выводящий это сообщение, выглядит так: trace(TRACE_DEBUG, "%s, %s: calling sort_and_deliver for useridnr [%llu]", __FILE__, __func__, useridnr); dsn_result = sort_and_deliver(tmpmsgidnr, msgsize, useridnr, delivery->mailbox); Можно заглянуть в реализацию sort_and_deliver и найти там подтверждение догадки. В delivery->mailbox по умолчанию передается [null]. Таким образом, задача сводится к тому, чтобы, проанализировав заголовки сообщения, передать в delivery->mailbox имя каталога IMAP. Заголовки сообщения функция insert_messages получает в виде структуры headerfields. После того как исходные данные для определения каталога назначения и параметр, в который нужно передать имя каталога, определены, можно реализовать функцию, которая и будет выполнять эту задачу. Вызов функции будет выглядеть так: trace(TRACE_DEBUG, "%s, %s: calling sort_and_deliver for useridnr [%llu]", __FILE__, __func__, useridnr); dsn_result = sort_and_deliver(tmpmsgidnr, msgsize, useridnr, db_get_mailbox_from_filters(useridnr, headerfields, delivery->mailbox)); Прототип функции, который мы поместим в db.h: char *db_get_mailbox_from_filters(u64_t useridnr, struct list *headerfields, const char *mailbox); При реализации функции необходимо использовать следующую таблицу: CREATE TABLE dbmail_filters ( user_id INT8 REFERENCES dbmail_users(user_idnr) ON DELETE CASCADE ON UPDATE CASCADE, filter_id INT8, filter_field varchar(128) NOT NULL, filter_value varchar(255) NOT NULL, mailbox varchar(100) NOT NULL, PRIMARY KEY (user_id, filter_id) ); CREATE INDEX dbmail_user_id_idx ON dbmail_filters(user_id); CREATE INDEX dbmail_filter_id_idx ON dbmail_filters(filter_id); В качестве образца чтения таблицы из БД можно использовать функцию db_get_users_from_clientid из db.c. В результате реализация функции db_get_mailbox_from_filters в файле db.c будет выглядеть так: char *db_get_mailbox_from_filters(u64_t useridnr, struct list *headerfields, const char *mailbox) { trace(TRACE_MESSAGE, "%s, %s: default mailbox [%s]", __FILE__, __func__, mailbox); if (mailbox == NULL) { unsigned i = 0; unsigned num_filters = 0; snprintf(query, DEF_QUERYSIZE, "SELECT filter_field, filter_value, mailbox FROM dbmail_filters WHERE user_id = '%llu' ORDER BY filter_id", useridnr); if (db_query(query) == -1) { trace(TRACE_ERROR, "%s,%s: error gettings filters for " "user_id [%llu]", __FILE__, __func__, useridnr); return NULL; } num_filters = db_num_rows(); for (i = 0; i < num_filters; i++) { struct element *el = list_getstart(headerfields); char *filter_field = db_get_result(i, 0); char *filter_value = db_get_result(i, 1); char *mailbox = db_get_result(i, 2); trace(TRACE_MESSAGE, "%s, %s: processing filter [%s : \"%s\" => %s]", __FILE__, __func__, filter_field, filter_value, mailbox); while (el) { struct mime_record *record = (struct mime_record *) el->data; trace(TRACE_MESSAGE, "%s, %s: processing header [%s : \"%s\"]", __FILE__, __func__, record->field, record->value); if (!strcmp(record->field, filter_field) && strstr(record->value, filter_value)) { trace(TRACE_MESSAGE, "%s, %s: header [%s : \"%s\"] accept filter [%s : \"%s\" => %s]", __FILE__, __func__, record->field, record->value, filter_field, filter_value, mailbox); return mailbox; } el = el->nextnode; } trace(TRACE_MESSAGE, "%s, %s: no header accept filter [%s : \"%s\" => %s]", __FILE__, __func__, filter_field, filter_value, mailbox); } db_free_result(); return NULL; } else { return mailbox; } } После внесения изменений в код, перекомпиляции, создания таблицы фильтров в БД и ее заполнения новый механизм фильтрации был тщательно протестирован. Ошибок выявлено не было. Фрагмент лога, в котором виден процесс анализа заголовков почтового сообщения, теперь выглядит так:
При этом содержимое таблицы фильтров таково: # psql -U dbmail dbmail dbmail=# select * from dbmail_filters;
Изменения были оформлены как .diff (с помощью утилиты gendiff – после этого они могут быть использованы утилитой patch для автоматического внесения изменений в оригинальный исходный код) и отправлены в списки рассылки пользователей и разработчиков DBMail. По согласованию с лидером проекта эти изменения не внесены в основную стабильную ветку, но патч включен в архив с кодом, и пакет DBMail для Debian Linux собран с этим патчем (т.к. лидер проекта по совместительству еще и мантейнер этого пакета в Debian). Пакет DBMail для ALT Linux также собран с этим патчем. Пользователи прочих дистрибутивов Linux или других UNIX-систем могут собрать DBMail с ним самостоятельно. Разумеется, патч не идеален, и в будущем, может быть, придется усовершенствовать его, добавив:
Итоги Проекту DBMail придется пройти еще долгий путь, чтобы заслужить признание и получить такую же популярность, как, например, Courier IMAP или Cyrus IMAP. Но уже сейчас видно, что его потенциальные возможности очень широки. В будущих версиях планируется реализовать следующее (часть уже реализована в версии 2.1.3):
Посмотрим, что ожидает DBMail в будущем. Литература, ссылки:
|
ЕВГЕНИЙ ПРОКОПЬЕВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
