Глобальные компьютерные сети

  Почтовое  сообщение состоит из трех частей:

• конверта;
• заголовка;
• тела сообщения.

  Пользователь  видит только заголовок и тело сообщения. Конверт используется программами доставки.

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

  Date: 26 Aug 05 1429 EOT

  From: Jones@Registry.org

или

  Date: 26 Aug 05 1429 EOT

  From: Jones@Registry.org

  To: Smith@Registry.org

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

  Часто заголовок содержит дополнительные поля:

  Date: 26 Aug 05 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 05 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 не дает возможностей включить в тело сообщения графику, аудио, видео и другие типы информации, а также текстовую информацию, которую нельзя реализовать 7-битовой кодировкой ASCII. Ограничения 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).

  Text. Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа text являются:

• plain – соответствует планарному тексту;
• richtext – соответствует размеченному текста, т.е. тексту со встроенными в него символами управления отображением;
• html – соответствует гипертекст, т.е. тексту, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам;

  Richtext определяет текст со встроенными в него специальными управляющими последовательностями, называемыми тегами, в соответствии со стандартом языка разметки документов SGML (Standard Generalized Markup Language). Теги представляют собой последовательность символов типа <строка символов>.

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

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

• mixed – может создавать сообщения, состоящие из нескольких фрагментов, которые разделены между собой границей, задаваемой в качестве параметра подтипа;
• alternative – позволяет организовать просмотр почтового сообщения с возможностью выбора в зависимости от типа программы просмотра;
• digest – предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип;
• parallel – предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра.

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

• partial – предназначен для передачи одного большого сообщения по частям. Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number) и общее число порций (total). Каждая часть имеет свое поле Content type, что означает – все сообщение может состоять из частей разных типов;
• external body – позволяет ссылаться на внешние относительно сообщения информационные источники;
• 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 позволяет пользователю описать свою процедуру преобразования.