mime头字段规范

男娘i 2022-03-10 10:16 107阅读 0赞

关键词:邮件 MIME规范 透明加密  
最近研究邮件透明加密用到了mime,其中天御云安推出的隐秘邮在确保邮件内容加密的同时，部署对于用户也是透明的，既满足加密需求也不影响用户使用习惯。网址：[https://mail.tyyunan.com/][https_mail.tyyunan.com]  
现将mime规范总结如下：

（1）始终在任何创建的邮件中生成“MIME-Version：1.0”标题字段。

（2）识别Content-Transfer-Encoding标题字段并解码所有接收到的用qp或base64编码的数据。7bit，8bit和二进制的转码特性也必须支持。任何未经编码发送的非7bit数据都必须正确标记一个8bit或二进制编码的Content-Transfer-Encoding ，视情况而定。如果底层传输不支持8bit或二进制（如 SMTP\[RFC-821\]没有），发送者需要编码数据并使用适当的Content-Transfer-Encoding标记数据是什么编码格式的，如quoted-printable或base64。

（3）必须处理任何无法识别的Content-Transfer-Encoding就好像它有一个内容类型的“application / octet-stream“，不管实际内容类型是否被识别。

（4）识别并解释Content-Type标题字段，并避免向用户显示具有Content-Type的原始数据字段以外的文字。实现必须能够发送至少文本/纯文本消息用字符集参数if指定的字符集它不是US-ASCII。

（5）忽略所有不被公认的名称的内容类型参数。

（6）显式处理以下媒体类型值：

文本：
    
    - 用“US-ASCII”字符集识别并显示“文本”邮件。
    
    - 识别其他类型的字符集，尽量告知用户邮件使用了那些字符集
    
    - 识别“ISO-8859- *”字符集到能够显示那些字符的程度，是ISO-8859- *和US-ASCII常见的，即所有的字符都由值为1-127的占8位的字节来表示。
    
    - 对于已知字符集中无法识别的子类型，向用户展示或提供数据从规范的内容形式转换成本地形式后的“原始”版本
    
    - 着重处理一个未知的字符集比如“application / octet-stream”类型。
    
    图像，音频和视频：
    
    - 不要过多的花费精力处理，可以把无法识别的子类型看做“application / octet-stream”类型。
    
    application ：
    
    - 要可以删除在本文档中定义的Qp或base64编码中的一个，如果这两个编码被使用，并把由他们产生的信息放到一个用户文件中。
    
    Multipart ：
    
    - 识别混合的子类型。显示所有和邮件级别和正文部分的标题级别相关的信息，然后分别显示或提供给每个正文部位。
    
    - 识别“可选的”子类型，并避免显示用户multipart/alternative 类型邮件的重复部分。
    
    - 识别“多部分/摘要”子类型，具体使用“message / rfc822”而不是“text / plain”作为正文部分的默认媒体类型内部“多部分/摘要”实体。
    
    - 把任何无法识别的子类型都当做混合类型。
    
    Message ：
    
    - 至少识别并显示RFC822的消息封装（message / rfc822）方式保留任何重复结构，即显示或者提供给被封装的数据根据其媒体类型。
    
    - 把无法识别的子类型看做“application / octet-stream”类型。

（7）遇到任何无法识别的Content-Type字段时，必须把它看作是一个不带参数子参数的“application / octet-stream”媒体类型。如何处理这些数据取决于实际情况，但处理这种无法识别的数据可能的选项包括提供给用户把它写入到一个文件（从它的邮件传输格式解码）或者为用户提供一个解码后的数据作为输入传递到程序。

（8）用户代理是必需符合标准要求，如果他们为采用US-ASCII字符集之外的非MIME标准邮件提供非标准支持使用，那么这样做仅可以接收邮件。符合用户代理不得发送所得的非MIME邮除了US-ASCII文本。特别是在没有MIME-Version字段的邮件消息中使用非US-ASCII的文本是强烈鼓励的，因为它阻碍了不同本地化惯例区域之间发送消息时的互操作性。符合用户代理必须在发送US-ASCII字符集的纯文本时包含适当的MIME标签。另外，即使MIME中没有任何内容被支持， 非MIME标准的用户代理也应该升 级，尽可能在他们发送的消息中加入适当的MIME头部信息。这样的升级会有很少改动，如果有的话，对非MIME收件人会有影响 ，可以帮助正确显示这些消息的MIME。它也为最终采用其他MIME功能提供了一条平稳的过渡路径。

（9）符合标准的用户代理必须确保任何以“=？”开头并以“？=”结束的“\* text”或“\* ctext(注释文本)”中的非空格可打印US-ASCII字符组成的字符串中是一个有效的encoded-word 。（“开头”的意思是：在正文字段的起始位置或挨着的linear-white-space (折行符)后面; “结束” 是指：在正文字段的结束位置或着挨着的linear-white-space (折行符)前面）。另外，在“短语”内的任何“单词”以“=？”开头 并 以“？=”结尾必须是有效的编码字。

（10）符合标准的用户代理必须能够区分来自“text”，“ctext”或"word"s 的encoded-words (编码词)，根据第4节的规则，他们随时可以出现在消息标题 的适当位置。在它所有支持的字符集中它必须同时支持“B”和“Q”编码。程序必须能够显示未编码的文本当字符集是“US-ASCII”时。对于ISO-8859- \*字符集，邮件阅读程序必须至少能够显示那些也在US-ASCII集合中的字符。符合上述条件的用户代理被称为MIME-标准。这句话的意思是它被假定为“安全”，并将几乎所有标记正确的数据发送给用户的邮件系统，因为这样的系统至少能够将数据视为未分化的二进制文件，而不会简单地飞溅它到了毫无戒心的用户的屏幕上。还有另外一种意思，它总是“安全”地发送符合MIME格式的数据，这种数据不会违反或被任何符合RFC821和RFC 822的已知系统破坏.符合MIME标准的用户代理具有额外的保证，用户不会显示未被视为文本的数据。

[https_mail.tyyunan.com]: https://mail.tyyunan.com/