IMAPプロトコルはマルチパート本体のバイナリをサポートしていますか？

Question

IMAPのRFC：

8ビットのテキストおよびバイナリメール
[MIME-IMB]コンテンツ転送符号化の使用を介して支持されています。 IMAP4rev1の実装はリテラルで
送信8ビットまたはマルチオクテット文字ができるが、そう[CHARSET]が同定されている場合にのみ
を行う必要があります。

BINARY本体エンコーディングが定義されているが、符号化されていないバイナリ ストリングは許可されません。 「バイナリ文字列」は、 NUL文字の文字列です。実装は、データを送信する前にバイナリデータをBASE64などのテキスト形式に にエンコードしなければならない（MUST）。CTL文字の量が多すぎる文字列は、 がバイナリとみなされることもあります。

1. 実装がBASE64に変換する必要がある場合、なぜRFCは、 "BINARYボディエンコーディングが定義されている" と言っています。 base64（またはその他の形式）としてデータを送信する必要があるたびに、効率的にバイナリはサポートされないためです。それとも、私は間違っていることを読んでいますか

2. IMAPは、MIMEマルチパートをサポートし、この内部の部品には、バイナリデータを持つことができますか？それはコンテンツ転送エンコーディングですか？

私はこの質問をした理由は、私がHTTPサーバで、HTTPやIMAPの両方をサポートするサーバーを開発する必要がされて、IMAP/HTTPに新しいですが、コンテンツと、バイナリ（HUGEマルチパートデータにデータをrecive -transfer-encodingをバイナリとして）、FETCHはIMAPで行うことができます。 IMAPがバイナリをサポートしていない場合、データを解析してmultipart内の各部分をbase64に変換する必要があります。これは深刻なパフォーマンスの問題だと思います。

Answer 1

答えは残念ながら "多分"です。

のMIME RFCはバイナリサポートしていますが、IMAPのRFCは、具体的NULL文字を送る禁止します。これは、テキストベースのパーサー、特にCで書かれたパーサーで混乱する可能性があるためです。ここで、NULLは文字列の終わりの意味を持ちます。いずれの場合

、いくつかのIMAPサーバは単に体が「バイトのバッグ」であることを考えると、私はいくつかの疑問、実際に再エンコードを行います。ですから、メッセージ全体を聞いてみると、おそらくそれの文字通りの内容が得られます。

クライアントがMIME-Binaryを処理できる場合は、おそらく問題ありません。

が正しくBINARYをサポートするためのIMAP拡張のためのRFC 3516ありますが、これは広く展開されていません。

補足として、なぜMultipart MIMEを使用していますか？それはHTTPのための奇妙な実装の選択です。