MIME在网络堆栈中的位置

Question

基于我在互联网上找到的内容， MIME （多用途互联网邮件扩展，现在Internet Media Type（？））是一种描述文件的方法类型（多个协议使用的标头）。

因此，MIME本身不是协议，而是其他协议使用的扩展，对吗？

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

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

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

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

感谢您的帮助。

Answer 1

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

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

换句话说，你过分思考这个问题。 SMTP服务器不必知道有关mp3文件附件或其他任何内容的信息，因为MIME格式（它不是协议）只是一种在消息中序列化mp3数据的方法。

Answer 2

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

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

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

某些服务器偏离此模型;例如，Microsoft Exchange似乎解析所有传入的消息，以便将它们变成其内部格式，这有点不利于它与标准工具的互操作性，以及那些需要可靠，恰当地访问我们实际电子邮件的少数人的理智