Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Наконец, тип 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).

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