Формат сообщения электронной почты
Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или То, например:
Date: 26 Aug 76 1429 EOT
From: [email protected]
Или
Date: 26 Aug 76 1429 EOT
From: [email protected]
Поле Date определяет дату отправки сообщения, поле From - отправителя, а поля ее и То - получателя или нескольких получателей. Чаще заголовок содержит дополнительные поля:
Date: 26 Aug 76 1429 EOT
From: George Jones
Sender: Secy@SHOST
Message -ID: <4231.629.XYzi - [email protected]>
В данном случае поле 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. [email protected]
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 позволяет расширить область применения электронной почты, обеспечить доступ к Другим информационным ресурсам сети в стандартных форматах.
СИСТЕМА WORLD WIDE WEB
В 1989 году гипертекст представлял новую многообещающую технологию, которая имела относительно большое число реализаций, с одной стороны, а с другой стороны, делались попытки построить формальные модели гипертекстовых систем, которые носили скорее описательный характер и были навеяны успехом реляционного подхода описания данных. Идея создания системы WWW заключалась в том, чтобы применить гипертекстовую модель к информационным ресурсам, распределенным в сети, и сделать это максимально простым способом. Он заложил три краеугольных камня системы из четырех существующих ныне, разработав:
· язык гипертекстовой разметки документов HTML (HyperText Markup Language);
· универсальный способ адресации ресурсов в сети URL (Universal Resource Locator);
· протокол обмена гипертекстовой информацией HTTP (HyperText Transfer Protocol).
Позже команда NCSA добавила к этим трем компонентам четвертый: универсальный интерфейс шлюзов CGI (Common Gateway Interface).
Язык программирования Java не включается в этот список намеренно, так как область применения этого языка гораздо шире, чем простое "оживление" World Wide Web.
Идея HTML - пример чрезвычайно удачного решения проблемы построения гипертекстовой системы при помощи специального средства управления отображением. На разработку языка гипертекстовой разметки существенное влияние оказали два фактора: исследования в области интерфейсов гипертекстовых систем и желание обеспечить простой и быстрый способ создания гипертекстовой базы данных, распределенной в сети.
В 1989 году активно обсуждалась проблема интерфейса гипертекстовых систем, то есть способов отображения гипертекстовой информации и навигации в гипертекстовой сети. Значение гипертекстовой технологии сравнивали со значением книгопечатания. Утверждалось, что лист бумаги и компьютерные средства отображения/воспроизведения серьезно отличаются друг от друга, и поэтому форма представления информации тоже должна отличаться. Наиболее эффективной формой организации гипертекста были признаны контекстные гипертекстовые ссылки, а кроме того, было признано деление на ссылки, ассоциированные со всем документом в целом и с отдельными его частями.
Обычно гипертекстовые системы имеют специальные программные средства построения гипертекстовых связей. Сами гипертекстовые ссылки хранятся в специальных форматах или даже составляют специальные файлы. Такой подход хорош для локальной системы, но не для распределенной на множестве различных компьютерных платформ. В HTML гипертекстовые ссылки встроены в тело документа и хранятся как его часть. Часто в системах применяют специальные форматы хранения данных для повышения эффективности доступа. В WWW-документах это обычные ASCII-файлы, которые можно подготовить в любом текстовом редакторе. Таким образом, проблема создания гипертекстовой базы данных была решена чрезвычайно просто.
Рис. 7.1. Финансовые индикаторы и новости финансового рынка на сервере информационного агентства Bloomberg
С момента разработки первой версии языка (HTML 1.0) прошло уже пять лет. За это время произошло довольно серьезное развитие языка. Почти вдвое увеличилось число элементов разметки, оформление документов все больше приближается к оформлению качественных печатных изданий, развиваются средства описания нетекстовых информационных ресурсов и способы взаимодействия с прикладным программным обеспечением. Совершенствуется механизм разработки типовых стилей. Фактически, в настоящее время HTML развивается в сторону создания стандартного языка разработки интерфейсов как локальных, так и распределенных систем. Вторым краеугольным камнем WWW стала универсальная форма адресации информационных ресурсов (Universal Resource Identification, URI), представляющая собой довольно стройную систему, учитывающую опыт адресации и идентификации E-mail, Gopher, WAIS, Telnet, FTP и т. п. Но реально из всего, что описано в URI, для организации баз данных в WWW требуется только Universal Resource Locator (URL). Без наличия этой спецификации вся мощь HTML оказалась бы бесполезной. URL используется в гипертекстовых ссылках и обеспечивает доступ к распределенным ресурсам сети. В URL можно адресовать как другие гипертекстовые документы формата HTML, так и ресурсы E-mail, Telnet, FTP, Gopher, WAIS. Различные программы различным образом осуществляют доступ к этим ресурсам. Следует отметить, что программы обработки электронной почты в формате MIME также имеют возможность отображать документы, представленные в формате HTML. Для этой цели в MIME зарезервирован тип text/html.
Третьим в нашем списке стоит протокол обмена данными в World Wide Web - HTTP (HyperText Transfer Protocol). Данный протокол предназначен для обмена гипертекстовыми документами и учитывает специфику такого обмена. Так, в процессе взаимодействия клиент может получить новый адрес ресурса сети, запросить встроенную графику, принять и передать параметры и т. п. Управление в HTTP реализовано в виде ASCII-команд. Реально разработчик гипертекстовой базы данных сталкивается с элементами протокола только при использовании внешних программ или при доступе к внешним относительно WWW информационным ресурсам, например базам данных.
Последняя составляющая технологии WWW - это спецификация CGI (Common Gateway Interface). CGI была специально разработана для расширения возможностей WWW за счет подключения внешнего программного обеспечения. Эта технология соответствовала принципам простоты разработки, доступности и наращивания возможностей WWW. Предложенный и описанный в CGI способ подключения не требовал дополнительных библиотек и буквально ошеломлял своей простотой. Сервер взаимодействовал с программами через стандартные потоки ввода/вывода, что упрощает программирование до предела. При реализации CGI чрезвычайно важное место заняли методы доступа, описанные в HTTP. И хотя реально используются только два из них (GET и POST), опыт развития HTML показывает, что сообщество WWW ждет развития и CGI по мере усложнения задач, в которых будет использоваться WWW-технология.