При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения 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 содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты.

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

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 - используемый метод кодирования для передачи.

С помощью 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 приведено соответствие между десятичным эквивалентом шестибитного кода и символом.

Таблица 4. Кодировочная таблица для base64.

В заключении приведем небольшой пример использования MIME. В заголовке указано, что используется версия MIME 1.0. Сообщение содержит две части. На это указывает тип содержимого сообщения: Content-Type: multipart/alternative. Каждая часть идентифицируется разделителем:
boundary="---- =_NextPart_001_01BE54E2.10C07C70"
Конец сообщения так же отмечен разделителем. Первая часть содержит простой русский текст в кодировке koi8-r для передачи которого использовалась кодирование по алгоритму base64. Вторая часть - документ формата MS Word. Для его передачи также использовалось кодирование. Причем если почтовый клиент "умеет" обращаться с DOC форматом, то данные будут отображены прямо в теле сообщения: Content-Disposition: inline.

From user@email.net Wed Feb 10 16:15:17 1999
To: "Sergey Makarov (E-mail)" 
Subject: FW: please resend it, because i can't translate it at work
Date: Wed, 10 Feb 1999 09:30:57 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative;
boundary="---- =_NextPart_001_01BE54E2.10C07C70"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BE54E2.10C07C70
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: base64

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBqb2huQHZ0YXUtYnNkLnBzdHUu
YWMucnUgW21haWx0bzpqb2huQHZ0YXUtYnNkLnBzdHUuYWMucnVdIA0KU2VudDogTW9uZGF5LCBG
ZWJydWFyeSAwOCwgMTk5OSAxOjM3IFBNDQpTdWJqZWN0OiANCg0KDQrN8yDt4Oru7eXpCPcICPYt

------ =_NextPart_001_01BE54E2.10C07C70
Content-Type: application/msword
Content-Disposition: inline
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWtvaTgtciI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENPTlRFTlQ9Ik1T

------ =_NextPart_001_01BE54E2.10C07C70-

Оригинальные документы по MIME: RFC-1341, RFC-1342, RFC-1521, RFC-1522, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049