なぜこのような小さな電子メール添付ファイルのサイズ制限があるのですか？[閉まっている]

輝かしい2011年に、私たちが互いに1GBファイルを電子メールで送信することを妨げる技術的な制限は何ですか？

それとも、単に主要なメールプラットフォームが足を引っ張っているだけですか？

受信ボックスを設定してヘッダーのみを取得し、必要に応じて完全な添付ファイルを取得できる場合、問題は何ですか？

メールの添付ファイルのサイズが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ははるかにまだ使われている）、ヘッダーのみをダウンロードすることができ、そしてないすべてのユーザーが週に電子メール「このfunneh 1ギガバイトのビデオを見、」20必然的にダウンロードしても構わないと思ってます（表示されます人々はシステムが許す限り大きなファイルを送信します;そして、はい、ほとんどのISPでFUPのようなものがあります）。

TL; DR：1GBファイルを電子メールで送信することは技術的には可能ですが、ドライバーを使用して釘を打ち込むことも技術的には可能です-そのようなタスクにより適したツール。

同じですが、わずかに異なるビューから：

電子メールは電子メールです。別の小さな紙の封筒に入れられたこの古紙としてメールを知っています。たくさんのテキストを書くことができますが、5、6ページを超えることはできません。また、電子メールも同じですが、電子的です。テキスト（タイプライターのようなプレーンテキスト）用に設計されています。次に、これらの派手な赤点滅HTMLメールを送信できるMIME拡張機能がありました。

世界の誰も文句を言うことはありません、「ああ、メールは西暦1322年のように立ち往生しています。なぜ紙の封筒で象を送れないのですか？」いかがですか。この種のもののために、人々はパケットや輸送コンテナのようなものを発明しました。これが商品と象の送り方です。そして、インターネット関係者はFTP（ファイル転送プロトコル）を発明し、名前を得ましたか？

FTPは大きな欠点を抱えた古代のプロトコルでもあるため、FTPの多くの代替手段があります（主にファイル転送ではなくセキュリティの面で）。ただし、HTTPは、メタデータを使用した中央集中型のドキュメントストレージ用に開発された代替手段ではありません。ファイルをダウンロードおよびアップロードできることは、それに対する残忍な拡張です。

したがって、文字を使用してテキストを送信し、パケットを使用して商品を送信します。電子メールを使用して情報を送信し、ファイル転送プロトコルを使用してファイルを送信します。

私が追加しなければならない写真にとどまるために：あなたが地元の郵便局に紙の封筒で象を受け入れるように説得しても（そして追加料金を支払う）、象の配達に関係するより多くのパーティーがあります。次の郵便局に運ばなければならない郵便配達員がいて、恐らくは象が収まる適切なバッグを持っていないでしょう。しかし、彼は次の郵便局に持って行きたいと思っています。象は受け入れません」

次に何をしますか？現実世界の優秀な郵便配達員は、象を最初の郵便局に持ち帰り、その後送信者に戻します。（電子の世界では、これは悪い郵便配達人になるでしょう。なぜなら、彼は象を撃ち、死の証明書だけを送り主に届けるべきだったからです）。

したがって、郵便配達のチェーン内のすべてのリンクを説得して象を受け入れることができたとしても、あなたは受取人に直面します。彼は象を望んでいるが、レターボックスが小さすぎて象が収まらないと言うことができます。送信者への帰還象の配達につながります。（象が送信者のレターボックスに収まらない場合はどうなるかは言うまでもありません...）

Exchange 2007では、管理者が「電子メールサイズに制限なし」という哲学に同意している状況にありました。

内部ユーザーが、音楽CDの.isoを使用して自分のhotmailアドレスにメッセージを送信しました。メッセージの処理中に1つのトランスポートサーバーでキューを妨害し、バックプレッシャーを点灯して、メッセージの送信を停止しました。次に、ユーザーの見通しは、機能していた他のトランスポートサーバーにメッセージを忠実に再送信しました。バックプレッシャー、メッセージ送信なし。

両方のトランスポートサーバーがメッセージを窒息させると、すべての送信メールが約90秒間停止しました。もちろん、Hotmailはメッセージを拒否しました。直後にサイズ制限がありました。

別のビューを次に示します。

電子メールは途中で複数のインスタンスに保存されるため、1 GBのファイルを送信すると、その数倍になります。

通常、「送信済みアイテム」のクライアント上のコピーであり、IMAPを使用している場合、サーバー上のコピーも（アカウント上に）表示される場合があります。

次に、受信側は、受信側のローカルクライアントにコピー（サーバー）を保持します。IMAPを使用している場合、サーバーで削除されません（もう一度）。

これは、1 GBの単一ファイルに対して合計4 GBです。もちろん、これをバックアップと考えることもできますが、そのためのより良いオプションもあります。ユーザーのメールボックスが無期限に増大するため、サーバーで発生する可能性のある速度は言うまでもありません。

そして、ファイルがbase64でエンコードされている場合はさらに大きくなると思いました（約33％大きいと思います）。

Piskvorの答えを補足するため。

はい、「主要な電子メールプラットフォーム」は足を引っ張っています。彼らは、今日の標準に達していないプロトコル（SMTP）を使用して（多くの点で）これを行います。

今日の世界では、現在の添付ファイルの問題を解決するSMTPに代わるプロトコルを簡単に設計できます。

問題は、世界をそれに切り替えることです。

言及されている問題は、主にデータのストレージと伝送に関するロジスティックの問題です-現代のクラウド抽象化では、ファイルはもはや物理的である必要はありません-ファイルハンドル抽象化は、さまざまなストレージ方法（ローカルディスク、ftp 、http、torrent、youtube、cloud storage、darknet、attachment、mule、distributed fs、excerpts、revisions）-これは新しいアイデアではなく、まだ完全にここにあるわけでも、1つにまとめられているわけでもありません。いつ、または到着した場合、メールの添付ファイルは、直接使用できるファイルポインターになります（たとえば、.torrentファイルやリンクではありません）ビデオプレーヤーまたはその他のソフトウェア。コンテンツのダウンロードまたは保存の実際の処理は透過的に行われます。コンテンツは、共同で修正可能なマニフェストで定義された複数のソースから部分的に配置できます（たとえば、.torrentファイルのように広く受け入れられ、修正可能な可用性とローカリティの制約があります）。実際のダウンロードとストレージ/キャッシュは、視聴された部分とコンテンツにアクセスすることさえ気にしたかどうかに応じて、しばしば部分的かもしれません-義母の巨大な添付ファイルは、社内の帯域幅を使い果たしませんあなたが彼女のメールのファンではない場合。永続性または可用性については、おそらく