Последний почтовый протокол, на котором мы остановимся в этом кратком обзоре, - это протокол MIME (Multipurpose Internet Mail Extensions). Как следует из названия, MIME является расширением существующей почтовой системы TCP/IP, а не заменой для нее. MIME больше заботит характер данных, передаваемых почтовой системой, а не механизмы доставки. Это не попытка заменить SMTP или TCP, но способ расширить определение «почтового сообщения».
Структура почтовых сообщений, передаваемых по SMTP, определена в документ е RFC 822 , Standard for the Format of ARPA Internet Text Messages (Стандарт формата текстовых сообщений сети ARPA Internet). RFC 822 содержит ряд определений для заголовков почтовых сообщений, которые получили столь широкое распространение, что применяются во многих почтовых системах, никак не связанных с протоколом SMTP. Такое положение очень выгодно для системы электронной почты, поскольку создает определенное взаимопонимание систем в вопросах перевода сообщений и доставки через шлюзы в различные почтовые сети. MIME дополняет RFC 822 в двух аспектах, не затронутых исходным документом:
- Поддержка различных типов данных. Почтовая система, определяемая документами RFC 821 и RFC 822, позволяет передавать только 7-битные ASCII-данные. Этого вполне достаточно для пересылки текстовых данных, состоящих из символов ASCII, но не достаточно для пересылки сообщений на языках с другим алфавитом, а также двоичных данных. Поддержка сложного наполнения сообщений. В RFC 822 нет подробного описания тела электронных сообщений, хотя довольно подробно описан состав заголовков сообщений.
С целью разрешения подобных затруднений MIME определяет методы кодирования, позволяющие передавать различные виды данных, и структуру тела сообщения, позволяющую передавать в одном сообщении несколько объектов. Документ RFC 1521 Multipurpose Internet Mail Extensions Part One: Format of Internet Message Bodies содержит два определения заголовков, структурирующих тело почтового сообщения и позволяющих передавать различные виды данных. Речь идет о заголовках Content-Type и ContentTransfer-Encoding.
Как следует из названия, заголовок Content-Type определяет тип данных, передаваемых в сообщении. Поле заголовка Subtype уточняет определение. Многие подтипы появились уже после публикации исходного документа RFC. Список типов MIME, имеющих хождение, можно найти в сети Интернет. Исходный документ RFC определяет семь базовых типов содержимого и ряд подтипов:
text - Текстовые данные. В RFC 1521 определены текстовые подтипы plain и richtext. Помимо определенных в стандарте, появилось еще более 30 подтипов, включа я enriched, xml и html.
application - Двоичные данные. Основной подтип, определенный в RFC 1521, - это octet-stream, указывающий на поток 8-битных байтов двоичных данных. Второй определенный в стандарте подтип - PostScript. Помимо определенных в стандарте, появилось еще более 200 подтипов. Они отмечают двоичные данные в формате конкретных приложений. Так, например, существует application-подтип msword.
image - Статичные изображения в графическом формате. RFC 1521 определяет два подтипа: jpeg и gif. Помимо определенных, появилось еще более 20 дополнительных подтипов, отражающих широко распространенные стандарты хранения изображений, такие как tiff, cgm и g3fax.
video - Анимированные изображения. Изначально был определен подтип mpeg, обозначающий распространенный стандарт хранения видеоданных на компьютере. Помимо этого появилось еще несколько подтипов, включая quicktime.
audio - Звуковые данные. Изначально был определен только один подтип - basic, обозначавший кодирование звука в формате PCM (pulse code modulation, импульсно-кодовая модуляция сигнала). В настоящее время существует еще около 20 дополнительных audio-типов, таких как MP4A-LATM.
multipart - Данные, состоящие из нескольких независимых разделов. Тело multipart - сообщения состоит из нескольких независимых частей. RFC 1521 определяет четыре подтипа. Основной подтип, mixed, означает, что каждая часть сообщения может представлять данные произвольного типа содержимого. Прочие подтипы: alternative, обозначающий повторение данных в различных форматах; parallel, означающий, что данные из различных частей должны просматриваться единовременно; digest, означающий, что данные разделов имеют тип message. В настоящее время уже существует ряд дополнительных подтипов, реализующих, в частности, поддержку голосовых сообщений (voice-message) и зашифрованных сообщений.
message - Данные, инкапсулирующие почтовое сообщение. RFC 1521 определяет три подтипа. Основной подтип, rfc822, указывает на данные, представляющие полное сообщение RFC 822. Подтипы partial и External-body предназначены для обработки больших сообщений, partial позволяет при инкапсуляции разбивать большие сообщения на ряд MIME-сообщений. External-body указывает на внешний источник содержимого большого сообщения, что позволяет передавать в MIME-сообщении только указатель, а не само сообщение. Два дополнительных подтипа, news и http, позволяют передавать соответственно сетевые новости и HTTP-трафик, отформатированный по требованиям типизации содержимого MIME.
Заголовок Content-Transfer-Encoding определяет тип кодирования данных. Консервативные SMTP-системы передают только 7-битные ASCII-данные с длиной строки не более 1000 байт. Поскольку данные, исходящие от MIME- системы, могут проходить через шлюзы, передающие только 7-битные ASCII-символы, возникает необходимость подвергать данные кодированию. RFC 1521 определяет шесть типов кодирования. Некоторые из них позволяют указывать кодировку, присущую данным. Лишь два типа связаны с конкретными методами кодирования, определенными в RFC. Шесть типов кодирования следующие:
7bit - Данные в формате ASCII. Семибитные ASCII-данные не подвергаются кодированию.
8bit - Восьмибитные данные. Кодированию не подвергаются. Данные двоич- ные, но строки данных достаточно короткие для SMTP-транспорта, то есть не превышают в длину 1000 байт.
binary - Двоичные данные. Кодированию не подвергаются. Данные двоичные, а длина строки может превышать 1000 байт. Между данными типа binary и 8bit нет разницы, кроме ограничения на длину строки; оба типа данных представляют незакодированные потоки 8-битных байтов. MIME не изменяет незакодированные потоковые данные.
quoted-printable - Закодированные текстовые данные. Этот метод кодирования применяется для данных, состоящих преимущественно из отображаемых ASCII-символов. Текст в формате ASCII передается в незакодированном виде, а байты со значениями больше 127 или меньше 33 передаются закодированными в виде строк, состоящих из последовательностей символов. Каждая последовательность состоит из знака равенства и шестнадцатеричного значения байта. Например, ASCII-символ прогона страницы, имеющий шестнадцатеричное значение ОС, передается в виде =0С. Естественно, есть и другие тонкости - так, знак равенства приходится передавать в виде =3D, а символ новой строки в конце строки не кодируется. Тем не менее описанный метод дает представление о передаче данных в кодировке quoted-printable.
base64 - Закодированные двоичные данные. Данный метод кодирования может применяться для любого байтового потока данных. Три октета (8-битных байта) данных кодируются в виде четырех 6-битных символов, что увеличивает размер файла на треть. 6-битные символы являются подмножеством ASCII и выбранны так, чтобы проходить через почтовую систему произвольного типа. Максимальная длина строки для данных в формате bаse64 - 76 символов. Рисунок иллюстрирует кодирование символов З-в-4.
11111
x-token - Данные в специальной кодировке. Разработчики программного обеспечения могут создавать собственные методы кодирования. Имена таких методов должны начинаться символами Х- . Однако это не приветствуется, поскольку снижает возможности взаимодействия почтовых систем.
Число применяемых типов данных и методов кодирования растет с появлением новых форматов данных, передаваемых в сообщениях. В новых документах RFC постоянно определяются дополнительные типы данных и кодировки. В поисках самой свежей информации по возможностям MIME обращайтесь к последним версиям документов RFC.
MIME определяет т гаы данных, перенос которых не планировался при разработке SMTP. Чтобы справиться с подобными и другими новшествами, был определен метод расширения SMTP - в документе RFC 1869, SMTP Service Extensions. RFC 1869 не определяет новых служб для SMTP; более того, в этом документе упоминаются лишь те расширения служб, что определены в других RFC. RFC 1869 определяет простой механизм, позволяющий системам SMTP согласовывать использование расширений. В документе определена новая команда приветствия (EHLO) и приемлемые ответы на эту команду. В частности, система, получившая такую команду, может вернуть список расширений, которые поддерживает. Такой ответ позволяет системеисточнику понять, какими из расширенных служб можно воспользоваться, и избежать использования тех, которые не реализованы удаленной системой. Реализации SMTP, понимающие команду EHLO, известны в качестве систем ESMTP (Extended SMTP).
Для почтовых программ MIME определен ряд дополнительных служб ESMTP. Отдельные расширения перечислены в табл. 3.4. Первая колонка таблицы содержит ключевые слова EHLO, связанные с каждым из расширений, вторая - номер руководящего документа RFC, третья - назначение расширения. Перечисленные расширения служб - просто примеры. Полная картина включает и другие усовершенствованные аспекты SMTP.
| Ключевое слово | Функциональность |
| 8BITMIME | Принимает 8-битные двоичные данные |
| CHUNKING | Принимает сообщения, разбитые на фрагменты |
| CHECKPOINT | Перезапуск почтовых транзакций по контрольным точкам |
| PIPELINING | Принимает наборы команд, объединенные в блоки |
| SIZE | Отображает максимально-допустимый размер сообщения |
| DSN | Обеспечивает передачу уведомлений о состоянии доставки |
| ETRN | Принимает внешние запросы на обработку очереди |
| ENHANCEDSTA-TUSCODES | Расширенные коды завершения операций |
| STARTTLS |
Использует механизм Transport Layer Security для шифрования почтового обмена |
| AUTH |
Усиленный механизм аутентификации для определения источника почтовых сообщений |
> telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 crab.wrotethebook.com ESMTP Sendmail 8.9.3+Sun/8.9.3; Mon, 23 Apr 2001 11:00:35-0400 (EDT) EHLO crab 250-crab.wrotethebook.com Hello localhost [127.0.0.1], pleased to meet you 250-EXPN 250 HELP 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-VERB 250-0MEX 250-XUSR QUIT 221 crab.foobirds.org closing connection Connection closed by foreign host.
Выяснить, какие расширения поддерживает сервер, можно при помощи команды EHLO. Следующий пример относится к стандартной системе Solaris 8, в состав которой входит sendmail 8.9.3:
Система из примера в ответ на приветствие EHLO перечисляет девять команд. Две из них, EXPN и HELP, являются стандартными командами SMTP, реализованными не во всех системах (стандартные команды перечислены в табл. 3.1). 8BITMIME, SIZE, DSN и ETRN - расширения ESMTP, описанные в таблице Еще три ключевых слова из ответа- VERB, ONEX и XUSR. Эти команды специфичны для sendmail версии 8. Их определений нет в документах RFC. VERB предписывает серверу sendmail работать в режиме подробной диагностики. ONEX ограничивает сеанс транзакциями для отдельных сообщений. XUSR - это эквивалент ключа -U командной строки sendmail.
Как видно по трем последним ключевым словам, документы RFC допускают применение частных расширений ESMTP. Конкретный набор расширений зависит от системы. Например, в случае стандартной системы Solaris 2.5.1 в ответ на команду EHLO отображается
лишь три ключевых слова (EXPN, SIZE и HELP). То, какие расширения доступны, зависит от применяемой версии, равно как и настройки sendmail. Назначение команды EHLO - выявить конкретику расширений до начала почтового обмена SMTP.
ESMTP и MIME - важные механизмы, позволяющие передавать посредством электронной почты данные, отличные от ASCII-текста. Пользователи привыкли обмениваться данными в форматах, специфичных для конкретных приложений, и для многих людей электронная почта является основным механизмом передачи таких файлов.
Протоколы SMTP, POP, IMAP и расширения MIME - это жизненно важные составляющие почтовой системы, но в будущем их место могут занять иные протоколы электронной почты. Можно с уверенностью говорить лишь о том, что сеть постоянно меняется. Необходимо следить за изменениями и не забывать о полезных технологиях, планируя работу сети. В частности, две технологии, которые пользователи находят полезными, - совместный доступ к файлам и принтерам. В следующем разделе мы изучим серверы файлов и печати.
