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

Response: 220 mail.domain1.com ESMTP Postfix

Command: EHLO host1.domain1.com

Response: 250-mail.domain1.com

Response: 250-PIPELINING

Response: 250-SIZE 10240000

Response: 250-ETRN

Response: 250-STARTTLS

Response: 250-AUTH PLAIN

Response: 250 8BITMIME

Message: STARTTLS

Response: 220 Ready to start TLS

Message: \026\003\001\000S\001\000\000O\003\001\000\033\2144\341\024A\361\

322EP\370yF\257\370x\273?\031<+\326\355\327\337X\347\207\305P\234\000\

000(\0009\0008\0005\0003\0002\000\004\000\005\000/\000\026\000\023\376\377\000

Message: \000\025\000\022\376\376\000\t\000d\000b\000\003\000\006\001\000

Расширение 8BITMIME, описанное в RFC 1652 (SMTP Service Extension for 8bit-MIME transport) позволяет использовать тип MIME-кодирования 8bit. Оно не является обязательным, поэтому использовать заголовки, закодированные таким образом, нежелательно.

Кроме использования протокола SMTP существует более простой способ отправить почтовое сообщение - это так называемая локальная отправка, поддерживаемая почти всеми MTA. Общепринятым способом локальной отправки является использование pipe-интерфейса программы sendmail, существуют MUA, которые поддерживают этот способ отправки (KMail, mutt, pine), а mailx вообще никаких других способов, кроме этого, не поддерживает. Ниже представлен простейший shell-скрипт, выполняющий локальную отправку.

#!/bin/sh

/usr/sbin/sendmail -t << EOF

From: user1@domain1.com

To: user2@domain2.com

Subject: Test Message

Hello!

EOF

1.1.4 Транспортировка сообщений

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

Среди существующих MTA (Mail Transfer Agent), в качестве кандидатов на место smtp-демона исключительно unix-совместимых MTA рассматриваются Sendmail, Qmail, Exim и Postfix.

Sendmail является самым старым MTA из списка чаще используемых. Несмотря на впечатляющий и мощный функционал у него есть ряд существенных недостатков. Программа представляет собой один монолитный блок. По этой причине в ней остается много уязвимостей и проблем с быстродействием. Немаловажным недостатком является очень сложная процедура конфигурирования. Для создания простейщей конфигурации необходимо иметь дело с компилятором M4, поэтому перспективы использования сильно снижаются. Хотя в силу того, что его используют достаточно давно, Sendmail имеет много приверженцев. Заключительным фактом против его использования для офиса (организации) среднего размера является то, что программа создана для намного более крупных масштабов, поэтому нецелесообразно использовать данное решение.

Qmail самый безопасный из претендентов, но обладает слишком жесткой иерархией запуска служебных программ. Для выполнения каждого класса своих задач он порождает дочерние процессы специальных программ. После выполнения задачи процесс дочерней программы уничтожается. С одной стороны это обеспечивает безопасность и запас прочности программы, но с другой создает некоторые накладные расходы на постоянное создание дочерних процессов и межпроцессорное взаимодействие. К тому же проект qmail развивается слишком медленно. Этот MTA так и не получил широкого распространения из-за лицензионных ограничений, благодаря которым многие дистрибутивы Linux не включают его в свой состав.

Exim это монолитный MTA подобно Sendmail, обладает мощным функционалом и потенциалом, однако процесс установки довольно нетривиален (достаточно сложный). Для включения тех или иных возможностей приходится редактировать Makеfile.

Postfix создавался как альтернатива Sendmail. Считается, что Postfix быстрее работает, легче в администрировании, более защищён и, что важно, совместим с Sendmail. Также Postfix являющийся ближайшим конкурентом qmail делает упор на быстродействие и безопасность. Принципы деления выполняемой задачи очень похожи на те что применяются в qmail, но дизайн системы совершенно другой. Основой идеологии postfix является наличие независимых резидентных модулей. Ни один из модулей не является дочерним процессом другого. В тоже время за счет постоянного присутствия модулей в памяти каждый из них может независимо пользоваться услугами других. Проект Postfix на данный момент является самым динамично развивающимся из всех перечисленных.

1.1.5 Доставка почтовых сообщений

Количество MTA, через которые пройдет письмо, пока не найдет своего адресата, в принципе не ограничено. На практике в большинстве случаев достаточно двух MTA, если домены отправителя и получателя обслуживаются разными MTA (и между ними есть прямой TCP/IP маршрут), или одного в противном случае. Задачей MTA после получения письма для своего домена является сохранение письма в постоянное хранилище, откуда его сможет прочесть адресат с помощью своего MUA. Доставкой письма в это хранилище занимается очень широкий класс ПО, который носит общее название MDA (Mail Delivery Agent).

Раньше процедура доставки была значительно проще. Использовалась исключительно push-технология: MTA посредством собственного локального MDA доставлял почтовые сообщения куда-нибудь в /var/mail или /var/spool/mail, а MUA, появившиеся в те времена (mailx, mutt, pine), читали сообщения непосредственно оттуда - при этом они обязаны были находиться на одной машине с MTA или монтировать свои почтовые ящики, например, по NFS.

Затем более популярными стали pop-технологии: /var/mail и /var/spool/mail выродились в специализированные серверные хранилища почты с собственными специализированными средствами доставки почты, появились сервисы, предоставляющие доступ к этим хранилищам по протоколам POP3 и IMAP по запросу самого MUA - причем новые MUA (Mozilla, Outlook, The Bat!) по другому себе жизнь уже не мыслят и о /var/mail и /var/spool/mail ничего не знают.

На рисунке 1.2 представлена схема использования протоколов при передаче почты в каждый узел, участвующий в передаче.

Рисунок 1.2 – Общая схема доставки почты

1.1.6 Форматы серверных почтовых хранилищ

На сегодняшний день существует два стандартных формата серверных хранилищ почты (mbox и Maildir - их стандартность проявляется в том, что доставлять в них почту и извлекать ее оттуда могут различные MDA) и несколько нестандартных (например, файловое хранилище Cyrus, похожее по идеологии на Maildir, но несовместимое с ним, и хранилище DBMail, использующее БД MySQL или PosgreSQL - если использовать эти хранилища, то вместе с их преимуществами одновременно резко ограничивается выбор MDA для доставки и извлечения почты).

К нестандартным хранилищам можно отнести Cyrus и DBMail.

DBMail — проект мира открытого ПО, обеспечивающий возможность хранения электронной почты в реляционной базе данных, а также работу пользователей со своей корреспонденцией посредством протоколов IMAP и POP3.

Наиболее распространены стандартные хранилища:

1. Mbox - это целое семейство не совсем совместимых друг с другом форматов, различные модификации которых используются как в хранилищах почты на серверах, так и локально в MUA. Все эти форматы объединяет то, что все сообщения хранятся в одном файле, начинаются с поля From и отделены друг от друга пустой строкой. В процессе доставки новые сообщения дописываются в конец mbox-файла.

From user1@domain1.com Sun Oct 23 16:26:52 2005

Return-Path: <user1@domain1.com>

Received: from mail.domain1.com (mail.domain1.com [xxx.xxx.xxx.xxx])

        by mail.domain2.com (8.13.5/8.13.1) with ESMTP id j9NCQqTZ012628

        for <user2@domain2.com>; Sun, 23 Oct 2005 16:26:52 +0400 (MSD)

        (envelope-from user1@domain1.com)

Received: from host1.domain1.com (host1.domain.com [xxx.xxx.xxx.xxx])

        by mail.domain1.com (Postfix) with ESMTP id CEA8840F0

        for <user2@domain2.com>; Sun, 23 Oct 2005 16:33:25 +0400 (MSD)

From: user1@domain1.com

To: user2@domain2.com

Subject: Test Message

Message-Id: <20051023123325.CEA8840F0@mail.domain1.com>

Date: Sun, 23 Oct 2005 16:33:25 +0400 (MSD)

Hello!

Хранение всех сообщений в одном файле приводит к тому, что писать приложения, осуществляющие одновременное добавление новых сообщений и редактирование уже существующих, не так просто, как хотелось бы, не слишком надежно (возможностей повредить mbox предостаточно), а иногда и просто невозможно (блокировка mbox на запись при доставке сообщений делает невозможной параллельную доставку). Именно это и было причиной появления другого формата - Maildir.

2. Maildir - это каталог с тремя подкаталогами внутри: tmp, new, cur. При доставке сообщения оно помещается в файл в подкаталоге tmp, имя файла формируется из текущего времени, имени хоста, идентификатора процесса, создавшего этот файл, и некоторого случайного числа - таким образом, гарантируется уникальность имен файлов. После записи в файл всего сообщения создается жесткая ссылка на этот файл в каталоге new, а текущая ссылка из tmp удаляется - это делается для того, чтобы никакой другой процесс не смог прочитать содержимое сообщения до тех пор, оно не будет записано полностью. По такому же алгоритму при чтении сообщения (это может делать как MUA, так и другой MDA, предоставляющий доступ к Maildir по протоколу POP3 или IMAP) оно перемещается в каталог cur, при этом название файла изменяется: к нему добавляются пометки о прочтении, ответе, удалении и т.д.

3. Maildir++ - это дальнейшее усовершенствование Maildir с поддержкой вложенных каталогов IMAP (они должны начитаться с .) и квот.

Все MTA содержат в своем составе локальные MDA для доставки в mbox, а иногда и в Maildir, но часто для доставки выгоднее бывает использовать внешние MDA общего назначения, позволяющие выполнить дополнительные операции с почтовыми сообщениями: переложить в другой почтовый ящик, переслать на другой почтовый адрес, передать другой программе по pipe-интерфейсу для дальнейшей обработки и т.д. Самыми распространенными внешними MDA общего назначения являются:

1. Procmail - в основном используется для доставки сообщений в mbox (хотя существует патч для поддержки Maildir).

2. Maildrop - является частью проекта Courier, может доставлять почту в mbox, но чаще используется для доставки почты в Maildir. Более эффективно расходует системные ресурсы, чем Procmail, поддерживает виртуальных пользователей, информация о которых может храниться в Berkley DB, LDAP, MySQL и PostgreSQL.

Procmail и Maildrop используют pipe-интерфейс для приема почты от MTA: для каждого почтового сообщения создается отдельный процесс MDA, получающий сообщение на stdin. Это не слишком экономный способ обработки почты, особенно при больших объемах, поэтому MTA предлагают еще один способ получения сообщений - протокол LMTP, описанный в RFC 2033 (Local Mail Transfer Protocol). MDA, использующий LMTP, принимает сообщения по TCP/IP или UNIX-сокету подобно MTA, поэтому создавать отдельный процесс на каждое сообщение не нужно. Cyrus и DBMail предлагают MDA, использующие LMTP, для доставки в собственные хранилища, а вот для mbox и Maildrop таких MDA нет.

Кроме фильтрующих MDA общего назначения в процессе доставки сообщения в серверное хранилище также могут использоваться специализированные контент-фильтры. Такие фильтры могут выполнять функцию отсеивания спама и вирусов, в этом качестве часто используются SpamAssassin и SpamOracle в связке с популярными антивирусами. Они могут использовать как pipe-интерфейс, так и интерфейс LMTP. Последний вариант, как правило, является более производительным, но затрудняет использование контент-фильтра в MDA общего назначения - остается использовать MDA из комплекта MTA.

1.1.7 Организация доступа к серверным хранилищам

Наиболее популярными MDA, предоставляющими доступ к mbox и Maildir по протоколам POP3 и IMAP, являются:

1. UW IMAP – самый простой из всех перечисленных. Работает под inetd/xinetd, не имеет вообще никаких настроек, в качестве механизма аутентификации использует только PAM, по умолчанию работает только с mbox (хотя существует патч для поддержки Maildir). Предоставляет доступ ко всем файлам домашнем в каталоге пользователя как к каталогам IMAP, даже если они не являются mbox - обязанность отображения только нужных файлов (действительно являющихся mbox) возлагается на MUA. Да и история безопасности у него очень нехорошая.

2. Courier IMAP – часть проекта Courier, в который также входят собственный (но не слишком распространенный) MTA, уже упоминавшийся Maildrop, менеджер списков рассылки, средства совместной работы (groupware) и средства доступа к почте через Web. В качестве формата хранилища поддерживается только Maildir. Для аутентификации и Courier IMAP, и Maildrop используют общую библиотеку Courier Authentication Library, которая поддерживает хранение логинов, паролей, пути к Maildir пользователя и квот Maildir в Berkley DB, LDAP, MySQL и PostgreSQL - таким образом, почтовые пользователи не обязаны иметь системные учетные записи. Кроме того, для аутентификации возможно использование PAM.

3. Dovecot – позиционируется как сервер POP3/IMAP, при написании которого в первую очередь учитывалась безопасность: другими словами, он относится к UW IMAP и Courier IMAP как Qmail и Postfix к Sendmail. В качестве формата хранилища поддерживается как mbox, так и Maildir, для увеличения производительности (которая всегда была слабым местом при работе с mbox) используются специальные индексы. Для аутентификации используется уже упоминавшийся механизм SASL - его же для аутентификации используют многие MTA и Сyrus IMAP. Но в целом по функциональности Dovecot пока не дотягивает до Courier IMAP.

4. Cyrus IMAP – наиболее продвинутая почтовая система, которая помимо уже перечисленных возможностей, доступных в других MDA, включает возможности кластеризации и проксирования, быстрый и гибкий механизм фильтрации почтовых сообщений Sieve, описанный в RFC 3028 (Sieve: A Mail Filtering Language). Однако все компоненты Cyrus используют собственный формат хранилища почтовых сообщений и не умеют работать со стандартными mbox и Maildir.

В тех случаях, когда поддержка протокола IMAP не требуется, возможно, использование более простых MDA, предоставляющих доступ к mbox и Maildir только по протоколу POP3: к их числу относятся Cubic Circle (cucipop), QPopper и Popa3d.

1.1.8 Получение сообщений

MDA, используемые для доставки почты в mbox и Maildir, и MDA, предоставляющие доступ к ним по протоколам POP3 и IMAP, взаимозаменяемы точно так же, как и различные MTA. С точки зрения MUA абсолютно не важно, какие MDA и какой тип хранилища используются на сервере.

Протокол POP3, описанный в RFC 1939 (Post Office Protocol - Version 3), подразумевает, что пользователи забирают сообщения из серверного хранилища и работают с ними в локальном хранилище своего MUA. Пример использования протокола POP3 с помощью telnet:

# telnet localhost 110

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

+OK Hello there.

USER user1

+OK Password required.

PASS pwd1

+OK logged in.

STAT

+OK 1 422

LIST

+OK POP3 clients that break here, they violate STD53.

1 422

.

RETR 1

+OK 422 octets follow.

Return-Path: <user1@domain1.com>

Received: from mail.domain1.com (mail.domain1.com [xxx.xxx.xxx.xxx])

        by mail.domain2.com (8.13.5/8.13.1) with ESMTP id j9NCQqTZ012628

        for <user2@domain2.com>; Sun, 23 Oct 2005 16:26:52 +0400 (MSD)

        (envelope-from user1@domain1.com)

Received: from host1.domain1.com (host1.domain.com [xxx.xxx.xxx.xxx])

        by mail.domain1.com (Postfix) with ESMTP id CEA8840F0

        for <user2@domain2.com>; Sun, 23 Oct 2005 16:33:25 +0400 (MSD)

From: user1@domain1.com

To: user2@domain2.com

Subject: Test Message

Message-Id: <20051023123325.CEA8840F0@mail.domain1.com>

Date: Sun, 23 Oct 2005 16:33:25 +0400 (MSD)

Hello!

.

DELE 1

+OK Deleted.

QUIT

+OK Bye-bye.

После аутентификации с помощью команд USER и PASS получаем количество сообщений в почтовом ящике и их общий размер - для этого используется STAT. С помощью LIST получаем список сообщений и их размеры. Затем запрашивается текст первого (и единственного) сообщения с помощью RETR, удаляется из серверного хранилища с помощью DELE и отключение от сервера - командой QUIT.