что такое sent в почте

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

Как работает 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 – отвечает за все функции, но вручную его обычно не запускают. Все же программы, которыми мы обычно пользуемся, являются не более чем простыми символьными ссылками на этот «бинарник»:

-r-xr-xr-x 1 root wheel 5236 11 ноя 10:01 mailwrapper

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

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

596 root sendmail: accepting connections (sendmail)

600 smmsp sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail)

83329 root sendmail: k35B3pRn083329 [59.42.1.71]: DATA (sendmail)

83670 root sendmail: server N023143.ppp.ne.jp [61.20.23.14] cmd read (sendmail)

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

serg$ sockstat | grep 596

root sendmail 596 3 tcp4 1.2.3.4:25 *:*

root sendmail 596 5 tcp4 127.0.0.1:25 *:*

root sendmail 596 6 tcp4 10.0.0.254:25 *:*

root sendmail 596 7 tcp4 *:587 *:*

Как видите, помимо стандартного 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. Приём сообщения

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

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

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

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

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

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

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

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

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

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

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

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

Пересоздаёт базу псевдонимов

Работа с очередью сообщений

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

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

account.myserver.ru uucp-dom : account

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

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

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

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

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

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

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

/etc/mail/aliases: 167 aliases, longest 47 bytes, 2529 bytes total

chmod 0640 /etc/mail/aliases.db

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

root# make restart-mspq

Нужно заметить, что сами команды управления процессами размещаются в /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».

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

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

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

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

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

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

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

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

dnl DAEMON_OPTIONS(‘Name=IPv4, Family=inet’)dnl

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

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

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

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

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

dnl FEATURE(‘dnsbl’, ‘sbl.spamhaus.org’)dnl

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

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

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

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

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

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

После этого 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

Connected to localhost.

Escape character is «^]».

250 server.ru Hello localhost [127.0.0.1], pleased to meet you

MAIL From: me@me.domain.ru

250 2.1.0 me@me.domain.ru. Sender ok

RCPT To: serg@server.ru

250 2.1.5 serg@server.ru. Recipient ok

354 Enter mail, end with «.» on a line by itself

Hello! It’s a test message.

250 2.0.0 k3BAK9Je017265 Message accepted for delivery

221 2.0.0 server.ru closing connection

Connection closed by foreign host.

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

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), имеющие свои достоинства и недостатки. В общем выбирать есть из чего.

Источник

Вам также может понравиться

Волшебные двери: почему входные двери делают металлическими

Привет, друзья! Сегодня я хочу рассказать вам о волшебных

Дверные петли: маленькие герои, которые держат двери на месте!

Привет, друзья! Сегодня я хочу рассказать вам об очень

Добро пожаловать в мир дверей: уникальные проходы в нашем доме!

Привет, маленькие строители! Сегодня я расскажу вам

Загадочный мир электронных дверных ключей

Привет, друзья! Сегодня я хочу рассказать вам о волшебном