なぜ私たちはまだこのような小さなメール添付ファイルサイズ制限を持っているのですか？
輝かしい2011年に、1 GBのファイルを互いにメールで送信することを妨げている技術的な制限は何ですか？
それとも、主要な電子メールプラットフォームが足を引っ張っているだけなのでしょうか。
ヘッダーのみを取得するように受信トレイを設定し、必要に応じて完全な添付ファイルを設定できる場合、問題は何ですか？
メールの添付ファイルのサイズが1992年に行き詰まっているような気がします...
問題はこれです。電子メール（SMTP/POP3/IMAP/what-have-you）は、もともとは信頼できるネットワークでプレーンテキストメッセージを送信することを目的とした古くてシンプルなプロトコルです。今日のインターネットを介して大量のバイナリデータを送受信するためにそれを使用することは、元のユースケースとはまったく異なる、ハッキングされたハックであり、この役割ではかなり惨めに機能します。
電子メールにファイルを添付すると、base64でエンコードされ、サイズが1/3増加します。したがって、1 GBのファイルはさらに300 MB大きくなります。また、ダウンロードプロトコルには組み込みの圧縮がないため、転送を高速化する方法（場合によっては（送信の場合はSMTP）、受信の場合はPOP3）、の方法もありません。再開壊れた転送-接続が1.2 GBで壊れましたか？申し訳ありませんが、すべて再送信する必要があります）。さらに、SMTPはストアアンドフォワードプロトコルです。何だと思う？そう、1.3 GBのファイルを複数のサーバー間でコピーする必要があります。メールサーバーの管理者から無限の幸福を手がかりに。
これは、有用な代替手段がなかった1990年代の問題でした（FTP？HTTP/1.0？Puh-leeze）。しかし、2011年の栄光の年には、クラウドとの間でデータをシームレスにアップ/ダウンロードするさまざまな方法（Dropbox、Ubuntu One、Amazon S3など）があり、「これを行うには他に役立つ方法はありません。 」はもはや真実ではありません。
また、誰もがインターネットへの100 Mbitリンクを使用しているわけではないことに注意してください。モバイルとスマートフォン;すべてのメールクライアントがヘッダーのみをダウンロードできるわけではありません（たとえば、POP3はまだ多く使用されています）。また、すべてのユーザーがwillが表示されます（システムで許可されているのと同じ大きさのファイルが送信されます。ほとんどのISPでFUPのようなものがあります）。
TL; DR：1 GBのファイルを電子メールで送信するなどの技術的には可能ですが、ドライバーを使用して釘を打ち込むことも技術的に可能です。これは良い方法ではありません。そのようなタスクにより適したツールがあるので、それを行う。
Exchange 2007で、管理者が「電子メールサイズの制限なし」の哲学に同意した状況にあった場合：
内部ユーザーが、音楽CDの.isoを含むメッセージをhotmailアドレスに送信しました。メッセージの処理中に1つのトランスポートサーバーのキューを詰まらせ、バックプレッシャーを照らし、メッセージの送信を停止しました。その後、ユーザーのOutlookは、機能していた他のトランスポートサーバーにメッセージを忠実に再送信しました。バックプレッシャ、メッセージ送信なし。
両方のトランスポートサーバーがメッセージを窒息させたため、すべての送信メールが約90秒間停止しました。もちろん、Hotmailはメッセージを拒否しました。その後すぐにサイズ制限がありました。
ここに別のビューがあります：
電子メールは途中で複数のインスタンスに保存されるため、1 GBのファイルを送信すると、その数倍の時間が消費されます。
通常は「送信済みアイテム」のクライアント上のコピーであり、IMAPを使用している場合は、サーバー上のコピーも（アカウント上に）表示される可能性があります。
次に、受信側はコピー（サーバー）を保持し、受信側のローカルクライアントにも保持します。 IMAPを使用している場合、サーバー上では削除されません（もう一度）。
これは、1つの1 GBファイルで合計4 GBです。もちろん、バックアップと見なすこともできますが、そのためのより良いオプションもあります。ユーザーのメールボックスが無制限に増大するためにサーバーで発生する可能性のある速度低下は言うまでもありません。
また、ファイルがbase64でエンコードされている場合はさらに大きくなると思います（約33％大きいと思います）。
Piskvorの答えを補足するため。
はい、「主要な電子メールプラットフォーム」は足を引っ張っています。彼らは、今日の標準に（多くの点で）準拠していないプロトコル（SMTP）を使用してこれを行います。
今日の世界では、SMTPに代わるプロトコルを簡単に設計して、現在の添付ファイルの問題を解決できます。
問題は、世界をそれに切り替えることです。