3. MIME头字段（MIME Header Fields）
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压缩文件）
