为什么我们仍然有这么小的电子邮件附件文件大小限制？[关闭]

在技​​术上的局限性是什么使我们在光荣的2011年无法通过电子邮件相互发送1GB文件？

还是仅仅是主要的电子邮件平台拖延了脚步？

如果我可以将收件箱设置为仅获取标头，然后如果需要完整附件，那么问题出在哪里？

我觉得电子邮件附件的大小在1992年陷入困境...

问题是这样的：电子邮件（SMTP / POP3 / IMAP /您拥有什么）是一种古老的简单协议，最初旨在在受信任的网络中发送纯文本消息。使用它在当今的Internet上发送或接收大量二进制数据是一种束手无策的技巧，与原始用例完全不同，并且在此角色中表现相当糟糕。

当您将文件附加到电子邮件时，该文件将被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的Internet链接-例如，手机和智能手机。不是每一个邮件客户端可以只下载标题（如POP3仍是多大用处），而不是每一个用户愿意下载20不可避免“这个funneh 1 GB的视频看”每周电子邮件即会出现（人们会发送与系统允许的一样大的文件；是的，大多数ISP都有类似FUP的东西）。

TL; DR：尽管从技术上来说可以通过电子邮件发送1GB的文件，但从技术上讲也可以使用螺丝起子敲打钉子-这不是一个好方法，因为更适合此类任务的工具。

相同，但观点略有不同：

电子邮件是电子邮件。您知道邮件是这种古老的纸质物品，放在另一个小纸信封中。您可以在上面写很多文本，但不能超过5或6页。电子邮件是一样的，但是是电子的。它设计用于文本（如打字机上的纯文本）。然后是一个MIME扩展名，您可以在其中发送这些花哨的红色闪烁HTML邮件。

世界上没有人会抱怨说：“哦，邮件被困在公元1322年的样子。为什么我不能在纸信封中寄送大象？” 就是这样。人们为这种东西发明了诸如小包或运输容器之类的东西。这是发送货物和大象的方法。互联网人发明了FTP（文件传输协议），得了名吗？

在现实世界中，有许多FTP替代方案，因为FTP也是一种古老的协议，具有很大的缺点（主要是在安全性和传输文件方面）。但是HTTP 并不是替代方案，因为它是为使用元数据进行集中式文档存储而开发的。您可以下载和上传文件是对它的残酷扩展。

因此，使用字母发送文本和使用小包发送货物；使用电子邮件发送信息并使用文件传输协议发送文件。

要留在图片中，我必须补充：即使您说服当地邮局接受纸质信封中的大象（并支付额外费用），也有更多的团体参与交付大象。有一个邮递员必须把它带到下一个邮局，可能他没有合适的皮包来装大象。但是也许他有，想把它运送到下一个邮局，而这又说：我们不接受大象”。

那该怎么办？现实世界中的好邮递员会将大象带回第一个邮局-之后再送回发件人。（在电子世界中，这将是一个糟糕的邮递员，因为他本应该开枪射击大象，并且只将死亡证明交还给发件人）。

因此，即使您可以说服邮寄链中的所有环节接受大象，您也将面对收件人。他可以说他想要大象，但信箱太小，无法放入大象。这导致大象寄回给寄件人。（更不用说如果大象不适合发件人的信箱会发生什么...）

在Exchange 2007中，管理阶层赞成“电子邮件大小不受限制”的理念：

内部用户使用音乐CD的.iso向其Hotmail地址发送了一条消息。处理邮件时，将队列塞在一台传输服务器上，点亮背压，停止邮件提交。然后，用户的外表忠实地将邮件提交给了其他正在运行的传输服务器；背压，无消息提交。

由于两个传输服务器都阻塞了邮件，所有出站电子邮件都停止了大约90秒。当然，Hotmail拒绝了该邮件。此后不久便有了大小限制。

这是另一种观点：

由于电子邮件在整个过程中都存储在多个实例中，因此发送1 GB的文件将花费一倍的时间。

它通常是客户端上“已发送邮件”中的副本，如果使用IMAP，则服务器上的副本也可能会显示在您的帐户上。

然后，接收端以及接收端的本地客户端将保留一份副本（服务器）。如果使用IMAP，则不会在服务器上将其删除（再次）。

单个1GB文件总共4 GB。当然，您可以将其视为备份，但是也有更好的选择。更不用说由于用户邮箱无限增长，服务器上可能出现的速度缓慢。

我只是意识到，如果文件是通过base64编码的，它将更大（我猜大约大33％）。

补充皮斯克沃的答案。

是的，“主要电子邮件平台”正在拖延脚步。他们通过使用不符合当今标准（许多方面）的协议（SMTP）来执行此操作。

在当今世界，我们可以轻松设计一种协议来替代SMTP，从而解决当前的附件问题。

问题将是让世界切换到它。

提到的问题主要是与数据的存储和传输有关的后勤问题-在现代云抽象中，不再需要物理文件-文件句柄抽象可用于包装各种存储方法（例如本地磁盘，ftp ，http，torrent，youtube，云存储，darknet，附件，mule，分布式fs，摘录，修订版）-这不是一个新主意，只是在这里还没有全部或全部。何时或是否到达，邮件附件将仅仅是可以使用的文件指针直接（例如，不是.torrent文件或链接），由视频播放器或任何软件提供。内容下载或存储的实际处理将透明地进行，内容可以部分地位于可协作修订的清单中定义的多个来源中（例如，.torrent文件，但被普遍接受，并且具有可修订的可用性和位置限制）；实际的下载和存储/缓存通常可能是部分的，具体取决于查看的部分以及您是否还想访问内容-因此，岳母的庞大附件不会占用您的所有内部带宽如果您不喜欢她的电子邮件。对于永久性或可用性，也许您