Протокол SMTP

Рис. 5. SMTP протокол в терминах модели OSI

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

SMTP-системы за последнее время активно развивались в следующих направлениях:

• расширение протокола общения сервер-сервер (собственно SMTP);
• создание и улучшение протокола общения клиент-сервер (POP3, IMAP4);
• внедрение и расширение нового формата сообщений (MIME).

Начальная версия протокола SMTP поддерживала ограниченный набор команд и сервисов для приема и передачи сообщений. В последнее время был разработан его расширенный вариант (Extended или ESMTP), обеспечивающий стандартную возможность дальнейшего расширения и поддержку таких функций как подтверждение доставки (Delivery Notification Request или DNR), согласование максимального допустимого размера сообщений, передаваемых между серверами и принудительная инициация передачи накопленной почты (dequeue). Однако одной из слабых сторон на данный момент SMTP было и продолжает быть отсутствие возможности аутентификации входящих соединений, шифрования диалога и потока передачи данных между серверами.

Отсутствие средств аутентификации входящих соединений не позволило использовать SMTP для обслуживания клиентского доступа. Классическая почтовая SMTP-система требует наличия файлового доступа клиента к своему почтовому ящику для получения и работы с сообщениями. Для реализации работы в режиме клиент-сервер был создан протокол обслуживания почтового офиса (Post Office Protocol или POP). Наиболее удачной оказалась версия POP3, широко используемая в современных SMTP-системах. Наиболее продвинутые реализации поддерживают аутентификацию с шифрованием имени и пароля и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако, при использовании протокола POP3 отсутствует возможность просмотра характеристик сообщения без предварительной загрузки его на станцию клиента. Для решения проблемы просмотра и манипуляции свойствами почтового сообщения непосредственно на сервере, а также преодоления ряда других функциональных ограничений был разработан протокол IMAP4, его поддержка в большинстве коммерческих систем ожидается в ближайшем будущем. Следует заметить, что как для случая использования классического клиента (команда mail), так и для случая применения POP3 или IMAP4 отправка подготовленных клиентом сообщений требует наличия сервера SMTP. На рисунке 1.6 приведена схема представления типичной SMTP-системы, использующей как традиционный для ОС UNIX файловый метод доступа к почтовому ящику, так и доступ по протоколам POP3 и IMAP4.

Изначально SMTP-системы рассчитывались на передачу информации исключительно в текстовом виде и не были ориентированы на передачу символов национальных алфавитов, т.е. использовали 7-битный набор символов. Для решения проблемы передачи двоичных файлов был разработан стандарт UUENCODE, позволяющий внедрять предварительно преобразованные из бинарного в текстовый вид произвольные данные непосредственно в текст сообщения. Однако всеобъемлющим данный подход назвать было трудно, ибо в общем случае никакой информации о природе вложения (типе передаваемых данных и породившем их приложении) принимающая сторона не имела. По мере расширения сети Internet, усложнения программного обеспечения и активного внедрения мультимедиа назрела необходимость создания универсального формата типизации и представления двоичных данных и текста, содержащего национальные символы. Таким универсальным форматом стали многофункциональные расширения почты Internet (Multipurpose Internet Mail Extensions или MIME). Формат MIME оказался чрезвычайно удачным, поскольку в него были заложены возможности неограниченного расширения, как поддерживаемых типов данных, так и национальных кодировок.

Рис. 6. Схема типичной SMTP-системы с поддержкой POP3 и IMAP4

Сообщение SMTP, подобно сообщению X.400, использует понятия конверта и содержимого, которое в свою очередь имеет заголовок и тело. Функциональное назначение их полностью идентично. Состав полей в заголовке определяется форматом тела сообщения (UUENCODE или MIME). Ни одно поле не является обязательным, но, как правило, указываются такие поля как, кому (To:), от кого (From:) и тема (Subject:). В случае использования формата MIME, в заголовке обязательно должна присутствовать строка "MIME-Version: 1.0". Полный перечень возможных полей в заголовке сообщения SMTP содержится в RFC 2076.

Отличительной особенностью SMTP-систем является то, что в них, как правило, обеспечивается фактическая независимость процесса передачи от формата содержимого. За интерпретацию содержимого должна отвечать только клиентская программа (mail reader). Однако платой за совместимость на уровне MTA в данном случае является неэффективность передачи любых нетекстовых данных или сообщений, использующих символы национальных алфавитов, вследствие предварительной трансляции информации в текстовое представление. В зависимости от используемого алгоритма преобразования размер фактически передаваемых данных может возрасти на 30-100%.

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

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

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

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

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

Формат почтового сообщения (RFC-822)

	Date:	26 Aug 76 1429 EDT	
	From:	Jones@Registry.org	
	cc:

	
	Date:	26 Aug 76 1429 EDT	
	From:	Jones@Registry.org	
	To:	Smith@Registry.org

Поле Dateопределяет дату отправки сообщения, поле From - отправителя, а поля сс и To - получателя(ей). Чаще заголовок содержит дополнительные поля:

	Date:	26 Aug 76 1429 EDT	
	From:	George Jones<Jones@Registry.org>	
	Sender:	Secy@SHOST	
	To:	Smith@Registry.org	
	Message-ID: <4231.629.XYzi-What@Registry.org>

В данном случае поле Sender указывает, что George Jones не является автором сообщения. Он только переслал сообщение, которое получил из Secy@SHOST. Поле Message-ID содержит уникальный идентификатор сообщения и используется программами доставки почты. Следующее сообщение демонстрирует все возможные поля заголовка:

	Date:	27 Aug 76 0932	
	From:	Ken Davis <Kdavis@This-Host.This.net>
	Subject:	Re: The Syntax in the RFC	
	Sender:		KSecy@Other-host	
	Reply-To:	Sam.Irving@Reg.Organization
	To:		George Jones <Jones@Registry.org>
	cc:		Important folks:			
			Tom Softwood <Balsa@Tree.Root>,
			"Sam Irving"@Other-Host;,
			Standard Distribution:
			/main/davis/people/standard@Other-Host	
	Comment:	Sam is away on bisiness.
	In-Reply-To:	<some.string@DBM.Group>, George`s message	
	X-Special-action: This is a sample of user-defined field-names.
	Message-ID:	<4331.629.XYzi-What@Other-Host

Поле Subject определяет тему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение относится к типу "В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее ...", X-Special-action - поле, определенное пользователем, которое не определено в стандарте.

Следует сказать, что формат сообщения постоянно дополняется и совершенствуется. В RFC-1327 введены дополнительные поля для совместимости с почтой X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто встречающихся заголовков, которые не регламентированы в RFC-822. Так первое предложение заголовка, которое начинается со слова From, содержит UUCP-путь сообщения, по которому можно определить, через какие машины сообщение "пробиралось". Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты.

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

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

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

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

DATA

Команда DATA вводится без параметров и идентифицирует начало ввода почтового сообщения. Сообщение вводится до тех пор, пока не будет введена строка с точкой в первой позиции. Согласно стандарту почтового сообщения RFC822 отправитель передает заголовоки тело сообщения, которые разделены пустой строкой. Сам протокол 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 и может посмотреть реакцию удаленной машины на его действия.

Адресация в SMTP-системах

В системах на базе SMTP используется интуитивно понятная, простая и одновременно очень мощная иерархическая схема адресации, аналогичная той, что принята в службе имен Internet (Domain Name Services или DNS). Данная схема может обеспечить уникальность адреса практически неограниченному числу пользователей. Почтовый адрес SMTP записывается в следующем виде:

	mailbox@domain

Сочетание имени и домена образует уникальный идентификатор пользователя. Почтовый домен хранит полную информацию о положении системы в иерархии почтового пространства организации. Каждый следующий уровень иерархии отделяется от предыдущего точкой. Разбор имени домена выполняется справа налево. Самый верхний уровень (top level), называемый корневым доменом (root domain), соответствует либо типу организации (com - для коммерческой, gov- для государственной, org - для общественной и т.п.), либо географическому региону (стране) (ru - для России, fr - для Франции и т.д.). Следующими в иерархии идут домены первого уровня (first level), как правило, представляющие имя организации. Регистрацией имен доменов первого уровня занимается международный центр Internet (Internet Network Information Center или InterNIC). За назначение имен доменов более низкого уровня чаще всего отвечают сами компании. Поскольку организациям не запрещается регистрировать для собственных нужд несколько параллельных доменов (например, CIT.MSK.RU и CIT.COM), пользователь может иметь более одного SMTP-адреса. Кроме того, современные SMTP-системы зачастую позволяют назначать псевдонимы для самого почтового ящика (например JohnDoe@CIT.MSK.RU и JonnyD@CIT.MSK.RU).

Рисунок 8 наглядно поясняет принципы SMTP-адресации.

Рис. 8. Иерархическая схема адресации SMTP

В приведенном примере CIT.MSK.RU является субдоменом MSK.RU, который в свою очередь является субдоменом RU. Компания CIT имеет два зарегистрированных имени, и каждый пользователь может иметь два почтовых адреса.

Маршрутизация

Для того, чтобы SMPT-сервер доставил почту на имя адресата JohnDoe@CIT.MSK.RU, ему предварительно нужно узнать IP-адрес машины, обслуживающей почтовый домен CTI.MSK.RU, обратившись с соответствующим запросом к серверу DNS. В службе имен DNS предусмотрен специальный тип ресурсной записи для обслуживания такого рода запросов - MX или Mail Exchanger, т.е. сервер выполняющий обмен почтовыми сообщениями от имени домена. Упомянутая запись имеет следующий формат:

	domain MX [cost] hostname

Таким образом, чтобы доставить сообщение на имя адресата JohnDoe@CIT.MSK.RU, сначала будет выполнен запрос к серверу DNS на получение списка ресурсных записей с типом MX. Если список не пуст, по имени компьютера с наименьшим значением стоимости доставки будет получен его адрес (опять же через DNS), после чего будет установлено соединение и отправлена почта. Если для домена CIT.MSK.RU нет MX-записи, домен будет трактоваться как имя компьютера. Будет выполнена попытка получить его IP-адрес и доставить сообщение напрямую.

Несмотря на то, что служба имен DNS полагается источником статической информации, маршрутизация сообщений SMTP в Internet может рассматриваться как динамическая, так как следующая точка маршрута (теоретически) должна определяться заново для каждого сообщения.

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

Согласно терминологии, принятой в Internet, SMTP-сервер может выступать в одной (или нескольких) из следующих ролей:

• mail exchanger - компьютер, непосредственно подключенный к Internet и выполняющий доставку сообщений напрямую адресатам внутри организации, к которой он принадлежит. В организации может быть несколько таких компьютеров с различными или одинаковыми значениями показателя стоимости доставки;
• relay - компьютер, выполняющий прием почтового трафика от лица других доменов, не имеющих непосредственного и/или постоянного подключения к Internet и, как правило не принадлежащий к организациям, чьи домены он обслуживает. Как косвенно следует из вышесказанного, для каждого отдельного домена может быть определено не более одного relay-сервера;
• smart host - компьютер, который способен осуществлять пересылку сообщений на основе собственной статической таблицы маршрутизации. Одной из функций smart host является переписывание на конверте адреса получателя и/или отправителя перед осуществлением дальнейшей передачи сообщения.

Большинство современных реализаций SMTP-серверов позволяют сочетать все перечисленные функции на одном компьютере.