推荐阅读 RFC 5322一Internet 邮件格式
https://blog.csdn.net/ao__ao/java/article/details/88619922
MIME－多用途Internet 邮件扩展
在ARPANET 早期，电子邮件只能由文本消息组成，这些消息用英文书写并且以ASCII码形式表示。在这样的环境下，RFC 822 完全能够胜任所需的工作：它指定了邮件头，但是把邮件内容完全留给用户自己。在20 世纪90 年代， Internet 在全球范围得到广泛使用，发件人希望通过邮件系统发送更为丰富多彩邮件内容的需求越来越强烈，因此原先的这种方法不再够用。主要问题包括了以下情况下的发送和接收两个方面：用带有重音符的语言（例如，法语和德语）来撰写的邮件、用非拉丁字母来撰写的邮件（例如，希伯来语和俄语）、用不带字母的语言来撰写的邮件（例如，中文和日文）以及完全不包含文本的邮件（例如，音频、图像或二进制文档和程序）。
解决方案是多用途Internet 邮件扩展。它已被广泛应用于在Internet 上收发邮件消息，除此之外它还可以描述诸如Web 浏览器等其他应用的内容。有关MIME 的信息由RFC2045 ～2047 、4288 、4289 及2049 文档描述。MIME 的基本思想是继续使用RFC 822 格式（在RFC 5322 之前MIME就己经被提出来了），但在邮件体中增加了结构性，并且为传送非ASCII 码的邮件定义了编码规则。由于它没有偏离RFC 822，因此己有的邮件传输代理和协议（基于RFC 821 ，现在是RFC 5321)都可以发送MIME 消息。需要改变的只是发送和接收程序，而这些可以由用户自己来完成。
MIME定义了5 种新的邮件头，如表所示。第一个邮件头只是告诉接收邮件的用户代理，它正在处理一条MIME 消息，以及该消息使用的是哪个版本的MIME。任何不包含“MIME-Version：”邮件头的消息都被假定是英语明文消息（或者至少只使用ASCII 字符），并按照这种假定情况下的方式来进行处理。
“ Content-Description：”头是一个ASCII 字符串，它指出了邮件包含什么内容。这个头是必需的，这样收件人才能知道是否值得解码和阅读该消息。如果这个字符串说的是“圣巴巴拉仓鼠的照片”，而收到该消息的人并不是一个狂热的仓鼠迷，那么这条消息就可能被丢弃，而不会被解码成一幅高清晰的彩色照片。“ Content-Id：”头标识了邮件的内容，它采用了与标准的“Message-Id：”头相同的格式。“ Content-Transfer-Encoding：”头指出了如何包装邮件体，以便通过网络进行传输。当开发MIME 时，邮件传送协议（ SMTP ）只能处理一行不超过1000 个字符的ASCII 邮件，这是一个很关键的问题。ASCII 字符占了每8 位字节中的7 位，而二进制数据（比如可执行程序和图像）则使用了每个字节的全部8 位作为扩展的字符集。如果没有任何保障措施，是无法安全传送这种数据的。因此，需要某种方式使得携带二进制数据的邮件看起来就像常规的ASCII 邮件消息一样。自从MIME 开发出来之后， SMTP 也做了相应的扩展，允许邮件正文传送8 位的二进制数据，即使今天二进制数据不进行编码，可能仍然不能被邮件系统正确传送。
MIME 提供了5 种传送编码方法，还有一个扩充新方案的入口（只是为了以防万一）。最简单的编码方案就是ASCII 文本消息。每个ASCII 字符占7 位，可以被邮件协议直接传送，只要每行都不超过1000 个字符。次简单的方案与上一个ASCII 方案相同，但使用的是8 位字符。也就是说，从0 到255并且包括255 在内的所有值都是允许的。使用8 位编码的邮件仍然必须遵循标准的最大行长度。然而，存在一些邮件使用了真正的二进制编码。它们是任意的二进制文件，不仅使用全部的8 位，甚至也不遵循每行1000 个字符的限制。可执行程序就属于这一类消息。现在，邮件服务器可以协商是否发送二进制（或者不是8 位的）编码消息，如果双方都不支持该扩展那么就回退到ASCII 字符。二进制数据的ASCII 编码方式称为基于64 编码（ base64 encoding ）。在这种方案中，每24 位编成一个组，每组被分成4 个6 位的单元，每个单元被当作一个合法的ASCII 码字符来发送。编码方式是“A”表示成0 、“ B ”表示成1 ，以此类推。接着是26 个小写字母、10 个数字，最后是“＋”和“／”分别表示成62 和63 。“＝”和“＝”分别表示最后一个组只含有8 位或者16 位。回车和换行被忽略，所以它们可被任意插入到编码字符流中以便保证每一行足够短。使用这种编码方案后，任意的二进制文本都可以被安全地发送出去，尽管效率不高。在二进制的邮件服务器开发出来之前，这种编码方式非常流行。现在仍然经常有人在用。
对于那些几乎全是ASCII 字符，只有少量非ASCII 字符的邮件， bas64 编码的效率有些低。发送这种邮件时采用了另一种替代方案，这种方案称为引用可打印编码。它正好是7 位ASCII 编码，但所有超过127 的字符都被编码成一个等号后面跟着2 个用十六进制数字来表示的字符值。控制字符、某些标点符号、数学符号以及结尾空白也用这种方式编码。最后，如果有足够的理由不使用上述任何一种编码方案，那么还可以通过“ Content-Transfer-Encoding：”头说明一种用户自定义的编码。上表中显示的最后一个邮件头实际上是最有趣的一个。它指定了邮件体的本质特性，而且具有超出电子邮件范畴的影响。例如，从Web 下载的内容被打上MIME 类型的标签，这样浏览器就知道如何表示该内容。同样地，对于诸如IP语音这样的流式媒体和实时传输，作为邮件内容发送时也作同样的处理。最初，RFC 1521 定义了7 种MIME 类型。每种类型都有一个或多个子类型。类型和子类型由一个斜线隔开，比如“ Content-Type: video/mpeg”。从此以后，针对每个类型都有数百个子类型被扩充进来。整个过程中，每当开发出某种新的内容类型时要添加额外的表项。分配的类型和子类型列表由IANA 在线维护 www.iana.org/assigments/media-types。
类型以及相关的常用子类型例子如表所示。让我们简单地浏览一下，从“text （文本〉”开始。“text/plain （文本／纯文本〉”结合起来可用于表达普通邮件，显示的就是收到的，无须编码，也不需要进一步处理。这个选项允许以MIME 方式传输普通邮件，只需少数几个额外的头。“text/html （文本／网页〉”子类型在Web (RFC 2854）变得流行后允许在RFC822 电子邮件中发送网页。"text/xml （文本／可扩展标记语言）”子类型在RFC 3023 中定义。XML 文档剌激了Web 的发展。
image （图像〉，它可传输静态图像。现在广泛用来存储和传输图像的格式有许多种，它们既可以是压缩的，也可以是未压缩的。其中的一些，包括GIF 、JPEG 和TIFF 几乎被内置到所有的浏览器中。除此以外还存在很多其他的图像格式和相应的子类型。
audio 〈音频〉和video 〈视频）类型分别用于表示声音和运动图像。请注意， video 类型只包含可视信息而不包含声音。如果要传输一部有声电影，那么视频和音频部分必须被分开传输， 具体如何操作则要依据所使用的编码系统。第一个定义的视频格式称为运动图像专家组(MPEG, Moving Picture ExpertsGroup），这种格式就是由这组专家设计的，但此后又增加了其他一些格式。除了“audio/basic＂以外，在RFC 3003 中增加了一种新的音频类型“audio/mpeg”，从而使人们可以通过电子邮件发送MP3 音频文件。“video/mp4”和“ audio/mp4”类型说明以新MPEG4 格式来存储视频和音频数据。在其他内容类型之后增加了model （模型〉类型，主要目的是用来描述3D 模型数据。
然而， 该类型至今尚未得到广泛的应用。
application （应用〉类型是对那些未被其他类型覆盖但又需要应用程序来解释数据的未知格式的统称。例如，我们分别为PDF 文档、JavaScrip 程序和Zip 压缩包列出了pelf、javascript 和zip 子类型。接收到这种邮件内容的用户代理使用第三方库函数或者外部程序来显示内容：显示程序可以集成到用户代理（邮件用户代理），也可以不和用户代理集成在一起。
通过使用MIME 类型，用户代理获得了一种处理应用内容的扩展能力。随着新类型应用程序被不断地开发出来，其传输的内容类型也可能是全新的，因此用户代理的这种可扩展处理能力好处很大。但另一方面，许多新形式内容由应用程序执行或者解释也带来了一些危险。显然，运行一个任意可执行程序是有安全隐患的，虽然通过邮件系统传送的可执行程序可能出自“朋友们”。但这种程序可能会对它可以访问到的那部分计算机带来各种令人讨庆的损害，尤其是如果它能够读取和写入文件，以及使用网络时危害更大。不那么明显的是文档格式也可以带来同样的危险。这是因为这些格式（如PDF ）根本是变相的编程语言。虽然它们被限定在一定范围内解释，但解释器中的错误常常让狡猎的文件挣脱限制的束缚。
因为存在许多应用，除了这些例子外还存在许多各种各样的应用程序子类型。如果没有其他已知的子类型更合适描述邮件，那么作为备用“ octet-stream ”子类型表示一个无法解释的字节序列。在接到这样一个字节流时，用户代理很可能会显示它，建议用户将其复制到一个文件。然后，在用户大概知道内容是什么样子之后，再决定对该内容做何种后续处理。
最后两个类型对于撰写和处理邮件本身非常有用。message 类型使得一个邮件可以被完全封装在另一个邮件中。这种方案对于转发电子邮件很有用。例如，当一个完整的RFC822 邮件被封装在另一个外部邮件中时，则应该使用RFC 822 子类型。类似地，对于封装HTML 文档也很普遍。partial 子类型使得有可能将一个被封装的邮件分成多个部分并分别传输它们（例如，如果被封装的邮件太长）。通过一些参数，接收方能够将各部分按照正确的顺序重新组装起来。
最后一个类型是multipart，它允许一个邮件包含多个部分，并且明确地分出每个部分开始和结束的界限。“mixed”子类型允许每个部分类型都不相同，而且无须强制任何额外结构。许多电子邮件程序允许用户在一个文本消息中提供一个或多个附件，这些附件可以multipart 类型发送。与mixed 相反的是， alternative 子类型允许同一个消息被包含多次，但是被表示成两种或多种不同的媒体。例如，一个消息可以按照3 种形式来发送：纯粹的ASCII 文本、HTML和PDF 。一个设计合理的用户代理在接收到这样的消息时，将按照用户的偏好显示。如果可能的话，首选用PDF 格式显示。第二选择应该是HTML 格式。如果这两者都不可能，则显示简单的ASCII 文本。这些部分应该按从简单到复杂的顺序排列，以帮助那些使用MIME (pre-MIME ）用户代理的收件人也能够在一定程度上理解消息的含义（例如，即使非MIME 的用户也可以阅读简单的ASCII 文本）。alternative 子类型也可被用来表示多种语言。在这个上下文意义下，罗塞塔石碑（ Rosetta Stone ）或许可以被看成是一条早先的multipart/altemative 消息。
有关子类型的其他两个例子是parallel 和digest 子类型。当邮件所有部分必须被同时“观看”时，要使用paralled 子类型。例如，电影往往由一个音频和视频组成。如果这两个频道不是并行播放而是先后播放，那么电影就无法得到应有的播放效果。当多个邮件被打包成一个复合邮件时，要使用digest 子类型。例如， Internet 上的一些讨论组往往收集来自各个本组成员的信息，然后将它们作为单个“multipart/digest”邮件定期发送到该讨论组。
下面通过一个例子说明电子邮件如何采用MIME 类型，下面给出了一个多媒体邮件。在这里，生日问候信息同时被当作HTML 和音频文件通过邮件代理传送。假设收件人有播放音频的功能，他的用户代理在展示邮件时将播放声音文件。在这个例子中，声音是作为message/external-body 子类型被引用的，因此用户代理首先必须通过FTP 获取声音文件birthday.snd。如果收件人没有音频能力，那么歌词就会悄无声息地显示在屏幕上。两部分之间的界限由两个连字符来划分，连字符后面跟着一个字符串（由软件生成的〉，字符串说明了boundary 参数。
请注意，在这个例子中，“ Content-Type”邮件头出现在3 个位置上。在顶层，它指出该邮件由多个部分组成。在每个部分中，它指出了该部分的类型和子类型。最后，在第二个部分的正文中，它必须告诉用户代理应该获取什么类型的外部文件。为了显示这种用法的细微不同之处，我们在这里使用了小写字母，尽管所有的邮件头是不区分大小写的。同样地，对于不是按7 位ASCII 编码的外部邮件体，则需要提供“Content-Transfer-Encoding ”头。
————————————————
版权声明：本文为CSDN博主「跃寒」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ao__ao/java/article/details/88619922
电子邮件加密：PGP 和S/MIME加密的区别 转载 weixin_34075268 最后发布于2018-12-26 11:36:00 阅读数 308 收藏
展开
为什么80%的码农都做不了架构师？>>>
电子邮件通常基于明文协议传输，没有加密和验证服务，攻击者可在邮件传输的任意节点截获数据或篡改内容，造成电子邮件数据泄露或身份仿冒。PGP加密和S/MIME加密都被用于电子邮件加密
PGP（全称：Pretty Good Privacy，优良保密协议），是一套用于信息加密、验证的应用程序，可用于加密电子邮件内容。PGP本身是商业应用程序；同类开源工具名为GnuPG（GPG）。PGP及其同类产品均遵守OpenPGP数据加解密标准。
菲利普·齐默曼（Philip R. Zimmermann）在1991年创造了第一个版本的PGP，1997年7月，PGP Inc.与齐默尔曼同意IETF制定一项公开的互联网标准，称作OpenPGP（RFC 4880），任何支持这一标准的程序也被允许称作OpenPGP。自由软件基金会开发的OpenPGP程序叫做GnuPG（GPG），也陆续有一些商用OpenPGP软件被开发出来。
S/MIME 是Secure/Multipurpose Internet Mail Extensions (安全多用途互联网邮件扩展协议)的缩写，是采用PKI技术的用数字证书给邮件主体签名和加密的国际标准协议。1992年，MIME（多用途互联网邮件扩展）协议编撰完成，用于互联网邮件服务器和网关之间通信。该标准方法支持非ASCII编码的附件格式，意味着你可以发送附件并保证文件可以送达另一端，但是附件有时会被篡改，无法确保邮件机密性和完整性。1995年，S/MIME(安全/多用途互联网邮件扩展)协议V1版本开发问世，对安全方面的功能进行了扩展，提供数字签名和邮件加密功能，邮件加密用来保护电子邮件的内容，数字签名用于验证发件人身份，防止身份冒用，并保护电子邮件完整性。1998年和1999年相继出台V2/V3版本并提交IETF形成系列RFC国际标准。
S/MIME和PGP都是用于通过互联网对消息进行身份验证和加密保护的协议，都使用公钥加密技术进行电子邮件签名和加密。而主要区别在于：
公钥可信度： S/MIME标准中，用户必须从受信任的证书颁发机构申请X.509v3数字证书，由权威CA机构验证用户真实身份并签署公钥，确保用户公钥可信，收件人通过证书公钥验证发件人身份真实性。而PGP不提供强制创建信任的策略，由发件人自己创建并签署自己的密钥对，或为其他通信用户签署公钥增加其密钥可信度，没有任何受信任的权威中心去验证核实身份信息，每个用户必须自己决定是否信任对方。
加密保护的范围： PGP的诞生是为了解决纯文本消息的安全问题，而S/MIME不仅保护文本消息，更旨在保护各种附件/数据文件。
集中化管理： 从管理角度来看，S / MIME被认为优于PGP，因为它具有强大的功能，支持通过X.509证书服务器进行集中式密钥管理。
兼容性和易用性： S/MIME具备更广泛的行业支持，S/MIME协议已经内置于大多数电子邮件客户端软件中，如Outlook、雷鸟和iMail等都支持S/MIME加密。从最终用户的角度来看，S/MIME的易用性也优于PGP，因为PGP需要下载额外的插件才能运行，S / MIME协议允许大多数供应商发送和接收加密电子邮件而无需使用其他插件。
因此，总体来说S/MIME标准的适用性更加广泛，能够更加全面保护电子邮件安全与可信。美国国家标准技术研究院发布的“可信邮件”标准中，就明确地推荐联邦机构使用S/MIME保护邮件安全：
5-4: 对于联邦使用，OpenPGP不是首选的消息加密技术。应该使用S/MIME 和由已知CA签发的证书。
4-11: 使用S/MIME 签名来确保邮件的真实性和完整性。
7-2：企业应建设密钥管理系统来保护电子邮件用户的会话加密密钥。
密信(MeSince)是一款基于S/MIME标准的免费加密邮件客户端
转载于:https://my.oschina.net/wossl/blog/2993404
