MIME 在网络堆栈中的位置答案

【问题标题】：Position of MIME in the Networking stackMIME 在网络堆栈中的位置
【发布时间】：2015-04-24 19:08:42
【问题描述】：

根据我在 Internet 上找到的内容，MIME（多用途 Internet 邮件扩展，现为 Internet Media Type (?)）是一种描述文件类型的方法>（多个协议使用的标头）。

所以，MIME 本身并不是一个协议，而是其他协议使用的扩展，对吧？

这意味着该扩展由应用程序在应用层使用，除了携带 MIME 标头之外没有任何协议做任何事情。

所以，如果我发送带有 mp3 附件的邮件，SMTP/其他应用层协议会识别出这是一个 mp3 附件，还是应用程序有责任识别文件？从这个意义上说，MIME 不能被称为 SMTP 的扩展，而是一种供应用程序使用的功能。

如果 SMTP 无法识别这是一种不同类型的文件，它将如何正确将其存储在邮件服务器中？（例如，一个 MPEG 视频文件需要特定的格式来存储，邮件服务器将如何存储它而不给予任何特殊处理？）

对不起，如果我的问题听起来有点含糊，但我想了解不同的协议（尤其是 SMTP）如何使用 MIME。

感谢您的帮助。

【问题讨论】：

如果您通过电子邮件向自己发送了一段短视频并检查了传入消息的来源，您会大开眼界。

标签： email browser smtp

【解决方案1】：

RFC 822 电子邮件最初是纯文本的 7 位 US-ASCII。 MIME 指定了一种将其他媒体类型封装在电子邮件容器中的工具。它没有指定对 SMTP 的任何更改（尽管例如 8BITMIME ESMTP 扩展对于简化 MIME 消息的传输很有用）。因此，它是现有协议的扩展，而不是独立的协议。其他协议（尤其是 HTTP）已合并（部分）MIME 以标记内容类型和编码，这一事实也证明了这一点。

Internet 媒体类型只是 MIME 用于编码的内容的一个方面；指定字符集和编码的机制仍然在 MIME 中定义。

传统上，邮件服务器只是将裸露的 RFC822 消息存储在其消息存储中；邮件客户端负责解析和可能操作正文中的任何 MIME 结构以进行显示和交互。（RFC 822 已被 2282 和 5322 取代的事实并没有从根本上改变实际的邮件消息格式。）

有些服务器偏离了这个模型；例如，Microsoft Exchange 似乎会解析所有传入的消息，以便将它们转换为内部格式，这在某种程度上损害了它与标准工具的互操作性，以及我们这些需要可靠、愉快地访问我们实际电子邮件的少数人的理智.

【讨论】：

【解决方案2】：

SMTP 协议本身对 MIME 格式一无所知，但 SMTP 服务器本身必须至少实现基本的 rfc0822 支持才能添加 Received 标头，但是，它不需要实现 MIME。

服务器如何将文件保存到磁盘？它通过 TCP/IP 流从客户端接收它的方式相同。它只是保存发送的原始字节（添加了我提到的 Received 标头）。

换句话说，你想太多了。 SMTP 服务器不需要知道任何关于 mp3 文件附件或任何其他内容的信息，因为 MIME 格式（它不是协议）只是序列化消息中的 mp3 数据的一种方式。

【讨论】：