Протокол электронной почты. Примеры и расширения

Примеры и дальнейшие расширения

Когда используется механизм внешнего тела в сочетании с типом среды multipart/alternative, это расширяет функциональность multipart/alternative, так как включает случай, когда один и тот же объект может быть получен через разные механизмы доступа. Когда это сделано, отправитель сообщения должен упорядочить части по предпочтительности формата, а затем по механизму доступа.

Для распределенных файловых систем очень трудно знать заранее группу машин, где файл может быть доступен непосредственно. Следовательно, имеет смысл предоставить как имя файла на случай его прямой доступности, так имена одного или нескольких узлов, где может быть доступен этот файл. Программные реализации могут пытаться извлечь удаленные файлы, используя FTP или другой протокол. Если внешнее тело доступно за счет нескольких механизмов, отправитель может включить несколько объектов типа message/external-body в секции тела объекта multipart/alternative.

Однако механизм внешнего тела не ограничивается извлечением файлов, как это показывается типом доступа mail-server. Помимо этого, можно предположить, например, использование видеосервера для внешнего доступа к видеоклипам.

Поля заголовка вложенного сообщения, которые появляются в теле message/external-body, должны применяться для декларации типа среды внешнего тела, если оно представляет собой нечто отличное от чистого текста US-ASCII, так как внешнее тело не имеет секции заголовка, чтобы декларировать тип. Аналогично здесь должно быть также декларировано любое транспортное кодирование, отличное от 7bit. Таким образом, полное сообщение message/external-body, относящееся к объекту в формате PostScript, может выглядеть как:

From: От кого-то
To: Кому-то
Date: Когда-то
Subject: Нечто
MIME-Version: 1.0
Message-ID: <id@itep.com>
Content-Type: multipart/alternative; boundary=42
Content-ID:
--42
Content-Type: message/external-body; name="BodyFormats.ps";
site="thumper.bellcore.com"; mode="image";
access-type=ANON-FTP; directory="pub";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
--42
Content-Type: message/external-body; access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
--42
Content-Type: message/external-body;access-type=mail-server
< server="listserv@bogus.bitnet">
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
Content-ID:
get RFC-MIME.DOC
--42--

Заметим, что в вышеприведенных примерах в качестве транспортного кодирования для Postscript данных предполагается 7bit.

Подобно типу message/partial, тип среды message/external-body предполагается прозрачным, т.е. передается тип данных внешнего тела, а не сообщение с телом данного типа. Таким образом, заголовки внешней и внутренней частей должны быть объединены с использованием правил, изложенных выше для message/partial. В частности, это означает, что поля Content-type и Subject переписываются, а поле From сохраняется в неизменном виде.

Заметьте, что, так как внешние тела не передаются вместе с указателем, они не должны удовлетворять транспортным ограничениям, которые налагаются на сам указатель. В частности, почтовая транспортная среда Интернет может реализовать 7-битовый обмен и накладывать ограничения на длину строк, но они не распространяются на указатели на двоичное внешнее тело. Таким образом, транспортное кодирование здесь не обязательно, но допустимо.

Заметим, что тело сообщения типа message/external-body регламентируется базовым синтаксисом сообщения RFC 822. В частности, все, что размещено перед первой парой CRLF является заголовком, в то время как все, что следует после заголовка, представляет собой данные, которые игнорируются для большинства типов доступа.

Подобно тому, как это рассказано в начале описания MIME, методика сконструирована так, чтобы допустить использование не-ASCII символов в заголовках сообщения, чтобы специфические почтовые программы (а) удаляли некоторые поля заголовков, сохраняя другие, (b) меняли содержимое адресов в полях To или Cc, (c) меняли вертикальный порядок размещения полей заголовка. Кроме того, некоторые почтовые программы не всегда способны корректно интерпретировать заголовки сообщений, в которых встречаются некоторые редко используемые рекомендации документа RFC 822, например, символы обратной косой черты для выделения специальных символов типа "<", "," или ":".

Расширения, описанные здесь, не базируются на редко используемых возможностях RFC-822. Вместо этого определенные последовательности обычных печатных ASCII-символов (известных как encoded-words — кодировочные слова) зарезервированы для использования в качестве кодированных данных. Синтаксис кодированных слов таков, что они вряд ли могут появиться в нормальном тексте заголовков сообщений. Более того, символы, используемые в кодировочных словах, не могут иметь специального назначения в контексте, где появляются эти слова.

Вообще, encoded-word представляет собой последовательность печатных ASCII-символов, которая начинается с "=?", завершается "?=" и имеет два "?" между ними. Оно специфицирует символьный набор и метод кодирования, а также включает в себя оригинальный текст в виде графических ASCII-символов, созданный согласно правилам данного метода кодирования.

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

Система чтения почты, которая реализует данную спецификацию, распознает кодировочные слова, когда они встречаются в определенной части заголовка сообщения. Вместо того, чтобы отображать кодировочное слово, программа осуществляет декодирование исходного текста с использованием соответствующего символьного набора.

Данный документ в заметной мере базируется на нотации и терминах RFC-822 и RFC-2045. В частности, синтаксис для ABNF, применяемый здесь, определен в RFC-822. Среди терминов, определенных в RFC-822 и использованных в данном документе: addr-spec (спецификация адреса), атом, CHAR, комментарий, CTL, ctext, linear-white-space (HT|SP|CRLF), фраза, quoted-pair, закавыченная строка, пробел и слово. Успешная реализация расширения этого протокола требует тщательного внимания к определениям этих терминов в RFC-822.

Когда в данном документе встречается термин ASCII, он относится к 7-битовому стандарту, ANSI X3.4-1986. Имя этого символьного набора в MIME US-ASCII.