メールにデータを添付すると、Thunderbirdが結果のメールの合計サイズを、添付したファイルよりもはるかに大きく計算していることに気付きました。

次に、最近の例を示します。13MBの画像と3.6MBの画像の合計2つの画像は、合計で約17MBです。4行のテキストがありました。その後、Thunderbirdから、合計サイズが22 MBのメールを本当に送信したいかどうかが尋ねられました。

その違いはどこから来たのですか？5MBのテキストは少し聞こえます。

データは17 MiBでした。MiBには1024 KiBがあります。KiBには1024 Bがあります。1バイトに8ビットがあります。つまり、142,606,336ビットです。

Base 64エンコードは、6ビットごとに個別のバイトとしてエンコードします。したがって、約23,767,722バイトが必要です。1024で2回除算すると、22.67 MiBになります。それが、22 MiBの由来です。

電子メールはかなり古い技術であり、8ビットのクリーンパイプを想定していません。

メールが大きくなるのはなぜですか？

データはbase64、最大3バイトのグループを4つの印刷可能なASCII文字のグループとしてエンコードするようにエンコードされているためです。通常、これらの印刷可能文字のグループは、行に分割されます。

その結果、エンコードされたデータは元のデータのサイズの1倍を超えます。

なぜbase64が使用されるのですか？

電子メールには長い歴史があり、もともとテキストを運ぶために設計されました。ASCII印刷可能文字を表すバイト値のみが、地球上のさまざまな電子メールシステムを確実に通過できます。

そのため、MIMEは、他のデータをASCIIテキストとしてエンコードするための2つのスキームを分割しました。

これらの制限を取り除こうとするSMTPプロトコルの拡張機能があります。まず、1994年の8BITMIMEは、より高いオクテット値を許可しましたが、残念ながら行の長さと行末に関連する制限を削除しなかったため、任意のバイナリデータには適していませんでした。その後、1995年にBINARYMIMEを使用して、任意のバイナリデータを含むメッセージの転送を許可しました。

ただし、これらの標準は広く採用されていません。1つの問題は、メールチェーンの1つのホップがそれらをサポートしているのに、次のホップがサポートしていない場合はどうなるかということです。メールサーバーはそのままではメールを送信できません。配信不能として拒否してバウンスする（ユーザーに受け入れられそうにない）か、変換する（メールサーバーに大幅な追加コードが必要） 。マルチパートタイプでコンテンツ転送エンコーディングを使用しないことに関するMIMEルールにより、変換は特に苦痛になります。