29. Форматы сообщений. RFC822. MIME. Правила кодировки base64, quoted-printable.

RFC 822

Сообщения состоят из примитивного конверта (описанного в RFC 821), нескольких полей заголовка, пустой строки и, наконец, тела сообщения. Каждое поле заголовка (логически) состоит из одной строки ASCII-текста, содержащей имя поля, двоеточие и (в большинстве случаев) значение поля. RFC 822 был создан несколько десятилетий назад, и в нем нет четкого разграничения конверта и заголовка. Хотя частично стандарт был пересмотрен в RFC 2822, целиком обновить его было невозможно, поскольку RFC 822 уже был очень широко распространен. Обычно пользовательский агент формирует сообщение и передает его агенту передачи сообщений, который с помощью одного из полей заголовка создает конверт нового вида, представляющий собой некую старомодную смесь сообщения и конверта.

Основные поля заголовка, связанные с транспортировкой сообщения, перечислены в таблице 5.2 . Поле То: содержит DNS-адрес основного получателя. Возможно наличие и нескольких получателей. В поле Сс: указываются адреса дополнительных получателей. С точки зрения качества доставки, никакой разницы между основным и дополнительными получателями нет. Разница между ними чисто психологическая и может быть важна для людей, но совершенно не существует для почтовой системы. Термин Сс: (carbon copy — экземпляр, сделанный «под копирку») несколько устарел, так как при работе с компьютерами копировальная бумага вообще-то не используется, тем не менее, он прочно обосновался в электронной почте. Поле Всс: (Blind carbon copy — слепая копия) аналогично предыдущему, с той разницей, что в последнем случае строка этого поля не видна получателям (как основному, так и дополнительным). Это свойство позволяет рассылать одно письмо одновременно нескольким получателям так, что получатели не будут знать, что это письмо послано еще кому-либо, кроме них.

Таблица 5.2 — Поля заголовка стандарта RFC 822, связанные с транспортировкой сообщения

Следующие два поля, From: и Sender:, сообщают, соответственно, кто составил и отправил сообщение. Это могут быть разные люди. Например, написать письмо может руководитель предприятия, а отослать — его секретарша. В этом случае руководитель будет числиться в поле From:, а секретарша — в поле Sender. Поле From: является обязательным, тогда как поле Sender: может быть опущено, если его содержимое не отличается от содержимого поля From:. Эти поля нужны на случай, если со-общение доставить невозможно и об этом следует проинфор-мировать отправителя. Кроме того, по адресам, указанным в этих полях, может быть оправлен ответ.

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

Поле Return-Path: добавляется последним агентом передачи сообщений. Предполагалось, что это поле будет сообщать, как добраться до отправителя. Теоретически эта информация может быть собрана из всех полей Received: заголовка (кроме имени почтового ящика отправителя), однако на практике оно редко заполняется подобным образом и обычно просто содержит ад-рес отправителя.

Помимо полей, показанных в таблице 5.2 , сообщения стан-дарта RFC 822 могут также содержать широкий спектр полей заголовка, используемых пользовательским агентом или самим пользователем. Наиболее часто используемые поля заголовка приведены в таблице 5.3 . Информации в таблице достаточно, чтобы понять назначение полей, поэтому мы не станем рассмат-ривать их все подробно.

Таблица 5.3 — Некоторые поля, используемые в заголовке сообщения стандарта RFC 822

MIME — многоцелевые расширения электронной почты

Интернет

На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений, написанных на английском языке и представленных символами ASCII. Для подобного применения стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. На сегодняшний день требуется обеспечить возможность отправления сообщений со следующими характеристиками.

1.   Сообщения на языках с надстрочными знаками (напри-
мер, на французском, немецком, испанском и т.д.).

2.      Сообщения на языках, использующих алфавиты, отличные от латинского (например, на иврите или русском).

3.      Сообщения на языках без алфавитов (например, китайском, японском, корейском).

4.      Сообщения, вообще не являющиеся текстом (например, аудио или видео).

    Решение было предложено в документе RFC 1341, а более новая редакция была опубликована в RFC 2045-2049. Это решение, получившее название MIME (Multipurpose Internet Mail Extensions, — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий мо-мент. Далее приведено его описание. Дополнительную информацию о наборе стандартов MIME смотрите в RFC.

Основная идея стандартов MIME — продолжить использование формата RFC 822, но с добавлением структуры к телу сообщения и с определением правил кодировки He-ASCII-сообщений. Не отклоняясь от стандарта RFC 822, MIME-сообщения могут передаваться с помощью обычных почтовых программ и протоколов. Все, что нужно изменить, — это отправляющие и принимающие программы, которые пользователи могут создать для себя сами.

Стандартами MIME определяются пять новых заголовков сообщения, приведенных в таблице

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

Заголовок Content-Description представляет собой ASCII-строку, информирующую о том, что находится в сообщении. Этот заголовок позволяет пользователю принять решение о том, нужно ли ему декодировать и читать сообщение. Если в строке сказано: «Фотография тушканчика Барбары», а получивший это сообщение не является любителем тушканчиков, то, вероятнее всего, он сразу удалит это сообщение, а не станет перекодировать его в цветную фотографию высокого разрешения.

Заголовок Content-Id содержит идентификатор содержимого сообщения. В нем используется тот же формат, что и в стандартном заголовке Message-Id:.

Заголовок Content-Transfer-Encoding сообщает о способе упаковки тела сообщения для его передачи по сети, которая мо-жет возражать против символов, отличных от букв, цифр и зна-ков препинания. Разработано пять схем (имеется возможность добавления новых схем).

Простейшая из них заключается в передаче просто ASCII-текста. Символы ASCII используют 7 разрядов и могут переда-ваться напрямую протоколом электронной почты при условии, что строка не превышает 1000 символов.

Следующая по простоте схема аналогична предыдущей, но использует 8-разрядные символы, то есть все значения байта от 0 до 255 включительно. Такая схема кодировки нарушает (исходный) протокол электронной почты Интернета, но используется в некоторых частях Интернета, в которых реализовано некоторое расширение исходного протокола. Хотя объявление о способе кодирования не делает его использование автоматически закон-ным, открытое объявление может, по крайней мере, в случае чего объяснить неправильную работу почтовых агентов. Сооб-щения, использующие 8-разрядную кодировку, также должны соблюдать правило о максимальной длине строки.

Еще хуже обстоит дело с сообщениями в двоичной коди-ровке. К ним относятся произвольные двоичные файлы, которые не только используют все 8 разрядов в байте, но еще и не со-блюдают ограничение на 1000 символов в строке. К этой кате-гории относятся исполняемые программные файлы. Не дается никакой гарантии, что эти двоичные сообщения будут доставле-ны корректно, но, тем не менее, очень многие пользователи все равно пересылают их друг другу.

Корректный способ кодирования двоичных сообщений состоит в использовании кодировки base64 (64-символьная кодировка), иногда называемой ASCII armor (ASCII-оплетка). При использовании данного метода группы по 24 бита разбиваются на четыре 6-разрядные единицы, каждая из которых посылается в виде обычного разрешенного ASCII-символа. В этой кодировке 6-разрядный символ 0 кодируется ASCII-символом «А», 1 — ASCII-символом «В» и т.д. Затем следуют 26 строчных букв — это уже 10 разрядов, и наконец, + и / для кодирования 62 и 63 соответственно. Последовательности == и = говорят о том, что последняя группа содержит только 8 или 16 бит соответственно. Символы перевода строки и возврата каретки игнорируются, поэтому их можно вставлять в любом месте для того, чтобы строки выглядели не слишком длинными. Таким способом можно передать любой двоичный код.

Для сообщений, почти полностью состоящих из символов ASCII, но с небольшими включениями не-ASCII-символов, подобный метод несколько неэффективен. Вместо него лучше применять кодировку quoted-printable (цитируемое печатное кодирование). Это просто 7-битный ASCII, в котором символы, соответствующие значениям ASCII-кода свыше 127, кодируются знаком равенства, за которым следуют две шестнадцатеричных цифры — ASCII-код символа.

Последний заголовок в таблице 5.4 представляет наибольший интерес. Он указывает тип тела сообщения. В документе RFC 2045 определены семь типов содержимого сообщений, каждый из которых распадается на несколько подтипов.