Далее идут сообщения в настоящей двоичной кодировке. К ним относятся произвольные двоичные файлы, которые не только используют все 8 бит, но и не соблюдают ограничение на 1000 символов в строке. К этой категории относятся исполняемые программные файлы. Сегодня почтовые серверы могут проверять, есть ли возможность переслать данные в бинарной (или 8-битной) кодировке, и если это расширение не поддерживается на обеих сторонах, данные будут передаваться в ASCII.
Кодировка бинарных данных в формате ASCII называется 64-символьной кодировкой (base64 encoding). При использовании данного метода группы по 24 бита разбиваются на четыре единицы по 6 бит, каждая из которых передается в виде обычного разрешенного ASCII-символа. В этой кодировке 6-битный символ 0 кодируется ASCII-символом A, 1 — ASCII-символом B и т.д. Затем следуют 26 строчных букв, затем 10 цифр и, наконец, + для кодирования 62 и / для 63. Последовательности == и = говорят о том, что последняя группа содержит только 8 или 16 бит соответственно. Символы перевода строки и возврата каретки игнорируются, поэтому их можно вставлять в любом месте закодированного потока символов, чтобы строки были достаточно короткими. Таким способом можно передать любой двоичный код, хотя и не слишком эффективно. Эта кодировка была крайне популярна до того, как стали широко применяться почтовые серверы, способные передавать бинарную информацию. Она часто встречается и сегодня.
Особый интерес представляет последний заголовок на илл. 7.14, Content-Type: (Тип содержания). В нем указан тип тела сообщения. Применение этого заголовка выходит далеко за пределы электронной почты. Например, контент, загружаемый из интернета, получает метку MIME-типа, что позволяет браузеру корректно отображать информацию. Так же обстоит дело с данными, которые передаются через потоковое мультимедиа и в реальном времени (например, в IP-телефонии).
Изначально в RFC 1521 были определены семь MIME-типов. У каждого из них есть один или несколько доступных подтипов. Подтип отделяется от типа косой чертой, например: Content-Type: video/mpeg. Впоследствии было добавлено более 2700 подтипов, а также два новых типа (font и model). Новые сущности добавляются постоянно, по мере появления новых типов контента.
Список утвержденных типов и подтипов поддерживается организацией IANA и расположен по адресу www.iana.org/assignments/media-types. Существующие типы, а также несколько примеров часто используемых подтипов показаны на илл. 7.15.
Тип
Примеры подтипов
Описание
text
plain, html, xml, css
Текст в различных форматах
image
gif, jpeg, tiff
Изображения
audio
basic, mpeg, mp4
Звуки
video
mpeg, mp4, quicktime
Видеофильмы
font
otf, ttf
Шрифты для форматирования текста
model
vrml
3D-модель
application
onoctet-stream, pdf, javascript, zip
Данные, производимые приложениями
message
http, rfc822
Инкапсулированное сообщение
multipart
mixed, alternative, parallel, digest
Комбинация нескольких типов
Илл. 7.15. Типы содержания MIME и примеры подтипов
Назначение MIME-типов на илл. 7.15 вполне очевидно, за исключением, возможно, последнего. Тип multipart служит для передачи сообщений с несколькими вложениями разного MIME-типа.
7.2.4. Пересылка сообщений
Теперь, когда мы описали пользовательские агенты и сообщения электронной почты, пора разобраться в том, как агенты передачи сообщений доставляют их от отправителя получателю. Передача почты осуществляется с помощью протокола SMTP.
Проще всего установить транспортное соединение между компьютером-источником и компьютером-получателем, а затем передать по нему сообщение. Так изначально и работал протокол SMTP. Однако со временем возникли два разных способа его применения. Первый — подача почтового сообщения, шаг 1 в архитектуре e-mail на илл. 7.9. Так пользовательские агенты передают данные в почтовую систему для их дальнейшей отправки. Вторым способом является пересылка сообщений между агентами передачи сообщений (шаг 2 на илл. 7.9). Такая последовательность обеспечивает доставку почты на всем пути от отправляющего до получающего агента передачи сообщений за один шаг. Окончательная доставка происходит при участии других протоколов, которые мы опишем в следующем разделе.
В этом разделе мы расскажем об основах SMTP и механизме его расширения. Затем мы обсудим разные способы его использования для подачи почты и передачи сообщений.
SMTP и его расширения
В интернете для доставки электронной почты компьютер-источник устанавливает TCP-соединение с портом 25 компьютера-получателя. Этот порт прослушивается почтовым сервером, который поддерживает простой протокол передачи электронной почты (Simple Mail Transfer Protocol, SMTP). Сервер проверяет безопасность входящих соединений, утверждает их и принимает сообщения для передачи. Если письмо невозможно доставить, отправителю возвращается отчет об ошибке, в котором содержится первая часть этого письма.
SMTP представляет собой простой ASCII-протокол. Это не недостаток, а его характерная особенность. Использование текста в формате ASCII позволяет легко модифицировать, тестировать и исправлять ошибки в протоколах. Они могут тестироваться отсылкой команд вручную, при этом записи сообщений легко читать. Сейчас так работает большинство интернет-протоколов прикладного уровня (например, HTTP).
Разберем простую передачу сообщений между почтовыми серверами, которые их доставляют. Установив TCP-соединение с портом 25, передающий компьютер, выступающий в роли клиента, ждет запроса принимающего компьютера, работающего в режиме сервера. Сервер начинает диалог с того, что отсылает текстовую строку с его идентификатором и информацией о том, готов ли он к приему почты. Если нет, клиент разрывает соединение и повторяет попытку позднее.
Если сервер готов принимать почту, клиент сообщает, от кого она поступила и кому предназначается. Если такой получатель существует на этом направлении, сервер дает клиенту добро на пересылку сообщения. Тогда клиент отправляет его, а сервер подтверждает его получение. Контрольные суммы не проверяются, так как TCP обеспечивает надежный байтовый поток. Если у отправителя есть еще почта, она также отсылается. После передачи всей почты в обоих направлениях соединение разрывается. Пример такого диалога представлен на илл. 7.16. Здесь строки, отправленные клиентом (то есть отправителем), снабжены префиксом C:. Строки, отправленные сервером (то есть получателем), снабжены префиксом S:.
Сначала клиент, естественно, отправляет серверу приветствие — HELO. Это наиболее удачный вариант сокращения слова HELLO до четырех символов. Зачем все эти команды нужно было сокращать до четырех символов, сейчас уже никто не помнит.
В нашем примере сообщение нужно отправить только одному получателю, поэтому используется только одна команда RCPT (от слова «recipient» — «получатель»). Использование этой команды несколько раз позволяет отослать одно сообщение ряду получателей. Каждая передача подтверждается или отвергается индивидуально. Даже если не получится передать сообщение некоторым получателям (из-за их отсутствия на этом направлении), сообщение все равно может быть доставлено по остальным адресам.
Наконец, несмотря на то что синтаксис четырехсимвольных команд строго определен, синтаксис ответов не столь строг. Ограничен только числовой код в начале строки. Все, что следует за этим кодом, может считаться комментарием и зависит от конкретной реализации протокола.
Базовый протокол SMTP хорошо работает, но имеет ряд ограничений. Прежде всего, он не предусматривает аутентификации. Это означает, что команда FROM в нашем примере может отобразить какой угодно адрес отправителя, что крайне удобно для рассылки спама. Еще одно ограничение протокола — он позволяет передавать сообщения в кодировке ASCII, но не бинарные данные. Именно поэтому для передачи MIME-контента приходилось использовать кодировку base64. Однако применение base64 при передаче почты ведет к неэффективному использованию пропускной способности, что становится проблемой в случае больших сообщений. Третье ограничение SMTP заключается в том, что он отсылает сообщение в незашифрованном виде. То есть сообщения никак не защищены от посторонних глаз.
S: 220 ee.uwa.edu.au - служба SMTP готова
C: HELO abcd.com
S: 250 cs.uchicago.edu приветствует ee.uwa.edu.au
C: MAIL FROM:
S: 250 подтверждаю отправителя
C: RCPT TO:
S: 250 подтверждаю получателя
C: DATA
S: 354 Отправляем письмо, завершая его символом ".", расположенным в отдельной строке
C: From: [email protected]
C: To: [email protected]
C: MIME-Version: 1.0
C: Message-Id: <[email protected]>
C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm
C: Subject: Земля обошла вокруг Солнца целое число раз
C:
C: Это преамбула. Пользовательский агент игнорирует ее. Хорошего дня.
C:
C: --qwertyuiopasdfghjklzxcvbnm
C: Content-Type: text/html
C:
C:
С днем рожденья тебя!
C: С днем рожденья тебя!
C: С днем рождения, дорогой
C: С днем рожденья тебя!
C:
C: --qwertyuiopasdfghjklzxcvbnm
C: Content-Type: message/external-body;
C: access-type="anon-ftp";
C: site="bicycle.cs.uchicago.edu";
C: directory="pub";
C: name="birthday.snd"
C:
C: content-type: audio/basic
C: content-transfer-encoding: base64
C: --qwertyuiopasdfghjklzxcvbnm
C: .
S: 250 сообщение принято
C: QUIT
S: 221 ee.uwa.edu.au разрывает соединение
Илл. 7.16. Передача сообщения от [email protected] для [email protected]