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

Поддержка кодировочных слов в программах чтения почты. Распознавание кодировочных слов в заголовках сообщений

Программа чтения почты должна осуществлять разбор сообщения и заголовков секций согласно правилам RFC-822, чтобы правильно распознать кодировочные слова. При этом следует выполнять следующие правила.

1. Поле заголовка любого сообщения или части тела, определенное как '*text', или любое поле заголовка, определенное пользователем, должно разбираться следующим образом. Начало обозначается LWS (HR|SP|CRLF); любая последовательность, вплоть до 75 печатных символов (не содержащая LWS) должна рассматриваться как кандидат в кодировочные слова и проверяться на соблюдение правил синтаксиса, описанных выше. Любую другую последовательность печатных символов следует рассматривать как обычный ASCII-текст
2. Любое поле заголовка, не определенное как '*text', должно разбираться согласно синтаксическим правилам для данного поля заголовка. Однако любое слово, которое появляется в пределах фразы, должно обрабатываться как кодировочное слово, если оно отвечает синтаксическим правилам. В противном случае оно должно обрабатываться как обычное слово
3. Внутри комментария любая последовательность с длиной до 75 символов (не содержащая LWS), которая отвечает синтаксическим правилам, должна обрабатываться как кодировочное слово. В противном случае она должно обрабатываться как обычный текст комментария
4. Поле заголовка MIME-Version может отсутствовать в кодировочных словах, которые обрабатываются согласно данной спецификации. Причиной является то, что программа чтения почты не предполагает разбирать весь заголовок сообщения, прежде чем отображать строки, которые могут содержать кодировочные слова

Транспортное кодирование

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

1. Многие виды транспорта, особенно пересылка сообщений, могут обрабатывать только данные, состоящие из относительно коротких строк текста. Существуют также строгие ограничения на то, какие символы могут использоваться в этих строках текста. Некоторые виды транспортировки допускают использование только субнабора US-ASCII, а другие не могут работать с некоторыми символьными последовательностями. Транспортное кодирование используется для того, чтобы преобразовать двоичные данные в текстовую форму. Примеры такого сорта транспортного кодирования включают применение base64 и закавыченных строк печатных символов, определенных в RFC-2045
2. Изображение, аудио, видео и даже объекты приложений имеют иногда довольно большой размер. Алгоритмы сжатия часто весьма эффективны для сокращения объектов большого размера. Транспортное кодирование может использоваться также для того, чтобы с помощью универсальных алгоритмов сжатия без потерь сократить размер MIME-объектов
3. Транспортное кодирование может быть определено как средства представления существующих форматов кодирования в контексте MIME.

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

Каноническая модель кодирования

Процесс формирования объекта MIME можно смоделировать в виде цепочки последовательных шагов. Заметим, что эти шаги сходны с используемыми в PEM [RFC-1421] и они реализуются для каждого внутреннего уровня тела сообщения.

1. Создание локальной формы.

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

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

   Например, в случае чистого текста данные должны преобразовываться с использованием поддерживаемого символьного набора, а строки должны завершаться CRLF, как этого требует RFC-822. Заметьте, что ограничения на длины строк, налагаемые RFC-822, игнорируются, если на следующем шаге выполняется кодирование с использованием base64 или закавыченных строк печатных символов.
3. Применение транспортного кодирования.

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

   Закодированное тело вкладывается в объект MIME, снабженный соответствующими заголовками. Объект затем вкладывается в объект более высокого уровня, если это требуется.

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

1. Во многих вариантах преобразование к канонической форме предваряется некоторой трансляцией в самой кодирующей программе, которая непосредственно работает с локальным форматом. Например, локальное соглашение о разрывах строк для текста тел может реализоваться с помощью самого кодировщика, который владеет информацией о характере локального формата
2. Выходные данные кодировщика могут проходить через один или более дополнительных ступеней, прежде чем будут переданы в виде сообщения. Выход кодировщика как таковой может не согласовываться с форматами, специфицированными в RFC-822. В частности, если это окажется удобно преобразователю, разрыв строки может обозначаться каким то иным способом, а не CRLF, как этого требует стандарт RFC-822

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

Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64

должно быть сначала представлено в форме text/foo, затем, если необходимо, представлено в символьном наборе и, наконец, трансформировано с использованием алгоритма base64 в формат, безопасный для пересылки через любые шлюзы.

Некоторые проблемы вызывают почтовые системы, которые для обозначения перехода на новую строку используют нечто отличное от CRLF, принятого в стандарте RFC-822. Важно отметить, что эти форматы не являются каноническими RFC-822/MIME. Заметим также, что форматы, где вместо последовательности CRLF заносится, например, LF, не способны представлять сообщения MIME, содержащие двоичные данные с октетами LF, которые не являются частью последовательности CRLF.