[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Настройка почты (sendmail, postfix, qmail)" (Архив | Для печати)

• Организация службы электронной почты в Интернет
  • Почтовые агенты в различных ОС
• Структура email-сообщения
  • Заголовки почтового сообщения
  • MIME
  • Примеры почтовых сообщений с заголовками
• Основные команды протокола SMTP
• Основные команды протокола POP
• Программа sendmail: ее функции и составные части
• Псевдонимы, списки рассылки и форвардинг
• Конфигурация sendmail (файл sendmail.cf)
  • Макросы и классы
  • Правила
  • Правила выбора агентов доставки
  • Порядок применения наборов правил
  • Специальные наборы правил (check_...)
• Обсуждение
• Управление работой sendmail и тестирование конфигурации
• Установка сервера POP3
• Задания

Литература и ссылки

• Bryan Costales, Eric Allman "Sendmail" - O'Reilly, Second Edition, January 1997; ISBN 1-56592-222-0, 1050 pages.
• Bryan Costales, Eric Allman "Sendmail Desktop Reference" - O'Reilly, First Edition, March 1997; ISBN 1-56592-278-6, 74 pages.
• Craig Hunt "TCP/IP Network Administration", 3.4. Mail Services; 10. sendmail; Appendix E. A sendmail Reference - O'Reilly, Second Edition, December 1997; ISBN 1-56592-322-7, 630 pages.
• Д.Р.Левин, К.Бароди. Секреты Интернет. - К.: Диалектика, ICE, 1996.
• Э.Немет, Г.Снайдер, С.Сибас, Т.Р.Хент. "UNIX/руководство системного администратора" - Киев, bhv, 1997; 830 стр.
• Ю.А.Семенов. Протоколы и ресурсы Интернет. - М.: Радио и Связь, 1996.
• Оригинальный сайт sendmail.
• RFC 821 (SMTP), 822 (Email message format), 2045-2049 (MIME), 1939 (POP-3), 1730-1733 (IMAP).

Используемое ПО:

• Unix (Solaris 2.x),
• sendmail v 8.9 (распространяется свободно),
• qpopper v. 2.2 (распространяется свободно).

См. архив на Уране.

В этой теме изучается организация и конфигурирование сервера электронной почты. Рассматривается служба электронной почты на основе протокола SMTP, известная также как Internet Mail.

Организация службы электронной почты в Интернет

Электронная почта - это служба пересылки сообщений между зарегистрированными адресами. Изначально речь идет только о текстовых сообщениях в узком смысле; о пересылке двоичного содержимого см. п. "Структура email-сообщения". Под текстовыми сообщениями в узком смысле понимаются сообщения, состоящие из строк ограниченной длины, каждая строка состоит из алфавитно-цифровых символов базового набора ASCII и знаков препинания (такие сообщения также называют 7-битовыми). Символы с 8-битовыми кодами (например, кириллица) в этот набор не входят.

Адрес электронной почты состоит выглядит как

почтовый_ящик@почтовый.домен
           m2@vvsu.ru
 Sidor.Ivanov@athena.vvsu.ru

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

Основную роль в системе электронной почты играют программы трех типов:

• транспортные агенты (MTA - Mail Transport Agent),
• агенты доставки (MDA - Mail Delivery Agent),
• пользовательские агенты (MUA - Mail User Agent).

Взаимодействие этих программ и работа системы электронной почты представлены на рисунке 4.1.

Рис. 4.1. Организация и функционирование службы электронной почты

Транспортный агент работает, как правило, на почтовом сервере. Транспортный агент функционирует как маршрутизатор почтовых сообщений. Его функции следующие:

• анализ и преобразование адресов и заголовков почтовых сообщений, в том числе:
  • разбор списков рассылки, пседонимов, переадресации (форвардинг),
  • преобразование адресов в формат другой почтовой системы, если MTA функционирует как шлюз между двумя почтовыми системами (например, между Internet Mail и Sprint Mail),
  • преобразование имени почтового домена отправителя (маскарад),
  • установка служебных заголовков в сообщении, отражающих его маршрут и процесс обработки;
• опрос DNS на предмет имени и адреса почтового сервера адресата сообщения;
• определение агента доставки для каждого сообщения и передача сообщения выбранному агенту доставки;
• управление очередью сообщений, отложенный и повторный вызов агентов доставки в случае невозможности немедленной доставки сообщения;
• возврат сообщений, которые по каким-либо причинам невозможно доставить по назначению.

Агент доставки производит доставку сообщения каким-либо специфическим способом. Существует несколько стандартных типов агентов доставки:

• local - письмо направлено на почтовый ящик, находящийся на этом же компьютере; доставка производится, например, добавлением содержимого сообщения в определенный файл (в Unix это файл /var/mail/почтовый_ящик).
• SMTP - письмо направлено на почтовый ящик в другом почтовом домене; доставка производится путем соединения с транспортным агентом на удаленном сервере с помощью протокола SMTP.
• prog - письмо должно быть обработано какой-либо программой; доставка производится вызовом этой программы, на вход которой подается содержимое письма.

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

Пользовательский агент является оболочкой пользователя для работы с электронной почтой, его функции:

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

Рассмотрим работу службы электронной почты на примере (рис. 4.1). Пусть почтовый сервер, изображенный на рисунке, имеет адрес m.vvsu.ru и сконфигурирован для приема почты с адресами типа некто@cts.vvsu.ru. Соответственно, в базе данных DNS для зоны vvsu.ru есть запись вида

cts.vvsu.ru.   IN     MX   10 m.vvsu.ru.

Рассмотрим входящее сообщение (красные стрелки) от bg@aquarium.ru к ivanov@cts.vvsu.ru. Сообщение поступает по сети к транспортному агенту. (Для передачи сообщений транспортному агенту по сети используется протокол SMTP, рассмотренный в соответствующем пункте ниже.) MTA, проанализировав заголовок сообщения, определяет, что оно адресовано в почтовый домен cts.vvsu.ru, который он обслуживает. В соответствии с этим выбирается агент доставки local, запускается программа этого агента и на вход ей подается текст сообщения со всеми заголовками. Агент доставки каким-то способом, не интересным для транспортного агента, производит доставку сообщения и прекращает свою работу. Транспортный агент анализирует статус выхода (exit status) программы агента доставки, по которому определяет было ли сообщение успешно доставлено или произошла ошибка. В случае ошибки MTA формирует сообщение об ошибке, исходящее с адреса MAILER-DAEMON@m.vvsu.ru, которое будет отправлено отправителю письма (и, как правило, администратору почтового сервера по адресу postmaster@m.vvsu.ru). В случае успешного завершения работы агента доставки письмо считается доставленным получателю.

Агент доставки local (в Unix это программа mail, запущенная как "mail -d ivanov") производит доставку методом добавления содержимого письма к файлу /var/mail/ivanov (в дальнейшем для упрощения мы будем говорить о почтовом сервере под Unix, хотя при обсуждении общей организации системы электронной почты это не имеет принципиального значения).

Иванов (точнее, пользовательский агент Иванова) может получить доступ к своей почте двумя способами:

a) Иванов работает на том же компьютере, где находится почтовый сервер. В этом случае MUA Иванова тривиальным образом считывает поступившее сообщение из файла /var/mail/ivanov и сохраняет его, в случае необходимости, куда-то в свой каталог для осуществления своих функций, описанных выше. Этому способу на рисунке соответствует красный пунктир.

б) Иванов работает на другом компьютере (точнее, Иванов не имеет возможности или желания работать на почтовом сервере). Эта ситуация наиболее типична для пользователей почты в организациях или сообществах. В этом случае для доступа к файлу /var/mail/ivanov через сеть используется протокол POP-3. На почтовом сервере запущена программа POP-сервер, а в MUA Иванова встроен POP-клиент. Этот вариант отражен на рисунке непрерывной красной линией, отходящей от почтовых ящиков. Подробно протокол POP-3 рассмотрен в соответствующем пункте ниже. Так как протокол POP-3 работает поверх TCP/IP, нет никаких ограничений на местоположение компьютера Иванова (красная линия на рисунке, исходящая от POP-сервера, в общем случае проходит через Интернет).

В настоящее время получает распространение протокол IMAP-4, по существу являющийся расширенной версией протокола POP-3. Он, в частности, позволяет пользовательскому агенту каталогизировать и хранить сообщения на почтовом сервере, а не на компьютере пользователя, как это происходит при использовании POP-3. Это удобно в случае, когда Иванов не имеет постоянно закрепленного за собой компьютера - например, Иванов - студент, работающий с почтой из компьютерного класса.

Теперь рассмотрим исходящее сообщение (сиреневые стрелки) от ivanov@cts.vvsu.ru к bg@aquarium.ru. Сообщение поступает к транспортному агенту двумя способами в зависимости от того, где работает Иванов. Если Иванов работает на почтовом сервере, то его MUA напрямую обращается к транспортному агенту и передает ему сообщение для БГ (сиреневый пунктир). Если же Иванов работает на другом компьютере, то его MUA связывается с транспортным агентом через сеть по протоколу SMTP. (Опять, так как протокол SMTP работает поверх TCP/IP, нет никаких ограничений на местоположение компьютера Иванова - сиреневая линия на рисунке, исходящая от комьютера Иванова, в общем случае проходит через Интернет.)

Получив сообщение, MTA анализирует его заголовок и определяет, что это сообщение направлено в другой почтовый домен и не попадает ни под какие особые случаи (например, не должно быть доставлено через UUCP или отослано по факсу - это все определяется конфигурацией MTA). Следовательно, для доставки этого сообщения выбирается агент SMTP, при этом MTA делает запрос в DNS на предмет того, кто является обработчиком почты для домена aquarium.ru. (DNS вернет relay.rinet.ru, IP-адрес=195.54.192.35). Этот адрес вместе с текстом сообщения будет передан агенту доставки, который по протоколу SMTP соединится с указанным адресом и таким образом отправит сообщение транспортному агенту сервера relay.rinet.ru. Если во время этой операции произошла нефатальная ошибка (например, удаленный сервер временно выключен), то агент SMTP вернется со статусом "Отложено" и MTA поставит сообщение в очередь для повторной отправки.

Если запись MX для почтового домена получателя не найдена в DNS, будет сделана попытка найти запись типа А (IP-адрес) для того же доменного имени, т.е. делается предположение, что почтовый домен является именем реального компьютера и на этом компьютере запущен MTA - это справедливо для большинства Unix-систем. Агент доставки попытается доставить сообщение непосредственно на этот адрес.

Почтовые агенты в различных ОС

В ОС Unix транспортным агентом является программа sendmail, ставшая де-факто стандартом MTA. Кроме того, в программу sendmail входит агент доставки SMTP. Локальный агент доставки - программа mail с ключом "-d". В качестве MUA могут использоваться mail, pine, различные MailTools под X-Windows и другие программы. В качестве POP-сервера может быть использована программа qpopper. Все вышеперечисленные программы распространяются свободно, либо являются частью поставки операционной системы.

MUA со встроенным POP-клиентом (Unix, Windows)- Netscape, Eudora, The Bat и др.

Под управлением ОС Windows работают такие почтовые серверы как Netscape Messaging Server и Microsoft Exchange. Они администрируются через оконный web-интерфейс, в котором интегрированы все необходимые функции: собственно транспортный агент, POP3-сервер, система администрирования почтовых ящиков пользователей, псевдонимов, групп и списков рассылки. Однако по сравнению c sendmail такие серверы громоздки, не надежны, малопрозрачны и не обладают той степенью гибкости и универсальности, какую имеет sendmail.

Структура email-сообщения

Базовая структура сообщения электронной почты определена в RFC-822. Сообщение состоит из заголовков и тела сообщения. Заголовки отделяются от тела сообщения пустой строкой.

Каждый заголовок начинается с новой строки и состоит из ключевого слова, за которым следует двоеточие, и данных:

From: "Sidorov" <sidorov@vvsu.ru>

Received: from u2.farm.idt.net (root@u2.farm.idt.net [169.132.8.11]) by
	m.vvsu.ru (8.9.1/8.9.1) with ESMTP id MAA00238 for
        <sidorov@vvsu.ru>; Wed, 5 Jan 2000 12:02:28 +1000 (VVO)

Тело сообщения представляет собой текст в узком смысле (см. выше). Однако, тело сообщения может содержать и символы из расширенного набора (с установленным битом номер 7) - например, кириллицу, - если все агенты, работающие с сообщением, поддерживают восьмибитные символы. В настоящее время большинство используемых агентов такую поддержку обеспечивают.

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

При пересылке сообщения по протоколу SMTP говорят о третьей части сообщения - конверте. Конверт - это адреса отправителя и получателя (получателей), передаваемые как аргументы команд "MAIL FROM" (от кого) "RCPT TO" (кому) во время SMTP-сеанса (см. также п. STMP). В простейшем случае адреса на конверте и адреса в заголовках "From:" и "To:" совпадают, но это далеко не всегда так.

Например, если письмо отправлено нескольким получателям в разные почтовые домены (petrov@a.ru, ivanov@b.ru, sidorov@c.ru, sidorenko@c.ru), то отправляющий MTA размножит это письмо и "разложит" его в 3 конверта, по одному конверту на домен. То есть, в SMTP-сеансе с сервером домена a.ru конверт будет содержать только "RCPT TO: petrov@a.ru", а в сеансе с сервером домена с.ru на конверте будет написано два адресата:

RCPT TO: sidorov@c.ru
RCPT TO: sidorenko@c.ru

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

Заголовки почтового сообщения

Ниже рассмотрены распространенные заголовки, кроме заголовков, добавленных спецификацией MIME.

From: ivanov@a.ru

отправитель; адрес также может иметь форму "Ivan Ivanov" <ivanov@a.ru>.

Reply-To: real_ivanov@a.ru

адрес, на который следует отправлять ответ на письмо. Если этот заголовок отсутствует, ответ отправляется на адрес, указанный в заголовке "From:".

To: sidorov@vvsu.ru, "Petr Petrov" <petrov@vvsu.ru>

основной получатель (получатели).

Сс: "Jonh Smith" <john@smith.a.com>, <sidorenko@c.ru>

дополнительный получатель (получатели), если необходимы. При доставке письма для адресов в заголовках "To:" и "Cc:" выполняются одинаковые действия; различия между "To:" и "Cc:" в техническом плане нет.

Bcc: "Fox Mulder" <mulder@fbi.gov>

получатель (получатели), невидимый для остальных получателей, если требуется. То есть те, кто перечислен в "To:" и "Cc:", не будут знать, что копия письма отправлена Малдеру.

Subject: Happy New Year!

тема письма (может отсутствовать); транспортными агентами и агентами доставки не интерпертируется; может интерпертироваться пользовательским агентом в целях фильтрации и сортировки.

Date: Sat, 15 Jan 2000 17:25:32 +1000

время отправки письма.

Message-ID: <3.0.6.32.20000104175623.007badf0@mail.a.ru>

уникальный идентификатор сообщения, генерируемый MTA-отправителем; для восприятия человеком не предназначен.

Received: ...

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

В большинстве писем встречаются заголовки, начинающиеся на "X-", это дополнительные заголовки, не определяемые стандартом. Например заголовок "X-Mailer:" содержит информацию о пользовательком агенте, отправившем письмо.

При пересылке (форвардинге) сообщения другому получателю в заголовки могут быть добавлены поля с префиксом "Resent-" ("Resent-From:", "Resent-To:", "Resent-Date" и т.п.). Эти поля содержат информацию, вставленную тем, кто произвел форвардинг. Например, поле "From:" содержит адрес первоначального отправителя, а "Resent-From:" - адрес того, кто переслал это сообщение. При таком способе форвардинга тело сообщения не изменяется, только добавляются заголовки. Другой метод форвардинга описан в следующем пункте при обсуждении типа данных message/rfc822.

MIME

• пересылки восьмибитных текстов и полностью двоичных данных;
• поддержки сложных сообщений, состоящих из нескольких разделов (возможно, содержащих данные разных типов).

Для выполнения указанных задач вводятся дополнительные заголовки "Content-Type:" и "Content-Transfer-Encoding:", которые определяют соответственно тип данных, содержащихся в сообщении (разделе сообщения), и способ представления этих данных, и заголовок "MIME-Version: 1.0". Он указывает версию MIME (в настоящий момент 1.0) и используется для обозначения того, что настоящее сообщение является не простым email-сообщением согласно RFC-822, а составлено по спецификации MIME.

Заголовок "Content-Type:" имеет формат:

Content-Type: тип/подтип [; параметр=значение [;...]]

Основные типы данных (MIME-types)

Стандартные типы и подтипы данных можно найти по адресу ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/. Типы и подтипы, начинающиеся с "x-", не входят в стандарт и считаются определяемыми пользователем для своих нужд, но фактически среди них есть много широко рапространенных наименований, например "audio/x-realaudio". MIME-types используются не только в электронной почте, но и в WWW - для определения типа данных, пересылаемых между сервером и броузером.

text

Текстовые данные (в том числе восьмибитные); наиболее распространенные подтипы: plain (обычный текст) и html. Возможный параметр: "charset=название_кодировки_символов"; наличие параметра необязательно. (Примеры кодировок символов: us-ascii [текст в узком смысле, только семибитные символы], кириллица: koi8-r, windows-1251, iso8859-5.) Если не указан charset, считается, что это us-ascii. Пример заголовка:

Content-Type: text/plain; charset=koi8-r

Если заголовок "Content-Type:" отсутствует, то считается, что это

Content-Type: text/plain; charset=us-ascii

image

Неподвижные изображения; примеры подтипов: jpeg, gif. Пример заголовка (параметры необязательны):

Content-Type: image/jpeg; name="portrait.jpg"

audio

Звук; примеры подтипов: mpeg, x-realaudio. Пример заголовка (параметры необязательны):

Content-Type: audio/x-realaudio; name="song.ra"

video

Видео; примеры подтипов: mpeg, quicktime. Пример заголовка (параметры необязательны):

Content-Type: video/mpeg; name="movie.mpeg"

application

Двоичные данные (поток байт), в общем случае предназначенные для какой-то прикладной программы и не попадающие в вышеперечисленные категории. Подтип позволяет определить, для какой именно программы предназначены данные. Определено большое число различных подтипов (например, postscipt, msword, zip, x-javascript). Если неизвестно, как интерпретировать данные, используется общий подтип octet-stream. Пример заголовка (параметры необязательны):

Content-Type: application/msword; name="my_file.doc"

multipart

Составное сообщение - письмо состоит из нескольких разделов, каждый из которых имеет свои заголовки и тело. Наиболее распространенный подтип - mixed, означающий, что каждый раздел письма может содержать данные любого зарегистрированного типа. Разделы отделяются друг от друга с помощью некоторого уникального набора символов, который указывается в заголовке как значение обязательного параметра "boundary"; выбор этого набора символов с учетом уникальности - задача пользовательского агента, формирующего сообщение. Пример заголовка:

Content-Type: multipart/mixed; boundary="------------CED5632469"

При разграничении разделов в теле сообщения, значение boundary предваряется двумя минусами (т.е. в данном примере вместо 12 минусов будет 14). Каждый раздел состоит из заголовков и тела (данных); заголовки отделены от данных пустой строкой. Заголовки раздела - "Content-Type:" и "Content-Transfer-Encoding:" - определяют тип данных раздела и их представление. Пример почтового сообщения из нескольких разделов со всеми заголовками см. в конце пункта.

message

Составное сообщение - тело сообщения в свою очередь является email-сообщением, которое может состоять из одного или нескольких частей. Такой тип может применяться при пересылке (форвардинге) сообщений. Основной подтип: rfc822; пример заголовка:

Content-Type: message/rfc822

Тип данных message может применяться и в заголовке "Content-Type:" раздела multipart-сообщения; это означает, что тело раздела представляет собой email-сообщение. Полные примеры сообщений см. в конце пункта.

Заголовок "Content-Transfer-Encoding:" определяет представление данных в теле сообщения (раздела). Возможные значения:

7bit

Текст в узком смысле (us-ascii). Данные помещаются в тело собщения (раздела) как они есть.

8bit

Восьмибитный текст (например, кириллица). Данные помещаются в тело собщения (раздела) как они есть.

binary

Двоичные данные (поток байт); помещаются в тело собщения (раздела) как они есть. Это представление обычно не используется, так как хотя современные реализации протокола SMTP и пропускают восьмибитные символы (т.е. фактически байты с любыми значениями кроме нулевого), но все равно требуется чтобы данные состояли из строк не длиннее 1000 символов - т.е. чтобы комбинация CRLF встречалась не реже чем каждые 998 символов. (Это как раз и есть представление "8bit".)

quoted-printable

Восьмибитный текст в закодированном виде. Кодировка выполняется посимвольно. Одни символ кодируется следующим образом (алгоритм неполный, см. RFC2045 для деталей): символ с ASCII-кодом от 32 до 127 включительно передается как он есть; символ с другим кодом передается в виде тройки символов, состоящей из символа "=", за которым следует шестнадцатеричное значение кода символа. Символ "=", являющийся частью текста, кодируется как "=3D". Переводы строки в конце каждой строки текста передаются как они есть.

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

base64

Произвольные двоичные данные, закодированные по алгоритму base64. Сущность алгоритма в следующем (описание и таблицу символов см. в RFC2045): из входного потока берется 24 бита (3 октета), которые разбиваются на 4 группы по 6 бит в каждой. Каждое возможное значение 4-битной группы (0-63) соответствует одному символу из таблицы 7-битных текстовых символов (0='A', 1='B', ..., 26='a', 27='b', ..., 52='0', ..., 62='+', 63='/'). Таким образом 3 входных октета с произвольными значениями преобразуются на выходе в четыре семибитных символа, которые без проблем обрабатываются любыми почтовыми агентами. Получившийся выходной поток символов разбивается на строки длиной не более 76 символов.

Можно разрабатывать и использовать также нестанданртные представления; их наименования обязаны начинаться с символов "x-"

Примеры почтовых сообщений с заголовками

Received: from ada.vvsu.ru (ada.vvsu.ru [212.16.195.70]) by maria.vvsu.ru
          (8.8.3/8.8.3) with SMTP id RAA04870 for <fire@maria.vvsu.ru>;
		  Tue, 18 Jan 2000 17:15:26 +1000 (VVO)
Message-ID: <388412B0.3522@vvsu.ru>
Date: Tue, 18 Jan 2000 17:13:53 +1000
From: Maxim Mamayev <m2@vvsu.ru>
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: fire@maria.vvsu.ru
Subject: test of mixed message
Content-Type: multipart/mixed; boundary="simple boundary"

This is a multi-part message in MIME format.

Эта часть (преамбула) игнорируется в MIME-сообщениях.
Как правило пользовательский агент помещает сюда объявление
о том, что это MIME-сообщение на случай, если агент получателя
не поддерживает MIME.

--simple boundary
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit

Основной текст сообщения на русском языке в КОИ-8

--simple boundary
Content-Type: image/jpeg; name="test.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="test.jpg"

YWJjZGVm
--simple boundary

Это эпилог. Он игнорируется как и преамбула.

2. Сообщение, являющееся результатом пересылки (форвардинга) некоторого исходного сообщения. Исходное сообщение (от xhawk@chat.ru для m2@vvsu.ru) содержится внутри тела нового сообщения.

Received: from ada.vvsu.ru (ada.vvsu.ru [212.16.195.70]) by maria.vvsu.ru
         (8.8.3/8.8.3) with SMTP id UAA04969 for <fire@maria.vvsu.ru>;
		 Tue, 18 Jan 2000 20:54:30 +1000 (VVO)
Message-ID: <3884460A.5AD0@vvsu.ru>
Date: Tue, 18 Jan 2000 20:52:58 +1000
From: Maxim Mamayev <m2@vvsu.ru>
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: fire@maria.vvsu.ru
Subject: [Fwd: forward it]
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Content-Type: message/rfc822

Received: from chat.ru (surf-6.vvsu.ru [212.16.195.86]) by wildcat.vvsu.ru
          (Netscape Messaging Server 3.62)  with ESMTP id 372
          for <m2@vvsu.ru>; Mon, 27 Dec 1999 17:43:13 +1000
Message-ID: <386718EE.90BD95DF@chat.ru>
Date: Mon, 27 Dec 1999 17:44:46 +1000
From: Yankee <xhawk@chat.ru>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
MIME-Version: 1.0
To: m2@vvsu.ru
Subject: forward it
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit

Текст исходного сообщения

3. Сообщение, являющееся результатом форвардинга сообщения из примера номер 1 (которое в свою очередь является сложным сообщением, состоящим из двух частей). Более того, при форвардинге в "объемлющее" новое сообщение был добавлен некоторый текст.

Received: from ada.vvsu.ru (ada.vvsu.ru [212.16.195.70]) by maria.vvsu.ru
         (8.8.3/8.8.3) with SMTP id SAA04920 for <fire@maria.vvsu.ru>;
		 Tue, 18 Jan 2000 18:58:00 +1000 (VVO)
Message-ID: <38842ABB.39CC@vvsu.ru>
Date: Tue, 18 Jan 2000 18:56:27 +1000
From: Maxim Mamayev <m2@vvsu.ru>
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: fire@maria.vvsu.ru
Subject: [Fwd: test mixed]
Content-Type: multipart/mixed; boundary="------------20EADB04695"

This is a multi-part message in MIME format.

--------------20EADB04695
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit

Текст, добавленный при форвардинге

--------------20EADB04695
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

Message-ID: <388412B0.3522@vvsu.ru>
Date: Tue, 18 Jan 2000 17:13:53 +1000
From: Maxim Mamayev <m2@vvsu.ru>
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: fire@maria.vvsu.ru
Subject: test mixed
Content-Type: multipart/mixed; boundary="simple boundary"

This is a multi-part message in MIME format.

--simple boundary
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit

Текст исходного сообщения

--simple boundary
Content-Type: image/jpeg; name="test.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="test.jpg"

YWJjZGVm
--simple boundary



--------------20EADB04695--

Основные команды протокола SMTP

Для пересылки почтовых сообщений через Интернет между транспортными агентами и от MUA к MTA (см. рис. 4.1) используется протокол SMTP (Simple Mail Transfer Protocol).

Номер порта сервера SMTP - TCP/25. После установления соединения с клиентом сервер ожидает ввода команд и данных в текстовом виде. Строчные и прописные буквы в командах не различаются. Реакция сервера заключается в трехзначном числовом коде, снабженном текстовым комментарием.

Числовой код предназначен для автоматической обработки ответов сервера программой-клиентом. Код, начинающийся на 2, является положительным ответом, на 3 - промежуточным положительным откликом (т.е. после ввода команды ожидаются дополнительные данные), коды вида 5хх сигнализируют об ошибке.

Основные команды SMTP:

HELO hostname

- первая команда сеанса, hostname - доменное имя вызывающего хоста (клиента).

MAIL FROM: email_адрес_от_кого

- обратный адрес.

RCPT TO: email_адрес_кому

- адрес получателя (в случае нескольких адресатов команда повторяется для каждого адресата).

DATA

- начало ввода текста сообщения; сервер посылает промежуточный положительный отклик 354 и рассматривает все последующие строки в качестве текста (тела) сообщения; конец ввода - строка состоящая из одной точки. Перед текстом сообщения вводятся поля заголовка (см. выше п. Структура email-сообщения). Каждое поле заголовка должно начинаться с новой строки. Между заголовком и текстом сообщения должна быть одна пустая строка.

VRFY email_адрес

- выдается положительный отклик (250,251 или 252), если сервер может попытаться доставить сообщение по указанному адресу; иначе выдается отрицательный отклик 550. Если email_адрес - не локальный адрес на сервере, то положительный отклик не обязательно означает, что этот адрес существует. Для локальных адресов производится подстановка из файла /etc/aliases (если адрес там указан) и в поле текстового комментария выводится результат, часто к нему добавляется настоящее имя пользователя.

EXPN email_addr

- если email_addr - локальный адрес списка рассылки, то вывести адреса в этом списке; иначе поведение команды не определено. Как правило, если email_addr - локальный адрес, то выполняется подстановка из файла /etc/aliases (если там этот адрес указан); иначе просто выдается положительный отклик 250.

RSET

- сброс сеанса к начальному состоянию (как после ввода HELO).

QUIT

- конец связи.

Команды EXPN и VRFY не обязательно выполняются сервером; часто их отключают из соображений секретности. Для передачи почты эти команды не нужны; фактически, они предназначены для человека. Действия этих команд в стандарте четко не определены и их реализация не является обязательной.

Сущетсвуют также дополнительные команды - так называемый Расширенный SMTP (ESMTP). Не все серверы поддерживают команды ESMTP и каждый сервер может поддерживать какое-то свое подмножетсво ESMTP-команд, в том числе нестандартных. Для того, чтобы выяснить, какие дополнительный команды поддерживаются, следует вместо HELO подать команду EHLO.

Пример SMTP-сеанса

Ниже приведен пример сеанса между пользовательским агентом, отправляющим письмо с компьютера ada.vvsu.ru, который для этого подсоединился к МТА на компьютере athena.vvsu.ru.

220 athena.vvsu.ru ESMTP Sendmail 8.9.3/8.9.1; Thu, 20 Jan 2000 15:24:27 +1000 (VVO)
HELO ada.vvsu.ru
250 athena.vvsu.ru Hello ada.vvsu.ru [212.16.195.70], pleased to meet you
MAIL FROM: m2@vvsu.ru
250 m2@vvsu.ru... Sender ok
RCPT TO: god@heavens.com
250 god@heavens.com... Recipient ok
RCPT TO: mulder@fbi.gov
250 mulder@fbi.gov... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From: Maxim Mamayev <m2@vvsu.ru>
To: The Lord <god@heavens.com>
Cc: mulder@fbi.gov
Subject: Apocalypse did not happen
Date: Thu Jan 20 15:37:59 VVO 2000

Hello, Sir
I would like to inform you that the Y2K apocalypse
did not occur.

M.
.
250 PAA00490 Message accepted for delivery
QUIT
221 athena.vvsu.ru closing connection

Основные команды протокола POP-3

Протокол POP (Post Office Protocol) используется для пересылки новой почты пользователя с сервера на рабочую станцию пользователя. В настоящий момент используется версия 3; по набору команд она несовместима с предыдущими версиями.

Номер порта сервера POP - TCP/110. После установления соединения с клиентом сервер ожидает ввода команд и данных в текстовом виде. Строчные и прописные буквы в командах не различаются. Реакция сервера - строка начинающаяся с метки "+OK" или "-ERR", за которой следует текстовый комментарий и, если команда это подразумевает, с новой строки выводятся данные (текст сообщения или листинг сообщений). Вывод данных заканчивается строкой, содержащей только символ "." ("точка"). Если среди данных есть такая строка, то точка в этой строке удваивается.

Команды POP-3:

USER имя_пользователя

- первая команда сеанса, вводится имя пользователя (идентификатор почтового ящика).

PASS пароль

- вторая команда сеанса, вводится пароль.

STAT

- после метки "+OK" выводит два числа: число сообщений и их общий объем в байтах.

LIST n

- если n указано, то после метки "+OK" выводит размер сообщения номер n в байтах. Иначе выводит список из двух колонок: номер сообщения, пробел, размер сообщения в байтах; вывод списка заканчивается строкой, содержащей только символ "." ("точка").

RETR n

- выводит сообщение номер n. Вывод заканчивается строкой, содержащей только символ "." ("точка").

DELE n

- удаляет сообщение номер номер n с сервера; при этом нумерация сообщений не изменяется, а все удаленные в данном сеансе сообщения могут быть восстановлены командой REST.

LAST

- после метки "+OK" выводит номер последнего по времени сообщения, для которого была выполнена команда RETR; эта информация сохраняется между сеансами, что позволяет не запрашивать дважды уже полученные пользователем, но не удаленные с сервера сообщения.

TOP n m

- выводит заголовок и m первых строк сообщения номер n. Вывод заканчивается строкой, содержащей только символ "." ("точка").

RSET

- отменяет удаление всех сообщений, удаленных в данном сеансе.

NOOP

- нет операции.

QUIT

- конец связи.

Программа sendmail: ее функции и составные части

Программа sendmail - это транспортный почтовый агент (MTA) плюс агент доставки SMTP. Sendmail фактически является стандартным MTA для Unix и поставляется вместе с операционной системой. Сайт разработчиков программы находится по адресу www.sendmail.org. Программа распространяется бесплатно, в исходных текстах. Полное описание программы, ее конфигурации и работы с ней см. в книге Bryan Costales, Eric Allman "Sendmail". Ниже описываются наиболее ключевые и необходимые для работы моменты.

Sendmail состоит из программы /usr/lib/sendmail, конфигурационного файла /etc/mail/sendmail.cf, файла псевдонимов /etc/mail/aliases и других вспомогательных файлов, а также документов справочника man. Программа использует каталоги /etc/mail для хранения конфигурационного и вспомогательных файлов и /var/spool/mqueue для очереди сообщений. Путь к каталогу очереди сообщений может варьироваться от системы к системе.

Программа /usr/lib/sendmail выполняет различные действия в зависимости от того, с какими ключами или под каким именем она запущена. Например

#/usr/lib/sendmail -bd

Запуск в режиме демона (производится при старте системы) для приема SMTP-соединений; подробнее см. ниже.

#/usr/lib/sendmail -bt

Запуск в тестовом режиме для проверки конфигурации; подробнее см. ниже.

#/usr/bin/newaliases

Разбор файла /etc/mail/aliases и обновление базы данных aliases. (/usr/bin/newaliases - ссылка на /usr/lib/sendmail.) См. также следующий пункт.

#/usr/bin/mailq

Вывод содержимого очереди сообщений. (/usr/bin/mailq - ссылка на /usr/lib/sendmail.)

%/usr/lib/sendmail sidorov@vvsu.ru

Вызов MTA для обработки и отправки сообщения Сидорову. Сообщение со всеми заголовками передается на стандартный ввод. Обычно такой вызов производится пользовательским агентом.

Основные задачи администратора при работе с sendmail: определение псевдонимов и списков рассылки (следующий пункт) и внесение изменений и дополнений в файл sendmail.cf (см.). Прочие задачи описаны в п. Управление работой sendmail и тестирование конфигурации.

Псевдонимы, списки рассылки и форвардинг

Файл /etc/aliases (->/etc/mail/aliases) позволяет определить альтернативные имена для получателей почты, связать стандартные имена типа MAILER-DAEMON с реальными получателями и создать списки рассылки.

Файл состоит из текстовых строк формата:

псевдоним: получатель[,получатель, ... ]

например:

#обязательные записи
MAILER-DAEMON: postmaster
postmaster:    root
#альтернативные имена для Петрова
ivan: petrov
ivan.petrov: petrov
petrov: ipetrov@aol.com

#список рассылки
friends: petrov, sidorov@vvsu.ru, ivanov
#администратор списка friends (его имя: "owner-имя_списка")
owner-friends: petrov

#вставить список рассылки из другого файла
staff: :include:/home/manager/mail/staff

#добавить сообщение в конец файла (обязательно полный путь к файлу)
filer: /var/tmp/add_to_this_file

# получателем сообщения является программа, которая запускается
# и текст сообщения подается ей на стандартный ввод
myprog: |"/usr/local/bin/do_something"

Чтобы записи в измененном файле /etc/aliases были прочитаны программой sendmail, необходимо выполнить команду newaliases.

Файл /etc/aliases является системным и редактируется администратором. С помощью директивы ":include:" удобно поручать формирование списка рассылки другому (обычному) пользователю. Адреса в файле, подключаемом директивой ":include:", располагаются под одному на строку; строки, начинающиеся с символа #, игнорируются.

Каждый пользователь может создать в своем домашнем каталоге файл .forward со списком почтовых адресов, по одному на строку. В этом случае вся почта, приходящая этому пользователю, будет направляться по указанным адресам, ВМЕСТО доставки пользователю. Чтобы поступающая почта оставалась также и в локальном почтовом ящике, его адрес должен быть тоже включен в .forward.

Файл .forward обрабатывается после файла /etc/aliases. Файл .forward может содержать также содержать директивы перенаправления почты в программу или добавления к файлу аналогично тому, как это делается в /etc/aliases.

Конфигурация sendmail (файл sendmail.cf)

Действия sendmail по обработке заголовков почтовых сообщений и определению способов и путей доставки сообщений определяются конфигурационным файлом /etc/mail/sendmail.cf, имеющим специальный синтаксис. В этом файле описаны служебные макросы (подстановки из одного элемента) и классы (наборы элементов); правила (правила переписывания заголовков и обработки сообщений), сгруппированные в наборы правил; агенты по доставке сообщений и др.

Файл sendmail.cf можно рассматривать как программу по обработке почтового сообщения на основании заголовков этого сообщения (преимущественно адресов отправителя и получателя). Центральными элементами этой программы являются правила, играющие роль операторов ветвления и цикла, и наборы правил, играющие роль функций. Макросы и классы приблизительно соответствуют переменным и массивам. Реультатом работы этой "программы" для каждого почтового сообщения являются сформированные (возможно, измененные) заголовки сообщения (особенно это касается заголовков "From:" и "To:") и выбор агента доставки.

Также в конфигурационном файле содержатся определения имеющихся в системе агентов доставки и опции, определяющие те или иные аспекты работы sendmail. (Опции описаны в литературе.)

Каждая запись начинается с однобуквенной метки-идентификатора типа записи (D,C,R,S,M,O и др.).

Макросы и классы

D - определить макрос, т.е. подстановку. Например,

DUmaria.vvsu.ru 

После D непосредственно следует имя макроса (один символ; в данном случае - U; строчные и прописные буквы различаются), за которым непосредственно следует значение макроса (последовательность символов; в данном случае - maria.vvsu.ru). В последних версиях sendmail (начиная с 8.7) имя макроса может состоять из нескольких символов; в этом случае оно берется в фигурные скобки:

D{cool_host}maria.vvsu.ru 

Подстановка значения макроса производится с помощью знака доллара, например: "mail.$U." и "mail.${cool_host}." оба преобразуются в "mail.maria.vvsu.ru.". Подстановка значений производится при считывании конфигурационного файла программой при ее запуске (аналогично препроцессору Си).

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

• $m - домен DNS, в котором находится данный хост;
• $w - короткое имя хоста (без домена);
• $j - каноническое имя DNS данного хоста (фактически, Dj$w.$m - если sendmail не может определить $j автоматически, это делается в конфигурационном файле);
• $d - текущая дата и время (в формате вывода команды date);
• $S - "smart host" - имя хоста, на который отправляется вся почта, которую данных хост не может доставить; используется при конфигурировании пользовательских хостов, не являющихся mail-серверами;
• $&{client_name} - доменное имя SMTP-клиента, подсоединившегося в настоящий момент; если DNS не может преобразовать адрес в имя, то - IP-адрес клиента, взятый в квадратные скобки; амперсанд после '$' обозначает, что значение макроса подставляется в момент разбора правила, в котором он встречается, а не при считывании конфигурационного файла.
• $&{client_addr} - IP-адрес SMTP-клиента, подсоединившегося в настоящий момент.

Классы

C - определить класс, то есть набор значений, например,

Cwlocalhost mail.vvsu.ru vvsu.ru

После С непосредственно следует имя класса (один символ; в данном случае - w; строчные и прописные буквы различаются), за которым непосредственно следует первое значение из класса (последовательность символов; в данном случае - localhost), далее, разделенные пробелами, - остальные значения. В последних версиях sendmail (начиная с 8.7) имя класса может состоять из нескольких символов; в этом случае оно берется в фигурные скобки.

Значения класса могут быть считаны из файла. Директива

FU /etc/mail/file

Отдельные классы трактуются заранее предопределенным образом; самый важный - класс w, содержащий список имен, которые sendmail, встретив их в доменной части почтового адреса, должен считать локальными, т.е. "своими". Сообщения, приходящие на такие адреса, не перенаправляются куда-либо дальше, а передаются одному из локальных агентов доставки. Класс w заполняется автоматически при старте sendmail всеми именами, псевдонимами и IP-адресами данного хоста, которые удалось обнаружить в DNS и файле /etc/hosts. Дополнительные значения могут быть добавлены в конфигурационном файле.

Примеры других классов с предопределенным значением см. в литературе.

Правила

R - описать правило, описания правил выглядят как

Rшаблон         действие

Левая (шаблон) и правая (действие) части разделяются символом табуляции. Пробелы недопустимы.

Каждое правило применяется к некоторому рабочему пространству (workspace), которое представляет собой строку, представленную в виде упорядоченного списка токенов (элементов). Пример "токенизации": рабочее пространство "m2@vvsu.ru" интерпретируется в правилах как список из 5 токенов: "m2", "@", "vvsu", ".", "ru".

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

Правила группируются в наборы правил, начало набора правил обозначается меткой S, за которой следует идентификатор набора (число или строка), например, S0 или Smy_ruleset (строчные и прописные буквы различаются). Один набор правил кончается там, где начинается другой. Правила в наборе выполняют какую-либо общую задачу.

Если рассматривать sendmail.cf как программу, то набор правил аналогичен функции. При вызове на вход ему подается некоторое рабочее пространство, которое становится рабочим пространством первого правила данного набора. После завершения работы одного правила его рабочее пространство подается на вход следующего правила данного набора. Набор правил возвращает как результат своей работы рабочее пространство последнего отработавшего правила. См. также п. "Порядок применения наборов правил" ниже.

В левой части правил, помимо токенов с буквальным текстом, могут встречаться регулярные выражения:

$*   ноль и более токенов,
$-   один токен,
$+   один и более токенов,
$@   ноль токенов,
$=X   один токен из класса X,
$~X   один токен не из класса X.

Пример:

R$+.vvsu.ru			vvsu.ru

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

$N ($1,$2,...) - подстановка значения N-го регулярного выражения из левой части. Например:

R$*.		$1

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

R$* <@$-.vvsu.ru> $*			$1 <@vvsu.ru> $3

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

$[ name $] - вместо этого оператора подставить каноническое имя DNS для name.

$>N - вызвать набор правил N (о группировке правил в наборы см. ниже). Набор правил можно рассматривать как функцию. Рассмотрим пример: пусть правая часть правила выглядит "$1 $>33 $2". Имеет место следующая последовательность действий: правая часть вычисляется как если бы "$>33" отсутствовало, т.е. формируется новое рабочее пространство, состоящее из подстановок значений $1 и $2. После этого вызывается набор правил 33, а в качестве рабочего пространства в него передается то, что стоит справа от "$>33" (т.е. значение подстановки $2). Набор 33, последовательно применяя правила, из которых он состоит, как-то модифицирует переданное ему рабочее пространство. После завершения его работы полученный результат помещается в рабочее пространство текущего правила вместо того, что стояло справа от "$>33".

$: - применить это правило один раз ("while" превращается в "if"). Оператор используется как префикс правой части. Пример (заключение рабочего пространства в скобки):

R$*			$: <$1>

(иначе возник бы бесконечный цикл).

$@ - применить это правило один раз ("if") и прервать выполнение набора правил (аналогично досрочному выходу из функции). Оператор используется как префикс правой части. Пример:
R$* <@$-> $*		   $@ $1<@ $[ $2 $] > $3
(если почтовый домен состоит из одного имени хоста, подставить туда полное каноническое имя DNS этого хоста и выйти из набора правил).

Правила выбора агентов доставки

Особый тип правил - это правила выбора агентов доставки: на основании совпадения рабочего пространства с шаблоном в левой части правила производится выбор агента доставки, указанного в правой части. Вследствие этого структура правой части отличается от рассмотренной выше. Пример такого правила:

R$* < @ $* > $*		$#smtp $@ $2 $: $1 < @ $2 > $3

Правило означает, что для доставки сообщений по адресам типа somebox@somehost нужно вызвать агент доставки smtp (об определении агентов см. ниже в этом пункте). Имя агента следует за оператором $#. Операторы $@ и $: имеют специальные значения. После $@ следует почтовый домен адресата; значение этого параметра записывается в макрос h, который может быть использован в определении агента доставки (см. ниже). После $: следует имя пользователя (для локальных агентов) или, в общем случае, адрес получателя (он будет аргументом команды "rcpt to" SMTP-диалога); значение этого параметра записывается в макрос u, который также может быть использован в определении агента доставки.

Другой пример (выбор локального агента, если адрес состоит из одного слова - очевидно, это просто имя пользователя в системе):

R$-                     $#local $:$1

После срабатывания правила выбора агента доставки производится выход из текущего набора правил; при этом результатом работы набора правил является выбор агента доставки.

Каждый агент доставки должен быть определен (зарегистрирован) где-либо в конфигурационном файле с помощью директивы М.

M - описать агент доставки

Мимя_агента, параметр=значение, параметр=значение, ...

Msmtp,  P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, A=IPC $h
Mlocal, P=/bin/mail/local, F=lsDFMrmn, S=10, R=20/40, A=mail -d $u
Mprog,  P=/bin/sh, F=lsDFMeuP, S=10, R=20, A=sh -c $u
# prog осуществляет доставку сообщения путем запуска программы, определяемой макросом $u

Параметры:

P= указывает путь к программе агента доставки ([IPC] - встроенный в sendmail модуль smtp). Текст сообщения со всеми загловками подается на стандартный ввод этой программы.

F= флаги, дающие sendmail информацию о программе доставки, например, флаг m означает, что агент может работать с несколькими получателями, D - в заголовке требуется поле Date. Полный список флагов см. в литературе.

S=, R= указывают наборы правил для окончательного (last-minute) преобразования адресов отправителя (S) и получателя (R). В случае двух номеров, указанных через дробь, первый применяется к преобразованию адреса в конверте, второй - к адресу в заголовке. Этих наборы правил предназначены для внесения пользовательских изменений.

E= символ(ы) конца строки.

L= максимальная длина строки сообщения.

U= пользователь, от имени которого будет запущен агент.

A= аргументы командной строки программы агента доставки, начиная с нулевого (имени программы).

Параметры P= и A= являются обязательными. Из агентов обязательно должны быть определены агенты local и prog.

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

R...		$#error $@ 5.1.8 $: "We do not want to relay your letters"

Порядок применения наборов правил

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

Сначала отдельно для адреса отправителя и отдельно для адреса получателя вызывается набор правил 3, который производит фокусировку. Фокусировка залючается в том, что любой почтовый адрес приводится к виду "пользователь < @ домен(хост) >". Для почтовых адресов Интернет эта процедру достаточно тривиальна: "m2@vvsu.ru" приводится к виду "m2 < @ vvsu . ru . >" (7 токенов) - обратите внимание, что доменное имя - полностью определенное, заканчивается на точку.

Фокусировка очень удобна при последующем разборе адресов с помощью правил.

После прохождения набора 3 сфокусированный адрес получателя подается одновременно на наборы 0 и 2. Набор 0 производит выбор агента доставки. Набор 2 предназначен для преобразования адреса получателя; в последних версиях это набор ничего не делает или отсутствует. После этого адрес получателя проходит через тот набор правил, который указан в параметре "R=" определения агента доставки (который уже выбран с помощью набора 0). Если в параметре "R=" указано два набора - один для конверта, другой для заголовка, - то адрес получателя подается одновременно в каждый из указанных наборов и на выходе получается два адреса получателя: один для конверта, другой для заголовка.

Обработка адреса отправителя производится в следующей последовательности: после набора 3 сфокусированный адрес отправителя подается в набор 1, который, аналогично набору 2, в последних версиях ничего не делает или отсутствует. После этого адрес отправителя проходит через тот набор правил, который указан в параметре "S=" определения уже выбранного агента доставки. Если в параметре "S=" указано два набора, то, аналогично случаю с адресом получателя, на выходе получается отдельный вариант адреса отправителя для конверта и отдельный - для заголовка.

Преобразования всех адресов завершаются набором 4, производящим дефокусировку (т.е. отменяющим изменения, сделанные набором 3).

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

Специальные наборы правил (check_...)

Специальные наборы правил check_mail, check_rcpt, check_relay и check_compat предназначены для проверки легитимности адресов сообщений, поступающих в sendmail, особенно через SMTP. Эти наборы формируют локальную политику приема и обработки сообщений. Каждый набор вызывается в определенный момент обработки сообщения. Если набор отсутствует или возвратил что угодно кроме агента доставки error, считается, что принято положительное решение. Иначе sendmail отказывает в обработке сообщения по причине, указанной в правиле, выбравшем агента error (пример правила см. выше).

Набор правил check_mail вызывается непосредственно после ввода подсоединившимся по SMTP агентом команды "MAIL FROM". В качестве рабочего пространства в набор подается аргумент команды "MAIL FROM" (т.е. адрес отправителя из конверта входящего письма). Этот набор правил решает, принимать ли вообще почту от данного отправителя.

Пример набора check_mail, который отказывает в приеме сообщений из почтового домена "spamming.org":

Scheck_mail
R$*                   $: $>3 $1              фокусировка
R$* <@ $+. > $*       $1 <@ $2> $3           удаление завершающей точки
R$* <@ $+ > $*        $: $2                  выделение доменной части адреса
R$* . $+ . $+         $: $2 . $3             выделение двух последних частей доменного имени
Rspamming.org         $#error $@ 5.7.1 $: "cannot accept mail from spamming.org"

Набор правил check_rcpt вызывается непосредственно после ввода подсоединившимся по SMTP агентом команды "RCPT TO". В качестве рабочего пространства в набор подается аргумент команды "RCPT TO" (т.е. адрес получателя из конверта входящего письма). Пример этого набора см. в литературе. Этот набор правил решает, отправлять ли вообще почту данному получателю.

Набор правил check_relay вызывается непосредственно перед началом SMTP-сеанса с подсоединяющимся агентом. В качестве рабочего пространства в набор подаются доменное имя и IP-адрес подсоединяющегося агента, разделенные символами "$|":

maria.vvsu.ru $| 212.16.195.98

Набор правил check_compat вызывается непосредственно перед передачей сообщения агенту доставки (все адреса уже преобразованы и дефокусированы; произведено раскрытие псевдонимов из /etc/mail/aliases и .forward). В качестве рабочего пространства в набор подаются адреса отправителя и получателя, разделенные символами "$|":

m2@vvsu.ru $| god@heavens.com

Обсуждение

Sendmail по-видимому является наиболее легендарной программой из обоймы Unix. Он ведет свою историю с того времени, когда действовало и было широко распространено множество служб электронной почты. Для того, чтобы правильно обрабатывать сообщения всех возможных форматов и подстраиваться под любые изменения, потребовалось развить достаточно изощренный язык файла конфигурации программы. Хотя этот язык не так сложен, как кажется на первый взгляд, с точки зрения настоящего положения вещей - унификации и стандартизации Интернет - он кажется неколько избыточным. Однако, богатство возможностей, предоставляемых администратору, окупает усилия, потраченные на изучение формата файла sendmail.cf.

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

Более того, в большинстве случаев все, что нужно сделать администратору, - это проконтролировать, что макрос j содержит полное доменное имя хоста, а класс w содержит весь список почтовых доменов, для которых данных хост принимает почту. Более сложные задачи, требующие знания языка sendmail.cf и редактирования конфигурационного файла, могут возникнуть у администратора почтового сервера предприятия. Примеры типичных задач и способов их решения приведены в таблице.

Задачи	Способы решения
Настройка политики приема и ретраснляции сообщений	Создание/редактирование наборов праил типа check_...
Маскарад - сокрытие деталей доменной структуры организации путем приведения всех обратных адресов к одному унифицированному почтовому домену	Внесение изменений в набор 1 или набор, указанный параметром "S=" агента доставки
Доставка определенного типа сообщений через специальных агентов - например, запись в базу данных	Идентификация типа сообщений (по особому доменному имени [добавить его в класс w], по именам пользователей, принадлежащих определенному классу, и т.п.); определение нового агента; добавление правил выбора нового агента для идентифицированных сообщений в набор 0
Взаимодействие (шлюзование) с системой электронной почты, работающей по другим протоколам	Внесение изменений в различные наборы правил в зависимости от конкретного случая

Управление работой sendmail и тестирование конфигурации

Тестовый режим

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

/usr/lib/sendmail -bt -C ./sendmail.cf.new

sendmail запускается в диалоговом тестовом режиме (./sendmail.cf.new - новый конфигурационный файл). Ожидаемый ввод:

>номер_набора адрес(рабочее пространство)

Программа произведет разбор рабочего пространства с помощью указанного набора правил. Несколько наборов правил могут быть указаны через запятую в порядке их вызова. Если набор правил 3 не указан явно, то адреса должны вводиться в сфокусированном виде. Примеры (определить агента доставки для адреса m2@vvsu.ru):

3,0 m2@vvsu.ru
0 m2 < @ vvsu . ru >

.DmValue

присвоить макросу m значение Value.

.CcValue

добавить в класс c значение Value.

$m

вывести значение макроса m.

$=c

вывести значения класса c.

=Sruleset

вывести все правила набора ruleset.

=M

вывести определения всех агентов доставки.

/mx name

найти в DNS запись MX для имени name.

/tryflags флаг

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

Флаг	Интерпретация адреса
er	адрес получателя в конверте
hr	адрес получателя в заголовке
es	адрес отправителя в конверте
hs	адрес отправителя в заголовке

/parse адрес

Произвести полный разбор адреса, как если бы он был указан в поступившем на обработку сообщении. Адрес интепретировать в соответствии с установкой флага командой tryflags; по умолчанию - адрес получателя из конверта сообщения.

Выход из тестового режима - Ctrl-D.

При запуске sendmail можно указать отладочные опции, включение которых приведет к выводу дополнительной информации. Наиболее полезные опции (аргументы командной строки):

-d0.1

Вывести информацию о версии программы, опции компиляции, информацию о системе.

-d0.4

Вывести все имена и псевдонимы данного компьютера.

-d21.12

Выводить информацию о выполнении каждого правила в процессе разбора.

ПРИМЕЧАНИЕ. Для проверки в тестовом режиме наборов check_relay и check_compat необходимо использовать дополнительный набор правил (так как комбинация $| в тестовом режиме по какой-то причине воспринимается не как один, а как два токена):

STranslate
R$* $$| $*			$1 $| $2

>Translate,check_compat m2@vvsu.ru $| xhawk@mail.ru

Запуск сервера sendmail

Запуск sendmail в режиме демона выполняется командой

/usr/lib/sendmail -bd -q1h

При загрузке системы перед запуском sendmail проверяется наличие конфигурационного файла и очищается очередь почтовых сообщений (каталог /var/spool/mqueue), все эти действия в ОС Solaris заносятся в загрузочный скрипт /etc/init.d/sendmail, который вызывается в /etc/rc2 как /etc/rc2.d/S88sendmail. В других Unix-системах производятся аналогичные действия.

Управление очередью сообщений

В очередь помещаются сообщения, немедленная доставка которых по какой-либо причине не удалась. Очередь находится в каталоге /var/spool/mqueue. Просмотр очереди выполняется командой (/usr/bin/)mailq; для каждого сообщения указан его идентификатор, размер, адреса отправителя и получателя и текущий статус сообщения.

Каждое сообщение представлено в виде нескольких (обычно двух) файлов. Их имена состоят из двухсимвольного префикса, обозначающего тип файла (df - файл с письмом, qf - файл со служебными данными по обработке этого письма), и идентификатора сообщения (выводимого командой mailq). Для удаления письма из очереди (т.е. для его полной ликвидации) нудно удалить все файлы этого сообщения. Например, для удаления сообщения с идентификатором MAA12345 нужно удалить файлы dfMAA12345, qfMAA12345 и т.п.

Для внеочередной обработки сообщений, стоящих в очереди, надо подать команду

#/usr/lib/sendmail -q

Sendmail и /etc/hosts

Для работы sendmail требуется, чтобы в файле /etc/hosts наряду с коротким именем компьютера было прописано его полное имя:

212.16.195.100 athena athena.vvsu.ru 

Установка сервера POP3

Сервер POP3 под Unix реализован в виде одной программы-демона, например, программы popper. Для ее запуска необходимо внести номер порта для сервиса pop3 (порт 110/tcp) в /etc/services и соответствующую строку в /etc/inetd.conf, например:

pop3    stream  tcp     nowait  root  /usr/local/lib/popper   popper  -s

Задания

Задание 1. Отправить почтовое сообщение по адресу firekeeper@iae.nsk.su через непосредственный диалог с SMTP-сервером, предварительно установив адрес почтового сервера, который принимает почту для этого адресата.

Задание 2. Создать на своем компьютере два специальных почтовых адреса: один - список рассылки сообщений студентам группы; другой - автомат, отвечающий на каждое письмо новогодним поздравлением.

Задание 3. Обеспечить доступ к почте для пользователей своего компьютера по протоколу POP-3. Создать POP-пользователя (пользователя, который может только получать/отправлять почту и менять пароль).

Задание 4. Получить почту по протоколу POP-3 вручную.

Задание 5. На своем компьютере проанализировать политику приема сообщений для отправки через SMTP. Проверить комбинации следующих параметров: МТА-клиент находится в своем домене или в другом; в MAIL FROM указывается адрес локального пользователя, или адрес, принадлежащий нашему домену, или адрес из другого домена; получатель (RCPT TO) - локальный пользователь, или находится в нашем домене, или находится в другом домене. Найти соответствующие правила в конфигурационном файле.

Изменить политику так, чтобы через SMTP принимались только сообщения, адрес отправителя или получателя которых - локальный для вашего компьютера; при этом адрес MTA-клиента не имеет значения.

Задание 6.

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

Имеется рабочий каталог, в котором содержится файл userlist и файлы по именам пользователей. В файле userlist перечислены имена пользователей по одному на строку. После запуска агента имя пользователя, которому направлено сообщение, берется из командной строки и проверяется на наличие в файле userlist. Если проверка прошла успешно, текст сообщения считывается из стандартного ввода и помещается в конец файла, имя которого совпадает с именем пользователя (если необходимо, файл создается). Текст сообщения в файле предваряется пустой строкой, а завершается комбинацией "\n.\n".

Агент завершает работу со следующими состояниями выхода (exit status):

• EX_OK = 0 - сообщение доставлено,
• EX_NOUSER = 67 - нет такого пользователя (пользователь не найден в userlist или файл userlist отсутствует),
• EX_USAGE = 64 - неверный вызов агента (не указано имя пользователя в командной строке),
• EX_SOFTWARE = 70 - ошибка в программе агента (например, ошибка при открытии файла).

(Если состояние выхода агента не равно нулю, sendmail, запустивший этого агента, вернет отправителю соответствующее сообщение об ошибке.)

Возможные проблемы:

• Вероятно, вы решите, что ваш агент должен запускаться sendmail'ом от имени пользователя nobody. В таком случае не забудьте установить права 777 на рабочий каталог агента и, как минимум, 644 на файл userlist.
• Не забудьте в базе данных DNS внести MX-запись для своего домена, указывающую на ваш компьютер; а при конфигурировании sendmail внести имя этого домена в класс C, чтобы sendmail опознал его как локальное.

Задание 7. В файле находится список пользователей. Сконфигурировать sendmail так, чтобы в обратных адресах писем, отправленных этими пользователями, имя вашего компьютера заменялось на athena.

Партнёры:

Хостинг: