 |
|
|
|
MeTA1: почтовый сервер на новый лад
MeTA1: почтовый сервер на новый лад Мы уже привыкли к «великолепной четвёрке» – Sendmail, Postfix, Exim, qmail – на рынке открытых серверов электронной почты. Sendmail хоть и занимает первую строчку «хит-парада», всё же неуклонно теряет свои позиции. Но команда разработчиков, похоже, не собирается так просто сдаваться... Зачем нужен «ещё один» Sendmail? Основным недостатком «старичка» Sendmail, который сразу же упоминается, как только речь заходит о сравнении различных почтовых серверов, является его монолитная архитектура. Размещение всего функционала в одном двоичном файле, безусловно, тянет за собой целую массу проблем: и не слишком эффективное расходование ресурсов; и неустойчивость системы в целом, когда ошибка в одном компоненте может привести к полной неработоспособности сервера; и сложность разработки... Также редко кто забывает о «дырявом» прошлом этого пакета, по инерции интерполируя это и на настоящее, и даже на будущее. Ну а сложность настройки – это вообще притча во языцех, хотя типовая настройка Sendmail уже очень давно занимает лишь десяток-другой простых и, что называется, интуитивно понятных строк в mc-файле. Можно долго спорить о том, насколько серьёзны эти недостатки (и недостатки ли это вообще), но понятно одно – «имидж» Sendmail на данный момент не слишком хорош, особенно среди начинающих системных администраторов, и как бы разработчики ни старались улучшать этот пакет, на него всё равно смотрят искоса. Необходимость избавиться от этой «кармы» ощущают, видимо, и сами разработчики Sendmail, и в результате они во главе с Клаусом Асманом решили пойти на «реинкарнацию» – создание практически с нуля нового пакета, на новых принципах, учитывая предыдущий опыт и стремясь исправить проблемы, присущие нынешним версиям Sendmail. Таким образом, на свет появился Sendmail X, недавно переименованный в MeTA1. В качестве основных требований к разрабатываемой системе декларируются:
А что внутри? MeTA1 объявлен как агент передачи сообщений (message transfer agent, MTA). Как сказано на домашней странице «родительского» проекта (http://www.sendmail.org/sm-X), Sendmail X нацелен на то, чтобы стать эффективным и безопасным почтовым шлюзом. Смена названия на эту основополагающую цель не повлияла, так что сказанное выше справедливо и для MeTA1. На данный момент он не поддерживает функции модификации сообщений, однако для будущих версий такая возможность не исключается. Основное отличие MeTA1 от Sendmail – его модульность. Подобно Postfix и Qmail, этот пакет состоит из нескольких взаимодействующих компонентов, каждый из которых решает свою отдельную задачу и работает с правами своего пользователя. Это повышает устойчивость пакета к ошибкам в той или иной подсистеме, а также поднимает общий уровень безопасности пакета – за счёт разграничения прав доступа взлом одной подсистемы не оказывает столь сильного влияния на сервер в целом. Причём нужно заметить, что все программы, кроме MCP, реализованы с поддержкой многопоточности.
Структура MeTA1 На рисунке представлена структурная схема MeTA1. Входящие сообщения обрабатываются программой smtps (SMTP-сервер), в задачи которой входит приём входящих сообщений и их помещение в очередь. Взаимодействующий с SMTP-сервером, модуль SMAR (address resolver) выполняет «прогон» адресов получателя и отправителя по базам access, aliases, mailertable и т. д. В его же юрисдикцию входит и реализация «грейлистинга», о которой чуть подробнее читайте дальше. Очередь представляет собой несколько хранилищ. Содержимое писем, включая информацию заголовков, помещается на диск в так называемое хранилище контента (CDB); информация конверта входящих сообщений (передаваемая в командах MAIL и RCPT в процессе SMTP-диалога) попадает во входящую очередь, размещаемую в оперативной памяти (IQDB), и дублируется на диск в так называемое «резервное» хранилище (IBDB). Управляет очередью программа qmgr (менеджер очереди). Если сообщение должно быть передано удалённому получателю, то данные его конверта перемещаются в активную очередь (AQ), которая периодически обрабатывается планировщиком менеджера QMGR. Когда планировщик принимает решение об отправке данного сообщения, его содержимое из CDB вместе с «конвертной» информацией передаётся SMTP-клиенту (программа smtpc). Если отправка завершается успешно, информация конверта передаётся в IBDB для протоколирования, а само сообщение из CDB удаляется. В случае ошибки сообщение (точнее, конверт плюс некоторая служебная информация) переносится на диск в очередь отложенных сообщений (DEFEDB), и попытки повторной отправки предпринимаются позже – как только сообщение «отлежится» в DEFEDB определённое время, планировщик вновь переносит его в AQ. Координацией работы всех модулей занимается менеджер MCP, который, собственно, и превращает всю эту россыпь отдельных программ в единое целое. На данный момент в пакет MeTA1 не включены агенты локальной доставки (LDA) и submission-агент (MSA). Но для построения полнофункциональной системы, способной взаимодействовать с локальными пользователями, необходимый функционал можно обеспечить сторонними программами, совместимыми с Sendmail. Например, в качестве LDA вполне можно использовать procmail (в каталоге contrib архива исходных текстов MeTA1 можно найти пару патчей для эффективной работы по протоколу LMTP). Для обработки исходящих сообщений требуется либо клиент, умеющий работать непосредственно по протоколу SMTP, либо сторонняя MSA-программа (например, в этой роли может работать Sendmail; можно найти и отдельные программы на эту роль, такие как mini_sendmail). Второе заметное изменение – формат конфигурационного файла. Он стал «Си-подобным» (популярный ныне XML-синтаксис Асмана, видимо, не вдохновил), и в нём для каждой подсистемы задаётся своя «подконфигурация». Все настройки сосредоточены в файле /etc/meta1/meta1.conf. В нём можно задать глобальные параметры (такие, как имена коммуникационных сокетов для взаимодействия частей системы) и секции параметров отдельных модулей. Например, так задаётся конфигурация SMTP-сервера по умолчанию: smtps { log_level = 11; log { facility=mail; ident="smtps"; } CDB_gid = 262; wait_for_server = 4; listen_socket { type=inet; port = 25; } start_action = pass; pass_fd_socket = smtps/smtpsfd; user = smxs; path = "/usr/local/libexec/smtps"; arguments = "smtps -f /etc/meta1/meta1.conf"; } Здесь задаются параметры протоколирования работы модуля (первые два параметра), номер группы для доступа к CDB, информация о прослушиваемом сокете, имя пользователя, путь к «бинарнику», параметры, с которыми он будет запускаться... Пожалуй, это понятнее и удобнее в работе, чем различные «фичи» и «опции» привычного нам mc-файла. Таким же образом задаются настройки для остальных модулей: smtpc, qmgr, smar... По умолчанию устанавливается вполне работоспособная конфигурация; подробности по тем или иным параметрам вы всегда сможете найти в README-файле. Кстати, MeTA1 позволяет очень просто запустить несколько однотипных модулей с различными параметрами, для чего достаточно задать несколько «именованных» секций для соответствующего модуля: smtps SERV1 { ... } smtps SERV2 { ... } Например, таким образом можно организовать работу сервера на различных портах (в «дефолтном» файле конфигурации показан пример запуска двух экземпляров сервера – один как MTA на 25-м порту, другой – на порту 587). Отмечу ещё некоторые новшества. Например, MeTA1 намного проще заставить работать в chroot-окружении. Хотя если учесть, что с правами суперпользователя теперь работает лишь mcp, прослушивающий 25-й порт (он относится к привилегированным), это кажется несколько излишним, но в ряде случаев может оказаться полезным. В MeTA1 появилась «родная» поддержка TLS и SASL. По умолчанию эти функции включены при сборке, но при желании вы можете их и отключить. Сохранилась концепция почтовых фильтров (milter), здесь они именуются policy milters (pmilters). К услугам сторонних разработчиков – всесторонний API, позволяющий воспользоваться всеми функциями фильтров. В дистрибутиве в каталоге contrib можно найти несколько примеров milter, в том числе и для работы со SpamAssassin. По сравнению с Sendmail, в MeTA1 расширились средства борьбы со спамом. В частности, появилась встроенная поддержка технологии «серых списков» (greylisting) – раньше она реализовывалась с помощью программ сторонних производителей, таких как milter-greylist. Правда, нужно заметить, что сделана она несколько «лениво» – вместо триплетов «IP-адрес/отправитель/получатель» учитывается только IP-адрес, который может иметь один из трёх статусов:
Настройки грейлистинга задаются в конфигурации модуля SMAR (помимо различных временных интервалов здесь можно задать и IP-маску, позволяющую считать «совпадающими» все IP-адреса, входящие в заданную подсеть). Кстати говоря, здесь же, в секции smar, задаются и параметры DNSBL – более привычной для администраторов Sendmail технологии противостояния спаму. Лучше один раз попробовать... Посмотрим на практике, что же из себя представляет MeTA1 – на примере версии 1.0.PreAlpha12.0. Очевидно, что на данном этапе разработки речь не идёт ни о прекомпилированных пакетах, ни даже о присутствии этой программы в коллекции портов. Так что единственный способ «пощупать» это творение Клауса Асмана – сборка из исходных текстов. Несмотря на раннюю версию, никаких проблем ни с компиляцией, ни с установкой не возникло – инсталляция прошла безошибочно и на FreeBSD 6.1, и на моей домашней Ubuntu 6.06. Единственный момент, о котором нужно не забыть, – это то, что вам предстоит вручную сформировать требуемую «инфраструктуру», в частности, создать учётные записи необходимых для работы пользователей и соответствующие группы. Используйте для этого принятые в вашей системе инструменты; результат должен быть таким:
Если в вашей системе есть утилита getent, то для доступа к информации, хранящейся в административных базах, правильней будет использовать её. После этого основные операции установки выполняются стандартным образом: распаковка архива с исходниками, переход в полученный каталог, конфигурация (сценарию configure, как обычно, можно передать ряд параметров, влияющих на поддержку тех или иных функций, таких как SASL или BDB; подробности см. в документации), сборка, инсталляция. Но, поскольку мы имеем дело с достаточно ранней версией, после сборки рекомендуется выполнить тесты: $ make check В файле README указывается на некоторые «типичные» ошибки. Например, одна из них – t-hostname – возникает, когда не удаётся определить полное имя хоста (full qualified host name, FQHN). Если вы тестируете MeTA1 на машине, которой не требуется такое имя, то чтобы не получать ошибку, просто внесите в /etc/hosts что-нибудь похожее на FQHN: 127.0.0.1 localhost toshiba toshiba.notebook.my После этого все тесты должны пройти нормально (у меня время от времени проскакивала ошибка t-dns-1, но на неё можно не обращать особого внимания – она лишь говорит о том, что некоторые DNS-запросы не «уложились» в отведённые для них по умолчанию интервалы времени). Теперь осталось завершить установку: $ sudo make install По умолчанию все конфигурационные файлы будут сосредоточены в каталоге /etc/meta1. Если вам доводилось работать с Sendmail, то из «старых знакомых» сразу после инсталляции вы встретите здесь лишь файл псевдонимов – aliases. Остальное – access, mailertable и т. д. – при необходимости придётся создавать вручную. Для быстрого и лёгкого создания хэш-таблиц для этих файлов предусмотрен Makefile, то есть после внесения изменений достаточно лишь выполнить команду make. Все необходимые для работы каталоги (в частности, очередь, которая будет размещена по умолчанию в /var/spool/meta1) должны быть созданы автоматически в процессе инсталляции. Так что уже можно попробовать запустить сервер. Стартовый скрипт размещается по умолчанию в довольно непривычном месте – в /var/spool/meta1, там же, где и очередь. Называется он mcp.sh и принимает в качестве параметра команды start, stop и restart. Им и воспользуемся: # cd /var/spool/meta1 # ./mcp.sh start Никаких сообщений о результате этой операции вы на консоль не получите, и лишь обнадёживающий шелест головок жёсткого диска подскажет вам, что ваша команда принята к исполнению. Убедиться в том, всё ли запустилось, можно, просмотрев список запущенных процессов:
Как видите, с правами root исполняется только «диспетчер» mcp (другие модули вы и не сможете запустить от имени суперпользователя). Но ему по-другому и нельзя – он должен иметь достаточные права для работы на привилегированном порту. Ключ -l указывает на то, что работа сервера будет протоколироваться (по умолчанию используется syslog); -p сообщает имя pid-файла (опять-таки размещаемое в /var/spool/meta1; хотя может так и удобнее, когда всё, относящееся к работе почтового сервера, сосредоточено в одном месте). Последним параметром передаётся полный путь к основному конфигурационному файлу. При желании эти ключи можно изменить непосредственно в mcp.sh (никто не мешает вам создать свой сценарий запуска или даже вызывать программу mcp вручную). Остальные программы пакета работают с правами своего отдельного пользователя. Они запускаются модулем mcp, так что вам об этом беспокоиться не нужно. Передаваемые параметры при необходимости можно подправить в meta1.conf. Если что-то пойдёт не так, то первым делом загляните в лог-файлы. Поскольку MeTA1 по умолчанию протоколирует свою работу, используя syslog, то имена и состав лог-файлов будут определяться настройками в /etc/syslog.conf. В Ubuntu это четыре файла в /var/log (хотя фактически три, поскольку mail.info и mail.log дублируют друг друга, что, естественно, всегда можно подправить в конфигурационном файле):
Одна из наиболее вероятных причин проблем с запуском (обычно о ней свидетельствуют массовые записи типа «Permission denied») – ошибки в создании учётных записей нужных пользователей и групп. Например, это может быть вызвано неверно установленным UID или отсутствием нужного пользователя в «чужой» группе (например, meta1s должен входить помимо своей группы meta1s также и в группы meta1m и meta1c). Наличие пользователей, кстати говоря, можно проверить с помощью входящего в дистрибутив скрипта misc/sm.check.sh:
Правда, он не проверяет вхождение пользователей в нужные группы, так что об этом вам придётся позаботиться самостоятельно. Если придётся подправлять права доступа к уже созданным файлам и каталогам, сверьтесь с файлом README, где подробно расписано, что кому должно принадлежать и с какими правами. Нужно заметить, что MeTA1 более строго относится к стандартам. Например, во время SMTP-сеанса такой вольности, как «mail from: user@server.ru» он не допустит, ругнувшись про «501 5.1.7 Bad sender’s mailbox address syntax». Адрес должен непременно быть в виде <user@server.ru>, причём пробел между двоеточием и открывающей угловой скобкой не допускается. Для адреса отправителя (точнее, для его доменной части) выполняется разрешение имени, и в случае неудачи адрес не принимается. Для адреса получателя такая проверка не выполняется. В остальном типичный SMTP-сеанс с сервером будет выглядеть как обычно, не считая того, что текстовые пояснения даются, скорее, в порядке соблюдения формальностей, а не для того, чтобы действительно что-то пояснить тому странному пользователю, который надумает поработать с SMTP-сервером через telnet. Ждём релиза Итак, на данный момент MeTA1, несмотря на очень скромный номер версии и альфа-статус, уже выглядит весьма достойно. Во время небольшого тестирования каких-либо ошибок и сбоев выявлено не было. Хотя на «боевой» сервер я пока что ставить этот пакет повременю. Задумка разработчиков понятна – опираясь на собственный опыт и опыт конкурирующих SMTP-серверов, вобрать в пакет всё самое лучшее и, по возможности, исключить любые недостатки. Пока что промежуточный результат выглядит неплохо. Что получится в итоге – увидим. Я лично с нетерпением жду первого релиза. Приложения Версии MeTA1 Sendmail X 0.0.0.0 увидел свет 30 октября 2005 года. Буква «X», видимо, намекала на то, что этот пакет вполне может со временем стать версией Sendmail 9 или Sendmail 10, в зависимости от готовности... В конце 2006 года ветвь 1.0 была выделена в «отдельное производство», получив наименование MeTA1. На момент написания статьи текущей была версия 1.0.PreAlpha12.0, вышедшая 11 ноября 2006 года. Сайт проекта – www.meta1.org. Документация Метод «научного тыка», безусловно, один из самых популярных и порой даже весьма эффективен, но всё же лучше иметь под рукой официальное руководство. Man-страницы помогут быстро окинуть взглядом основные ключи запуска той или иной программы, входящей в пакет. В дистрибутиве их 7: meta1(8), meta1.conf(5), mcp(8), qmgr(8), smar(8), smtpc(8) и smtps(8). Но всё же основным источником информации на данный момент остаётся файл README. В дистрибутиве он поставляется в самых различных форматах – txt, pdf, html, tex и т. п. Найти его (наряду с др-угими документами) можно на домашней странице проекта – www.meta1.org. |
СЕРГЕЙ СУПРУНОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
