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

Френк Херберт "Дом Глав Дюны"

От автора
   Дорогие мои читатели, Цель этого документа и последующего цикла статей связанного с ним - донести до ВАС в наиболее понятной форме знания известные мне самому и материалы беспечно блуждающие по сети Интернет. Быть может попытаться дать почву для размышлений и приемы решения некоторых задач, в частности задач по электронной почте. Показать, что на самом деле Sendmail не такая уж и жуткая штука, как о ней многие отзываются и если у вас, что-то не получается реализовать на его основе - это вовсе не должно являться поводом перехода на альтернативное программное обеспечение. Sendmail - это такая программа, в которой нет ничего невозможного, больше, на мой взгляд, его возможности ограничиваются только вашим воображением, научитесь разговаривать на его языке, да быть может столь запутанном и с первого взгляда не понятном, но сделайте первый шаг ему навстречу и будьте, уверены - вас начнут понимать.

Электронная почта
   Электронная почта появилась на свет сразу после появления первых вычислительных сетей в мире и по сей день является одним из основных средств компьютерных коммуникаций. В настоящее время существует множество разнообразных стандартов обмена почтовыми сообщениями. Почтовые узлы Интернета используют стандарт изложенный в RFC-822 дополненный другими RFC. Помимо спецификаций, напрямую связанных с организацией работы почтовой системы, этот стандарт также определяет независимый от аппаратной платформы способ передачи по электронной почте практически любой информации, включая графику, звуковые файлы. Для семейства систем UNIX было разработано множество реализаций транспортных программ. Одна из наиболее известных - sendmail, разработанная Эриком Олманом в университете Беркли. Сейчас sendmail распространяется на коммерческой основе, однако сама программа остается бесплатной.

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

   1. Данные специфические для способа пересылки, адреса отправителя и получателя. Поэтому эту информацию часто называют конвертом.

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

   2. Вторая разновидность служебной информации, одинаковой для всех почтовых систем, включает в себя строку темы письма (subject), список всех получателей и дату отправления.

Список основных полей заголовка:

From:
Почтовый адрес отправителя и иногда его реальное имя. Существует множество разнообразных форматов этого поля.

To:
Список почтовых адресов получателей. Адреса в списке разделяются запятыми.

Cc:
Carbon Copy - Список адресов получателей, которым будет направлена копия сообщения. Адреса в списке разделяются запятыми.

Bcc:
Blind Carbon Copy - Список адресов получателей, которым будет направлена копия сообщения. Главное отличие между полями "Сс:" и "Bcc:" заключается в том, что адреса, перечисленные в поле "Bcc:", не включаются в заголовок сообщения, доставляемых получателям. Таким образом вы предупреждаете получателей о том, что копия сообщения была направлена другим лицам, но не указываете, кому именно. Адреса в списке разделяются запятыми.

Subject:
Краткое описание темы сообщения.

Date:
Дата и время отправления письма.

Reply-To:
Адрес, на который получатель должен прислать ответ. Это поле применяется, например, в случае, если отправитель использует несколько почтовых учетных записей, однако желает, чтобы входящие сообщения приходили на какой-то один из них. Поле не является обязательным.

Organization:
Наименование организации, которой принадлежит компьютер отправителя. Если компьютер принадлежит вам лично, либо не заполняйте это поле, либо напишите здесь "private" или любое другое слово. Это поле не описывается в RFC и является необязательным. Одни почтовые программы поддерживают его, другие нет.

Mesage-ID:
Строка, сгенерированная транспортной системой отправителя. Каждому сообщению соответствует уникальный идентификатор.

Received:
Это поле вставляется в заголовок каждым из узлов, через которые передается ваше сообщение (включая машины отправителя и получателя). Здесь указывается имя узла, идентификатор сообщения, время и дата получения, с какого из улов сообщение получено и какая транспортная программа была использована. При помощи этих полей можно определить путь, по которому было передано сообщение, и в случае возникновения каких-либо проблем обратиться к лицу, отвечающему за соответствующий узел.

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

Передача почтовых сообщений
   Электронные сообщения создаются при помощи программ почтового интерфейса - например, программа mail. Эти программы называют почтовыми агентами пользователя (MUA). Когда вы посылаете сообщение, интерфейсная программа обычно передает его другой программе для дальнейшей пересылки. Такая программа называется почтовым транспортным агентом (MTA). MTA не используется для написания писем. Ее задача - отправить локальную почту MTA в другую систему. В большинстве систем для локальной и удаленной пересылки почты обычно используется один и тот же транспортный агент, вызываемый командой /usr/sbin/sendmail.

Локальная пересылка почты не ограничивается простым присоединением входящего сообщения к почтовому ящику получателя. Обычно локальные MTA поддерживают работу с псевдонимами (aliasing). Кроме того, сообщение, которое по каким-то причинам не может быть доставлено, должно возвращаться отправителю с добавленным сообщением об ошибке.

При удаленной пересылке почты используемая транспортная программа обычно определяется природой канала связи. При использовании каналов TCP/IP обычно применяется протокол SMTP. Выступая в роли протокола "сервер-сервер", SMTP требует дополнительного протокола, типа POP3, для локального сбора и обработки сообщений и их доставки конкретным пользователям. Протокол SMTP проектировался с расчетом на то, чтобы почта доставлялась прямо на компьютер получателя, а процесс пересылки согласовывался с демоном SMTP, работающим на удаленном конце. Протокол SMTP наделяется дополнительными возможностями благодаря протоколу ESMTP (Extended Simple Mail Transport Protocol). К таким возможностям относятся, в частности, 8-битовое кодирование MIME без применения типа base64 и возможность получения сервером сведений о размере сообщения (при использовании SMTP единственным способом отказа от приема слишком больших сообщений было получение их целиком и последующее уничтожение, что, естественно, создавало дополнительную нагрузку на сеть).

В обязанности MTA также входит и маршрутизация почты (так, письмо, отправляемое пользователю той же локальной системы, передается непосредственно локальному MDA - Mail Delivery Agent).

В задачи MDA входит обработка приходящих сообщений. Так sendmail, получив сообщение, вызывает MDA для его передачи из очереди sendmail в очередь MUA. Чаще всего эту роль выполняют /bin/mail и procmail.

Маршрутизация почты
   Процедура направления сообщения на узел получателя называется маршрутизацией (routing). Кроме определения маршрута от отправителя к получателю, маршрутизация подразумевает также проверку на ошибки и оптимизацию скорости и затрат.

В интернете выполнение процедуры маршрутизации зависит от конфигурации узла назначения. По умолчанию сначала определяется узел, на который должно быть доставлено сообщение, после чего сообщение передается на узел назначения напрямую. В большинстве сетей с подключением к Интернету вся входящая почта обычно направляется на специализированный, наиболее доступный почтовый сервер, способный поддерживать большую нагрузку. Этот почтовый сервер осуществляет дальнейшую пересылку почты на локальные сетевые узлы. Чтобы объявить о предоставлении такого рода услуг, сетевой узел должен обладать соответствующей ему записью MX в базе данных DNS. Запись MX означает Mail Exchanger (сервер обмена почтовыми сообщениями) и указывает на то, что данный сетевой узел выполняет функции почтового сервера домена.

Каждая запись MX содержит параметр приоритета. Это положительное целое число. Если почтовое сообщение, адресованное некоторому сетевому узлу может быть доставлено к месту назначения при помощи одного из нескольких почтовых серверов, почтовый транспортный агент будет пытаться переслать сообщение на сервер MX, у которого этот параметр имеет наименьшее значение, и только в случае неудачи сообщение будет передано на сервер с более высоким значением параметра приоритета. Если локальный узел сам является почтовым сервером для получателя сообщения, он не имеет права пересылать почтовое сообщение на серверы MX c большим значением приоритета, чем его собственный. Таким образом удается избежать передачи почтовых сообщений по замкнутому кругу. Если для домена не осталось ни одной подходящей записи MX или такой записи вообще не существует, транспортный агент проверяет, не связан ли с узлом IP-адрес и пытается доставить почту прямо на узел.

Допустим, в организации VasiyaPupkin, вся почта обрабатывается компьютером mail. В базу данных DNS включается записи MX следующего вида:

boss.vasiyapupkin.ru. IN MX 5 mail.vasiyapupkin.ru.

Это означает, что компьютер mail.vasiyapupkin.ru является почтовым сервером для домена boss.vasiyapupkin.ru со степенью приоритета 5. Узел, собирающийся передать сообщение для joe@boss.vasiyapupkin.ru, сначала обратится к DNS и обнаружит запись MX со ссылкой на mail. Если в базе данных DNS не будет записей MX, относящихся к этому же домену и с приоритетом ниже 5, сообщение будет передано mail, который в дальнейшем перешлет его на boss.

Это только приблизительное описание принципа работы MX, более подробная информация о маршрутизации почты изложена в RFC-821, RFC-974, RFC-1123.

Программа sendmail
   Вот мы наконец и добрались до настройки этого зверя, столь критикуемого многими администраторами.

Многие администраторы сравнивают эту программу с "ужасом, летящим на крыльях ночи". Настройка sendmail очень сложна, но как отвечал критикам автор sendmail Эрик Олмен, это потому, что мир в целом далеко не прост. Программа sendmail в состоянии сделать с почтой буквально все, если только вы сумеете объяснить, чего именно от нее хотите. Говорят, если никогда не редактировали вручную файл sendmail.cf, вас нельзя назвать настоящим администратором системы UNIX. Так же говорят, что только сумасшедший возьмется за редактирование этого файла еще раз. sendmail - это невероятно мощная программа, однако для многих людей она является слишком сложной и непонятной. Ясно, что программный продукт, руководство, по использованию которого содержит 1050 страниц текста, способен отпугнуть даже самых бывалых компьютерщиков. Что касается последних версий, sendmail настраивать их стало легче благодаря большим набором макросов M4 и возможности использовать более или менее понятные имена опций в конфигурационном файле.

Рассмотрим процесс компиляции и установки sendmail. Исходные тексты можно загрузить с анонимного FTP-сервера ftp.sendmail.org. Или же здесь можно взять RPM той версии исходников, которую использовал я. Процесс компиляции довольно прост, так дистрибутив напрямую поддерживает Linux. Поэтому, не теряя времени, стоит рассмотреть процесс прикручивания к sendmail аутентификации.

Sendmail 8.10/8.11 поддерживают SMTP AUTH, как это описано в RFC 2554, которая базируется на SASL. Следует отметить, что не все е-маил клиенты в полной мере поддерживают SMTP AUTH, поэтому здесь мы рассмотрим только Outlook Express и The Bat, как наиболее популярные в данный момент. Таблицу совместимости для различных клиентов можно посмотреть на официальном сайте sendmail:
http://www.sendmail.org/~ca/email/mel/SASL_ClientRef.html

Для организации аутентификации в sendmail нам потребуется библиотека Cyrus SASL, RPM которой можно взять здесь. Безусловно, версии исходников можно брать и напрямую с сайта разработчика:
ftp://ftp.andrew.cmu.edu/pub/cyrus-mail
После установки этой RPM в систему, исходные коды Cyrus SASL, а точнее их архив, следует искать в /usr/src/RPM.

Распаковываем полученный архив cyrus-sasl-1.5.27.tar.bz2. Затем следует предпринять несколько следующих шагов с правами root, для конфигурации и компиляции библиотеки, с последующей установкой ее в систему:

cd cyrus-sasl-1.5.27/
./configure --prefix=/usr --enable-login
make
make install

Многие советуют отключить в SASL такие методы, как PLAIN и LOGIN, но к сожалению такие клиенты, как Outlook Express, не поддерживают другие, поэтому если большая часть ваших пользователей используют этот почтовый клиент или схожий с ним, нужно при конфигурировании SASL включить метод LOGIN (--enable-login), что и было продемонстрировано выше. Для уверенности, что все идет правильно проверьте наличие установленных библиотек в каталоге /usr/lib и include файлов (с расширением h) в каталоге /usr/include.

Теперь сделаем конфигурационный файл для Sendmail, этот файл будет использоваться SASL, для проведения аутентификации в Sendmail. Для этого необходимо создать файл /usr/lib/sasl/Sendmail.conf и добавить в него следующую информацию:

pwcheck_method: sasldb

Здесь же, для особо интересующихся можно прикрутить и mysql, т.е. информация с именами и паролями пользователей будет вестись в базе данных. На следующем шаге нужно организовать базу для всех пользователей, которые будут наделены полномочиями отсылать почту, т.е. использовать ваш почтовый сервер как relay. Так как мы используем SASL, то в нем есть две программы, которые и занимаются решением этой проблемы. Первая программа создает базу данных с вашими пользователями:

saslpasswd -a sendmail newuser
password:<пароль для newuser>

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

Вторая программа называется:
sasldblistusers
Служит она для отображения базы с пользователями. Запустив ее можно увидеть нечто подобное:

user: newuser realm: yourhost.youdomain mech: CRAM-MD5
user: newuser realm: yourhost.youdomain mech: DIGEST-MD5
user: newuser realm: yourhost.youdomain mech: PLAIN
user: newuser realm: yourhost.youdomain mech: LOGIN

Эта информация означает, что аутентификация для пользователя newuser может быть проведена следующими методами: CRAM-MD5, DIGEST-MD5, PLAIN, LOGIN.

Теперь перейдем к настройке Sendmail. Для начала следует проверить, не скомпилирована ли ваша версия Sendmail с поддержкой SASL?

sendmail -d0.1 -bv root | grep SASL

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

Собираем Sendmail:
скачиваем (www.sendmail.org) нужную, или последнюю версию Sendmail

tar -xzf senmail-x.xx.xx.tar.gz
cd sendmail-x.xx.xx/

Теперь для того чтобы прикрутить поддержку SASL, нужно сделать следующее:
зайти в sendmail-x.xx.x/devtools/Site и создать там файл site.config.m4 в котором нужно написать следующее:

APPENDDEF(`confENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl')
APPENDDEF(`confLIBDIRS', `-L/usr/lib/')
APPENDDEF(`confINCDIRS', `-I/usr/include/')

Конечно, подключить поддержку SASL в ваш sendmail можно и другим способом, к примеру, для себя я делал несколько иначе, но результат остается прежним. Затем возвращаемся в каталог sendmail-x.xx.xx/ и запускаем следующий скрипт:

./Build
./Build install

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

/usr/sbin/sendmail -bd -q30m

Обычно эта команда помещается в сценарий загрузки (например, в каталоге /etc/rc.d/init.d/sendmail).

#Start daemons.

echo -n "Staring sendmail: "
daemon sendmail -bd -q30m
echo
touch /var/lock/subsys/sendmail
;;

В приведенном примере опция -bd указывает, что sendmail должен запуститься в режиме демона, а опция -q30m заставляет проверять и обрабатывать очередь писем каждые тридцать минут.

После этого, если вы дадите следующую команду:

sendmail -d0.1 -bv root | grep SASL

Вы должны увидеть среди прочей информации, уже знакомое нам слово SASL.

Теперь собственно приступим к конфигурации самого Sendmail'а.
Программа sendmail имеет возможность использовать препроцессор m4, что упрощает создание конфигурационного файла, содержащего выбранные вами возможности. В поставку sendmail входит множество образцов таких файлов. Обычно такой исходный файл имеет расширение .mc, но оно не является обязательным. Минимальный файл для системы Linux выглядит так:

OSTYPE(linux)dnl
MAILER(local)dnl

Впишем в свой файл sendmail.mc, следующие строчки:

TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 CRAM-MD5 PLAIN
                                                           LOGIN')dnl
define(`confDEF_AUTH_INFO', `/etc/mail/auth/auth-info')dnl
FEATURE(`no_default_msa')dnl turn off default entry for MSA
DAEMON_OPTIONS(`Port=25, Name=MSA, M=E')dnl

Если вместо M=E в конфигурации поставить M=A, то Sendmail начнет требовать авторизацию при любой попытке послать через него почту. Если включить эту опцию, то не один сервер не сможет отправить вам почту, так как не сможет авторизироваться у вас!

Теперь соберем конфигурационный файл Sendmail'а используя следующую команду:

m4 sendmail.mc>sendmail.cf

Здесь m4 - вызов препроцессора m4, sendmail.mc - входной .mc фай, > sendmail.cf - указывает, что вывод должен быть помещен в файл sendmail.cf.

Теперь при использовании для генерации конфигурационного файла препроцессора m4 в файле будут находиться только заказанные вами возможности и не будет ничего лишнего. Кроме того, возможно добавление своих макросов, тем самым можно расширять функциональные возможности sendmail.

Скопируем полученный файл туда, где Sendmail его берёт, для примера это может быть либо
/etc/mail либо /etc:

cp sendmail.cf /etc/mail/sendmail.cf

Проверим насколько правильно мы настроили sendmail:

telnet localhost 25
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
220 local.sendmail.ORG ESMTP Sendmail 8.10.0/8.10.0;
                                   Thu, 9 Sep 1999 10:48:44 -0700 (PDT)
ehlo localhost
250-local.sendmail.ORG Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-DSN
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250 HELP
quit

#########################
# Format of headers     #
#########################

К примеру можно вписать следующее:

$.$?{auth_type}(authenticated with ${auth_type} from ${auth_author}$.)

Тогда в заголовке письма будет содержаться следующая информация:
(authenticated with CRAM-MD5 from newuser)

Если все сконфигурировано правильно, в том числе и ваш DNS, то в клиенте в качестве логина и пароля следует задать информацию вида:

login: newuser
password: <пароль для newuser>

Если же в конфигурации DNS имеются ошибки, то следует передать эту информацию так:

login: newuser@yourhost
password: <пароль для newuser>

RFC
   RFC (Request for Comments) представляет собой формальное описание протоколов, а также форматов используемых в Internet. Выпускаются RFC, IETF (Internet Engineering Task Force), их идентификация происходит посредством уникальных номеров. Документов RFC очень много - примерно более двух тысяч, однако среди них имеются устаревшие, замененные более новыми. Найти необходимый RFC можно по адресу http://www.ietf.org. Электронная почта весьма широко используется в Internet, поэтому ее описывает множество RFC.

Вот некоторые из них:
RFC-822 Standard of the format of ARPA Internet text messages. (Стандарт форматирования текстовых сообщений в сети ARPA Internet). D. Crocker. Описание формата сообщений электронной почты, используемого в современных компьютерных сетях. Несмотря на то, что многие слышали о существовании и предназначении этого документа, мало кто прочитал его от начала до конца. Дополнения к этому RFC содержатся в RFC-1123, RFC-1138, RFC-1148, RFC-1327 and RFC-2156.
RFC-0821 Simple Mail Transfer Protocol (Простой протокол передачи почты, SMTP). J. Postel. Спецификация SMTP - транспортного протокола, предназначенного для передачи почты через канал TCP/IP.
RFC-974 Mail routing and domain system (Маршрутизация почты и система доменов). C. Partridge. Этот документ описывает маршрутизацию почты в Internet. В нем содержится подробное описание всего, что связано с записями MX.
RFC-819 Domain Naming. Соглашение для пользовательских приложений Internet.
RFC-976 UUCP Mail Interchange Format Standard Определяет протокол UUCP.
RFC-1123 Requirements for Internet Hosts - Application and Support. Расширенные и обновленные версии RFC-822 (в основном используемые для устранения неоднозначностей). RFC-1327 Maping between X.400 (1988)/ISO 10021 and RFC-822 Обновление RFC-822.
RFC-1521
RFC-1522 MIME ( Multipurpose Internet Mail Extensions) parts 1 and 2. Расширение формата сообщений, определенного в RFC-822.
RFC-1651 SMTP Service Extensions. Описание ESMTP.
RFC-1652 SMTP Service Extensions for 8-bit MIME Transport.
RFC-1653 MTP Service Extensions for Message.
RFC-1869 SMTP Service Extensions. Замена для RFC-1651.
RFC-1870 SMTP Service Extensions for Message Size Declaration. Замена для RFC-1653.
RFC-1891 SMTP Service Extension for Delivery Status Notifications.
RFC-1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages.
RFC-1893 Enhanced Mail System Status Codes.
RFC-1894 An Extensible Message Format for Delivery Status Notifications.
RFC-2045-2049 Multipurpose Internet Mail Extensions (MIME) parts 1 - 5. Замена для RFC-1521 and RFC-1522.

Использованная справочная литература
1. Олаф Кирх - LINUX Руководство администратора сети.

Благодарности
Хотелось бы особо поблагодарить Eugene не только, как первого человека пожелавшего высказать свою точку зрения по этому документу, но и как человека оставившего свои ценные комментарии и пожелания, и, конечно же, отдельная благодарность за его обоснованную критику!

P.S. На данном этапе развития ведется работа над следующей частью документа, так как самая интересная часть осталась за кадром, сего опуса. Попрошу набраться немного терпения и немного подождать.

Статья написана специально для UInC (http://www.uinc.ru).

Все документы и программы на этом сайте собраны ТОЛЬКО для образовательных целей, мы не отвечаем ни за какие последствия, которые имели место как следствие использования этих материалов\программ. Вы используете все вышеперечисленное на свой страх и риск.

Любые материалы с этого сайта не могут быть скопированы без разрешения автора или администрации.