(このブログ記事はこちらの英語版記事の翻訳になります。最新の記事ではないので内容がいくらか古いものであることをご了承ください)

 

かなり長い前の話になりますが、電子メールは1つの目的のために設計されました: テキストのメッセージをとある場所から異なる場所に配信することです。米国でこれは開発された為、電子メールの主要言語は英語に設定されていました。そして、英語の言語 はちょうど26文字(大文字と小文字を区別する場合は52になります)といくつかの記号を使用するため、ASCIIは電子メールのデファクト文字コードとして選択されまし た。


それ以来、多くの事が変化しました。電子メールに使用される文字コードを指定出来るようになりました。殆どで共通しているのは、ASCIIもしくはUTF-8です。単なる 短いテキストメッセージを送るだけでなく電子メールには他に多くの事を出来るようになりました。ある用途では、電子メールはファイルを宛先に送るために使用されます。しか し、送信者のコンピュータではファイルはバイナリ形式で保存されており、これを他のコンピュータに送信するため、ASCII形式を使用する通信媒体を通して送信しなければ ならないという困難に直面しております。これにはいくつかの手段を使いメッセージを再エンコーディングする必要が出てくるのは明らかです。その時点ではUUEncode と UUDecode が用いられていました。UUencode は電気的メールを介してASCII形式で転送する際にファイルをエンコードします。UUdecode はエンコードされたファイルを再びデコードします。これらのツールの問題点は使用には非効率で難しかったことです; エンコードとデコードの作業は電子メールウインドウの外側で行わなければならなかったことです。その後、Quoted-Printable (QP) と Base 64 が登場し、バイナリの添付ファイルの使用には殆ど取って代わられました。


しかし、これらのツールも依然非効率な部分がありました。特にQ-P や Base 64 が使用するファイルエンコードはサイズが拡大することです。ASCIIテキストのみを含むファイルは殆どサイズが拡大することはありませんが、実行形式や他のバイナリフ ァイルはサイズが非常に拡大してしまいます。更に悪いことには、サイズの小さいファイルはサイズの大きいファイルよりも拡大率が高くなる傾向があることです。これは小さい サイズのファイルの方が繰り返しパターン数がより少なく、同様に管理上のオーバーヘッドもかかってしまう理由があるからです。結果として、ファイルサイズが大きくなると、 拡大率は33%になります(エンコードの方法によります)。小さいファイルサイズの場合は、これは電子メールの転送のエンコードの際に50-75%にも及ぶことがあります 。


それでは、管理者はどれくらいのサイズ制限を行えばいいでしょう?一般的には管理下のユーザが電子メールが受信できる最大の添付ファイルサイズを目安にするといいでしょう 。このサイズを決定したら、そのサイズに4/3 もしくは 133% を掛け算してください。これがアプライアンスで許容する必要がある添付ファイルのおおよそのサイズになります。また、FTPや他のバイナリ形式のファイル転送メカニズム を使用する方がサイズの大きいファイルにははるかに効率的であることも述べておきます。


どちらにせよ、ファイル添付サイズ機能の設定には、実際の最大ファイルサイズよりも33%大きく制限を設けておくことをお勧めいたします。

主なリンク:


http://ask-leo.com/why_are_emailed_attachments_larger_than_the_original_file.htm l


http://tzodns.com/support/faq/225


http://googlesystem.blogspot.com/2009/11/why-its-bad-idea-to-send-huge-files-by. html