Кратко

  • RFC 3516 позволил IMAP-серверу снять MIME Content-Transfer-Encoding и вернуть декодированный раздел через BINARY, включая NUL в literal8. Результат был производным представлением, а не исходной последовательностью сообщения.
  • Размер и частичные смещения относились к декодированным данным. Хранение, FETCH BODY, CRLF, кодированные заголовки и криптографически покрытые байты оставались отдельными границами.

Base64 помогал произвольным данным проходить через почтовые системы, не способные прозрачно переносить все октеты. При чтении по IMAP клиент мог загрузить увеличенное представление лишь для того, чтобы тут же его отменить. RFC 3516 считал такую цену заметной на медленных радиоканалах и при потоковой передаче мультимедиа.

Опубликованное в апреле 2003 года расширение перенесло декодирование на сервер. Объявив BINARY в CAPABILITY, сервер мог принять FETCH BINARY, удалить транспортное кодирование выбранного MIME-раздела и отправить результат. Экономия трафика не доказывала, что возвращены байты, в которых сообщение поступило в ящик.

У каждого раздела тела IMAP есть Content-Transfer-Encoding: явное либо подразумеваемое 7bit. В MIME CTE задаёт алгоритм обратного преобразования и область значений результата. Base64 и quoted-printable меняют представление. Кодирование-тождество может не требовать преобразования, но обозначать область, которую базовый literal IMAP не переносит, например из-за NUL.

Поэтому RFC разделил обработку на два логических действия. Сначала сервер выполняет декодирование CTE, затем определяет область полученных данных. Само наличие последовательности октетов ещё не выбирает протокольный элемент для её передачи.

Для более широкой области появился literal8. После тильды и счётчика он несёт любые октеты, включая NUL. Если результат остаётся восьмибитным и не содержит нуля, серверу следует использовать обычную строку. Клиент узнаёт более узкую область по обрамлению, не просматривая весь поток.

Счётчик точно подтверждает длину этого элемента ответа, но не форму хранения. Из него нельзя узнать, держал ли сервер данные декодированными, только что восстановил их из base64, нормализовал строки либо использовал иной допустимый внутренний формат.

BINARY.PEEK отделяет состояние почтового ящика. Подобно BODY.PEEK, он не устанавливает \\Seen неявно. Сохранение статуса непрочитанного — полезное операционное свойство, но не свидетельство происхождения байтов. Ответ остаётся созданным сервером декодированным видом.

BINARY.SIZE сообщает длину раздела после удаления CTE, то есть ожидаемое число октетов в соответствующем FETCH BINARY. Это не размер кодированного тела, не занятое место и не длина всего сообщения. RFC предупреждал о стоимости: некоторым серверам приходится полностью декодировать раздел только ради подсчёта.

Частичные запросы работают в координатах декодированного раздела. Смещение в base64-тексте или результате FETCH BODY не обязательно указывает на то же содержимое. Если продолжить BINARY-загрузку счётчиком от другого представления, можно получить формально верный фрагмент с неправильной логической позиции.

Не зная CTE, сервер не имел права угадывать. BINARY и BINARY.SIZE должны завершаться NO [UNKNOWN-CTE]. Такая квитанция доказывает неспособность выполнить названное преобразование, но не повреждение сообщения.

Позже RFC 4466 обновил схему кодов ответа IMAP, а RFC 9051 включил двоичные механизмы в IMAP4rev2. Для современной трассы версии важны. Однако кодированное тело, декодированный раздел и сохранённое представление не стали одной последовательностью.

Заголовки имели отдельную кодировку. Encoded-words из RFC 2047 размещают не-ASCII-текст в допустимых полях, но не являются CTE тела. RFC 3516 запрещал преобразовывать их при BINARY FETCH или APPEND. Команда декодировать раздел не разрешала переписывать всё, что похоже на код.

Текстовые разделы со строками подвергались ещё одной контролируемой нормализации. Сервер обязан был передавать их с IMAP-окончаниями CRLF независимо от локального хранения. Это стабилизировало интерфейс, но не позволяло считать ответ судебной копией байтов перевода строки на диске.

Граница хранилища была явной. Сервер мог держать бинарное содержимое без кодирования. Тем не менее BODYSTRUCTURE описывала сообщение так, будто бинарные разделы используют приемлемый для базового IMAP CTE, а FETCH BODY возвращал обещанную форму. Интерфейс был договором, а не снимком памяти.

APPEND проходил путь в обратную сторону. Клиент мог добавить данные с NUL в literal8. Если ящик не поддерживал бинарное хранение, сервер отклонял запрос через UNKNOWN-CTE. При поддержке сервер мог сменить CTE, но без потери данных полезной нагрузки.

Сохранность нагрузки не означает тождество сериализации. Base64, quoted-printable и прямая форма восстанавливают одинаковое содержимое из разных октетов. Поле CTE, свёртка заголовков и окончания строк входят в сообщение. Поэтому верное по содержанию изменение способно нарушить хеш или подпись над сериализованной формой.

RFC 3516 прямо предупреждал: лишние изменения кодирования делают бесполезными большинство криптографических операций над сообщением. Правила не противоречат друг другу. Одно сохраняет восстанавливаемое содержимое, другое зависит от точных байтов и полей. Слово «без потерь» не фиксирует вход проверяющей программы.

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

Различие Heng Lu между символической и операционной реальностью упорядочивает квитанции. BINARY в CAPABILITY — заявление о возможности. BINARY.SIZE — обещание длины одного вида. Счётный literal — наблюдение в соединении. Байты хранения, RFC 5322, MIME-нагрузка, отображение и вход подписи находятся в связанных, но незаменяемых слоях.

Достаточная цепочка сохраняет идентификатор и контекст, BODYSTRUCTURE, раздел, CTE, команду, влияние на \\Seen, код ответа, область, длину, смещение и хеш полученных байтов. Если важна исходная идентичность, отдельно получают raw message и его хеш. Для подписи записывают canonicalization и точную последовательность на входе проверяющего.

Тогда две истинные фразы не конфликтуют: сервер правильно вернул декодированное тело, но хеш файла не совпал с сериализованным сообщением. RFC 3516 определил преобразование между этими фактами, а не обещал их равенство.

Историческая польза была практичной: бинарное содержимое перестало оплачивать при каждом IMAP-чтении накладные расходы, придуманные для другого транспорта. Более глубокий урок касается доказательств. Сервер декодировал тело, клиент получил полезные октеты; исходному сообщению всё ещё требовались собственное извлечение, хеш и подтверждение.

Источники