3. MIME頭字段（MIME Header Fields）<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
MIME定義了許多新的RFC822頭字段，用以描述MIME實體內容(entity content)。這些頭字段至少會在以下兩個地方出現：
（1） 做爲規則的RFC822消息(message)頭信息的一部分。
（2） 在多部分結構（multipart construct）裏，存在於“部分主體”（body part）頭信息中。
這些頭字段的形式定義如下：
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
MIME-message-headers := entity-headers
fields
version CRLF
; 當前BNF所暗含的實體頭信息
; 順序可以被忽略。
MIME-part-headers := entity-headers
[ fields ]
; 任何不以“content-”開始的字段
; 都沒有被定義，可以被忽略。
; 當前BNF所暗含的實體頭信息
; 順序也可以被忽略。
不同的MIME頭字段的語法細節會在下面的章節中說明。
4. MIME-Version頭字段
自從1982年發佈了RFC 822以來，實際上只存在這一種Internet消息格式標準，而且幾乎沒人意識到需要聲明那些正在使用中的格式。這篇文檔是一個補充RFC822的獨立說明。雖然在這篇文檔中所做的擴展已經被定義爲與RFC 822兼容，但是，郵件處理代理仍然需要知道一個消息是否是按照新的標準構成。
爲此，本文檔定義了一個新的頭字段：“MIME-Version”。它被用來聲明Internet消息主體(message body)所使用格式的版本號。
按照本文檔格式所構成的消息(message)，必須按如下格式包含這個頭字段：
MIME-Version: 1.0
這個字段就是一個聲明，它表示消息的結構符合本文檔所規定的格式。
因爲今後的文檔中有可能再次擴展消息格式的標準，所以這裏給出MIME-Version頭字段的BNF：
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
這樣，將來的格式說明符都被約束爲以小數點分隔的兩個整數，它們可能會替代或擴展字符：“1.0”。如果接收到一個消息，它的MIME-version值不是“1.0”，那麼就可以假定它不符合本文檔的規範。
還有一件值得注意的事情是，不可以使用MIME-Version機制來實行對媒體類型的版本控制。特別的，一些格式（如application/postscript）擁有包含在媒體格式內部的約定版本號。當這種約定存在時，MIME不會將其取代。當這種約定不存在時，MIME會在必要的時候使用“content-type”字段中的一個“version”參數進行聲明。
實現者要注意的問題：在檢查MIME-Version的時候，一定要忽略任何在RFC822中所定義的註釋部分。詳細的說，以下的MIME-Version字段是等價的：
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
當缺少MIME-Version字段時，接收郵件的代理（無論此代理是否符合MIME要求）都可以按照本地的約定，任意的解釋消息體。在當前的使用中存在的許多這樣的約定。應該注意到，在實際中非MIME消息可以包含任何內容。
無法確定一個非MIME郵件消息中只包含US-ASCII字符集的純文本內容，因爲這個消息很可能使用了一些非標準的比MIME更早出現的本地約定，或是包含其它字符集的內容或非文本的內容，這樣，消息就無法被自動的識別。（如用UUENCODE方式編碼的UNIX tar壓縮文件）