ФОРМАТ СООБЩЕНИЯ ЭЛЕКТРОННОЙ ПОЧТЫ

Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или То, например:

Date: 26 Aug 76 1429 EOT

From: Jones@Registry.org

Или

Date: 26 Aug 76 1429 EOT

From: Jones@Registry.org

To: Smith@Registry.org

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

Date: 26 Aug 76 1429 EOT

From: George Jones

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

Subject: Re: The Syntax in the RFC

Sender: KSecy@Other – host

Reply to: Sam. Irving@Reg.Organization

To: George Jones

cc:Important folks: Tom Softwood , "Sam Irving"@0ther - Host;

Standard Distribution: /main/davis/people/standard@0ther – Host

Comment: Sam is away on bisiness.

In reply to: George's message

X special action: This is a sample of user - defined field - names. Message - ID:

<4331.629.XYzi - What@0ther – Host

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

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

Возможности электронной почты не ограничиваются только пересылкой корреспонденции. По почте можно получить доступ ко многим ресурсам Интернета, которые используют почтовых роботов, отвечающих на запросы пользователей. Поэтому имеет смысл более детально изучить программное обеспечение, поддерживающее электронную почту. Стандарт MIME (или, в нотации Интернета, RFC-1341) предназначен для описания тела почтового сообщения Интернета. Предшественником MIME является Стандарт почтового сообщения ARPA (RFC-822). Стандарт RFC-822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети, невозможно передать по почте без специальных преобразований. Так, в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC-822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать 7-битовой кодировкой ASCII. Естественно, что при использовании RFC-822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC-822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в Х.400 (новый стандарт ISO), который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как в этом случае не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть интерпретированы различным образом в Х.400 и в программе рассылки почты в Интернете (mail-agent).

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

- поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте;

- поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретацию данных;

- поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования;

- два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже недопустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority). Остановимся подробнее на форме и назначении полей, определяемых стандартом.

Поле версии MIME (MIME - Version) указывается в заголовке почтового сообщения и позволяет программе рассылки почты определить, что сообщение подготовлено в стандарте MIME. Формат поля выглядит так:

MIME - Version: 1.0

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC-822 стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения, и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.

Поле типа содержания тела почтового сообщения (Content type) используется для описания типа данных, которые содержатся в теле почтового сообщения. Это поле сообщает программе чтения почты, какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании/декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма:

текст (text);

смешанный тип (multipart);

почтовое сообщение (message);

графический образ (image);

аудиоинформация (audio);

фильм или видео (video);

приложение (application).

Остановимся подробнее на каждом из типов, разрешенных стандартом MIME. Text. Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа text является plain, что соответствует так называемому планарному тексту. Понятие планарного текста появилось в связи с тем, что существует еще размеченный текст, то есть текст со встроенными в него символами управления отображением, и гипертекст, то есть текст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип richtext, а для обозначения гипертекста - подтип html. Вообще говоря, это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World Wide Web, которая получила широкое распространение в Интернете. Понятие размеченного текста требует более подробного обсуждения, так как его передача и интерпретация являются одной из причин появления стандарта MIME. Richtext определяет текст со встроенными в него специальными управляющими последовательностями, называемыми тегами, в соответствии со стандартом языка разметки документов SGML (Standard Generalized Markup Language). Теги представляют собой последовательность символов типа <строка символов>.

Разметка гипертекста строится по тому же принципу, что и в тексте типа richtext. При этом могут применяться теги, позволяющие описать гипертекстовые ссылки. К таким тегам относятся <А HREF="......">.....</А>.

Multipart. Этот тип почтового сообщения определяет смешанный документ, который может состоять из данных разного типа. Тип multipart имеет ряд подтипов. Подтип mixed может создавать сообщения, состоящие из нескольких фрагментов, которые разделены между собой границей, задаваемой в качестве параметра подтипа.

Другим подтипом может быть подтип alternative. Данный подтип позволяет организовать просмотр почтового сообщения с возможностью выбора в зависимости от типа программы просмотра.

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

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

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

Подтип partial предназначен для передачи одного большого сообщения по частям. Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number) и общее число порций (total). Каждая часть имеет свое поле Content type. Это означает, что все сообщение может состоять из частей разных типов. Другим подтипом является External body, который позволяет ссылаться на внешние относительно сообщения информационные источники.

Стандартным подтипом типа message является rfc822. Данный подтип определяет типы описания нетекстовой информации по стандарту RFC-822. Таких типов имеется четыре:

image - для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG;

audio - для описания аудиоинформации. Для воспроизведения сообщения данного типа требуется специальное оборудование;

video - для передачи видеоизображений. Наиболее популярным является формат MPEG;

application - для передачи данных любого другого формата. Обычно используется для передачи двоичных данных с последующим промежуточным преобразованием. Так, если на машине стоит видеокарта с 512 Кбайт памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать, и здесь может помочь тип application. Основной подтип данного типа - octet stream, но существуют ODA и postscript;

поле типа кодирования почтового сообщения (Content-Transfer-Encoding) <pclass=just>. Многие данные передаются по почте в их исходном виде. Это могут быть 7-битные символы, 8-битные символы, 64-base символы и т. п. Однако при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде - US - ASCII. Для этого существуют процедуры кодирования такого рода данных. Наиболее широко применяемая - uuencode. Для того чтобы при получении данные были правильно распакованы, в стандарт введено поле Content-Transfer-Encoding. Синтаксис этого поля следующий:

Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / "8ВГГ / "7ВГГ / "BINARY" / x-token

Каждая из альтернатив применяется в подходящем случае. Альтернативы 8bit, 7bit, BINARY реально никакого преобразования не требуют, так как почта передается байтами и SMTP не делает различия между ними. Однако они введены для строгости описания типов. BASE64 обычно используется в связке с типом text/ ISO - 8859 - 1. Элемент x-token позволяет пользователю описать свою процедуру преобразования.

Дополнительные необязательные поля: как уже говорилось ранее, стандарт определяет еще два дополнительных поля: Content-ID и Content-Description. Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария. Ни то, ни другое программами просмотра обычно не отображаются.

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