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

В нотации BNF значение поля заголовка Content-Type определяется следующим образом:

Заметим, что определение tspecials совпадает с определением specials в RFC 822 с добавлением трех символов "/", "?" и "=" и удалением "." (точка).

Заметим также, что спецификация субтипа является обязательной (MANDATORY) — она не может быть удалена из поля заголовка Content-Type. Не существует субтипов по умолчанию. Тип, субтип и имена параметров не зависят от регистра, в которых они напечатаны. Например, TEXT, Text и TeXt являются эквивалентными типами среды верхнего уровня. Значения же параметров в норме чувствительны к регистру, в котором они напечатаны, но иногда интерпретируются без учета регистра — в зависимости от приложения. (Например, границы типа multipart являются чувствительными к регистру, а параметр access-type для сообщения message/External-body не чувствителен).

Обратите внимание, что значение строки в кавычках не включает в себя сами кавычки. В полях заголовка в соответствии с RFC 822 допускаются комментарии. Таким образом, две приведенные ниже формы являются эквивалентными.

Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii".

Предполагается, что имена субтипов при их применении не вызовут конфликтов. Так, недопустимо, чтобы в различных приложениях "Content-Type: application/foobar" означало различные вещи. Существует два приемлемых механизма определения новых субтипов среды.

1. Частные значения (начинающиеся с X-) могут быть определены для двух взаимодействующих агентов без официальной регистрации или стандартизации.
2. Новые стандартные значения должны регистрироваться IANA, как это описано в RFC 2048.

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

Content-type: text/plain; charset=us-ascii

Это значение подразумевается, если не специфицировано поле заголовка Content-Type. Рекомендуется, чтобы это значение по умолчанию использовалось в случае, когда встретилась нераспознанное значение поля заголовка Content-Type. В присутствии поля заголовка MIME-Version и отсутствии поля Content-Type, принимающий агент пользователя может также предположить, что отправитель предлагает простой текст в ASCII-кодировке. Простой ASCII-текст может предполагаться в отсутствии MIME-Version или в присутствии синтаксически некорректного поля заголовка Content-Type, хотя это может и не совпадать с намерениями отправителя.

Многие типы среды, которые могут передаваться посредством электронной почты, представляются в своем естественном формате, таком, как 8-битовые символы или двоичные данные. Такие данные не могут быть переданы посредством некоторых транспортных протоколов. Например, RFC 821 ( SMTP ) ограничивает почтовые сообщения 7-битовым символьным набором ASCII со строками, короче 1000 символов, включая строчные разделители CRLF.

Таким образом, необходимо определить стандартный механизм кодировки таких данных в 7-битный формат с короткими строками. В MIME для этой цели используется поле заголовка "Content-Transfer-Encoding".

Значения полей Content-Transfer-Encoding представляют собой лексему, характеризующую тип кодирования, как это описано ниже.

Эти значения не чувствительны к регистру, в котором напечатаны. Записи Base64, BASE64 и bAsE64 эквивалентны. Тип кодировки 7BIT требует, чтобы тело уже имело 7-битовое представление, пригодное для передачи. Это значение по умолчанию означает, что в отсутствии поля Transfer-Encoding предполагается "Content-Transfer-Encoding: 7BIT".

Лексема Content-Transfer-Encoding предоставляет два вида информации. Она специфицирует, какому виду кодового преобразования подвергнуто тело сообщения и, следовательно, какая процедура декодирования должна использоваться при восстановлении исходного вида сообщения.

Преобразовательная часть любого Content-Transfer-Encodings специфицирует явно или неявно алгоритм декодирования, который либо восстановит исходный вид последовательности, либо обнаружит ошибку. Преобразования Content-Transfer-Encodings для нормальной работы никогда не требуют какой-либо дополнительной внешней информации. Преобразование заданной последовательности октетов в другую эквивалентную кодовую последовательность является совершенно легальным.

В настоящее время определены три преобразования: тождественное (никакого преобразования), преобразование в последовательность печатных символов и в последовательность кодов base64.

Значения Content-Transfer-Encoding 7bit, 8bit и binary означают, что никакого преобразования не произведено. Они указывают на тип тела сообщения, и позволяют предполагать, какое кодирование может потребоваться при передаче данных.

Кодирование в последовательность печатных символов или в кодовую последовательность base64 предполагает преобразование из произвольного исходного формата в представление 7bit, что позволяет передачу через любые транспортные среды.

Всегда должна использоваться корректная метка Content-Transfer-Encoding. Пометка данных, преобразованных программой UUENCODE и содержащих 8-битовые символы, как 7bit не допустима — такие данные должны помечаться только как binary.

При прочих равных условиях предпочтительным представлением является последовательность печатных символов или кодов base64.

Передача почтовых сообщений, закодированных программой uuencode, описана в документе RFC 1652. Но следует иметь в виду, что ни при каких обстоятельствах Content-Transfer-Encoding binary нельзя считать приемлемым для e-mail. Однако когда используется MIME, двоичное тело сообщения может быть помечено как таковое.

Программисты могут, если необходимо, определить частные значения Content-Transfer-Encoding. При этом должны использоваться x-лексемы, которые представляют собой имена с префиксом X-, что указывает на нестандартный статус, например, "Content-Transfer-Encoding: x-my-newencoding". Дополнительные стандартизованные значения Content-Transfer-Encoding должны быть специфицированы в официальных документах RFC.

В отличие от типов среды и субтипов, формирование новых значений Content-Transfer-Encoding категорически не рекомендуется, так как может привести к полному выходу из строя системы.

Если поле заголовка Content-Transfer-Encoding появляется как часть заголовка сообщения, оно относится ко всему телу сообщения. Если поле заголовка Content-Transfer-Encoding появляется в качестве части заголовка объекта, то зоной его действия будет тело этого объекта. Если объект имеет тип multipart, то Content-Transfer-Encoding не может иметь значение 7bit, 8bit или binary. Следует заметить, что большинство типов среды определены в терминах октетов, а не бит, поэтому описываемые механизмы относятся к кодировке произвольных потоков октетов, а не бит. Если необходимо закодировать битовую последовательность, она должна быть преобразована в последовательность октетов с сетевой последовательностью бит (big-endian), в которой более ранние биты становятся старшими битами октетов. Битовые потоки, длина которых не кратна 8, должны быть дополнены нулями.

Механизмы кодировки, определенные здесь, осуществляют преобразование любых данных в ASCII. Таким образом, предположим, например, что объект имеет следующие поля заголовка:

Content-Type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: base64

Это должно интерпретироваться так, что тело имеет кодировку base64, а исходные данные имели представление в ISO-8859-1.

Определенные значения Content-Transfer-Encoding могут использоваться только с определенными типами среды. В частности, категорически запрещено применять любую кодировку отличную от 7bit, 8bit или binary с любым составным типом среды, т.e. включающим и другие поля Content-Type. В настоящее время разрешены составные типы среды multipart и message. Все кодировки, допустимые для тел типа multipart или message должны использоваться на самом внутреннем уровне.

Следует также заметить, что по определению, если составной объект имеет значение transfer-encoding равное 7bit, но один из составляющих объектов имеет менее регламентирующее значение, например, 8bit, тогда либо внешняя метка 7bit является ошибкой, либо внутренняя метка 8bit устанавливает слишком высокое требование к транспортной системе (следовало проставить 7bit).

Хотя запрет использования content-transfer-encodings для составного тела может показаться чрезмерно регламентирующим, следует избегать вложенных кодирований, в которых данные подвергаются последовательно обработке несколькими алгоритмами. Вложенные кодирования заметно повышают сложность агентов пользователя. Помимо очевидных проблем эффективности при множественном кодировании, они могут затемнить базовую структуру сообщения. В частности, они могут подразумевать, что необходимо несколько операций декодирования, чтобы определить, какие типы тел содержит сообщение. Запрет вложенных кодировок может осложнить работу некоторых почтовых шлюзов, но это представляется меньшей бедой, чем осложнение жизни агентов пользователя при вложенном кодировании.

Любой объект с нераспознанным значением Content-Transfer-Encoding должен рассматриваться, как если бы он имел код Content-type "application/octet-stream", вне зависимости от того, что утверждается полем заголовка Content-Type.

Может показаться, что Content-Transfer-Encoding может быть выяснено из характеристик среды, для которой нужно осуществить кодирование, или, по крайней мере, что определенное Content-Transfer-Encodings может быть предназначено для использования с определенными типами среды. Есть несколько причин, почему это не так. Во-первых, существуют различные типы транспорта, используемые для почты, некоторые кодирования могут подходить для определенных комбинаций типов среды и транспорта, но быть непригодными для других. Например, при 8-битовой передаче, при определенном символьном наборе для текста не потребуется никакого кодирования, в то время как такое кодирование очевидно необходимо для 7-битового SMTP.

Во-вторых, определенные типы среды могут требовать различного транспортного кодирования при разных обстоятельствах. Например, многие PostScript-тела могут целиком состоять из коротких строк 7-битовых кодов и, следовательно, совсем не требуют кодирования. Другие тела PostScript (в особенности те, что используют механизм двоичного кодирования уровня 2 PostScript) могут быть представлены с использованием двоичного транспортного кодирования. Наконец, так как поле Content-Type ориентировано на то, чтобы предоставлять открытые механизмы спецификации, строгие ассоциации типов среды и кодирования эффективно соединяют спецификацию прикладного протокола с определенным транспортом нижнего уровня. Это нежелательно, так как разработчики типа среды не должны заботиться обо всех видах транспорта и их особенностях.

Кодирование с использованием закавыченных строк печатных символов и кодов base64 устроено так, чтобы позволить взаимные преобразования. Единственная проблема, которая здесь возникает, — это обработка принудительных разрывов строк для закавыченных последовательностей печатных символов. При преобразовании закавыченных строк в коды base64 принудительные разрывы строк отображаются последовательностями CRLF. Аналогично, последовательность CRLF в канонической форме данных, полученной после декодирования из base64, должна преобразоваться в принудительный разрыв строки в случае представления текста в виде закавыченной строки печатных символов. Каноническая модель кодирования представлена в документе RFC 2049.