26. Формат сообщений электронной почты. Mime.

Формат почтового сообщения (RFC-822)

При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или То, например:

Date: 26 Аug 76 1429 EDT From: Jones@Registry.org cc: Smith@aol.com

или

Date: 26 Aug 76 1429 EDT From: Jones@Registry.org To: Smith@Registry.org

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

Date: 26 Aug 76 1429 EDT

From: George Jones<Jones@Registry.org>

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 <Kdavis@This-Host. This. net>

Subject: Re: The Syntax in the RFC

Sender: KSecy@Other-host

Reply-To: Sam. lrving@Reg .Organization

To: George Jones <Jones@Registry.org>

cc: Important folks:

Tom Softwood <Balsa@Tree.Root>, "Sam Irving"@Other-Host;

Standard Distribution:

/main/davis/people/standard@Other-Host

Comment: Sam is away on bisiness.

In-Reply-To: <some.string@DBM.Group>, George's message

X-Special-action: This is a sample of user-defined field-names.

Message-ID: <4331.629.XYzi-Wnat@Other-Host

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

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

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

Первоначально электронная почта была предназначена исключительно для передачи текстовых сообщений, содержащих ASCII символы. Если же требовалось передать двоичный файл или текст на языке отличном от английского, то возникала необходимость кодирования такого файла или текста символами ASCII. Далее, закодированное сообщение передавалось с помощью обычных средств электронной почты. Принимающая сторона (пользователь) должна быть извещена о способе кодирования и должным образом декодировать сообщение. Одна из таких кодировок - UUE.

Разнородность сетей и обилие не стандартизированного ПО различных производителей зачастую не позволяло пользователям "понимать" друг друга. Причины проблем:

1. Разные клиенты работали с разными кодировками.

2. Не была определена структура размещения и идентификации типа закодированных данных. Чтобы понять, что собой представляет полученная информация, ее необходимо было "вынуть" из сообщения и декодировать.

С ростом популярности E-mail и multimedia возникла необходимость в одном сообщении передавать данные различных типов:

• текстовую информацию на различных языках,

• графические изображения,

• видеопоследовательности,

• голосовые сообщения (аудиоинформацию),

• и просто, бинарные файлы;

При этом для большей интеграции E-mail и multimedia одной из задач была просматривать сообщение "на лету". Это послужило толчком к созданию унифицированного интерфейса (стандарта), который бы интерпретировался всеми почтовыми системами одинаково.

Стандарт MIME (Multipurpose Internet Mail Extention, многоцелевое расшироение интернет почты) представляет такой удобный интерфейс. Он не заменяет, а расширяет существующий способ формирования электронных сообщений. MIME - новый формат представления данных, представляющий почтовому клиенту гибкий интерфейс для работы с E-mail.

Для идентификации MIME-сообщений в заголовке сообщения должны присутствовать следующие поля.

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

Mime-Version - версия MIME, например, 1.0 или 1.1 Content-Type - тип сообщения.

Возможные типы, подтипы (скобки содержат стандартные расширения файлов, соответствующие этим подтипам) и параметры:

text/подтип; charset="кодировка" - текст; Кодировка: koi8-r, windows-1251, iso-8859-1 и др.;

Значения подтипа:

• text (txt)- простой текст;

• html (htm, html)- форматированный текст HTML;

image/подтип; name="имя_файла" - изображение; Значения подтипа: jpg или jpeg, gif, bmp

video/подтип; name="имя_файла" - видеоролик; Значения подтипа mpeg, x-msvideo (avi), quicktime (qt)

audio/подтип; name="имя_файла" - аудиоролик; Значения подтипа: ra, wav, basic (au)

application/подтип; name="имя_файла" - файл общего формата; Значения подтипа:

• octet-stream - бинарный файл (исполняемый или др. файл);

• msword (doc)- файл MS Word;

• x-compress (z), x-compressed (tgz), x-gzip (z), z-tar (gz), x-zip-compressed (zip)- файлы в сжатых архивах

имя_файла - любое допустимое в системе имя файла.

multiaprt/подтип; bound="разделитель" - сообщение из многих частей; Значения подтипа определяют, каким образом будут интерпретироваться каждая из частей:

• mixed - все части обрабатываются последовательно;

• parallel - все части обрабатываются параллельно;

• alternative - интерпретация определяется клиентом;

Каждая часть multipart может выступать в роли отдельного сообщения (контейнера), отделенных друг от друга разделителями. В одной такой части может находиться любой из типов, описанных выше (text, image, video...)

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

Content-Disposision - расположение части внутри собщения. Значения:

• attachment; filename="имя_файла" - прикрепленный файл, не интерпретируется почтовым клиентом. Для просмотра файл необходимо сохранить на локальном диске.

• inline - если почтовый агент "знает" формат файла, то он будет отображен прямо в теле сообщения.

Content-Transfer-Encoding - используемый метод кодирования для передачи.

Возможные значения: base64, quoted-printable, 8bit, 7bit, binary. Кодирование применяется для передачи бинарных файлов и текста в национальных кодировках.

С помощью 8bit можно передавать сообщения с символами, у которых включен 8-й бит, напрмер, письмо на русском языке в кодировке windows-1251.

quoted-printable позволяет закодировать любые не ASCII символы и передавать их в сообщении в перемешку с первыми. Каждый закодированный символ сообщения представляет собой последовательность из знака равно ("=") и шестнадцатиричного кода символа. Цифра 1 представима как =31, а символ @ - как =40. Кодировка удобна, когда в тело сообщения требуется включить несколько нестандартных символов, коды которых не выходят в ASCII набор. Так, например, для включения в сообщение символа "(c)", на его месте нужно указать его код - =A9. Если же сообщение будет полностью закодировано quoted-printable, то его объем увеличится втрое. И все же это достаточно простая кодировка, поддерживается большенством почтовых агентов, зачастую применяется для передачи сообщений на русском языке. Слово "Привет", написанное в кодировке windows-1251 будет закодировано как: =CF=F0=E8=E2=E5=F2. За более подробной информацией обращайтесь к RFC-1341.

Для передачи двоичных файлов повсеместно используется base64. Вкраце процесс кодирования можно описать так:

1. Битовый поток разбивается по 24 бита (по 3 байта), которые в свою очередь делятся на четыре части по 6 бит.

2. Каждая такая часть кодируется одним из 64 ASCII символов (отсюда название - base64). В таблице 4 приведено соответствие между десятичным эквивалентом шестибитного кода и символом.