Содержание
Формат почтового сообщения (RFC-822)
Многоцелевое расширение интернет почты (MIME)
При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения 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.
Разнородность сетей и обилие не стандартизированного ПО различных производителей зачастую не позволяло пользователям "понимать" друг друга. Причины проблем:
- Разные клиенты работали с разными кодировками.
- Не была определена структура размещения и идентификации типа закодированных данных. Чтобы понять, что собой представляет полученная информация, ее необходимо было "вынуть" из сообщения и декодировать.
С ростом популярности 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. Вкраце процесс кодирования можно описать так:
- Битовый поток разбивается по 24 бита (по 3 байта), которые в свою очередь делятся на четыре части по 6 бит.
- Каждая такая часть кодируется одним из 64 ASCII символов (отсюда название - base64). В таблице 4 приведено соответствие между десятичным эквивалентом шестибитного кода и символом.
Таблица 4. Кодировочная таблица для base64.
Код |
Символ |
Код |
Символ |
Код |
Символ |
Код |
Символ |
0 |
A |
16 |
Q |
32 |
g |
48 |
w |
1 |
B |
17 |
R |
33 |
h |
49 |
x |
2 |
C |
18 |
S |
34 |
i |
50 |
y |
3 |
D |
19 |
T |
35 |
j |
51 |
z |
4 |
E |
20 |
U |
36 |
k |
52 |
0 |
5 |
F |
21 |
V |
37 |
l |
53 |
1 |
6 |
G |
22 |
W |
38 |
m |
54 |
2 |
7 |
H |
23 |
X |
39 |
n |
55 |
3 |
8 |
I |
24 |
Y |
40 |
o |
56 |
4 |
9 |
J |
25 |
Z |
41 |
p |
57 |
5 |
10 |
K |
26 |
a |
42 |
q |
58 |
6 |
11 |
L |
27 |
b |
43 |
r |
59 |
7 |
12 |
M |
28 |
c |
44 |
s |
60 |
8 |
13 |
N |
29 |
d |
45 |
t |
61 |
9 |
14 |
O |
30 |
e |
46 |
u |
62 |
+ |
15 |
P |
31 |
f |
47 |
v |
63 |
- |
В заключении приведем небольшой пример использования 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
Содержание
|