Протокол электронной почты

Многоцелевое расширение почты Интернет (MIME)

Стандарт STD 11 (RFC 822) определяет протокол представления сообщений, структуру их заголовков. При этом предполагается, что текст сообщения построен исключительно из кодов US-ASCII (смотри также http://book.itep.ru/4/4/mime.htm). Набор документов MIME (Multipurpose Internet Mail Extensions; RFC-2045-49) задает формат сообщений, который предоставляет следующие возможности.

1. Передача текстовых сообщений с символьным набором, отличным от US-ASCII.
2. Передача сообщений нетекстового формата (например, звукового письма или изображения).
3. Использование комбинированных сообщений, содержащих разнородные части.
4. Размещение в заголовке информации в символьном наборе, отличном от US-ASCII.

Документ RFC-2045 характеризует различные заголовки, которые служат для описания структуры MIME-сообщений. RFC 2046 определяет общую структуру MIME и исходный набор типов среды. RFC 2047 описывает расширения документа RFC 822, позволяя применение в полях заголовков символьных наборов, отличных US-ASCII. RFC 2048 специфицирует различные ограничения, вводимые IANA, для процедур, сопряженных с MIME. RFC 2049 характеризует критерии соответствия требованиям MIME, содержит примеры допустимых форматов и библиографию. Новейшие усовершенствования протокола MIME (особенно в направлении безопасности) можно найти в документах: RFC-2045-49, -2110, -2156, -2184, -2231, -2387, -2425, -2480, -2557, -2634, -2912-13, -3030, -3156, -3204, -3250, -3302, -3335, -3454, -3555, -3735, -3802 -03, -3839, -3850-51, -3850-35, -4021.

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

Одним из существенных ограничений традиционной электронной почты, базирующейся на RFC 821-822, является установка предельного размера строки (1000 7-битовых US-ASCII символов). Это вынуждало пользователей конвертировать текст различными методами в последовательность US-ASCII-кодов (например, процедура uuencode или преобразование в коды Base-64).

Существенные проблемы возникали при почтовом обмене между узлами, поддерживающими протоколы RFC 822 и X.400. Протокол X.400 [X400] определяет механизм включения нетекстовых материалов в почтовые сообщения. Существующие протоколы согласования работы X.400 и RFC 822 предполагают, что X.400 осуществляет преобразование нетекстовых вставок в формат IA5Text или такие сообщения просто выбрасываются. Отправитель сообщения часто не знает о возможностях получателя, и в результате последний, получив сообщения, попросту не сможет его прочесть. Таким образом, нужен механизм согласования возможностей отправителя и получателя на начальной стадии их взаимодействия до начала передачи тела сообщения. В протоколе MIME регламентируется:

1. поле заголовка MIME-Version, которое характеризует версию протокола и позволяет почтовым агентам согласовать свои возможности и исключить конфликты с устаревшим программным обеспечением;
2. поле заголовка Content-Type, которое используется для спецификации типа среды и субтипа данных в теле сообщения, а также для описания канонической формы этих данных;
3. поле заголовка Content-Transfer-Encoding, которое может использоваться для задания типа преобразования;
4. два дополнительные поля заголовка, предусмотренные для уточнения описания данных в теле сообщения (Content-ID и Content-Description).

Важно заметить, что основополагающими принципами при создании MIME были совместимость с существующими стандартами и надежность работы. Для тех, кто попытается реализовать протокол MIME, определенный интерес могут представлять документы RFC 1344, RFC 1345 и RFC 1524.

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

Терм CRLF в данном описании относится к последовательности октетов, соответствующих ASCII-символам CR (десятичный код 13) и LF (десятичный код 10), которые обозначают разрыв строки.

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

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

Термин "символьный набор" был первоначально введен для описания прямых схем преобразования, таких, как ASCII и ISO-8859-1, для которых характерна однозначная связь символов и кодовых октетов. Многооктетные кодированные символьные наборы и методики переключения несколько осложнили ситуацию.

Термин "сообщение" обозначает сообщение типа RFC 822, передаваемое по сети, либо сообщение, инкапсулированное в тело типа "message/rfc822" или "message/partial".

Термин "объект" (entity) относится к полям заголовка MIME и содержимому сообщения или его части в случае, если оно составное. Спецификация таких объектов определяется исключительно MIME. Так как содержимое объекта часто называется "тело", имеет смысл говорить о теле объекта. Любой вид поля может быть представлен в заголовке объекта, но только поля, имена которых начинаются с "content-", имеют значение, связанное с протоколом MIME.

Выражение "7-битовые данные" относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Октеты с кодом больше чем 127 или равные нулю недопустимы. Октеты CR (десятичный код 13) и LF (десятичный код 10) могут встречаться только в виде последовательности, отмечающей конец строки.

Выражение "8-битовые данные" относится к данным, которые образуют относительно короткие строки с длиной менее 998 октетов, завершающиеся последовательностью CRLF [RFC-821]. Но здесь разрешены октеты с десятичными значениями кодов, превышающими 127 (нулевые коды не допускаются).

Строки в данном контексте представляют собой последовательности октетов, завершающиеся CRLF. Это согласуется с документами RFC 821 и RFC 822.

MIME определяет ряд новых полей заголовков по сравнению с RFC 822. Они описывают содержимое MIME-объекта. Эти поля заголовков используются в двух контекстах:

1. в качестве части стандартного заголовка RFC 822;
2. в MIME-заголовке в рамках составной конструкции сообщения.

Ниже представлено формальное описание этих полей заголовка.

entity-headers := [ content CRLF ] [ encoding CRLF ] [ id CRLF ] [ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers fields version CRLF

Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

MIME-part-headers := entity-headers [ fields ]

Любое поле, не начинающееся с "content-", не может иметь какого-либо значения и может игнорироваться.

Порядок полей заголовка, представленный в данном BNF-определении, не имеет никакого значения.

Так как документ RFC 822 был опубликован в 1982 году, там имелся только один формат для сообщений, передаваемых по каналам Интернет, и по этой причине не было необходимости декларировать тип такого стандарта. MIME является независимым дополнением документа RFC 822. Хотя протокол MIME строился так, чтобы обеспечить совместимость с RFC 822, бывают обстоятельства, когда почтовому агенту желательно выяснить, составлено ли сообщение с учетом нового стандарта. Поле заголовка "MIME-Version" служит как раз для того, чтобы можно было определить, какому стандарту соответствует тело сообщения. Сообщения, соответствующие MIME обязаны содержать такое поле заголовка со следующим текстом:

MIME-Version: 1.0

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

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

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

Заметим, что поле заголовка MIME-Version должно располагаться в самом начале сообщения. При составном сообщении не требуется, чтобы каждая из частей начиналась с поля версии. Это необходимо лишь в случае, когда заголовки встроенных сообщений типа "message/rfc822" или "message/partial" объявляют о совместимости со стандартом MIME.

Для некоторых приложений согласование версий должно проводиться независимо. Некоторые форматы (такие, как application/postscript) имеют внутреннюю систему нумерации версий для каждого типа среды. Там, где выполняется такое соглашение, MIME не предпринимает попыток подменить эту систему. Там, где такого соглашения нет, тип среды MIME может использовать параметр version в поле типа содержимого. При проверке значений MIME-Version любые строки комментария RFC 822 должны игнорироваться. В частности, следующие четыре записи поля

MIME-Version эквивалентны.
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0

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

Нельзя быть уверенным, что почтовое сообщение, не согласованное с MIME, является непременно обычным текстом в кодировке ASCII, так как оно может содержать код согласно локальному соглашению (например, результат работы процедуры UUENCODE или какого-то архиватора).

Поле заголовка Content-Type

Задачей поля Content-Type является описание информации, содержащейся в теле сообщения. Этого описания должно быть достаточно, чтобы принимающий агент пользователя был способен воспринять и отобразить полученные данные. Значение этого поля называется типом среды.

Введение поля тип среды (Content-Type) решило не только проблемы почты, оно открыло возможности мультимедийного отображения в HTTP и других приложениях.

Поле заголовка Content-Type было первым определенным в документе RFC-1049. В RFC-1049 использовался более простой и менее мощный синтаксис, который, впрочем, вполне согласуется с регламентациями MIME.

Поле заголовка Content-Type специфицирует природу данных в теле объекта, сообщая тип среды и идентификаторы субтипа, а также предоставляя вспомогательную информацию, которая может требоваться для определенного типа среды. После типа среды и имен субтипов может следовать набор параметров, который описывается в нотации атрибут = значение. Порядок параметров не имеет значения. Тип среды верхнего уровня используется для декларирования общего типа данных, в то время как субтип определяет специфический формат информации. Таким образом, типа среды image/xyz достаточно, чтобы сообщить агенту пользователя, что данные представляют собой изображение, даже если агент пользователя не имеет представления о формате изображения xyz. Такая информация может применяться, например, для того, чтобы решить, следует ли показывать пользователю исходные данные нераспознанного субтипа. Такая операция разумна для нераспознанного субтипа текста, но бессмысленна для изображения или звука. По этой причине зарегистрированные субтипы текста, изображения, аудио и видео не должны содержать вложенной информации другого типа. Такой составной формат должен быть представлен с использованием multipart или application типов.

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

Например, параметр charset применим к любому субтипу текста, в то время как параметр boundary необходим для любого субтипа типа среды multipart. Не существует параметров, применимых для всех типов среды.

Исходный набор из семи типов среды верхнего уровня определен в документе RFC 2046. Пять из них являются дискретными типами, остальные два — составные типы, чье содержимое требует дополнительной обработки процессорами MIME.

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