Email MIME在网络堆栈中的位置

根据我在互联网上找到的一个例子，（多用途互联网邮件扩展，现在（？）是一种描述文件类型的方法（多个协议使用的头）

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

这意味着应用程序在应用程序层使用该扩展，除了携带MIME头之外，没有任何协议执行任何操作。

因此，如果我发送带有mp3附件的邮件，SMTP/其他应用程序层协议会识别这是mp3附件，或者应用程序有责任识别该文件？从这个意义上讲，MIME不能被称为SMTP的扩展，而是应用程序要使用的功能

如果SMTP无法识别这是另一种文件，它将如何正确将其存储在邮件服务器上？（例如，MPEG视频文件需要存储特定格式，邮件服务器如何存储它而不进行任何特殊处理？）

抱歉，如果我的问题听起来有点模糊，但我想了解不同的协议（特别是SMTP）如何使用MIME

---

感谢您的帮助。

SMTP协议本身对MIME格式一无所知，但SMTP服务器本身必须至少实现基本的rfc0822支持，以便对接收到的头进行ad，但是，它不需要实现MIME

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

---

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

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

互联网媒体类型只是MIME用来编纂的内容的一个方面；指定字符集和编码的机制仍然在MIME中定义

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

---

有些服务器偏离了这种模式；例如，Microsoft Exchange似乎解析所有传入的邮件，以便将其转换为内部格式，这在一定程度上损害了它与标准工具的互操作性，也损害了我们中少数需要可靠，非常方便地访问我们的实际电子邮件。

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