Звуки

video

mpeg, mp4, quicktime

Видеофильмы

model

vrml

3D-модель

application

onoctet-stream, pdf, javascript, zip

Данные, производимые приложениями

message

http, rfc822

Инкапсулированное сообщение

multipart

mixed, alternative, parallel, digest

Комбинация нескольких типов

Тип model был добавлен позднее, чем остальные типы контента. Он предназначен для описания 3D-моделей. Однако пока он не особо широко используется.

Тип application (приложение) предназначен для всех форматов, которые не покрываются остальными типами и требуют от приложения интерпретации данных. Мы перечислили подтипы pdf, javascript и zip как примеры PDF-документов, программ на Java-Script и архивов в формате Zip соответственно. Пользовательские агенты, получающие этот контент, используют для его отображения стороннюю библиотеку или внешнюю программу. Отображение может быть интегрировано в пользовательский агент, а может и не быть.

Используя типы MIME, пользовательские агенты расширяют возможности обработки новых типов контента по мере их появления. Это значительное преимущество. С другой стороны, многие новые формы контента обрабатываются и интерпретируются приложениями, что представляет некоторую опасность. Совершенно очевидно, что запуск произвольной исполняемой программы, которая пришла по электронной почте от «друга», влечет за собой определенный риск. Такая программа может серьезно повредить те части компьютера, к которым получает доступ, особенно если она может считывать и создавать файлы и использовать сеть. Форматы документов также могут нести определенную угрозу, хотя это менее очевидно. Подобную возможность нельзя исключать, так как форматы типа PDF являются замаскированными развитыми языками программирования. Несмотря на то что они интерпретируются и ограничены в доступной им области, ошибки в интерпретаторе часто позволяют документам избежать ограничений обходными путями.

Помимо этих примеров, существует еще множество подтипов приложений, так как и самих приложений немало. Так, например, тип octet-stream (байтовый поток) представляет собой просто последовательность никак не обрабатываемых байтов. Он приписывается при невозможности описать контент (если нет ни одного типа, который подходил бы лучше). Получив такой поток, пользовательский агент должен, вероятно, предложить пользователю сохранить его в виде файла. Последующая обработка файла целиком зависит от пользователя, который, предположительно, знает, с каким контентом он столкнулся.

Последние два типа, о которых пойдет речь, полезны при создании сообщений и манипулировании ими. Тип message позволяет помещать одно сообщение в другое. Это может быть полезно для переадресации письма. Если внутри одного сообщения заключено целое сообщение стандарта RFC 822, следует использовать подтип rfc822. Сходным образом обычно инкапсулируются документы в формате HTML. А подтип partial позволяет разбивать сообщение на части и передавать их отдельно (например, в случае, когда инкапсулированное сообщение является слишком длинным). Параметры обеспечивают восстановление сообщения получателем из отдельных фрагментов в правильном порядке.

Наконец, тип multipart позволяет составлять сообщение из нескольких частей, при этом начало и конец каждой части отчетливо указывается. Подтип mixed позволяет создавать сообщение из частей различных форматов. Многие почтовые программы позволяют пользователю прикрепить к текстовому сообщению одно или более приложений. Эти приложения пересылаются с использованием типа multipart. В случае применения подтипа alternative, напротив, каждая часть должна содержать одно и то же сообщение, но в другом виде или другой кодировке. Например, сообщение может быть послано в виде простого ASCII-текста, а также в форматах HTML и PDF. Грамотно созданный пользовательский агент, получив такое сообщение, сначала попытается отобразить его в формате, зависящем от предпочтений пользователя. Скорее всего, это будет PDF, если данный формат допустим. Если это по какой-либо причине невозможно, тогда производится попытка отобразить часть в формате HTML. Если и это невозможно, отображается ASCII-текст. Части следует располагать в порядке увеличения сложности, чтобы даже старые (до MIME) пользовательские агенты смогли отобразить сообщение, хотя бы в виде простого ASCII-текста.

Подтип alternative также может использоваться для сообщений, посылаемых одновременно на разных языках. В этом контексте знаменитый розеттский камень, найденный в Египте, может считаться одним из ранних вариантов сообщений типа multipart/alternative.

Что касается двух других примеров подтипов, подтип parallel используется, когда все части должны «просматриваться» одновременно. Например, в фильмах часто есть видео- и аудиодорожки. Гораздо приятнее смотреть фильм, если эти две дорожки проигрываются одновременно, а не последовательно. Подтип digest используется, когда несколько сообщений объединяются в одно составное. Например, какая-нибудь дис

куссионная группа в Интернете может собирать сообщения от подписчиков, а затем высылать их в виде единого сообщения типа multipart/digest.

Пример того, как типы MIME могут использоваться для сообщений электронной почты, приведен в листинге 7.2. В данном случае поздравление с днем рождения посылается одновременно в двух альтернативных формах: в виде HTML и в виде аудиозаписи. Если у получателя есть возможность воспроизвести звуковой файл, пользовательский агент воспроизведет его. В этом примере звук передается как подтип message/external-body по ссылке, так что сначала пользовательский агент должен обратиться за звуком к файлу birthday.snd через FTP. В противном случае на экране получателя в полной тишине отобразится текст сообщения. Эти две части письма разделены двойными дефисами, за которыми следует (определяемая пользователем) строка, указанная как значение параметра boundary (граница).

Листинг 7.2. Сообщение типа multipart, содержащее HTML и аудио

Обратите внимание: заголовок Content-Type трижды встречается в данном сообщении. На верхнем уровне он указывает, что сообщение состоит из нескольких частей. Для каждой части он сообщает ее тип и подтип. Наконец, в теле второй части сообщения он указывает пользовательскому агенту тип внешнего файла. Чтобы подчеркнуть это различие, мы использовали в последнем случае строчные символы, хотя для всех заголовков регистр символа не имеет значения. Для внешнего тела в формате, отличном от 7-разрядного ASCII, также требуется заголовок content-transfer-encoding.

7.2.4. Пересылка сообщений

Теперь, когда мы описали пользовательские агенты и сообщения электронной почты, пора разобраться в том, как агенты передачи сообщений доставляют их от отправителя получателю. Передача почты осуществляется посредством протокола SMTP.

Для этого проще всего установить транспортное соединение от машины-источника до машины-приемника, а затем просто передать по нему сообщение. Так изначально работал SMTP. Однако за последние годы возникло два разных способа использования SMTP. Первый — для подачи почтового сообщения (mail submission, первый шаг в архитектуре e-mail на рис. 7.4). Этим способом пользовательские агенты переправляют сообщения в почтовую систему для их дальнейшей отправки. Второй вариант использования — передача сообщений между агентами передачи сообщений (шаг 2 на рис. 7.4).

Такая последовательность обеспечивает доставку почты на всем пути от посылающего до получающего агента передачи сообщений за один шаг. Окончательная доставка происходит при участии других протоколов. Ее мы опишем в следующем разделе.

В этом разделе мы расскажем об основах протокола SMTP и механизме его расширения. Затем мы обсудим то, как он различным образом используется для принятия подачи и передачи сообщений.