Как работает Sendmail? Полезные подробности. Часть 1

Сергей Супрунов

Как работает Sendmail?

Полезные подробности. Часть 1

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

Среди системных администраторов, особенно начинающих, бытует мнение, что Sendmail – чрезвычайно сложная, неуклюжая, неэффективная и небезопасная программа. Конечно, дыма без огня не бывает, и причины для подобных мнений есть. Достаточно взглянуть на основной конфигурационный файл – sendmail.cf, чтобы согласиться с первым утверждением. Монолитная архитектура, когда практически все функции выполняются одним двоичным файлом, навевает мысли о втором и третьем. Нередкие взломы в прошлом (долго ещё люди будут помнить червя Морриса, потрясшего мир в 1988 году) серьёзно подорвали доверие к Sendmail в плане защищённости системы.

Однако идёт время, меняется ситуация. Кое-что из сказанного выше несколько улучшилось, что-то вообще стало неправдой. Скажем, конфигурационный файл по-прежнему остался пугающе непонятным. Но ведь никто вас и не заставляет его править! Для этого существуют более удобные и простые инструменты. Монолитность сохранилась, но работа этого единственного «бинарника» стала более эффективной, появилось более чёткое разделение на задачи, причём уже не все из них требуют наличия прав суперпользователя. Говоря же о безопасности, надо признать, что последняя критическая уязвимость была обнаружена сравнительно недавно – 22 марта 2006 года (к чести разработчиков, была она исправлена достаточно быстро). Но вот предпоследняя датируется аж 18 сентября 2003 года.

Конечно, если сравнивать Sendmail с такими альтернативами, как Postfix, Exim, Qmail, то по некоторым параметрам он проигрывает своим конкурентам. Но только не в плане функциональности. Так что вряд ли стоит так просто сбрасывать его со счетов. Тем более что Sendmail по-прежнему остаётся почтовой программой, устанавливаемой по умолчанию во FreeBSD, OpenBSD, Solaris и ряде других систем.

Впрочем, я не ставлю своей целью поднять очередную волну религиозных войн среди приверженцев того или иного MTA. Каждый вправе пользоваться тем инструментом, какой ему ближе по духу и лучше подходит для тех или иных задач. Надеюсь, что аргумент «я не понимаю эту программу» не является для вас основным критерием выбора, что ставить и использовать. И после прочтения данной серии вы сможете более осознанно подходить к выбору почтовой программы, руководствуясь исключительно объективными данными.

Всё, о чём будет идти речь сегодня, относится к версии Sendmail 8.13.4 с последним патчем, работающей во FreeBSD 6.0 (используется дистрибутивная установка). Применимость утверждений, примеров конфигурации, путей к файлам и т. д. к другим системам и версиям не проверялась, но в большинстве случаев всё должно работать аналогично.

Учитывая, что на системах Linux в последнее время более распространён Postfix (за исключением некоторых дистрибутивов), отвлекаться на особенности Sendmail в этих системах я не буду.

Архитектура и основы функционирования

Как уже упоминалось, Sendmail является монолитной программой. Единственный двоичный файл – /usr/sbin/mailwrapper – отвечает за все функции, но вручную его обычно не запускают. Все же программы, которыми мы обычно пользуемся, являются не более чем простыми символьными ссылками на этот «бинарник»:

serg$ ls -l /usr/sbin | grep mailwrapper

serg$ ls -l /usr/bin | grep mailwrapper

Если говорить точнее, то собственно работа выполняется файлом /usr/libexec/sendmail/sendmail, а mailwrapper, как следует из его названия, является «обёрткой» к этому файлу. Система, как правило, пользуется ссылкой sendmail, остальные же запускаются администратором для решения конкретных задач.

Посмотрим, какие задачи возлагаются на программу Sendmail. Если посмотреть на вывод команды ps, то можно увидеть, что в системе активны сразу несколько процессов sendmail:

serg$ ps awxo pid,user,command | grep sendmail | grep -v grep

Чем же они занимаются? Два верхних (с PID 596 и 600 соответственно) запускаются при старте системы и постоянно присутствуют в памяти. Первый, как следует из описания, обслуживает входящие соединения, поступающие на порты, выделенные для SMTP-соединений:

serg$ sockstat | grep 596

Как видите, помимо стандартного 25-го порта на обслуживаемых интерфейсах (рассматриваемая система имеет две сетевые карты – внешнюю, с условным IP-адресом 1.2.3.4, и внутреннюю – 10.0.0.254, а также непременный loopback-интерфейс 127.0.0.1) процесс 596 прослушивает порт 587. Этот порт (в /etc/services определён как «submission 587/tcp») предназначен согласно RFC 2476 для приёма новых писем от клиентов, чтобы не перегружать данной работой основной, 25-й порт, служащий для пересылки сообщений между серверами. (То есть более правильно в настройках почтовых клиентов – The Bat, Thunderbird, Outlook и проч. – указывать для исходящих соединений 587-й порт.) В настоящее время протокол Submission используется не слишком широко, и клиенты для отправки электронной почты задействуют тот же 25-й порт, но ничего плохого в том, что данный порт открыт, в принципе нет. Тем более что данная рекомендация (я про RFC 2476) рано или поздно должна стать популярной. UNIX-сокет на /var/run/logpriv (с дескриптором 4) используется для записи журнальной информации с помощью syslog (обратите внимание, что поскольку этот процесс sendmail работает с правами суперпользователя, то используется привилегированный сокет).

Думаю, задача этого процесса понятна – получив запрос на соединение, он порождает дочерний процесс (в нашем выводе команды ps вы можете наблюдать два экземпляра оных – с PID 83329 и 83670), который и занимается обслуживанием данного соединения согласно протоколу SMTP.

Второй процесс, PID которого равен 600, отвечает за обслуживание очереди. Если говорить точнее, то сам он очередь не обслуживает, а лишь запускает с заданным интервалом (в данном случае он составляет 30 минут, как видно из листинга) другой процесс, который и выполняет всю грязную работу.

Ах да, я же ещё не рассказал, что такое очередь! Ничего, скоро этот пробел будет восполнен…

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

Кто кому родитель

Итак, при обработке сообщения для локального клиента, выполняется следующая последовательность действий (см. рис. 1):

1. Удалённый сервер, желая передать нам сообщение, отправляет запрос на соединение на 25-й порт нашего сервера.
2. Процесс sendmail, обслуживающий соединения (тот, который в примере выше имеет PID 596), порождает дочерний процесс (назовём его sm1).
3. Дочерний процесс sm1 проверяет возможность принять данное сообщение (анализируя конверт, прежде всего «rcpt to:») и в случае положительного ответа помещает сообщение в очередь, в файлы qf (заголовки) и df (тело сообщения). Причём qf обычно создаётся в памяти и записывается на диск только в  случае невозможности переслать письмо сразу. То есть очередь – это каталог, куда временно сохраняются почтовые сообщения, проходящие через сервер электронной почты (по умолчанию используется /var/spool/mqueue).
4. Если запись пройдёт успешно, Sendmail подтверждает факт приёма сообщения (принимая тем самым на себя всю ответственность за его дальнейшую судьбу) и завершает соединение с удалённым сервером.
5. Далее sm1 анализирует заголовок сообщения и принимает решение о том, что нужно с ним делать. Если оно предназначено для локального пользователя, то вызывается локальный агент доставки, LDA (Local Delivery Agent), которому даётся поручение положить письмо в почтовый ящик пользователя.
6. Когда LDA успешно выполняет доставку, он рапортует об этом процессу sm1, который удаляет сообщение из очереди и завершает свою работу.

Рисунок 1. Приём сообщения

Передача сообщения от локального пользователя на удалённый сервер выполняется в следующем порядке (см. рис. 2):

1. Локальный клиент (MUA – Mail User Agent), такой как утилита mail, вызывает процесс send-mail (выступающий в роли MSA – Mail Submission Agent).
2. Процесс send-mail принимает сообщение, переданное клиентом, и подключается на 25-й порт хоста localhost.
3. Процесс, прослушивающий соединения на 25-м порту, порождает дочерний процесс sm1 для обработки данного соединения.
4. Sm1, приняв сообщение и поставив его в очередь, предпринимает попытку передать его получателю, для чего составляет маршрут движения письма и устанавливает соединение с первым сервером (в большинстве случаев он же является и последним, т.е. сервером, непосредственно обслуживающим домен получателя).
5. Дождавшись подтверждения о приёме сообщения от удалённого сервера, sm1 удаляет сообщение из очереди и завершает работу.

Рисунок 2. Передача сообщения

В случае транзитной передачи сначала выполняются пункты 1-4 алгоритма приёма сообщения, затем выполняется доставка согласно пунктам 4-5 алгоритма передачи локального сообщения (см. рис. 3).

Рисунок 3. Транзитная передача

Обратите внимание, что здесь всё завязано на выполнении основополагающего требования – надёжности передачи. Ни при каких обстоятельствах письмо не должно потеряться (разве что в случае прямого попадания в сервер из «базуки»). Промежуточная запись на диск, даже когда это, казалось бы, излишне, является обязательной, поскольку только это гарантирует целостность данных в случае сбоя на сервере. Впрочем, «если нельзя, но очень хочется – то можно», и здесь есть приёмы, позволяющие обойтись без «лишней» записи на диск (это мы обсудим в одной из последующих частей статьи, где будем говорить об оптимизации и нестандартной настройке).

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

Возвращаясь к процессам

Как видите, Sendmail может выступать в трёх ипостасях – MTA, MSA и MDA. В таких инструментах, как Postfix и Qmail, применяется понятная структура «одна задача – одна программа». Здесь же всё делает один исполнимый файл. Так что не мудрено, что он обладает огромным количеством самых разных параметров. Перечислю здесь наиболее востребованные (за подробностями обратитесь к странице man sendmail(8)):

• -b: этот ключ указывает на то, что  необходимо выполнить какое-то действие, и всегда дополняется уточняющим ключом;
• -bd: работать в режиме демона;
• -bm: работать в режиме отправки сообщения – аналогично команде mail;
• -bs: выводить команды SMTP на стандартный вывод (фактически, то же самое, что и «telnet localhost 25»);
• -bt: работать в режиме тестирования (позволяет выполнить ряд команд, например, обработать адрес или определить MX-запись для хоста);
• -bv: проверить адрес получателя (фактически, «разворачивает» псевдонимы, показывая реального пользователя или скрипт, которые получат письмо). Следующий пример показывает, что на моей системе адресу postmaster соответствует скрипт maildigest.py, используемый для обработки сообщений антивирусного пакета и сбора статистики по вирусной активности на узле:

root# sendmail -bv postmaster

Другие полезные ключи:

• -C: с помощью этого ключа вы можете указать альтернативный файл конфигурации (отличный от /etc/mail/sendmail.cf).
• -q: этот ключ задаёт период обработки очереди. Например, указанный как -q30m, он установит обработку очереди сообщений каждые 30 минут.
• -t: даёт указание извлечь адрес получателя из соответствующих полей заголовка самого почтового сообщения. Может быть полезен при ручной отправке почты.
• -d: эти ключи задают уровень отладки.

Вот, кстати, приём, позволяющий получить информацию о версии вашего Sendmail:

serg$ echo "" | /usr/sbin/sendmail -bt -d0 | grep Version

Для сокращения числа ключей можно использовать другие ссылки на mailwrapper, специально предназначенные для решения конкретных задач. В таблице 1 приводится соответствие «специализированной» команды ключам программы sendmail.

Таблица 1. Ключи sendmail и специальные ссылки

Если вы посмотрите на сценарии инициализации, используемые системой, то увидите, что FreeBSD использует преимущественно ссылку sendmail с необходимыми для решения той или иной задачи ключами.

Основы настройки

Как же всё это настраивается? Начиная с 4-й (если не ошибаюсь) ветви, в системе FreeBSD основные настройки сосредоточены в каталоге /etc/mail (ранее, по крайней мере в 3.5-RELEASE, они размещались непосредственно в /etc). Здесь вы найдёте следующие основные файлы:

• your.domain.mc: основной конфигурационный файл (так называемый master config, или просто mc-файл). Его имя будет соответствовать доменному имени вашего сервера. Именно в него вносятся необходимые изменения, и на его основе автоматически будет собираться рабочий файл sendmail.cf.
• your.domain.submit.mc: конфигурационный файл для работы в режиме доставки сообщений, когда Sendmail не обслуживает внешние соединения, а только отправляет почту от локальных пользователей (в этом случае Sendmail запускается с правами обычного пользователя и использует для работы очередь /var/spool/clientmqueue).
• sendmail.cf, submit.cf: рабочие файлы конфигурации, которые и использует Sendmail. Настоятельно не рекомендуется вносить в них исправления вручную, хотя никто и не запрещает это делать. Просто нужно иметь в виду, что в данном случае все сделанные вами изменения будут потеряны при первом же выполнении make install, поскольку утилита make при сборке cf-файлов руководствуется исключительно данными, содержащимися в mc-файлах. Безусловно, учитываются и m4-шаблоны, размещённые в /usr/share/sendmail/cf/, но их тоже лучше не изменять.
• aliases: здесь хранятся псевдонимы пользователей. Говоря упрощённо, псевдоним позволяет вам наиболее простым способом перенаправлять почту, приходящую на тот или иной почтовый ящик, на конкретного пользователя. Этот же механизм используется для создания списков рассылки или перенаправления почты на вход какой-либо программы.
• access: этот файл позволяет управлять доступом к почтовому серверу извне. Например, вы можете запретить доступ из конкретной подсети или разрешить пересылку (relaying) почты для некоторых нелокальных адресов.
• local-host-names: список хостов (их доменных имён), для которых сервер Sendmail будет принимать почту. Используется, в частности, для организации виртуального почтового хостинга.
• mailertable: этот файл используется для определения специфических обработчиков для некоторых адресов. Например, так может выглядеть строка для обработки UUCP-почты пользователя account.

account.myserver.ru uucp-dom : account

То есть для обработки почты локального пользователя account будет использоваться протокол UUCP с соответствующим преобразованием адреса.

• virtusertable: здесь размещаются записи, определяющие виртуальных пользователей. Подробнее вопросы виртуального хостинга будут рассмотрены во второй части статьи.
• mailer.conf: конфигурационный файл для /usr/sbin/mailwrapper. Здесь задаётся соответствие «удобных» имён файлов, таких как mailq, реально вызываемому двоичному файлу. Например, согласно такой строке в этом файле:

mailq     /usr/libexec/sendmail/sendmail

если mailwrapper будет вызван по ссылке mailq, то он запустит программу sendmail, которая размещается по указанному пути. Собственно говоря, любая команда будет запускать этот файл (архитектура-то монолитная), но теоретически здесь заложена возможность использовать для тех или иных задач внешние файлы или в дальнейшем безболезненно перейти на модульную структуру (это, в частности, используется в Postfix).

• helpfile: здесь размещаются строки, которые Sendmail будет выводить во время SMTP-сеанса в ответ на команды HELP.

Более подробно использование того или иного файла будет рассматриваться во второй части статьи.

Обратите внимание, что около aliases, access и ряда других будут размещаться файлы с таким же именем, но суффиксом «.db». Это базы (обычно в формате hash, но также поддерживаются dbm и btree), которые и использует Sendmail в своей работе, чем достигается сокращение времени, расходуемого на разбор этих файлов. Следовательно, после внесения изменений в «хэшируемые» конфигурационные файлы вы должны пересоздавать соответствующие базы.

Традиционно это выполняется командой makemap (для базы aliases – команда newaliases, являющаяся одной из ссылок на mailwrapper). Однако разработчики FreeBSD предоставили нам замечательный Makefile, который делает большую часть работы по обслуживанию почтовой системы, самостоятельно вызывая необходимые служебные утилиты.

В данном случае достаточно перейти в каталог /etc/mail и выполнить команду make:

root# cd /etc/mail

root# make

При этом make самостоятельно определит, какие файлы были изменены, и пересоздаст соответствующие базы. Если были изменения в конфигурационном mc-файле, то эта же команда построит на его основе cf-файл (например, your.domain.cf; далее нужно будет ещё выполнить make install, чтобы этот файл был скопирован как sendmail.cf). При желании вы можете явно указать, что именно должно быть пересобрано:

root# make aliases

Как видите, всё предельно просто. Кстати, раз уж у нас зашла речь о Makefile, помимо сборки и установки конфигурационных файлов, он же позволяет управлять запуском/остановом/перезагрузкой необходимых процессов (make start, make stop, make restart соответственно). Можно даже работать по отдельности с каждым процессом:

root# make restart-mspq

root# make stop-mta

Нужно заметить, что сами команды управления процессами размещаются в /etc/rc.sendmail. Makefile лишь вызывает этот сценарий с нужными параметрами. Обратите внимание, что в рассматриваемой версии FreeBSD запуск sendmail при загрузке системы может выполняться другим сценарием – /etc/rc.d/sendmail. Это более соответствует принятому начиная с 5-й ветви порядку инициализации (он был позаимствован из NetBSD), но подобное «двоевластие» может в некоторых случаях привести к путанице и ошибкам (например, если вам нужно внести в эти файлы какие-то специфические изменения, то приходится особо следить за их синхронизацией).

Раз уж мы заговорили о сценариях инициализации, рассмотрим параметры rc.conf, определяющие работу Sendmail. Основные настройки сосредоточены в файле /etc/defaults/rc.conf. По умолчанию переменная sendmail_enable установлена в значение «NO», что подразумевает работу Sendmail только для отправки сообщений локальных пользователей. MTA, обслуживающий внешние соединения, запускаться не будет. Чтобы разрешить работу Sendmail в режиме MTA, следует установить значение этой переменной в «YES». Кстати, если вы хотите полностью запретить работу Sendmail, используйте значение «NONE», а не «NO».

Обратите внимание на одну важную переменную:

mta_start_script="/etc/rc.sendmail"

Именно она определяет, какой из сценариев – /etc/rc.sendmail или /etc/rc.d/sendmail – будет использоваться при загрузке системы. По соображениям «однозначности» лучше оставить использование rc.sendmail, как это и предусмотрено по умолчанию.

Подробнее узнать об опциях, которые вы можете изменить, можно в самом файле /etc/defaults/rc.conf – он достаточно хорошо прокомментирован. Ну и при необходимости что-то переопределить внесите соответствующие строки в /etc/rc.conf (надеюсь, вы даже спросонья без запинки скажете, почему не рекомендуется делать изменения непосредственно в default-скриптах).

Пример файла конфигурации

Рассмотрим небольшой пример mc-файла, для того чтобы в общих чертах познакомиться с синтаксисом и наиболее типичными директивами (подробно конфигурация будет рассматриваться во второй части статьи). Он представляет собой набор команд макропроцессору m4, который используется для сборки cf-файла. Подробнее о m4 мы поговорим в следующий раз, пока же просто рассмотрим некоторые опции, не вдаваясь в подробности. Поскольку комментарии в m4 выглядят не совсем привычно, то вместо пояснений в самом файле разобьём его на отдельные строки:

divert(-1)dnl

. . . . .

divert(0)dnl

Директива divert() служит для переключения режимов макропроцессора. Собственно, сама конфигурация начинается после divert(0), поэтому между указанными строками часто помещают комментарии к файлу. Буквы dnl, присутствующие в конце каждой строки, в m4 означают конец строки. Если вы хотите закомментировать какую-то директиву, перенесите dnl в начало строки.

OSTYPE(freebsd6)dnl

Тип операционной системы. Согласно данному параметру m4 будет выбирать необходимые для работы шаблоны (из /usr/share/sendmail/cf/ostype/), поэтому очень важно следить здесь за актуальностью информации (особенно когда выполняется обновление системы на другую «ветку»). В первую очередь от этого параметра зависят принятые в той или иной системе полные имена агентов доставки (LDA), используемые флаги и т. д.

DOMAIN(generic)dnl

Ещё один параметр, влияющий на выбор шаблонов. Шаблоны можно найти в /usr/share/sendmail/cf/domain/, в большинстве случаев следует использовать домен «generic». Впрочем, если вам нужны специфические параметры, которые по тем или иным причинам вам не хотелось бы выносить в конфигурационный файл, можно создать здесь свой «доменный» шаблон (посмотрите здесь же примеры для доменов Berkley.EDU) и использовать его.

dnl DAEMON_OPTIONS('Name=IPv4, Family=inet')dnl

DAEMON_OPTIONS('Port=smtp,Addr=1.2.3.4,Name=MTA')dnl

DAEMON_OPTIONS('Port=smtp,Addr=127.0.0.1,Name=MTA')dnl

DAEMON_OPTIONS('Port=smtp,Addr=10.0.0.254,Name=MTA')dnl

Подобным образом указывается, на каких адресах и портах следует прослушивать входящие соединения. Первая строка из приведённых (закомментированная) указывает ожидать входящие соединения на всех IPv4-интерфейсах. Если прослушивать нужно только конкретные интерфейсы, можно поступить так, как показано в последующих двух строках.

FEATURE(use_cw_file)dnl

define('confCW_FILE', '-o /etc/mail/local-host-names')dnl

Эти строки задают использование файла local-host-names и указывают путь к нему.

dnl FEATURE('accept_unqualified_senders')dnl

dnl FEATURE('accept_unresolvable_domains')dnl

Данные две директивы (сейчас они закомментированы) позволяют несколько ослабить требования стандартов. Первая разрешает обслуживать не полностью квалифицированных отправителей (т.е. не имеющих полного имени формата user@domain). Вторая допускает работу с доменами, для которых не удалось определить их DNS-имя по IP-адресу.

FEATURE(mailertable, 'hash -o /etc/mail/mailertable')dnl

FEATURE(access_db, 'hash -o -T<TMPF> /etc/mail/access')dnl

FEATURE(virtusertable, 'hash -o /etc/mail/virtusertable')dnl

Эти строки описывают пути к специальным файлам конфигурации. Обратите внимание, что имена баз указаны без суффикса «.db».

FEATURE(blacklist_recipients)dnl

dnl FEATURE('dnsbl', 'sbl.spamhaus.org')dnl

FEATURE('dnsbl', 'relays.ordb.org')dnl

FEATURE('dnsbl', 'dul.ru')dnl

FEATURE('dnsbl', 'bl.spamcop.net')dnl

Строки, реализующие встроенный в Sendmail механизм борьбы с так любимым нами спамом. Он основан на «чёрных списках», отклоняя любые попытки установить соединение со стороны IP-адреса, присутствующего в одном из указанных списков. Для таких адресов Sendmail выдаёт код 550 и разрывает соединение. Если же адреса в базе rbl-сервера нет, то соединение принимается. На страницах журнала уже неоднократно обсуждались недостатки такого подхода, так что использовать его следует с особой аккуратностью.

define('confMAX_MESSAGE_SIZE', '12500000')dnl

Эта строка задаёт ограничение на максимальный размер сообщения, которое может быть обработано сервером. Весьма полезная опция, если вы хотите защитить свой сервер и почтовые ящики ваших пользователей от чьих-нибудь «шалостей».

define('confMAX_DAEMON_CHILDREN','45')dnl

Максимальное число дочерних процессов, которые могут быть запущены одновременно. Эта опция помогает ослабить последствия DoS-атаки на почтовую подсистему, ограничивая число запущенных процессов и не позволяя, тем самым, вызвать катастрофическую перегрузку системы.

define('confPRIVACY_FLAGS', 'noexpn,novrfy')dnl

Эта опция позволяет задать ряд дополнительных флагов, управляющих работой протокола SMTP. В данном случае запрещается выполнять smtp-команды VRFY и EXPN, которые по умолчанию позволяют любому пользователю (в том числе и спамеру) достаточно легко проверить наличие на сервере конкретного почтового ящика и «развернуть» списки рассылки (если таковые имеются).

MAILER(local)dnl

MAILER(smtp)dnl

dnl MAILER(uucp)

Ну а так указывается, какие агенты доставки будут использоваться. Здесь определены локальный агент доставки (LDA), и использование протокола SMTP для доставки на удалённые серверы (MDA). Закомментированная строка отвечала некогда за подключение агента, работающего по протоколу UUCP, ныне практически вымершему.

Немного подробнее мы поговорим о конфигурации в следующий раз. После внесения всех изменений в mc-файл нужно выполнить следующие действия:

root# cd /etc/mail

root# make

root# make install

root# make restart

После этого Sendmail будет перезапущен в новой конфигурации.

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

На этом первую часть цикла, пожалуй, и завершим. В следующий раз мы более детально обсудим настройку Sendmail (в частности, формат cf-файла и работу макропроцессора m4), некоторые примеры конфигураций и ряд других вопросов.

Приложение

Как всё начиналось

В конце семидесятых Эрик Олман (Eric Allman), работая в Университете Беркли, бился над одной проблемой – как обмениваться электронной почтой в университетской сети, объединяющей несколько машин, взаимодействующих между собой по разным протоколам. Существовали, конечно, отдельные программы, обеспечивающие взаимодействие каждой пары машин, но Эрику хотелось создать именно универсальную программу.

И вот в 1983 году появилась первая версия программы Sendmail, основанной на менее универсальной delivermail (разработанной для сети ARPANET). Первоначально созданная для BSD 4.1c, она постоянно развивалась, переносилась на другие системы. Многие компании брали Sendmail за основу для построения собственных почтовых программ.

В настоящее время наиболее известной и распространённой версией Sendmail является открытая программа, разрабатываемая Sendmail Consortium при спонсорской помощи компании Sendmail Inc. Последняя выпущенная версия – 8.13.6.

Несколько слов про SMTP

Simple Mail Transfer Protocol (SMTP) – простой протокол передачи электронной почты – является основным протоколом, на котором основана работа электронной почты в сети Интернет. Описан он в RFC 821, который дополнен рядом других рекомендаций. Наиболее серьёзным дополнением (скорее даже заменяющим документом) является RFC 2821, описывающий расширенный протокол SMTP и более соответствующий современным реалиям.

SMTP является, скажем так, «терминальным» протоколом, то есть взаимодействие двух систем осуществляется путём обмена текстовыми строками. Клиент (хост, инициировавший соединение) передаёт на сервер (хост, принимающий соединение) команды, состоящие из четырёх букв и следующих далее параметров. Сервер отвечает трёхзначным числовым кодом с последующей строкой-пояснением.

Типичный пример SMTP-диалога может выглядеть таким образом:

serg$ telnet localhost 25

Как видите, смоделировать работу SMTP-протокола достаточно просто. Но нужно заметить, что полная поддержка протокола – достаточно сложная задача, требующая учёта многих факторов.

Что такое UUCP?

Unix to Unix Copy Program (UUCP) – некогда очень популярный протокол взаимодействия между удалёнными хостами. Пересылка электронной почты не была его единственной обязанностью, но эта услуга была наиболее востребована. Sendmail, будучи разработанным как универсальный почтовый сервер, призванный объединить разнородные сети, обладает поддержкой этого протокола (правда, реализация осуществляется сторонней программой – во FreeBSD это Taylor UUCP, установить её можно из коллекции портов: /usr/ports/net/freebsd-uucp).

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

Системы-конкуренты

По различным данным, среди наиболее популярных открытых серверов электронной почты наблюдается примерно такое соотношение: Sendmail – 24%, Postfix – 17%, Exim – 9%, Qmail – 4%. Если сравнить эти цифры с данными за 2001 год (соответственно 42%, 2%, 1%, 17%), то можно отметить довольно существенное снижение доли Sendmail, прежде всего за счёт Postfix, активно используемого на небольших серверах и домашних системах. Тем не менее, Sendmail по-прежнему занимает лидирующие позиции.

В качестве основных характеристик конкурирующих открытых систем можно отметить следующие:

Postfix: выросший из IBM Secure Mailer разрабатывается как быстрая и безопасная альтернатива Sendmail. Отличается модульной структурой, простым форматом конфигурационного файла. Благодаря имитации взаимодействия Sendmail с операционной системой миграция на Postfix может быть выполнена сравнительно безболезненно.

Exim: был разработан в 1995 году Филипом Хазелем (Philip Hazel) на базе MTA Smail для почтовой системы Кембриджского университета. Достаточно мощная и гибкая почтовая система. К её преимуществам также часто относят хорошую документированность. Как и Sendmail, имеет монолитную архитектуру, но (по отзывам) работает несколько быстрее.

Qmail: при разработке этого MTA (автор – Даниэль Бернштайн (Daniel J. Bernstein)) основной акцент делался на вопросах безопасности. Имеет модульную структуру. Для решения различных задач запускает процессы от имени разных пользователей, чем достигается максимальный уровень защищённости в случае обнаружения проблем в одном из модулей. Довольно странную лицензию, допускающую распространение только в исходных кодах и сильно осложняющую развитие программы (текущая версия – 1.03 – датируется аж 1998 годом), можно назвать одной из причин, по которым Qmail стремительно теряет популярность.

Существуют и другие MTA (например, Comminigate Pro), имеющие свои достоинства и недостатки. В общем выбирать есть из чего.