Поддерживает ли протокол IMAP двоичный файл внутри многочастного тела?

Question

IMAP RFC:

8-битная текстовая и бинарная почта поддерживается с помощью
[MIME-IMB] кодировка передачи контента. Реализация IMAP4rev1 МОЖЕТ
передавать 8-битные или многооктетные символы в литералах, но СЛЕДУЕТ делать
так только когда [CHARSET] идентифицирован.

Несмотря на то, что задана двоичная кодировка, не закодированные двоичные строки не допускаются. "Двоичная строка" - это любая строка с NUL-символами. Реализации ДОЛЖНЫ кодировать двоичные данные в текстовую форму, такую ​​как BASE64, перед передачей данных. Строка с чрезмерным количеством символов CTL МОЖЕТ также считаться двоичной.

1. Если реализация должна преобразовать в base64, почему RFC говорит: "Определено двоичное кодирование тела". Поскольку каждый раз, когда нам нужно отправить данные в формате base64 (или в другом формате), двоичный файл не поддерживается. Или я что-то не так читаю?

2. IMAP поддерживает MIME, состоящий из нескольких частей, могут ли части внутри него иметь двоичные данные? что такое кодирование передачи контента?

Я новичок в IMAP/HTTP, причина для того, чтобы задать этот вопрос, я должен разработать сервер, который поддерживает как HTTP, так и IMAP, на HTTP-сервере получать данные в двоичном формате (ОГРОМНЫЕ многокомпонентные данные, с кодировкой передачи содержимого в двоичном виде), FETCH можно сделать в IMAP. Проблема в том, что мне нужно проанализировать данные и преобразовать каждую часть внутри multipart в base64, если IMAP не поддерживает двоичный файл. Который я думаю, является серьезной проблемой производительности.

Answer 1

Ответ, к сожалению, "возможно".

MIME RFC поддерживает двоичный файл, но IMAP RFC специально запрещает отправку NULL персонажи. Это вероятно потому, что они могут сбивать с толку текстовые парсеры, особенно написанные на C, где NULL имеет значение End of String.

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

Если ваши клиенты могут работать с MIME-Binary, вы, вероятно, будете в порядке.

Существует RFC 3516 для расширения IMAP для правильной поддержки BINARY, но он не получил широкого распространения.

В качестве примечания: почему вы используете Multipart MIME? Это странный выбор реализации для HTTP.