位置MIME的疊加

Question

，MIME（多用途互聯網郵件擴展，現在Internet Media Type（？））是一種能夠描述文件類型（所用的標題幾個協議）。

因此，MIME本身不是一個協議，而是其他協議使用的擴展，對嗎？

這意味着應用程序會在應用程序層使用該擴展，除了攜帶MIME頭之外，協議沒有任何協議執行任何操作。

所以，如果我發送郵件帶有附件的mp3，SMTP /等應用層協議認識到這是一個MP3附件，或者是應用僅識別文件的職責是什麼？從這個意義上說，MIME不能稱爲SMTP的擴展，而應該被應用程序使用。

如果SMTP不承認，這是一個不同類型的文件，如何將它正確它儲存在郵件服務器？ （例如，一個MPEG視頻文件需要存儲特定的格式，郵件服務器如何存儲它而不給予任何特殊處理？）

對不起，如果我的問題聽起來有點模糊，但我想知道如何不同協議（尤其是SMTP）使用MIME。

感謝您的幫助。

Answer 1

RFC 822電子郵件最初純粹是純文本的7位US-ASCII。 MIME指定一個將其他媒體類型封裝在電子郵件容器中的工具。它沒有指定對SMTP的任何改變（儘管例如8BITMIME ESMTP擴展對於簡化MIME消息的傳輸是有用的）。因此，它是現有協議的延伸，而不是單獨的協議。其他協議（特別是HTTP）也已將MIME（部分）用於內容類型和編碼的標記，這也證明了這一點。

互聯網媒體類型只是MIME用於編碼的一個方面;指定字符集和編碼的機制仍然在MIME中定義。

傳統上，郵件服務器只是將裸露的RFC822消息存儲在其消息存儲中;郵件客戶端負責解析並可能操縱身體中的任何MIME結構進行顯示和交互。 （事實上​​，RFC 822已被2282和5322取代，並沒有從根本上改變實際的郵件格式。）

有些服務器偏離此模型;例如，Microsoft Exchange似乎會解析所有傳入的消息，以便將它們轉換爲其內部格式，這有損於與標準工具的互操作性，以及我們中少數需要對我們的實際電子郵件進行可靠，巧妙訪問的神智清醒。

Answer 2

SMTP協議本身對MIME格式一無所知，但SMTP服務器本身必須至少實現基本的rfc0822支持才能添加Received頭，但是它不需要實現MIME。

服務器如何將文件保存到磁盤？與通過TCP/IP流從客戶端接收它的方式相同。它只是保存了發送的原始字節（添加了我提到的Received頭文件）。

換句話說，你是這樣想的。 SMTP服務器不必知道任何關於mp3文件附件或任何其他內容，因爲MIME格式（它不是協議）只是將消息中的mp3數據序列化的一種方式。