3.2.4. Протокол обмена почтой SMTP (Simple Mail Transfer Protocol)

Протокол SMTP был разработан для обмена почтовыми сообщениями в сети Internet. SMTP не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и Х.25. Достигается это за счет концепции IPCE (Inter-Process Communication Environment). IPCE позволяет взаимодействовать процессам, поддерживающим SMTP, в интерактивном режиме, а не в режиме "STOP-GO".

Модель протокола. Взаимодействие в рамках SMTP строится по принципу двусторонней связи, которая устанавливается между отправителем и получателем почтового сообщения. При этом отправитель инициирует соединение и посылает запросы на обслуживание, а получатель - отвечает на эти запросы. Фактически, отправитель выступает в роли клиента, а получатель - сервера.

Рис. 3.15. Схема взаимодействия по протоколу SMTP

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

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

Наиболее распространенной дисциплиной является отправление почтового сообщения, которое начинается по команде MAIL, идентифицирующей отправителя:

MAIL FROM: paul@quest.polyn.kiae.su

Следующей командой определяется адрес получателя:

RCPT TO: paul@apollo.polyn.kiae.su

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

DATA

Команда DATA вводится без параметров и идентифицирует начало ввода почтового сообщения. Сообщение вводится до тех пор, пока не будет введена строка с точкой в первой позиции. Согласно стандарту почтового сообщения RFC-822 отправитель передает заголовок и тело сообщения, которые разделены пустой строкой. Сам протокол SMTP не накладывает каких-либо ограничений на информацию, которая заключена между командой DATA и "." в первой позиции последней строки. Приведем пример обмена сообщениями при дисциплине отправки почты:

S:   MAIL FROM: <paul@quest.polyn.kiae.su>
R:   250 Ok
S:   RCPT TO: <dobr@kiae.su>
R:   250 Ok
S:   DATA
R:   354 Start mail input; end with <CRLF>.<CRLF>
S:   Это текст почтового сообщения
S:   .
R:   250

Другой дисциплиной, определенной в протоколе SMTP, является перенаправление почтового сообщения (forwarding). Если получатель не найден и известно его местоположение, то сервер может выдать сообщение:

R:      251 User not local; will forward to <user@domain.domain>

Если сервер может сделать только предположение о дальнейшей рассылке, то ответ будет несколько иным:

R:      551 User not local; please try <user@host.domain>

Верификация и расширение адресов составляют дисциплину верификации. В ней используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие или отсутствие указанного пользователя:

S:      VRFY paul
R:      250-Paul Khramtsov<paul@quest.polyn.kiae.su>

Используя команду EXPN, можно получить список местных пользователей:

S:      EXPN Example-People
R:      250-Paul Khramtsov<paul@quest.polyn.kiae.su>
R:      250-Vladimir Drach-Gorkunov<vovka@quest.polyn.kiae.su>

В список дисциплин, разрешенных протоколом SMTP, входит кроме отправки почты еще и прямая рассылка сообщений. В этом случае сообщение будет отправляться не в почтовый ящик, а непосредственно на терминал пользователя, если пользователь в данный момент находится за своим терминалом. Прямая рассылка осуществляется по команде SEND, которая имеет такой же синтаксис, как и команда MAIL. Кроме SEND прямую рассылку осуществляют SOML (Send or Mail) и SAML (Send and Mail).

Для инициализации канала обмена почтой и его закрытия используются команды HELO и QUIT соответственно. Первой командой сеанса должна быть команда HELO.

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

Если сообщение по какой-либо причине не может быть разослано, то получатель формирует сообщение о неразосланном сообщении:

S:      MAIL FROM:<>
R:       250 Ok
S:      RCPT TO: <@host.domain:JOE@host.domain>
R:      250 Ok
S:      DATA
R:      354 send the mail data, end with .
S:      Date 23 Oct 95 11:23:30
S:      From: SMTP@remote.domain
S:      To: <JOE@host.domain>
S:
S:      Undelivered message. Your message lost. 550 No such user.
S:      .

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

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

Для отладки или проверки соединения по SMTP можно использовать telnet. Для этого вслед за адресом машины следует ввести номер порта:

/users/local>telnet apollo.polyn.kiae.su 25

25 порт используется в Internet для обмена сообщениями по протоколу SMTP. В интерактивном режиме пользователь сам изображает клиента SMTP и может посмотреть реакцию удаленной машины на его действия.

3.2.5. Интерфейс Eudora

Интерфейс Eudora является одним из множества почтовых интерфейсов, ориентированных на работу с почтой Internet из системы MS-Windows. На примере этого интерфейса мы рассмотрим типичные проблемы, которые возникают у пользователей персональных компьютеров при подключении к почтовому сервису Internet, и пути их решения.

Первой проблемой является тот факт, что компьютер выключается из сети на время отсутствия пользователя. Это значит, что в это время прием почтовых сообщений не производится. Следовательно, вся почта должна хранится на почтовом сервере и получаться пользователем по его запросу. При работе с Unix об этом заботится программа sendmail, в MS-Windows такой программы нет (точнее есть, но она не ориентирована на Internet). Поэтому обычно применяется следующая схема (рисунок 3.16):

Рис. 3.16. Схема работы с почтовым сервером из-под MS-Windows и MS-DOS

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

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

На рисунке 3.17 приведен экран Eudora, на котором представлено меню настройки и два почтовых ящика: принятых писем и отправленных писем.

На этом рисунке в меню настроек хорошо виден POP Account - адрес пользователя на машине-сервере, SMTP-сервер и POP (Ph) сервер. Как видно из настроек, Eudora каждые 30 минут проверяет почтовый ящик пользователя и сообщает о получении новых писем. Кроме того, что Eudora позволяет читать просто письма в обычном почтовом формате Internet (RFC822), о котором пойдет речь в следующем параграфе, она распознает и новый формат, ориентированный на отображение мультимедийных почтовых сообщений MIME, который последнее время становится все более популярен в Internet.

Рис. 3.17. Интерфейс Eudora для MS-Windows

Для установки этого интерфейса требуются определенные знания и доступ к информации, которой располагает только системный администратор, поэтому предпочтительней обратиться именно к нему с просьбой об установке программы или за необходимой информацией (адреса машин серверов). Работа с Eudora чрезвычайно проста: надо выбирать при помощи мыши или клавиатуры интересующие Вас сообщения и отправлять в "корзину" то, что бесполезно.

И последнее замечание относительно работы из под MS-Windows с почтой в Internet. Если пользователь пишет только по английски, то у него нет проблем с кодировкой и набором текста, но если он пишет по русски и получает такие же сообщения, то сразу же возникают проблемы. Дело в том, что большинство почтовых сетей для обмена данными между серверами используют кодировку KOI8. Эта кодировка отличается как от кодировки для MS-DOS, так и от кодировки MS-Windows. Поэтому, возвращаясь к иллюстрации с настройками интерфейса Eudora, хочется обратить внимание читателя на поля "Send Font" и "Printer Font". В этих полях указан шрифт "Arial-Relcom", который разложен по кодировке KOI8, и используется для отображения и печати почтовых сообщений. Для того, чтобы правильно набирать сообщения, следует к стандартным раскладкам клавиатуры в драйвере клавиатуры (cyrwin, например) добавить раскладку для KOI8.

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

На этом описание существующих почтовых клиентов можно закончить, так как в наличии имеется их великое множество и описать их все в рамках этого курса нет возможности.

3.2.6. Системы почтовой рассылки (программа sendmail)

Основным средством рассылки почты в Internet является программа sendmail. Она обеспечивает работу модульной системы рассылки, которая предназначена для получения и отправки корреспонденции, а также управления программами подготовки и просмотра почтовых сообщений. Sendmail позволяет организовать почтовую службу локальной сети и обмениваться почтой с другими серверами почтовых служб через специальные шлюзы. Send-mail может быть сконфигурирована для работы с различными почтовыми протоколами. Обычно это протоколы UUCP (Unix-Unix-CoPy) и SMTP (Simple Mail Transfer Protocol).

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

Первые являются стандартными адресами Internet и фактически являются стандартом де-факто. Именно этот адрес обычно указан на визитных карточках.

Sendmail можно настроить для поддержки:

3.2.6.1. Принцип работы программы sendmail

Sendmail отправляет почту в два приема: сначала почтовые сообщения собираются в очереди, а затем отсылаются.

Каждое сообщение состоит из трех частей: конверта, заголовка и тела сообщения.

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

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

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

Sendmail может быть вызвана:

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

На рисунке 3.18 представлена схема функционирования почтового сервера на базе программы sendmail.

Рис. 3.18. Схема функционирования почтового сервера на базе программы Sendmail

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

Первый этап рассылки - сбор сообщений. Sendmail получает почтовые сообщения из трех источников:

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

При получении сообщений по протоколу SMTP, sendmail используется как программа клиента и сервера протокола. Протокол определен в RFC-821 и является основным для рассылки почты в Internet. В этом случае sendmail запускается как демон, который "слушает" порт TCP и в случае получения сообщения устанавливает соединение с удаленным клиентом SMTP. Как правило, таким клиентом является другая программа sendmail.

Программа подготовки почты на локальной машине также может использовать SMTP. Для этого sendmail открывает канал (pipe) межпроцессного обмена.

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

Вторая стадия рассылки почты - рассылка сообщений.

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

Рассылка на удаленную машину. Для вызова программы рассылки sendmail открывает pipe и запускает программу рассылки, командная строка которой находится в файле конфигурации. Sendmail записывает заголовок и тело сообщения в pipe. Если программа рассылки не использует протокол SMTP, то адрес получателя передается через pipe. Если используется SMTP, то открывается двунаправленный канал для интерактивного взаимодействия с удаленным сервером SMTP. Если в качестве транспортного протокола используется TCP, то sendmail не запускает внешнюю программу рассылки, а сама инициирует TCP-соединение с удаленным сервером SMTP.

Доставка местной почты. Если sendmail определяет, что адреса доставки местные, то происходит обращение к файлу адресных синонимов и производится преобразование адресов (расширение). Файл адресных синонимов можно использовать для перенаправления почты в файлы или для обработки местными программами. Пользователь может иметь и свой собственный файл адресных синонимов для управления рассылкой персональной почты. После преобразования адресов почта отправляется программе местной рассылки (например rmail).

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

Местные адреса имеют вид:

user
user@localhost
user@localhost.localdomain
user@alias
user@alias.localdomain
user@[local.host.internet.address]
localhost!user
localhost!localhost!user
user@localhost.uucp

Местный адрес - это адрес, который распознается как адрес на машине, с которой осуществляется отправка почты.

Адреса UUCP имеют вид:

host!user
host!host!user
user@host.uucp

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

Адреса SMTP - это адреса, описанные в стандарте RFC-822 или стандартные адреса Internet. Эти адреса имеют вид:

usr@host
usr@host.domain
<@host1,@host2,@host3:user@host4>
user@[remote.host`s.internet.address]

Почта с адресами SMTP рассылается по протоколу SMTP.

Если в системе для адресации используется BIND-сервер, то sendmail может определять адреса получателей, используя сервис BIND. Если BIND не используется, то sendmail сама определяет адреса.

При рассылке почты можно использовать и смешанную адресацию:

user%hostA@hostB - почта отправляется с машины hostB на машину hostA
user!hostA@hostB - почта отправляется с машины hostB на машину hostA
hostA!user%hostB - почта отправляется с hostA на hostB

Подводя итог под обсуждением принципов работы sendmail следует специально подчеркнуть тот факт, что почта реально рассылается двумя принципиально разными способами. При использовании протокола UUCP почта рассылается по принципу "stop-go", т.е. сообщения передаются от машины к машине по указанному в адресе пути. Следует ясно представлять, если почта ушла с машины отправителя, то это не означает, что она поступит получателю. Промежуточная машина может вернуть почту назад, если не сможет разослать. Электронная почта действительно работает как система обычной почты, физически перемещая и храня сообщения на промежуточных почтовых станциях. При работе по протоколу SMTP почта реально отправляется только тогда, когда установлено интерактивное соединение с программой-сервером на машине-получателе почты. При этом происходит обмен командами между клиентом и сервером протокола SMTP в режиме on-line. При смешанной адресации доставка почты происходит по смешанному сценарию. Как шла доставка и как маршрутизировалось сообщение можно определить из заголовка сообщения, которое вы получили.

3.2.7. Настройка программы sendmail

Настройка программы sendmail происходит при помощи файла /etc/sendmail/conf. Этот файл можно разбить на несколько частей:

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

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

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

Все команды, которые используются в файле настроек sendmail можно представить в виде следующей таблицы:
КомандаСинтаксисНазначение
Define MacroDxvalueУстановить значение x
Define ClassСсword1 word2 ...Установить значение класса c
Define ClassFcfileзагрузить значение класса из файла
Set OptionOovalueУстановить значение опции o
Trusted UsersTuser1 user2 ...Определить доверенных пользователей
Set PrecedencePname=numberДля номера ошибки number установить имя name
Define MailerMname,[field=value]Определить программу рассылки почты.
Define HeaderH[?mflag?]name:formatОпределить формат поля заголовка
Set RulsetSnНачать определение набора правил преобразования адресов
Define RuleRlhs rhs commentОпределить правило преобразования адреса.

Формат команды файла настроек sendmail не очень удобен для чтения. В целом его можно определить следующим образом:

Рис. 3.19. Структура команды файла настроек sendmail

Теперь разберем более подробно некоторые команды и секции файла настроек sendmail. Лучше всего это сделать на основе реального файла. Начнем с секции описания локальных параметров:

##################
#   local info   #
##################
Cwlocalhost
CP.
# UUCP relay host
DYucbvax.Berkeley.EDU
CPUUCP
#  BITNET relay host
#DBmailhost.Berkeley.EDU
DBrelay.kiae.su
CPBITNET
# "Smart" relay host (may be null)
DSrelay.kiae.su
# who I send unqualified names to (null means deliver locally)
DR
# who gets all local email traffic ($R has precedence for unqualified names)
DH
# who I masquerade as (null for no masquerading)
DM
# class L: names that should be delivered locally, even if we 
# have a relay
# class E: names that should be exposed as from this host, even if we 
# masquerade
#CLroot
CEroot
# operators that cannot be in local usernames (i.e., network indicators)
CO @ % !
# a class with just dot (for identifying canonical names)
C..
# dequoting map
Kdequote dequote

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

Следующая секция - определение макросов sendmail:

######################
#   Special macros   #
######################
# SMTP initial login message
De$j Sendmail $v/$Z ready at $b
# UNIX initial From header format
DlFrom $g  $d
# my name for error messages
DnMAILER-DAEMON
# delimiter (operator) characters
Do.:%@!^/[]
# format of a total name
Dq$?x$x <$g>$|$g$.
# Configuration version number
DZ8.6.6

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

Dq$?x$x <$g>$|$g$.

Здесь описана условная подстановка значения. Все предложение можно описать следующей фразой:

"Если значение переменной x установлено, то: q = значение_x <значение_g>,
иначе: q=значение_g".

То же самое можно записать и по другому:

if(x!=NULL)
        {
                strcpy(q,x);
                strcat(q," <");
                strcat(q,g);
                strcat(q,">");
        {
else
        {
                strcpy(q,g);
        }

В данном случае $? соответствует оператору if, $| - else, а $. - конец условного оператора.

Следующая секция - это определение опций:

###############
#   Options   #
###############
# strip message body to 7 bits on input?
#O7False
# Insist that the BIND name server be running to resolve names
OI
# deliver MIME-encapsulated error messages?
OjTrue

В данном случае приведен только фрагмент этой секции. Большинство параметров общие для всех установок sendmail. Указанные же в листинге параметры являются принципиальными с точки зрения режимов работы sendmail. Первый параметр определяет тот факт, что по почте можно пересылать 7-битовую информацию. Согласно RFC-822 информация должна быть 7-битовая, но для передачи кириллицы это значит использовать кодирование, что абсолютно не приемлемо. Поэтому данный параметр должен быть закомментирован. В системах, где используется сервер доменных имен, опция I должна быть установлена, чтобы не было ошибок при идентификации доменов. Последний параметр не является принципиальным, но для более понятного представления его следует установить. Если почтовый клиент не поддерживает MIME, то данный параметр следует закомментировать.

Следующие две секции определяют уровень сообщений об ошибках и доверенных пользователей:

###########################
#   Message precedences   #
###########################
Pfirst-class=0
Pspecial-delivery=100
Plist=-30
Pbulk=-60
Pjunk=-100
#####################
#   Trusted users   #
#####################
Troot
Tdaemon
Tuucp

За этими двумя секциями следует секция описания полей заголовка почтового сообщения, который генерируется программой sendmail:

#########################
#   Format of headers   #
#########################
H?P?Return-Path: $g
HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.by $j ($v/$Z)$?r 
                                    with $r$. id $i$?u for $u$.; $b
H?D?Resent-Date: $a
H?D?Date: $a
H?F?Resent-From: $q
H?F?From: $q
H?x?Full-Name: $x
HSubject:
# HPosted-Date: $a
# H?l?Received-Date: $b
H?M?Resent-Message-Id: <$t.$i@$j>
H?M?Message-Id: <$t.$i@$j>

Формат команд данной секции определяет, какие поля включаются в заголовок, а какие не включаются. Данная секция тесно связана с секцией определения программ рассылки почты. Если после "H" нет знака вопроса, то поле включается в заголовок сообщения для любой программы рассылки, если после "H" символ "?" присутствует, то в строке аргументов программы рассылки данный флаг должен быть определен для того, чтобы данное поле было включено в заголовок. Как следует из приведенного выше описания, всегда включаются только поля Recieved и Subject. Все перечисленные поля не являются обязательными полями заголовка.

Следующая секция - правила преобразования адресов. Но прежде чем обсуждать ее содержание следует сказать как и когда sendmail эти адреса преобразовывает.

Рис. 3.20. Порядок обработки адресов

Данная диаграмма представляет типовой набор блоков правил преобразования адресов. Как видно из рисунка, все адреса попадают на правила канонизации адресов (Rule Set 3). Если адреса достаточны для рассылки, то выполняется набор правил 0, в противном случае адреса анализируются на наличие в них доменной информации и, если данная информация отсутствует, то в блоке D она добавляется к адресу. Набор 1 применяется ко всем адресам отправителей, набор 2 применяется ко всем адресам получателей. Набор правил 4 - это выходной набор, который предназначен для преобразования адресов в формат программ рассылки. Ниже приведен фрагмент правил набора 3:

###  Rulset 3 -- Name Canonicalization  ###
S3
# handle null input (translate to <@> special case)
R$@                     $@ <@>
# basic textual canonicalization -- note RFC733 heuristic here
R$*<$*>$*<$*>$*         $2$3<$4>$5            strip multiple <> <>
R$*<$*<$+>$*>$*         <$3>$5                2-level <> nesting
R$*<>$*                 $@ <@>                MAIL FROM:<> case
R$*<$+>$*               $2                    basic RFC821/822 parsing

Не будем подробно разбирать все записи секции преобразования адресов, их очень много, поясним только сам механизм этого преобразования. Механизм основывается на применении так называемых token'ов и pattern'ов, образованных этими token'ами.

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

PatternЗначение
$*пусто или любое количество token'ов
$+один или более token'ов
$-точно один token
$=xлюбое количество token'ов одного класса x
$~xлюбое количество token'ов, не принадлежащих классу x
$xвсе token'ы макро x
СимволЗначение
$nToken номер n
$[name$]Каноническое имя
$>nВызвать набор правил n
$@Завершить набор правил
$:Завершить правило
$#mailer$@host$:userобразец вызова программы рассылки

Приведем пример преобразования:

XPOL    <       @       xbm11   .       BITNET  >
$+      <       @       $+      .       BITNET  >
$1      %               $2      <       @       $B              >
XPOL    %               xbm11   <       @       relay.kiae.su   >

В этом примере правило преобразования выглядит следующим образом:

R$+<@$+.BITNET>         $1%$2<@$B>

Речь идет о преобразовании адресов сообщений отправленных в BITNET.

Ниже приведен фрагмент правил набора 0, в котором определяется рассылка почты программами рассылки:

######################################
###   Ruleset 0 -- Parse Address   ###
######################################
S0
:.
# handle local hacks
R$*                $: $>98 $1
# short circuit local delivery so forwarded email works
R$+ < @ $=w . >     $: $1 < @ $2 . @ $H >      first try hub
R$+ < $+ @ $+ >         $#local $: $1              yep ....
R$+ < $+ @ >            $#local $: @ $1            nope, local address
# resolve remotely connected UUCP links (if any)
# resolve fake top level domains by forwarding to other hosts
R$*<@$+.BITNET.>$*  $: $>95 < $B > $1 <@$2.BITNET.> $3   user@host.BITNET
# forward non-local UUCP traffic to our UUCP relay
R$*<@$*.UUCP.>$*           $: $>95 < $Y > $1 <@$2.UUCP.> $3    uucp mail
# pass names that still have a host to a smarthost (if defined)
R$* < @ $* > $*     $: $>95 < $S > $1 < @ $2 > $3   glue on smarthost name
# deal with other remote names
R$* < @$* > $*      $#smtp $@ $2 $: $1 < @ $2 > $3     user@host.domain
:

За секцией преобразования адресов следует секция определения программ рассылки почты. В ней определяется локальная программа рассылки (mail), программа рассылки для выполнения (sh), и программа рассылки по SMTP.

##################################################
###   Local and Program Mailer specification   ###
##################################################
Mlocal,         P=/usr/libexec/mail.local, F=lsDFMrmn, S=10, R=20/40,
                A=mail -d $u
Mprog,          P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/,
                A=sh -c $u
S10
R<@>                    $n                 errors to mailer-daemon
R$+                     $: $>40 $1
S20
R$+ < @ $* >            $: $1              strip host part
S40
#####################################
###   SMTP Mailer specification   ###
#####################################
Msmtp,          P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n,
                L=990, A=IPC $h
Mesmtp,         P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n,
                L=990, A=IPC $h
Mrelay,         P=[IPC], F=mDFMuXa, S=11/31, R=61, E=\r\n,
                L=2040, A=IPC $h

Затем идут правила определения локального преобразования адресов для конкретных программ рассылки, в частности набор правил S11.

#  envelope sender and masquerading recipient rewriting
#
S11
R$+                     $: $>51 $1            sender/recipient common
R$* :; <@>              $@ $1 :;              list:; special case
R$*                     $@ $>61 $1            qualify unqual'ed names

В секции программ рассылки мы в нашем примере не указали еще одну важную возможность - рассылку по протоколу UUCP:

Мuucp,  P=/usr/bin/uux, F=DFMhuU,       S=13,   R=23, M=100000,
                A=uux - -r -z -a$f -gC $h!rmail

Естественно, что правила преобразования адресов S13 и R23 должны быть описаны в файле настроек sendmail.

3.2.7.1. Тестирование Sendmail и способы запуска

При работе с программой Sendmail возникает ряд ситуаций, когда необходимо протестировать работу системы рассылки электронной почты. Чаще всего это связано с тем, что программа неаккуратно работает с сервисом доменных имен. Дело в том, что определение макросов w и j связано скорее с функционированием системы в среде NIS, а не BIND, что влечет за собой определенные проблемы при идентификации программы при работе по SMTP, например.

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

Для проверки работы можно запустить sendmail с ключом -v:

quest:/usr/paul:\[1\]%sendmail -v paul@polyn.kiae.su
This is a test message.
.
paul@polyn.kiae.su... Connecting to cpuv1.net.kiae.su. (relay)...
220 cpuv1.net.kiae.su (RELCOM) ready ( Tue, 5 Nov 1996 11:46:12 +0300 )
>>> EHLO quest.net.kiae.su
500 Command unrecognized
>>> HELO quest.net.kiae.su
250 Hello quest.net.kiae.su, pleased to meet you
>>> MAIL From:<paul@quest.net.kiae.su>
250 <paul@quest.net.kiae.su>... Sender ok
>>> RCPT To:<paul@polyn.kiae.su>
250 <paul@polyn.kiae.su>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Ok
paul@polyn.kiae.su... Sent (Ok)
Closing connection to cpuv1.net.kiae.su.
>>> QUIT
221 cpuv1.net.kiae.su closing connection
quest:/usr/paul:\[2\]%

Как видно из этого примера, система выдает полную трассу взаимодействия с удаленным хостом по протоколу SMTP.

Стандартный режим запуска sendmail - это запуск в виде процесса демона в момент начальной загрузки системы:

/usr/paul>sendmail -bd -q30m

Однако, надо всегда помнить, что перед запуском в режиме демона следует создать файл ali-ases:

/usr/paul>sendmail -bi

Назад | Содержание | Вперед