SMTP

Электронная почта (e-mail), несомненно, одно из самых популярных приложений. [Caceres et al. 1991] показывает, что примерно половина всех TCP соединений занята передачей почтовых сообщений с исполььзованием простого протокола передачи почты (SMTP - Simple

Mail Transfer Protocol). (С точки зрения количества переданных байт, по FTP соединениям передается значительно больше данных.) [Paxson 1993] обнаружил, что среднее почтовое

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

На рисунке 28.1 показан обмен почтой с использованием TCP/IP.

Рисунок 28.1 Доставка электронной почты в Internet.

Пользователи общаются с пользовательскими агентами (user agent). В настоящее время

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

пользовательские агенты для Unix это MH, Berkeley Mail, Elm и Mush.

Обмен почтой с использованием TCP осуществляется посредством агентов передачи сообщений (MTA - message transfer agent). Наиболее распространенные MTA для Unix систем это Sendmail. Пользователи обычно не общаются с MTA. В задачу системного администратора входит установка локального MTA.

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

пользовательских агентов.

RFC 821 [Postel 1982] описывает протокол SMTP. А именно то, как два MTA общаются друг с другом по TCP соединению. RFC 822 [Crocker 1982] приводит формат сообщения электронной почты, которое передается между двумя MTA в соответствии с RFC 821.

Протокол SMTP

При общении между двумя MTA используется NVT ASCII. Команды посылаются клиентом серверу, а сервер отвечает с помощью цифровых кодов и опциональных текстовых строк

(для чтения человеком). Это несколько напоминает сценарий, который мы видели для FTP в предыдущей главе.

Клиент может послать серверу небольшое количество команд: меньше дюжины. (Для

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

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

Простой пример

Пошлем простое сообщение размером в одну строку и посмотрим, как осуществляется SMTP соединение. Для этого воспользуемся нашим пользовательским агентом с флагом -v,

который передается транспортному агенту почты (Sendmail в данном случае). Когда указан этот флаг, MTA отображает все, что посылается и принимается по SMTP соединению.

Строки, начинающиеся с >>>, это команды, посылаемые SMTP клиентом, а строки, начинающиеся с 3-циферного кода отклика, приходят от SMTP сервера. Ниже приводится интерактивная сессия:

(Sendmail)

Connecting to mailhost via ether...

Trying 140.252.1.54... connected.

220 noao.edu Sendmail 4.1/SAG-noao.G89 ready at Mon, 19 Jul 93 12:47:34 MST

>>> HELO sun.tuc.noao.edu.

250 noao.edu Hello sun.tuc.noao.edu., pleased to meet you

>>>MAIL From:<rstevens@sun.tuc.noao.edu> 250 <rstevens@sun.tuc.noao.edu>... Sender ok

>>>RCPT To:<rstevens@noao.edu>

250 <rstevens@noao.edu>... Recipient ok

>>> DATA

354 Enter mail, end with "." on a line by itself

>>> .

250 Mail accepted

>>> QUIT

221 noao.edu delivering mail

rstevens@noao.edu... Sent

sent. это вывод от пользовательского агента

Для отправки почты было использовано всего пять SMTP команд: HELO, MAIL, RCPT, DATA и

QUIT.

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

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

Клиент осуществляет активное открытие на TCP порт 25, после чего ожидает приветственного сообщения (отклик с кодом 220) от сервера. Ответ сервера должен

начинаться с полного имени домена хоста сервера: noao.edu в данном примере. (Обычно вместе с цифровым кодом отклика возвращается необязательный текст. Здесь требуется имя домена.)

Затем клиент идентифицирует себя с использованием команды HELO. В качестве аргумента указывается полное имя домена хоста клиента: sun.tuc.noao.edu.

Команда MAIL идентифицирует автора сообщения (или отправителя). Следующая команда, RCPT, идентифицирует получателя. Если сообщение предназначено нескольким

получателям, может быть исполнено несколько команд RCPT.

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

На рисунке 28.2 приведена временная диаграмма SMTP соединения между отправителем

SMTP (клиент) и получателем SMTP (сервер). Мы удалили все связанное с установлением и

разрывом соединения, а также объявления размера окна.

В этом примере пользовательский агент отправляет сообщение длиной в одну строку ("1, 2, 3."), однако в сегменте 12 передается 393 байта данных. Следующие 12 строк включают в себя 393 байта, которые были посланы клиентом:

Received: by sun.tuc.noao.edu. (4.1/SMI-4.1)

id AA00502; Mon, 19 Jul 93 12:47:32 MST Message-Id: <9307191947.AA00502@sun.tuc.noao.edu.> From: rstevens@sun.tuc.noao.edu (Richard Stevens) Date: Mon, 19 Jul 1993 12:47:31 -0700

Reply-To: rstevens@noao.edu X-Phone: +1 602 676 1676

X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rstevens@noao.edu

Subject: testing 1, 2, 3.

Рисунок 28.2 Принцип доставки почты SMTP.

MTA добавляет первые три строки, а также Received: и Message-Id:, а следующие девять строк генерируются пользовательским агентом.

SMTP команды

Минимальные SMTP реализации поддерживают восемь команд. Мы видели пять из них в предыдущем примере: HELO, MAIL, RCPT, DATA и QUIT.

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

Команда VRFY позволяет клиенту попросить отправителя проверить адрес получателя, не отправляя ему почту. Этим часто пользуются системные администраторы, чтобы вручную определить проблемы с доставкой почты. Мы увидим, как это делается, в следующем

разделе.

Команда NOOP не делает ничего, однако заставляет сервер ответить, что все нормально, а именно откликом с кодом 200.

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

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

Версия 8 Sendmail в 4.4BSD больше не обрабатывает одинаково эти две команды. VRFY не расширяет псевдонимы и не отслеживает файлы .forward.

Команда TURN позволяет клиенту и серверу поменяться ролями, чтобы послать почту в обратном направлении, не разрывая TCP соединение и не создавая новое. (Sendmail не

поддерживает эту команду.) Существуют еще три команды (SEND, SOML и SAML), которые

очень редко реализуются и призваны заменить собой команду MAIL. Эти три команды в своих комбинациях позволяют доставлять почту непосредственно на пользовательский терминал

(если пользователь находится терминалом в системе) или складывать ее в почтовый ящик

получателя.

Конверты, заголовки и тело

Электронная почта состоит из трех частей.

1.Конверт используется MTA для доставки. В нашем примере конверт был указан двумя

SMTP командами:

MAIL From:<rstevens@sun.tuc.noao.edu>

RCPT To:<rstevens@noao.edu>

RFC 821 определяет содержимое и интерпретацию конверта, а также протокол,

который используется для обмена почтой по TCP соединению.

2.Заголовки используются пользовательскими агентами. В примере мы видели девять

полей заголовков: Received, Message-Id, From, Date, Reply-To, X-Phone, X-Mailer, To и Subject. Каждое поле заголовка содержит имя, после которого следует двоеточие, а затем следует значение этого поля. RFC 822 определяет формат и интерпретацию

полей заголовка. (Заголовки, начинающиеся с X-, это поля, определяемые пользователем. Другие определены в RFC 822.) Длинные поля заголовков, такие как

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

строки начинаются с пробела.

3.Тело это содержимое сообщения от отправителя к получателю. RFC 822 определяет тело сообщения как текстовые строки в формате NVT ASCII. Когда происходит

передача с использованием команды DATA, заголовки передаются первыми, за ними

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

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

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

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

Содержимое посылается клиентом с использованием команды DATA.

Транслирующие агенты

Первая информационная строка от локального MTA в примере была следующей: "Connecting to mailhost via ether".

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

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

в роли почтового ретранслятора, возможно пряча тем самым все остальные индивидуальные

системы.

В нашем примере транслирующая система имеет имя хоста mailhost в локальном домене

(.tuc.noao.edu), а все индивидуальные системы сконфигурированы таким образом, чтобы

посылать свою почту на этот хост. Мы можем исполнить команду host, чтобы посмотреть, как это имя определено в DNS:

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

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

Большинство организаций в настоящее время используют транслирующие системы. На рисунке 28.3 показана упрощенная схема почты в Internet (рисунок 28.2), причем сделано

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

Между отправителем и получателем присутствует четыре MTA. Локальный MTA на хосте

отправителя просто доставляет почту на свой транслирующий MTA. (Этот транслирующий MTA должен иметь имя mailhost в домене организации.) Здесь SMTP использует локальные сети организации. Затем транслирующий MTA организации отправителя посылает почту по

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

могут встретиться и другие протоколы доставки.

NVT ASCII

Одна из характеристик SMTP заключается в том, что он использует NVT ASCII абсолютно везде: в конверте, заголовке и теле сообщения. Как мы сказали в разделе "Протокол

Telnet" главы 26, NVT ASCII это 7-битная кодировка символов, символы при этом передаются как 8-битные байты, у которых старший бит установлен в 0.

Рисунок 28.3 Электронная почта по Internet с транслирующими системами на обоих концах.

В разделе "Будущее SMTP" этой главы мы обсудим некоторые более новые характеристики

почты в Internet, расширенный SMTP и мультимедийную почту (MIME), которая позволяет

отправлять и принимать звуковую и видео информацию. Мы увидим, что MIME использует NVT ASCII в качестве конверта, заголовка и тела, а изменения касаются только пользовательских агентов.

Интервалы между ретрансляциями

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

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

Требования к хостам Host Requirements RFC рекомендует устанавливать первоначальный

тайм-аут по крайней мере в 30 минут. Отправитель должен повторять свои попытки по меньшей мере 4-5 дней. Более того, если сбои в доставке происходят часто (получатель

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

Примеры SMTP

В предыдущем разделе показана обычная доставка почты; сейчас рассмотрим, как для доставки почты записи используются MX, а также проиллюстрируем работу команд VRFY и

EXPN.

Записи MX: хост не подключен непосредственно к Internet

В разделе "Записи ресурсов" главы 14 мы сказали, что один из типов записи ресурса в DNS используется для обмена почты и называется записями MX. В следующем примере мы

покажем, как используются записи MX, для отправки почты на хосты, не подключенные к

Internet непосредственно. RFC 974 [Partridge 1986] описывает, как MTA обрабатывает записи

MX.

Хост mlfarm.com не подключен к Internet, однако имеет MX запись, указывающую на

перенаправителя почты, который, в свою очередь, находится в Internet:

Здесь показаны две записи MX, каждая с различной степенью предпочтительности. Мы

ожидаем, что MTA начнет с меньшего из двух значений предпочтительности.

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

MTA определил, что хост назначения имеет MX запись и использует MX запись с минимальным значением предпочтительности.

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

видим обмен почтой с хостом назначения. Также в конфигурации было сказано использовать DNS сервер на хосте noao.edu (к которому можно получить доступ через SLIP канал с дозвоном). Благодаря этому, с использованием tcpdump, мы можем посмотреть и передачу почты, и DNS траффик на SLIP канале. На рисунке 28.4 показана начальная часть вывода

команды tcpdump.

Рисунок 28.4 Посылка почты на хост, который использует MX записи.

В строке 1 MTA запрашивает свой DNS сервер о MX записи для mlfarm.com. Знак плюс,

следующий за 2, означает, что установлен флаг "необходима рекурсия". Отклик в строке 2

имеет установленным бит полномочности (звездочка, следующая за 2) и содержит 2 записи ресурса (RR) ответа (два имени MX хостов), 0 записей ресурса RR прав доступа и две дополнительные RR (IP адреса двух хостов).

В строках 3-5 устанавливается TCP соединение с SMTP сервером на хосте mercury.hsi.com. Первоначальный отклик сервера (220) показан в строке 6.

Каким-либо образом хост mercury.hsi.com должен доставить это почтовое сообщение в пункт назначения - mlfarm.com. Протокол UUCP является распространенным способом обмена

почтой с MX узлами для систем, которые не подключены к Internet.

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

указывает, что MTA должен сначала запросить MX записи, и если они не найдены, попробовать доставить почту на хост назначения (то есть запросить DNS на предмет записи A для хоста, его IP адрес). MTA должен также поинтересоваться записями CNAME в DNS

(канонические имена).

Например, если мы пошлем почту хосту rstevens@mailhost.tuc.noao.edu с BSD/386 хоста, MTA

(Sendmail) проделает следующее.

1.Sendmail запрашивает DNS, существуют ли записи CNAME для хоста mailhost.tuc.noao.edu. Мы видим, что записи CNAME существуют:

sun % host -t cname mailhost.tuc.noao.edu mailhost.tuc.noao.edu CNAME noao.edu

2.Делается DNS запрос о существовании записи CNAME для noao.edu, в отклике сообщается, что записи не существует.

3.Затем Sendmail запрашивает DNS о существовании MX записей для noao.edu и

получает одну MX запись:

sun % host -t mx noao.edu noao.edu MX noao.edu

4.Sendmail запрашивает DNS о существовании записей A (IP адрес) для noao.edu и получает значение 140.252.1.54. (Возможно, эта A запись была возвращена DNS

сервером для noao.edu как дополнительная запись ресурса (RR) с MX откликом в шаге

3.)

5.Открывается SMTP соединение на адрес 140.252.1.54, и почта отправляется.

Запрос CNAME не осуществляется для данных, возвращенных в MX записи (noao.edu). Данные в MX записи не могут быть псевдонимами - они должны быть именем хоста, который имеет запись A.

Версия Sendmail, распространяемая с SunOS.4.1.3, обращается к DNS только с запросами о существовании MX записей и сразу прекращает все попытки, если MX запись не найдена.