Рис. 4.1. Организация и функционирование службы электронной почты
Курс "Технологии Интернет", Лабораторный практикум
Кафедра КТС
Максим Мамаев
См. архив на Уране.
В этой теме изучается организация и конфигурирование сервера электронной почты. Рассматривается служба электронной почты на основе протокола SMTP, известная также как Internet Mail.
Электронная почта - это служба пересылки сообщений между зарегистрированными адресами. Изначально речь идет только о текстовых сообщениях в узком смысле; о пересылке двоичного содержимого см. п. "Структура email-сообщения". Под текстовыми сообщениями в узком смысле понимаются сообщения, состоящие из строк ограниченной длины, каждая строка состоит из алфавитно-цифровых символов базового набора ASCII и знаков препинания (такие сообщения также называют 7-битовыми). Символы с 8-битовыми кодами (например, кириллица) в этот набор не входят.
Адрес электронной почты состоит выглядит как
почтовый_ящик@почтовый.домен
m2@vvsu.ru
Sidor.Ivanov@athena.vvsu.ru
где почтовый.домен - некое доменное имя, а почтовый_ящик - имя-идентификатор корреспондента. Почтовый ящик может соответствовать одному человеку, группе людей,
официальному почтовому адресу, автомату-обработчику и т.д. - форма адреса от этого не зависит. Далее в этом пункте будем считать, что почтовые ящики являются персональными. Почтовый домен - это доменное имя, для которого в системе DNS существует запись типа MX (см. тему "DNS"), либо запись типа A, если MX отсутствует.
Компьютер, на который указывает запись MX, является почтовым сервером для данного почтового домена. Вся почта, направленная на адреса в данном почтовом домене, поступает на этот сервер, которые принимает решение о том, как дальше поступить с этой почтой, см. ниже.
Основную роль в системе электронной почты играют программы трех типов:
Взаимодействие этих программ и работа системы электронной почты представлены на рисунке 4.1.
Транспортный агент работает, как правило, на почтовом сервере. Транспортный агент функционирует как маршрутизатор почтовых сообщений. Его функции следующие:
Агент доставки производит доставку сообщения каким-либо специфическим способом. Существует несколько стандартных типов агентов доставки:
Вообще методы доставки (и, соответственно, агенты) могут быть разнообразными: например, сохранение письма в базе данных; пересылка письма по факсу и т.д. Выбор агента доставки для каждого конкретного письма производится транспортным агентом в соответствии с заданной конфигурацией транспортного агента и адресом назначения письма.
Пользовательский агент является оболочкой пользователя для работы с электронной почтой, его функции:
Рассмотрим работу службы электронной почты на примере (рис. 4.1).
Пусть почтовый сервер, изображенный на рисунке, имеет адрес m.vvsu.ru и сконфигурирован для приема почты с адресами типа некто@cts.vvsu.ru. Соответственно, в базе данных DNS для зоны vvsu.ru есть запись вида
cts.vvsu.ru. IN MX 10 m.vvsu.ru.
Пусть также пользователь, изображенный на рисунке, имеет адрес ivanov@cts.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.
Базовая структура сообщения электронной почты определена в 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
в то время как в заголовке сообщения могут быть перечислены все адресаты (а могут и не быть - если письмо направлено на список рассылки типа my_friends@vvsu.ru, который состоит из вышеназванных адресов; тогда в заголовке будет адрес списка рассылки. См. также "Псевдонимы, списки рассылки и форвардинг").
Вообще, переписывание заголовков и формирование конверта зависит от конфигурации траспортного агента и здесь имеется большой выбор разных вариантов и причин для отличия адресов в конверте от адресов в заголовках. Общее правило: конверт содержит информацию, необходимую для доставки сообщения через сеть; заголовки - информацию для транспортного и пользовательского агентов и самого пользователя.
Ниже рассмотрены распространенные заголовки, кроме заголовков, добавленных спецификацией MIME.
From: ivanov@a.ru
Reply-To: real_ivanov@a.ru
To: sidorov@vvsu.ru, "Petr Petrov" <petrov@vvsu.ru>
Сс: "Jonh Smith" <john@smith.a.com>, <sidorenko@c.ru>
Bcc: "Fox Mulder" <mulder@fbi.gov>
Subject: Happy New Year!
Date: Sat, 15 Jan 2000 17:25:32 +1000
Message-ID: <3.0.6.32.20000104175623.007badf0@mail.a.ru>
Received: ...
В большинстве писем встречаются заголовки, начинающиеся на "X-", это дополнительные заголовки, не определяемые стандартом. Например заголовок "X-Mailer:" содержит информацию о пользовательком агенте, отправившем письмо.
При пересылке (форвардинге) сообщения другому получателю в заголовки могут быть добавлены поля с префиксом "Resent-" ("Resent-From:", "Resent-To:", "Resent-Date" и т.п.). Эти поля содержат информацию, вставленную тем, кто произвел форвардинг. Например, поле "From:" содержит адрес первоначального отправителя, а "Resent-From:" - адрес того, кто переслал это сообщение. При таком способе форвардинга тело сообщения не изменяется, только добавляются заголовки. Другой метод форвардинга описан в следующем пункте при обсуждении типа данных message/rfc822.
MIME
MIME (Multipurpose Internet Mail Extensions - многоцелевые расширения почты Интернет) - спецификации, определяющие дополнения в формате почтовых сообщений для
Для выполнения указанных задач вводятся дополнительные заголовки "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 - для определения типа данных, пересылаемых между сервером и броузером.
Content-Type: text/plain; charset=koi8-r
Если заголовок "Content-Type:" отсутствует, то считается, что это
Content-Type: text/plain; charset=us-ascii
Content-Type: image/jpeg; name="portrait.jpg"
Content-Type: audio/x-realaudio; name="song.ra"
Content-Type: video/mpeg; name="movie.mpeg"
Content-Type: application/msword; name="my_file.doc"
Content-Type: multipart/mixed; boundary="------------CED5632469"
При разграничении разделов в теле сообщения, значение boundary предваряется двумя минусами (т.е. в данном примере вместо 12 минусов будет 14). Каждый раздел состоит из заголовков и тела (данных); заголовки отделены от данных пустой строкой. Заголовки раздела - "Content-Type:" и "Content-Transfer-Encoding:" - определяют тип данных раздела и их представление. Пример почтового сообщения из нескольких разделов со всеми заголовками см. в конце пункта.
Content-Type: message/rfc822
Тип данных message может применяться и в заголовке "Content-Type:" раздела multipart-сообщения; это означает, что тело раздела представляет собой email-сообщение. Полные примеры сообщений см. в конце пункта.
Заголовок "Content-Transfer-Encoding:" определяет представление данных в теле сообщения (раздела). Возможные значения:
Предполагается что это кодировка используется для текстов, которые состоят в основном из символов латиницы, цифр и знаков препинания, с незначительными вкраплениями других символов.
Можно разрабатывать и использовать также нестанданртные представления; их наименования обязаны начинаться с символов "x-"
Примеры почтовых сообщений с заголовками
1. Сообщение, состоящее из двух частей. Первая часть - текст на русском языке в кодировке КОИ-8; при создании письма этот текст был введен как собственно текст письма. Вторая часть создана почтовой программой как attachment, содержащий файл test.jpg. Файл test.jpg, названный так умышленно, состоит из шести символов "abcdef"; тем не менее почтовая программа, основываясь на расширении, интерпретировала его как JPEG-файл, выставила соответствующий Content-Type и провела кодировку содержимого как двоичных данных по base64 (получилось "YWJjZGVm").
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--
Для пересылки почтовых сообщений через Интернет между транспортными агентами и от MUA к MTA (см. рис. 4.1) используется протокол SMTP (Simple Mail Transfer Protocol).
Номер порта сервера SMTP - TCP/25. После установления соединения с клиентом сервер ожидает ввода команд и данных в текстовом виде. Строчные и прописные буквы в командах не различаются. Реакция сервера заключается в трехзначном числовом коде, снабженном текстовым комментарием.
Числовой код предназначен для автоматической обработки ответов сервера программой-клиентом. Код, начинающийся на 2, является положительным ответом, на 3 - промежуточным положительным откликом (т.е. после ввода команды ожидаются дополнительные данные), коды вида 5хх сигнализируют об ошибке.
Основные команды SMTP:
HELO hostname
MAIL FROM: email_адрес_от_кого
RCPT TO: email_адрес_кому
DATA
VRFY email_адрес
EXPN email_addr
RSET
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 (Post Office Protocol) используется для пересылки новой почты пользователя с сервера на рабочую станцию пользователя. В настоящий момент используется версия 3; по набору команд она несовместима с предыдущими версиями.
Номер порта сервера POP - TCP/110. После установления соединения с клиентом сервер ожидает ввода команд и данных в текстовом виде. Строчные и прописные буквы в командах не различаются. Реакция сервера - строка начинающаяся с метки "+OK" или "-ERR", за которой следует текстовый комментарий и, если команда это подразумевает, с новой строки выводятся данные (текст сообщения или листинг сообщений). Вывод данных заканчивается строкой, содержащей только символ "." ("точка"). Если среди данных есть такая строка, то точка в этой строке удваивается.
Команды POP-3:
USER имя_пользователя
PASS пароль
STAT
LIST n
RETR n
DELE n
LAST
TOP n m
RSET
NOOP
QUIT
Программа 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
#/usr/lib/sendmail -bt
#/usr/bin/newaliases
#/usr/bin/mailq
%/usr/lib/sendmail sidorov@vvsu.ru
Основные задачи администратора при работе с 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 по обработке заголовков почтовых сообщений и определению способов и путей доставки сообщений определяются конфигурационным файлом /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 имеется множество макросов, трактуемых предопределенным образом. Значения этим макросам могут присваиваться как автоматически программой, так и явно записываться в конфигурационном файле. Ниже приведены примеры, полный список и справки см. в литературе.
Классы
C - определить класс, то есть набор значений, например,
Cwlocalhost mail.vvsu.ru vvsu.ru
После С непосредственно следует имя класса (один символ; в данном случае - w; строчные и прописные буквы различаются), за которым непосредственно следует первое значение из класса (последовательность символов; в данном случае - localhost), далее, разделенные пробелами, - остальные значения. В последних версиях sendmail (начиная с 8.7) имя класса может состоять из нескольких символов; в этом случае оно берется в фигурные скобки.
Значения класса могут быть считаны из файла. Директива
FU /etc/mail/file
берет значения класса U из файла /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 как программу, то набор правил аналогичен функции. При вызове на вход ему подается некоторое рабочее пространство, которое становится рабочим пространством первого правила данного набора. После завершения работы одного правила его рабочее пространство подается на вход следующего правила данного набора. Набор правил возвращает как результат своей работы рабочее пространство последнего отработавшего правила. См. также п. "Порядок применения наборов правил" ниже.
В левой части правил, помимо токенов с буквальным текстом, могут встречаться регулярные выражения:
Пример:
R$+.vvsu.ru vvsu.ru
Это правило для адресов из домена vvsu.ru исключает из рабочего пространства все, кроме собственно имени домена.
В правой части правила, помимо буквального текста, могут встречаться специальные операторы. Некоторые из них ниже:
R$*. $1
это правило удаляет все точки с конца рабочего пространства, если они там есть: $1 производит подстановку 1-го регулярного выражения из левой части ($*), которая соответствует всему рабочему пространству за исключением замыкающей точки, после этого рабочее пространство опять сравнивается с шаблоном.
R$* <@$-.vvsu.ru> $* $1 <@vvsu.ru> $3
это правило изымает из доменной части почтового адреса имя хоста. (Угловые скобки являются результатом фокусировки - операции, отделяющей имя пользователя от почтового домена - см. ниже п. Порядок применения наборов правил)
R$* $: <$1>
(иначе возник бы бесконечный цикл).
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"
За в этом случае $@ следует код ошибки (5.1.2 - плохой адрес получателя, 5.1.8 - плохой адрес отправителя), за $: следует текстовый комментарий ситуации.
Существуют базовые наборы правил 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_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
Пример этого набора см. в литературе. Этот набор правил решает, открывать ли вообще SMTP-сеанс для данного агента.
Набор правил check_compat вызывается непосредственно перед передачей сообщения агенту доставки (все адреса уже преобразованы и дефокусированы; произведено раскрытие псевдонимов из /etc/mail/aliases и .forward). В качестве рабочего пространства в набор подаются адреса отправителя и получателя, разделенные символами "$|":
m2@vvsu.ru $| god@heavens.com
Пример этого набора см. в литературе. Этот набор правил решает, разрешена ли доставка сообщения, основываясь не на одном адресе, а на паре адресов отправитель-получатель. Набор вызывается не только при выборе агента SMTP, но и при выборе любого другого агента доставки.
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 с новым конфигурационным файлом рекомендуется провести тестирование измененных наборов правил. С помощью команды
/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.CcValue$m$=c=Sruleset=M/mx name/tryflags флаг
Флаг Интерпретация адреса er адрес получателя в конверте hr адрес получателя в заголовке es адрес отправителя в конверте hs адрес отправителя в заголовке
/parse адресВыход из тестового режима - Ctrl-D.
При запуске sendmail можно указать отладочные опции, включение которых приведет к выводу дополнительной информации. Наиболее полезные опции (аргументы командной строки):
-d0.1-d0.4-d21.12ПРИМЕЧАНИЕ. Для проверки в тестовом режиме наборов check_relay и check_compat необходимо использовать дополнительный набор правил (так как комбинация $| в тестовом режиме по какой-то причине воспринимается не как один, а как два токена):
STranslate
R$* $$| $* $1 $| $2
("$$" обозначает собственно знак доллара). Набор Translate должен вызываться непосредственно перед check_relay или check_compat. Пример проверки check_compat в тестовом режиме:
>Translate,check_compat m2@vvsu.ru $| xhawk@mail.ru
Запуск sendmail в режиме демона выполняется командой
/usr/lib/sendmail -bd -q1h
где "-q1h" - периодичность обработки сообщений, поставленных в очередь (1 час); допускаются значения и в минутах, например, "-q15m".
При загрузке системы перед запуском 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 наряду с коротким именем компьютера было прописано его полное имя:
212.16.195.100 athena athena.vvsu.ru
Сервер 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".Далее при выполнении задания используется доменная система, созданная при выполнении задания 8 темы 2. Сконфигурировать sendmail на ares-N так, чтобы он получал почту для адресов user@ваш_домен.cts-class.vvsu.ru, где ваш_домен - один из доменов "","d2","d3","d5","d5", за который ваш компьютер первично отвечает. Вся почта, направленная на такие адреса, должна быть передана написанному вами агенту доставки. При этом, разумеется, адреса user@ares-N.vvsu.ru должны работать как обычно.Агент завершает работу со следующими состояниями выхода (exit status):
(Если состояние выхода агента не равно нулю, sendmail, запустивший этого агента, вернет отправителю соответствующее сообщение об ошибке.)
- EX_OK = 0 - сообщение доставлено,
- EX_NOUSER = 67 - нет такого пользователя (пользователь не найден в userlist или файл userlist отсутствует),
- EX_USAGE = 64 - неверный вызов агента (не указано имя пользователя в командной строке),
- EX_SOFTWARE = 70 - ошибка в программе агента (например, ошибка при открытии файла).
Возможные проблемы:
Задание 7. В файле находится список пользователей. Сконфигурировать sendmail так, чтобы в обратных адресах писем, отправленных этими пользователями, имя вашего компьютера заменялось на athena.