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

问题是这样的：电子邮件（SMTP / POP3 / IMAP /你有什么）是一个古老的，简单的协议，最初旨在发送纯文本消息在一个可信的networking。 使用它在今天的互联网上发送或接收大量的二进制数据是一种疯狂的攻击，与原始用例完全不同，它在这个angular色中performance得相当悲惨。

当您将一个文件附加到电子邮件中时，它会进行base64编码，这会将其大小增加1/3。 因此，您的1 GB文件变成另一个300 MB的文件; 也没有内置的压缩​​下载协议，因此没有办法加快转移（在某些情况下（SMTP发送，POP3接收），甚至没有办法恢复一个破碎的转移 – 连接在1.2 GB？对不起，您需要重新传输一遍）。 而且，SMTP是一种存储转发协议。 你猜怎么了？ 是的，这个1.3 GB的文件需要复制到多个服务器上; 提示来自邮件服务器pipe理员的无限快乐。

这在20世纪90年代是一个问题，当时没有其他有用的select（FTP？HTTP / 1.0？Puh-leeze）; 但是在2011年的辉煌一年中，通过各种方式无缝地上传/下载数据到/从云端（例如Dropbox，Ubuntu One，Amazon S3，名称最为人熟知），“借口没有其他有用的方法可以做到这一点“不再是真的了。

还要注意的是，不是每个人都在连接到互联网的100 Mbit链路上 – 例如手机和智能手机; 不是每个邮件客户端都能够只下载头文件（例如POP3仍然在使用中），并且并不是每个用户都愿意下载每周将出现的20个不可避免的“看这个funneh 1 GBvideo”的电子邮件人们会发送大量的文件，系统会让他们;是的，有像大多数互联网服务提供商的FUP）。

TL，DR ：虽然在技术上可以做电子邮件发送一个1GB的文件，但在技术上也可以用螺丝刀敲打一个指甲 – 这不是一个好办法，因为有工具更适合这样的任务。

同样的，但从一个略有不同的观点：

电子邮件是电子邮件。 你知道在另一个小纸信封邮件这个古纸。 你可以写很多文本，但不超过5或6页。 而电子邮件是相同的，但电子。 它是专为文字（如在打字机上的纯文本）。 然后有一个MIME扩展，你可以发送这些奇特的闪烁HTML邮件。

世界上没有人会抱怨，并说：“哦，邮件卡在公元1322年，为什么我不能把一个大象放在一个纸信封？ 这是怎么回事 人们发明这种东西就像一个小包或一个运输容器。 这是如何发送货物和大象。 而互联网的人发明的FTP（文件传输协议），得到了名字？

在现实世界中有很多FTP的替代品，因为FTP也是一个古老的协议，有很大的缺点（主要是安全性，而不是传输文件）。 但是HTTP 并不是一个替代品，因为它是用元数据集中存储的。 你可以下载和上传文件是一个残酷的扩展。

所以用信件发送文本和一个包裹发送货​​物; 使用电子邮件发送信息和文件传输协议来发送文件。

编辑：

要留在这幅图中，我必须补充一句：即使你说服当地的邮局接受大象的信封（并支付额外的费用），也有更多的派对参与交付大象。 有一个邮递员必须把它带到下一个邮局，可能他没有合适的大象适合的袋子。但也许他已经并且想要把它送到下一个邮局，邮局又说：“没有我们不接受大象“。

那该怎么办？ 现实世界中的优秀邮差将把大象带回到第一个邮局，然后回到发件人那里。 （在电子世界中，这将是一个不好的邮递员，因为他应该已经开枪了，只把死亡证书交给发件人）。

所以即使你能说服邮件链中的所有环节都接受你面对收件人的大象。 他可以说他想要大象，但是信箱对于大象来说太小了，导致回到发件人的大象交付。 （更不用说如果大象不适合发件人的信箱会发生什么……）

在Exchange 2007中，pipe理层订阅了“不限制邮件大小”的理念：

内部用户使用音乐CD的.iso发送邮件到他们的Hotmail地址。 在处理消息时堵塞了一个传输服务器上的队列，点亮了背压，停止提交消息。 用户的前景然后忠实地将消息重新提交给正在运行的其他传输服务器; 背压，没有消息提交。

由于两个传输服务器都窒息了邮件，所有出站邮件停止了大约90秒。 Hotmail当然拒绝了这个消息。 之后不久就有了尺寸限制。

这是另一种观点：

由于电子邮件一直存储在多个实例中，发送一个1 GB的文件会一直用完几次。

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

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

单个1GB文件总共为4 GB。 当然，你可以把它作为备份，但也有更好的select。 更不用说服务器上可能发生的缓慢，因为用户邮箱无限增长。

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

补充Piskvor的答案。

是的，“主要电子邮件平台”正在拖延。 他们通过使用不符合当今标准（在许多方面）的协议（SMTP）来做到这一点。

在当今世界，我们可以轻松devise一个协议来取代SMTP，以解决目前的附件问题。

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

所提到的问题主要是数据存储和传输的后勤问题 – 在现代云抽象中，文件不再需要是物理的 – 可以使用文件句柄抽象来包装各种存储方法（例如本地磁盘，ftp ，http，torrent，youtube，云存储，darknet，attachment，mule，fs，excerpts，revisions） – 这不是一个新的想法，它只是在这里还没有完整的。 当或者如果它到达，你的邮件附件将只是一个文件指针，可以直接使用（例如不是一个.torrent文件或链接）的video播放器或任何软件。 内容下载或存储的实际处理将会透明地进行，内容可能部分地来自协作可修改清单中定义的多个来源（例如，类似于.torrent文件，但被普遍接受，并且具有可修改的可用性和局部性约束）。 实际下载和存储/caching通常可能是部分的，取决于哪一部分被查看，如果你甚至打扰到访问的内容 – 所以你的婆婆的巨大依恋不会吃掉你的任何内部带宽如果你不是她的电子邮件粉丝。 对于永久性或可用性，也许你会有一个邮件客户端，可以过滤和修改存储清单，然后导致某些未打开的附件从其来源迁移到您的云存储，例如，当其可用性减less，例如