LXF103:Hardcore Linux

Материал из Linuxformat.

Почта: собери свой сервер

Большинство людей пользуется электронной почтой, понятия не имея, как она работает. Светоч знаний д-ра Криса Брауна рассеет тьму невежества.

Чтобы вы могли представить, с чем вообще едят почтовый сервер, взгляните на Рис. 1: там показана схема доставки почты в Интернете.

Рис. 1: Один день из жизни почтового сообщения.

Проследим продвижение почтового сообщения на его пути через Интернет от отправителя к получателю и разберемся, как все компоненты работают совместно. Пусть Маша сидит за своим компьютером и составляет электронное послание, используя почтовый клиент (Mail User Agent – MUA). В мире Linux клиент Маши будет чем-то вроде Evolution или KMail. Она пишет своей маме Ане, электронный адрес которой anna@example.com. Когда Маша нажимает кнопку Послать, ее MUA соединяется с Mail Transport Agent (MTA – почтовым транспортным агентом), на который Маша настроила свой MUA для отправки почты. Обычно MTA предоставляется Маше ее интернет-провайдером (ISP). MUA и MTA говорят друг с другом на языке протокола SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты), организовывая доставку сообщений. В ходе этого диалога MUA определяет получателя сообщения и передает текст письма.

MTA отвечает за «дальнюю перевозку» сообщения. Он сделает запрос к DNS (Domain Name System, системе доменных имен) на поиск записи MX (Mail Exchanger), которая скажет ему, какая машина действует как почтовый сервер для домена example.com, где расположен Анин почтовый ящик. Из этого запроса он может узнать, что почтовый сервер, допустим, mail.example.com. MTA Маши теперь соединяется с MTA на mail.example.com, снова использует SMTP для указания получателя письма и передает тело сообщения. Принимающий MTA проверяет, что он и вправду почтовый сервер для домена получателя, а потом уж дает согласие на прием. Если все проходит нормально, принимающий MTA передает сообщение MDA (Mail Delivery Agent – почтовому агенту доставки), который сохраняет сообщение в хранилище сообщений (оно находится в файловой системе почтового сервера). Для этого сообщения работа MTA выполнена.

Аня проводит выходные с дядей Васей, помогая ему разбирать чердак, и не может в эти дни читать почту. Но когда она доберется до компьютера, ее почтовый клиент соединится с Mail Access Agent (MAA – агентом доступа к почте) на ее почтовом сервере example.com для проверки почты, которую MTA ее домена сохранил в ее хранилище. Ее MUA может использовать для этого один или два протокола. Чаще всего это Post Office Protocol (POP3 – почтовый протокол) версии 3. POP – это протокол, который скачивает почту с почтового сервера, затем (как правило) удаляет ее с сервера и оставляет ее на клиенте (компьютере в Аниной квартире), обеспечивая долговременное хранение сообщения. Но если Аня работает в корпорации Example.Com, данное учреждение может иметь почтовый сервер, работающий по протоколу IMAP4. IMAP расшифровывается как Internet Message Access Protocol [интернетпротокол доступа к сообщениям]; он позволяет Аниному MUA получать доступ к ее почтовому архиву, но долговременное хранение писем происходит на сервере (хотя некоторые MUA поддерживают локальные копии). Благодаря IMAP можно подключаться к серверу с любого компьютера с IMAP-клиентом и видеть весь почтовый архив – а вот если бы вы читали почту, используя POP на разных машинах, то в итоге ваши письма были бы раскиданы по этим машинам, что я знаю по своему горькому опыту.

Наш почтовый сервер изображен на Рисунке 1 как большой серый квадрат в правом верхнем углу. В реальности необходимы два компьютера – один для почтового сервера, другой для клиента. Возьмем Postfix как SMTP-сервер и Dovecot как почтовый POP3-сервер. На почтовом сервере моя основная ОС – CentOS 5 (CentOS – это клон Red Hat Enterprise Linux), но конфигурация и операции с Postfix и Dovecot не зависят от используемого дистрибутива Linux. Клиентская машина может быть любой. В моем случае на ней Ubuntu 7.04 с Evolution в качестве MUA.

Начнем: Mail Transfer Agent

Сперва мы установим Postfix. Но предварительно проверим: вдруг Sendmail уже установлен и запущен. На системах типа Red Hat это могут сделать следующие команды:

# rpm -q sendmail
# service sendmail status

Если Sendmail запущен, надо его остановить и позаботиться, чтобы он не запустился после перезагрузки:

# service sendmail stop
# chkconfig sendmail --del

При наличии на вашей машине включенного брандмауэра, вы должны открыть порт для SMTP (tcp/25).

Моя собственная установка Postfix споткнулась, обнаружив отсутствие административной группы под названием postdrop. То есть до установки пакетов нужно было создать эту группу:

# groupadd -r postdrop
# yum install postfix

Возможно, эта проблема касается только моего дистрибутива, и на вашей системе такого не произойдет.

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

 # chkconfig --add postfix

Файл настройки Postfix – /etc/postfix/main.cf. Фактически, Postfix должен заработать «из коробки» как простой почтовый сервер с минимальной доработкой готовой конфигурации, но есть несколько параметров, требующих внимания. Так, строку в main.cf

 inet_interfaces = localhost

нужно заменить на

 inet_interfaces = all

Это мы велим Postfix слушать SMTP соединения на всех сетевых интерфейсах машины, а не только на локальном (localhost).

Далее проверим установки параметра myhostname. Он определяет FQDN этой почтовой системы. Если он не определен, то по умолчанию берется имя хоста машины, на которой запущен сервер, возвращаемое командой hostname. Так, если ваш хост – mail.example.com, это имя и будет принято по умолчанию.

Наконец, параметр mydestination задает список доменов, которые эта машина считает для себя пунктом назначения (то есть домены, для которых машина сохраняет сообщения). Минимальное значение этого параметра должно походить на следующее:

 mydestination = example.com

Установив все эти параметры, можно запускать Postfix. На RedHat-совместимых системах это делается командой

 # service postfix start

Далее, я создал учетную запись для пользователя anna и установил пароль:

# useradd anna
# passwd anna

Без них не обойтись, потому что «локальный» агент доставки почты в Postfix требует, чтобы получатель имел учетную запись в Linux-системе: по ней происходит аутентификация в Dovecot (который мы рассмотрим чуть позже).

Теперь у нас все готово для теста доставки почты в хранилище сообщений. На моей настольной системе с Ubuntu я создал запись в файле /etc/hosts, возвращающую IP-адрес машины mail.example.com. В моем случае строка выглядела так:

192.168.0.41 mail.example.com

В реальности, почтовый сервер должен иметь DNS-запись, и вам не нужно задавать ее в /etc/hosts. Затем я сконфигурировал «учетную запись» в моем MUA (Evolution) на использование SMTP-сервера mail.example.com для исходящих сообщений. Я включил эту учетную запись Evolution и отключил остальные. Затем я попытался послать несколько писем на anna@example.com.

Сработало? Ну, тот факт, что письма исчезли из моих Исходящих [Outbox] в Evolution, уже обнадеживал, но лучший способ проверки – найти сообщения сохраненными на почтовом сервере. Что выводит нас на ...

Хранилище сообщений

Традиционный способ хранения сообщений на почтовом сервере известен как формат Mbox: для каждого пользователя хранится отдельный текстовый файл. Имя этого файла совпадает с именем учетной записи пользователя, чью почту он хранит, а каталог определяется параметром mail_spool_directory настройки Postfix (обычно /var/spool/mail или /var/mail). Например, Анины сообщения могут заноситься в /var/spool/mail/anna. Внутри этого файла каждое сообщение начинается строкой с первым словом “From” и заканчивается пустой строкой. (Вас может сбить с толку наличие в этом файле других строк, тоже начинающихся на “From:” – заметили двоеточие? Это часть заголовков сообщения.) Надеюсь, Postfix вписал мое тестовое сообщение в этот файл.

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

Если посланное вами сообщение появилось в хранилище, пора перейти к нашему POP3-серверу. Если его нет, прочитайте советы во врезке Решение проблем, внизу .

Установка и настройка Dovecot

На моей CentOS для установки Dovecot надо всего лишь скомандовать:

# yum install dovecot

Теперь нужно найти файл конфигурации Dovecot. Обычно это /etc/dovecot.conf. Как типичный современный файл конфигурации, он довольно длинен (более 1000 строк), но почти целиком состоит из комментариев. Как оказалось, мне нужно было изменить две строчки; одна задает протокол(ы), которые должен обслуживать Dovecot, а вторая говорит, где находятся файлы почтового ящика. Эти два параметра я изменил так:

protocols = pop3
    mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n

Первая строка говорит, что мы будем использовать только протокол POP3. Во второй строке, установка INBOX использует специальный параметр %n для замены именем пользователя, под которым мы зашли проверить почту (в нашем примере – “anna”). Заметим, что значение параметра INBOX должно совпадать с расположением хранилища почты, указанном в Postfix.

Если у вас на почтовом сервере запущен брандмауэр, нужно также открыть порт POP3 (110/tcp).

Теперь мы готовы к запуску сервиса:

# service dovecot start

Пора тестировать. На клиенте, в настройках MUA мне необходимо установить для приема почты использование протокола POP и сервера mail.example.com, затем задать имя anna и отключить опции шифрования, предлагаемые MUA. Теперь я готов принять мои сообщения. В этом пункте мой MUA должен (надеюсь) запросить пароль anna, а мне необходимо предоставить пароль, который я задал, создавая ее учетную запись Linux на сервере. Если все пройдет гладко, вы должны увидеть ранее посланные письма появившимися во Входящих MUA. И если вы вернетесь на сервер, то обнаружите, что сообщения исчезли из хранилища anna. Если опять ничего не выйдет, обратитесь ко врезке Решение проблем.

Ура, оно работает!

Если вы дошли досюда, поздравляем! У вас появился работающий почтовый сервер. Как обычно, я создавал максимально простую конфигурацию, чтобы все поскорее заработало. Однако эта реализация подразумевает несколько допущений: во-первых, почтовый сервер обслуживает только один домен (example.com), а во-вторых, все пользователи, желающие получать почту, имеют учетные записи Linux на почтовом сервере. Это последнее ограничение задается как со стороны локального агента доставки в Postfix, так и Dovecot, который, в своей конфигурации по умолчанию, требует действующей учетной записи Linux для аутентификации пользователей, для входа через POP и получения электронной почты. Отметим также, что в нашей конфигурации MTA (Postfix) не требуется аутентификации пользователя, в отличие от MAA (Dovecot).

Поддерживаем несколько доменов

В реальных условиях одной машине приходится быть почтовым сервером для множества доменов. Самый простой путь это обеспечить – добавить домены в параметр mydestination в /etc/Postfix/main.cf. Например, установка:

mydestination = example.com example.org example.net 

велит Postfix принимать почту для трех указанных доменов. Конечно, если вы что-то поменяли в main.cf, нужно заставить postfix перечитать его:

# service postfix reload

Конечно, надо также обеспечить, чтобы MX-записи в DNS для всех трех доменов ссылались на сервер mail.example.com. Однако эта методика имеет ограниченное применение, поскольку у всех доменов – общее пространство имен: так, почта на anna@example.com, anna@example.org и anna@example.net будет в конце концов сохранена в одном и том же месте. И, конечно, Ане (и всем другим получателям почты) нужна учетная запись Linux на сервере.

Более гибкое решение – использовать так называемые «виртуальные» почтовые домены. При таком способе каждый домен имеет отдельное пространство имен, и письма для anna@example.com и anna@example.net окажутся в разных хранилищах почты. Получателю также не требуется иметь системную учетную запись Linux. Но зато требуется чуть больше работы по настройке...

Требуемые для этого строки в main.cf показаны в Листинге А ниже. Учтите, что номера строк проставлены только для удобства ссылки: в файле их нет.

ЛИСТИНГ A

Строка 1 в Листинге А содержит список доменов, которые будут поддерживаться. Их надо удалить из параметра mydestination, так как они теперь будут обрабатываться с использованием «виртуального» агента доставки Postfix, и «локальный» агент им больше не нужен.

Если список доменов по-настоящему большой, вы можете предпочесть поместить его в отдельный файл, например, /etc/postfix/virtual_domains, по образцу:

 # list of virtual domains for postfix
        example.com
        example.net
        example.org
 # ... and lots more ...

и ссылаться на этот файл через параметр virtual_mailbox_domains в main.cf:

 virtual_mailbox_domains = /etc/postfix/virtual_domains

Аналогично, многие параметры в main.cf могут иметь список требуемых значений, помещенный в отдельный файл.

Строка 2 в Листинге А задает директорию верхнего уровня, где должны сохраняться сообщения. Очевидно, надо выбрать схему, совместимую с нашими POP- и IMAP-серверами. Здесь выбрано одно из множества возможных решений.

Создадим то, что Postfix называет «картой» – для отметки, где получатели почтовых адресов будут сохранять сообщения относительно заданного virtual_mailbox_base. Я создал простую карту в файле, который назвал /etc/postfix/virtual_mailbox_map:

anna@example.com anna
anna@example.net anna_smith
chris@example.org cbrown

Теперь, например, письмо, посланное на anna@example.net, будет сохранено в /var/spool/vmail/anna_smith; письмо, посланное на адрес chris@example.org, «упадет» в /var/spool/vmail/cbrown, и так далее. Заметьте, что здесь не требуется совпадения видимых снаружи имен пользователей (в нашем примере, anna и chris) со внутренними именами (anna_smith и </font color="darkred">cbrown</font>).

Конвертируем этот файл в «карту», используя команду postmap:

 # postmap /etc/postfix/virtual_mailbox_map

В результате появится файл virtual_mailbox_map.db. Карта, в данном случае, просто вид индексированной структуры данных, ключи которой могут быть эффективно просмотрены Postfix. Postfix поддерживает несколько типов «карт»; по умолчанию это обычно «хэш».

Далее, в строке 3 Листинга А, вы сообщаете Postfix, где находится карта.

Postfix нуждается в отождествлении пользователя, используемом для доставки сообщения в хранилище. Возможно задание нескольких карт (uid_map и gid_map), определяющих отдельные отождествления для всех и каждого получателя, но мы сделаем проще и используем одну и ту же личность для всех получателей. Я создал пользователя с именем postmanpat для этой цели.

 # useradd -d /var/spool/vmail -g postdrop -u 550 -m postmanpat

Отметим, что домашняя директория postmanpat находится в моей выбранной директории virtual_ mailbox_base. Далее я смягчил права доступа в /var/spool/vmail, чтобы Dovecot мог ей воспользоваться.

 # chmod 755 /var/spool/vmail

Нет необходимости предварительно создавать файл сохраненных сообщений для индивидуальных получателей – Postfix сделает это по требованию. Наконец, строки 4 и 5 Листинга А задают тождество пользователя и группы, которые Postfix будет использовать для помещения сообщений в хранилище. Они соответствуют ID пользователя postmanpat и группы postdrop.

После внесения данных изменений та часть, за которую отвечает Postfix, должна работать. Возвратитесь к клиентской машине и пошлите тестовое сообщение на chris@example.org. На сервере проверьте, что это сообщение появилось в /var/spool/vmail/cbrown. Если да, то доставка Postfix на виртуальные почтовые домены работает!

На стороне Dovecot я просто изменил определение параметра mail_location на следующее:

 mail_location = mbox:~/mail:INBOX=/var/spool/vmail/%n

Продолжение следует

Пока мы не касались аутентификации POP3 при входе в Dovecot. В текущем состоянии, чтобы Dovecot заработал, вам необходимо создать очередные учетные записи Linux пользователям anna, anna_smith и cbrown, для новой аутентификации Dovecot. Чтобы виртуальные домены применялись правильно, необходимо рассмотреть вопрос об аутентификации учетных записей POP3 через базу данных пользователей, не зависящую от учетных записей Linux. На данном уроке уже подпущено достаточно ежей под череп, но в следующем номере Linux Format я попытаюсь решить вопрос об аутентификации внутри почтовых систем и в Postfix и в Dovecot. Пишите на [[1]], если у вас возникнут проблемы с вашим почтовым сервером. LXF

Решение проблем (врезка)

Пример использования команды telnet.

Если вы не можете передать и принять почту, используя ваш почтовый сервер, попробуйте проверить следующее:

1. На клиенте проверьте, что почтовый сервер пингуется по его IP-адресу и имени, используя команды:

# ping 192.168.0.41
# ping mail.example.com

(Естественно, подставьте сюда IP-адреc вашего сервера.)

2. На сервере проверьте, что серверы SMTP и POP слушают соединения, используя команду

# netstat -at

Вы должны увидеть LISTEN в конце информации о портах SMTP и POP3.

3. На клиенте, попробуйте использовать telnet для соединения с портом 25 на почтовом сервере, используя команду:

# telnet mail.example.com 25

Вы должны получить отклик с сервера типа такого:

220 mail.example.com ESMTP Postfix

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

4. На сервере проверьте, что брандмауэр не блокирует доступ к портам 25 (SMTP) и 110 (POP3), используя команду:

# iptables -L

Если вы не уверены, отключите брандмауэр командой:

# itables -F

и попробуйте снова. Не забудьте потом восстановить работоспособность брандмауэра.

5. На сервере поищите разгадку в системных журналах почты (обычно /var/log/maillog).