Протокол электронной почты

Тип среды Message

Часто желательно при посылке почты вложить туда какое-то другое сообщение. Для решения этой задачи определен специальный тип среды message. В частности, для вложения в сообщения RFC-822 служит субтип rfc822.

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

Тип среды message/rfc822 указывает, что тело содержит инкапсулированное сообщение. Однако в отличие от сообщений верхнего уровня RFC-822, ограничение, связанное с обязательным присутствием в теле message/rfc822 заголовков From, Date, и, по крайней мере, одного адреса места назначения, здесь удалено. Необходимо лишь присутствие одного из заголовков From, Subject или Date. Следует заметить, что, несмотря на использование чисел 822, объект message/rfc822 не должен абсолютно следовать регламентациям RFC-822. Более того, сообщение message/rfc822 может быть статьей новостей или сообщением MIME.

В теле объекта message/rfc822 не разрешены никакие кодировки помимо 7bit, 8bit или binary. Поля заголовка сообщения содержат только US-ASCII в любом регистре, а информация в теле может быть закодирована. Не-US-ASCII-текст в заголовках инкапсулированного сообщения может быть специфицирован с использованием механизма, описанного в документе RFC-2047.

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

Так как данные типа message могут не быть закодированы в виде base64 или закавыченной строки печатных символов, может возникнуть проблема, если объекты message/partial созданы в среде, которая поддерживает двоичный или 8-битовый обмен. Проблема возникает из-за того, что двоичные данные надо будет разбить на несколько сообщений message/partial, каждое из которых требует двоичного транспорта. Если такие сообщения встретят по пути шлюз с 7-битовой передачей, не будет никакой возможности перекодировать эти фрагменты для 7-битовой среды. Можно, конечно, дождаться прихода всех составных частей, собрать исходный объект, закодировать его с помощью, например, base64, после чего начать все с начала. Но даже такой сложный сценарий может оказаться неосуществимым из-за того, что фрагменты могут транспортироваться разными путями. По этой причине было специфицировано, что объекты типа message/partial должны всегда иметь транспортное кодирование 7bit (по умолчанию). В частности, даже для сред, которые поддерживают двоичный или 8-битовый обмен, использование транспортного кодирования 8bit или binary для MIME-объектов типа message/partial запрещено. Это, в свою очередь, предполагает, что внутреннее сообщение не должно использовать кодирование 8bit или binary. Так как некоторые агенты пересылки сообщений могут выбрать автоматическую фрагментацию длинных сообщений, а также из-за того, что эти агенты могут использовать разные пороги фрагментации, может так получиться, что фрагменты после сборки в свою очередь окажутся частями сообщения. Это вполне допустимо.

В поле Content-Type типа message/partial необходимо специфицировать три параметра. id — уникальный идентификатор, который должен использоваться для привязки фрагментов друг к другу. number — целое число, которое является номером фрагмента. total — целое число, характеризующее полное число фрагментов. Число фрагментов является опционным и обязательно присутствует только в последнем фрагменте. Заметим также, что эти параметры могут быть заданы в любом порядке. Таким образом, второй сегмент 3-фрагментного сообщения может иметь поля заголовка одного из следующих видов.

Content-Type: Message/Partial; number=2; total=3;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Content-Type: Message/Partial;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
number=2

Но в третьем сегменте должно быть специфицировано полное число фрагментов.

Content-Type: Message/Partial; number=3; total=3;
Id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Заметьте, что нумерация фрагментов начинается с 1, а не c 0.

Когда фрагменты объекта, разорванные таким способом, складываются вместе, результатом всегда будет исходный MIME-объект, который может иметь свое собственное поле заголовка Content-Type и, следовательно, иметь любой другой тип данных.

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

1. Фрагментирующие агенты должны разделять сообщения только по границам строк. Это ограничение вводится из-за того, что при несоблюдении данного правила возникнет транспортная проблема сохранения семантики сообщения, не заканчивающегося последовательностью CRLF. Многие виды транспорта не способны решить такую задачу
2. Все поля заголовка исходного вложенного сообщения, за исключением тех, чьи имена начинаются с "Content-", и специфических полей заголовка Subject, Message-ID, Encrypted и MIMEVersion, должны копироваться в новое сообщение
3. Поля заголовка вложенного сообщения, начинающиеся с "Content-", плюс поля Subject, Message-ID, Encrypted и MIMEVersion, должны быть добавлены к полям нового сообщения. Любые поля заголовка, которые не начинаются с "Content-" (за исключением полей Subject, Message-ID, Encrypted и MIMEVersion) будут проигнорированы и отброшены
4. Все поля заголовка второго и любых последующих вложенных сообщений отбрасываются принимающей программой в процессе сборки

Если аудио-сообщение разделено на два фрагмента, первая часть может выглядеть как:

X-Weird-Header-1: Foo
From: Bill@host.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2)
Message-ID:
MIME-Version: 1.0
Content-type: message/partial; id="ABC@host.com";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID:
Subject: Audio mail
Content-type: audio/basic
Content-transfer-encoding: base64
... здесь помещается первая половина закодированных аудиоданных ...

а вторая часть может выглядеть следующим образом:

From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
MIME-Version: 1.0
Message-ID:
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... здесь помещается вторая половина закодированных аудиоданных ...

Затем, когда фрагментируемое сообщение оказывается собрано, результат, отображаемый для пользователя, должен выглядеть как:

X-Weird-Header-1: Foo
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID:
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... здесь помещается первая половина закодированных аудиоданных ...
... здесь помещается вторая половина закодированных аудиоданных ...

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

Наконец, следует заметить, что поле Encrypted заголовка является устаревшим из-за внедрения конфиденциальной почты PEM (Privacy Enhanced Messaging; RFC-1421, RFC-1422, RFC-1423, RFC-1424), но правила, описанные выше, несмотря ни на что, описывают правильный путь его обработки, если оно встретится в контексте прямого и обратного преобразования фрагментов message/partial.

Субтип external-body указывает, что в сообщении содержатся не данные, а ссылка на место, где эти данные находятся. В этом случае параметры описывают механизм доступа к внешним данным.

Когда объект MIME имеет тип message/external-body, он состоит из заголовка, двух последовательностей CRLF и заголовка для инкапсулированного сообщения. Если появится еще одна пара последовательностей CRLF, это завершит заголовок инкапсулированного сообщения. Однако, так как тело инкапсулированного сообщения само является внешним, оно не появится вслед за заголовком. Например, рассмотрим следующее сообщение:

Content-type: message/external-body;
access-type=local-file;
name="/u/nsb/Me.jpeg"
Content-type: image/jpeg
Content-ID:
Content-Transfer-Encoding: binary
Это в действительности не тело!

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

Инкапсулированные заголовки во всех объектах message/externalbody должны включать в себя поле заголовка Content-ID, чтобы предоставить уникальный идентификатор, который служит для ссылки на данные. Этот идентификатор может быть использован в процессе кэширования и для распознавания входных данных, когда типом доступа является mailserver.

Заметим, что, как это специфицировано здесь, лексемы, которые описывают данные внешнего тела, такие, как имена файлов и команды почтового сервера, должны быть записаны с использованием символьного набора US-ASCII.

Как с message/partial, объекты MIME типа message/external-body имеют транспортное кодирование 7-бит (по умолчанию). В частности, даже в среде, которая поддерживает 8-битовую транспортировку, использование транспортного кодирования 8bit или binary категорически запрещено для объектов типа message/external-body.

Типы доступа ftp и tftp

Тип доступа FTP или TFTP указывают, что тело сообщения доступно в виде файла с помощью протоколов FTP [RFC-959] или TFTP [RFC-783], соответственно. Для этих типов доступа необходимы следующие параметры.

1. NAME (имя). Имя файла, который содержит тело данных
2. SITE (узел). ЭВМ, с которой может быть получен файл с помощью данного протокола. Это должно быть официально зарегистрированное имя, а не псевдоним
3. Прежде чем какие-либо данные будут извлечены с помощью FTP, пользователь должен выполнить процедуру аутентификации (ввести имя и пароль) на машине, указанной в параметре SITE. По соображениям безопасности имя и пароль не специфицируются параметрами типа доступа, они должны быть получены непосредственно от пользователя

Кроме того, следующие параметры являются опционными:

1. DIRECTORY (каталог). Каталог, из которого должен быть взят файл с именем, заданным параметром NAME
2. MODE (режим). Строка символов, не зависящая от регистра ввода и указывающая на режим, который должен использоваться при извлечении информации. Допустимыми значениями параметра типа доступа TFTP являются NETASCII, OCTET и MAIL, как это определено для протокола TFTP [RFC- 783]. Допустимыми значениями параметра для типа доступа FTP являются ASCII, EBCDIC, IMAGE и LOCALn, где "n" — целое число, обычно 8. Они соответствуют типам представления "A" "E" "I" и "L n", как это задано протоколом FTP [RFC-959]. Заметим, что BINARY и TENEX не являются корректными значениями для MODE и что вместо этого следует использовать OCTET, IMAGE или LOCAL8. Если параметр MODE не задан, значением по умолчанию является NETASCII для TFTP и ASCII во всех прочих случаях

Тип доступа local-file

Тип доступа local-file указывает, что тело данных доступно в виде файла на локальной ЭВМ. Для этого типа доступа определены два дополнительные параметра.

1. NAME (имя). Имя файла, который содержит тело данных. Этот параметр является обязательным для типа доступа local-file
2. SITE (узел). Спецификатор домена для данной ЭВМ или набора машин, которые имеют доступ к данному информационному файлу. Этот опционный параметр используется для описания локального указателя на данные, т.е., узел или группу узлов, откуда данный файл доступен. В качестве символов подмены в имени домена могут использоваться звездочки, как, например, в "*.bellcore.com", чтобы указать на группу ЭВМ, откуда данные доступны непосредственно

Тип доступа mail-server

Тип доступа mail-server указывает, что тело данных доступно на почтовом сервере. Для этого типа доступа определены два дополнительные параметра.

1. SERVER (сервер). Спецификация адреса почтового сервера, с которого могут быть получены данные. Этот параметр является обязательным для типа доступа mail-server
2. SUBJECT (тема сообщения). Тема сообщения (subject), которая используется в почтовом сообщении с целью получения данных. Этот параметр является опционным

Так как почтовые серверы воспринимают разнообразные синтаксисы, некоторые из которых являются многострочными, полная команда, которая должна быть послана почтовому серверу, не включается в качестве параметра с полем заголовка content-type. Вместо этого она заносится как тело-фантом, когда тип среды соответствует message/external-body, а типом доступа — mail-server.

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

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