44、电子邮件之一（应用层）

引言

电子邮件或者更常用的E-mail，己经存在30 多年了（不止了）。由于比纸质信件更快更便便宜，电子邮件成为自早期Internet 出现以来最广泛的应用。在1990 年以前，它主要被用于学术界。在整个20 世纪90 年代，它变得普及起来并呈指数形式增长，以至于现在每天发送的电子邮件数量远远超过了传统的纸质邮件（ snail mail ）数量。其他形式的网络通信，比如即时消息和IP语音在近10 年也有了极大的发展，但是电子邮件仍然是Internet 通信的主要负载。电子邮件广泛地用于业界公司内部的通信，例如，分散在世界各地的员工们就一个复杂项目进行协同。不幸的是，像纸质信件一样，大多数电子邮件都是邮寄宣传品或者垃圾邮件(spam），某些甚至10 封邮件里面高达9 封是垃圾邮件（ McAfee, 2010 ）。
与大多数其他通信方式一样，电子邮件有它自己的约定和风格。特别是它非常不拘小节，使用户门槛很低。那些从来没有梦想过给某个大人物打一个电话或者写一封信的人，可以毫不犹豫地给他发一封随意书写的电子邮件。由于消除了与社会地位、年龄和性别有关的大多数暗示，通过电子邮件展开辩论通常关注于内容本身而不是状态。有了电子邮件，某个暑期学生的绝妙想法比一个执行副总裁的愚钝想法影响力更大。电子邮件中充满了诸如BTW (By The Way ，顺便）、ROTFL C Rolling On The Floor Laughing，笑得满地打滚）和IMHO（ln My Humble Opinion，恕我直言）等行话。很多人还在他们的电子邮件中使用一些称为微笑图标（ smiley ）的ASCII 符号，这种符号始于普适的“：－）”。这种符号和其他情绪图标（emoticon ）有助于传递邮件语气，现在它们已经被扩散到其他形式的通信中，比如即时消息。
电子邮件协议在其使用期间经历了很大的演变。第一个电子邮件系统简单地由文件传输协议和约定组成，约定规定每个邮件的第一行（即文件）必须给出收件人地址。随着时间的推移，文件传输和电子邮件分歧越来越大，最终电子邮件从文件传输中分离出来并增加了许多功能，例如发送一个邮件给一组收件人的能力。在20 世纪90 年代，多媒体功能变得非常重要，邮件可以包括图像和其他非文字材料。相应地，阅读电子邮件的程序也变得更为复杂，从单纯的基于文本阅读转变成图形用户界面，．并且为用户增加了在任何地方通过笔记本电脑访问邮件的能力。最后，随着垃圾广告邮件的盛行，邮件阅读器和邮件传输协议现在必须具备发现这些不想要的邮件并删除它们的能力。在我们的电子邮件描述中，我们将精力集中在用户之间如何移动邮件，而没有考查和体验邮件阅读程序。然而，在描述了整体架构后，我们将开始介绍电子邮件系统中面向用户的那一部分。

1、体系结构

在本节将概述，说明电子邮件系统如何组织以及它们可以做什么。电子邮件系统的体系结构如图所示。它包括两类子系统：用户代理( user agent ）和邮件传输代理（ message transfer agent ）。人们通过用户代理阅读和发送电子邮件：邮件传输代理负责将用户邮件从源端移动到目的地。我们把邮件传输代理非正式地称为邮件服务器。
用户代理是一个程序，用户通过它与电子邮件系统交互。用户代理提供了一个图形界面，有时是一个基于文本和基于命令的接口。它包括了撰写邮件、回复邮件、显示入境邮件信息的手段，同时还提供了如何过滤、搜索和删除邮件的组织方式。把新邮件发送给邮件系统，并通过它传递的行为称为邮件提交（ mail submission ）。
有些用户代理可能会自动完成对邮件的处理，预测用户想要什么。例如，为了提取出或者降低可能是垃圾邮件的优先级，入境邮件可能会先被过滤。某些用户代理还包括一些先进功能，比如安排电子邮件的自动回复（“现在我正在度一个美妙假期，一旦我回去将立即给你回复")。用户代理运行在用户阅读邮件的同一台计算机上。这只是另一个程序，而且或许只运行一段时间。邮件传输代理通常是系统进程。它们运行在邮件服务器机器的后台，并始终保持运行状态。它们的工作是通过系统自动将电子邮件从发送端移动到收件人，采用的协议是简单邮件传输协议（ SMTP, Simple Mail Transfer Protocol ）。
SMTP 最早由RFC 821 说明，之后被修订成为当前的RFC 53210 它通过一个连接发送邮件、返回传递状态和任何错误的报告。对许多应用来说，确认交付非常重要，甚至可能具有法律上的意义（“哦，先生，我的电子邮件系统没那么可靠，所以我猜测电子传票可能遗失在某个地方了”）。邮件传输代理还实现了邮件列表( mailing list）功能，一个邮件的完全相同副本被传递到电子邮件地址列表中的每个人。其他先进的功能包括抄送、秘密抄送、高优先级电子邮件、秘密（即加密）电子邮件：如果主要收件人当前不方便接收邮件，那么可指定另一个接收者，以及阅读老板邮件并代替回复邮件的辅助能力。
将用户代理和邮件传输代理衔接起来的是邮箱这个概念，以及电子邮件的标准格式。邮箱（ mailbox）存储用户收到的电子邮件。邮箱由邮件服务器负责维护，用户代理只需向用户展示邮箱中的内容即可。要做到这一点，用户代理向邮件服务器发送操纵邮箱的命令，包括检查邮箱内容、删除邮件等。邮件检索在图中是最后交付（第3 步）。在这样的体系结构下，一个用户可以在多台计算机上使用不同的用户代理来访问同一个邮箱。在两个邮件传输代理之间发送的邮件具有标准的格式。原来由RFC 822 规定的格式被修订为当前的RFC5322 ，并且扩展成支持多媒体内容和国际文本。这个方案称为MIME。
电子邮件系统的一个关键思想是将信封（ envelope ）与邮件内容区分开来。信封将消息封装成邮件，它包含了传输消息所需要的所有信息，例如目标地址、优先级和安全等级，所有这些都有别于消息本身。消息传输代理根据信封来进行路由，就好像邮局的做法一样。信封内的消息由两部分组成：邮件头（ header）和邮件体（ body ）。邮件头包含用户代理所需的控制信息。邮件体则完全提供给收件人，代理和邮件传输代理都不在意邮件体包含了什么信息。下面，我们按照一个用户给另一个用户发送电子邮件涉及的每个步骤，来详细考查这种体系结构下的每个组成部分。这个考查之旅就从用户代理开始。

2、用户代理

用户代理是一个程序（有时也称为电子邮件阅读器），它接收各种各样命令，从接收和回复邮件到操纵邮箱的命令。目前流行的用户代理有许多，其中包括谷歌Gmail 、微软的Outlook、Mozilla 的Thunderbird 和苹果的Apple Mailo 这些用户代理在外形上相差很大。大多数用户代理有一个菜单或图标驱动的图形界面，需要使用鼠标进行操作：在小型移动设备上的界面通常是触摸界面。老的用户代理，比如Elm 、mh 和Pine 提供的是基于文本的界面，期望用户从键盘输入一个字符命令。从功能上看，这些界面都相同，至少对文本消息是一样的。
用户代理界面的典型元素如图所示。你的邮件阅读器可能比这个要华丽得多，但或许具有同等的功能。当用户代理被启动时，它一般会给出用户邮箱内邮件的摘要信息。通常情况下，摘要信息是每个邮件占一行，并且按照某种排序排列。摘要突出的是从邮件信封或邮件头中提取出来的一些关键字段。
图中显示了的例子中的摘要信息有7 行。每一行使用了发件人、标题和何时接收三个字段，显示的顺序可以按照邮件的发送者、邮件的标题以及邮件的接收时间来排列。所有信息的格式都以用户友好的方式呈现，而不是显示消息字段的文字内容，但无论采用什么方式都必须基于邮件字段。
摘要中也可能包括许多其他字段或指示信息。例如，图中邮件标题旁边的图标可能表明未读邮件〈信封）、有附件（回形针）和重要邮件，至少发件人判定为重要〈感叹号）。还可以按照其他规则进行邮件的排序。最常见的是根据接收到邮件的时间，将最近收到的邮件优先显示，同时还使用一些指示消息是新的还是己被用户读取过的图标。在邮件摘要显示的字段和排序方式用户可以自己的喜好定制。
需要时用户代理必须能够显示入境邮件信息，方便人们阅读他们的电子邮件。通常系统会提供一个短消息预览，帮助用户决定何时进一步阅读该邮件。预览可以使用小图标或图像来描述邮件的内容。用户代理还提供其他表示的处理方式，包括重新格式化邮件来适应当前的显示，或者翻译或转换邮件内容成更便利的显示格式（例如，可识别文本的数字化语音）。邮件被阅读过后，用户可以决定用它来做什么。这就是所谓的邮件处置（ message disposition ）。邮件的进一步处理选项包括删除邮件、回复邮件、把邮件转发给另一个用户，以及保存邮件供日后参考。大多数用户代理可以用多个文件夹保存一个邮箱的入境邮件。文件夹允许用户根据发件人、标题或一些其他分类方法来保存消息。
在用户阅读邮件之前，用户代理可以自动完成邮件的归档。一个常见的例子，系统检查邮件的字段和内容，根据有关以前邮件的用户反馈，使用邮件字段和内容来确定是否可能是垃圾邮件。许多ISP 和企业都运行这样的软件，给邮件贴上重要或者垃圾邮件的标签，这样用户代理可以将这些邮件归档到相应的邮箱中。对于许多用户来说， ISP 和公司具有预先看到邮件的优势，并且它们可能拥有己知垃圾邮件发送者的名单。如果几百个用户恰好刚刚收到类似的消息，那么这个邮件很有可能是垃圾邮件。通过预先将入境邮件分类到“可能合法”和“可能垃圾邮件”的做法，用户代理可以为用户节省从垃圾邮件中分离出有用信息的大量工作。
那么，什么是最流行的垃圾邮件？它是由一组被感染的计算机产生的邮件，具体内容取决于你居住的地方。这种被感染的计算机集合就称为僵尸网络（botnet）。在亚洲，典型的垃圾邮件是假文凭的制作；在美国，廉价药品和其他可疑产品的供给是典型的垃圾邮件。用户还可以构造其他归档规则。每个规则指定了一个条件和相应的一个动作。例如，规则可以将来自老板的邮件都放到一个要立即阅读的文件夹中，而指定从某个特定邮件列表发来的任何消息存到另一个文件夹供稍后阅读。图显示了几个文件夹。其中最重要的文件夹是lnbox （收件箱〉，用来存放没有预先规定存放的邮件，即没有其他地方可去的入境邮件：还有一个文件夹是Junk Mail （垃圾邮件），被认为是垃圾邮件的邮件都归类到该文件夹。
除了显式构造自己喜欢的各种文件夹外，用户代理还为用户提供了丰富的搜索邮箱功能。搜索能力为用户提供了快速查找邮件的手段，比如上个月有人发送的有关“在哪里买Vegemite ”的邮件。电子邮件自从刚出现时作为一种文件传输以来，己经走过了很长的路。现在服务提供商经常能为用户支持高达1 GB 的邮箱用来存储邮件，而且这些邮件是用户在很长一段时间内邮件交互的细节。用户代理先进的邮件处理的能力，包括搜索和自动分类处理，使得它可以管理这些大量的电子邮件。对于一年要发送和收到数千封电子邮件的用户来说，这些工具非常宝贵。
另一个有用的功能是用户代理能够以某种方式自动响应邮件。一种响应是将入境的电子邮件转发到一个不同的地址，例如，由一个商业传呼服务所操纵的计算机，通过无线电或卫星寻呼用户，并在他的寻呼机上显示“主题：”行。这些自动响应功能必须运行在邮件服务器上，因为用户代理可能无法在所有的时间内部保持运行状态，而且很有可能只是偶尔检索电子邮件。基于这些因素的考虑，用户代理不能提供一个真正的自动响应服务。然而，自动响应的接口通常由用户代理表示。
另一个不同的自动响应例子是休假代理。这是一个程序，它首先检查每个入境消息，然后给发件人回送一个平淡的答复，比如＝“嗨。我在度假。我将于8 月24 日回来后立即联系你。”这样的答复也可以指定如何处理在此期间发生的紧急事项，或者针对某人就某个特殊问题的邮件给予回复等。大多数度假代理跟踪它们己经给哪些用户发过这种“罐装回复”（ canned reply ），以免给同一人重复发送相同的回复。然而，这些代理依然有缺陷。例如，它给来自一个大邮件列表的群发邮件回送一个罐装答复显然是不可取的。
让我们现在把注意力转到一个用户将消息发送给另一个用户的场景。用户代理支持的基本功能之一是邮件的组成，这点我们还没有讨论过。邮件的组成涉及创建邮件、回复邮件，以及为了将邮件交付给收件人而将这些邮件发送到邮件系统的其余部分。虽然在创建邮件时，可以使用任何文本编辑器来撰写邮件正文，但邮件正文编辑器通常集成在用户代理中，以便它可以为每个邮件提供类似寻址和多个头字段的辅助功能。例如，在回复邮件时，电子邮件系统可以从收到的邮件中提取发件人的地址，并自动插入到回复邮件的适当的地方。其他一些共同功能包括在邮件底部追加一个签名块、更正拼写错误和计算表明该消息是否有效的数字签名。
发往邮件系统的邮件遵循一个标准格式，这个格式的创建基于提供给用户代理的信息。传输消息的最重要部分是信封，信封中最重要的是目的地址。邮件目的地址必须是邮件传输代理可以处理的格式。期望的地址形式是用户＠DNS 地址（ [email protected] ）。然而，值得注意的是还存在其他形式的地址。特别是，X.400 地址看上去和DNS 地址完全不同。X.400 是邮件处理系统的ISO 标准，它曾经是SMTP 的竞争对手。SMTP 轻而易举地取得了胜利，虽然仍有人在使用X.400 系统，而且使用者大多在美国以外的地区。X.400地址由“属性＝值”对组成，相互之间用斜线分开，例如：
/C=US/ST=MASSACHUSETTS/L=CAMBR工DGE/PA=360 MEMORIAL DR./CN=KEN SMITH/
这个地址指定了一个国家、国内的州、地方城市、个人的地址和通用名字（ Ken Smith ）。标准还允许许多其他属性，你可以发送电子邮件给某个人，他的准确电子邮件地址你并不知道，只要你知道关于他的足够其他属性（例如，公司和职位〉。虽然X.400 名字使用的方便程度大大低于DNS 域名，但这个问题对用户代理没有实际意义，因为它们有用户友好的别名（有时也称为昵称〉，允许用户输入或选择一个人的名字，并得到正确的电子邮件地址。因此，它通常没有必要实际输入这些奇怪的字符串。
最后一点与发送邮件有关的是邮件列表，即允许用户通过一个命令把相同的邮件发送给群发列表中的每个人。如何维护这个邮件列表有两个选择。第一个，可以由用户代理在本地维护。在这种情况下，用户代理只是给每个目标收件人发送一个单独的邮件。另一个选择是远程维护一个在邮件传输代理上的群发名单。然后，邮件在整个邮件传
输系统中被扩散，等同于多个用户给群发列表中的用户发送邮件的作用。例如，如果一群观鸟者有一个称为birders 的邮件列表，该群发列表安装在传输代理 meadowlark.arizona.edu上，那么任何发送到[email protected] 的邮件都将被路由到美国亚利桑那大学，并在那里被进一步扩散到邮件列表中的所有成员，这些成员可能分布在全世界的任何地方。这个邮件列表中的用户无法分辨这是一个邮件列表，它可能只是Gabriel 0. Birders教授的个人邮箱。

3、邮件格式

现在我们从用户接口转到邮件消息格式本身。用户代理发出的邮件必须设置成邮件传输代理能处理的标准格式。首先，我们将考查使用RFC 5322 的基本ASCII 电子邮件，然后我们再考查基本格式的多媒体扩展。RFC 5322 是Internet 邮件格式的最新版本，最初的Internet 邮件格式由RFC822 描述。

RFC 5322一Internet 邮件格式

邮件由一个基本的信封（作为SMTP 的一部分由RFC 5321 描述〉、数个头字段、一个空行和邮件体组成。头的每个字段（逻辑上）由一行ASCII 文本组成，其中包括域名、一个冒号，对于大多数头的字段来说还包括一个值。几十年前完成设计的最初RFC822 没有明确区分开信封字段和头字段。虽然RFC 5322 己经对RFC 822 做了许多修订，但由于RFC822 己经被广泛使用，因此要想完全重新设计是不可能的。在一般的用法中，用户代理创建一个邮件并把它传递给邮件传输代理，然后邮件传输代理利用某些头字段来构造出实际的信封，这个信封有点像老式的邮件与信封混合体。
图中列出了与邮件传输相关的主要头字段。“ To：”字段给出了主要收件人的DNS地址，邮件系统允许有多个收件人。＂ Cc：”字段给出了所有次要收件人的地址。从邮件投递的角度来看，主收件人和次收件人没有区别。这完全是一种心理上的差别，这种差别也许对于相关的人而言很重要，但是对邮件系统来说无关紧要。＂ Cc ：”（ Carbon copy ，抄送）这个术语有点过时，因为计算机不使用复写纸，但是它己经被约定成俗了。“ Bcc："（ Blind carbon copy ，密件抄送) 字段与Cc：字段类似，只是在发送给主收件人和次收件人的所有副本中，这一行被删除了。这个特性允许人们在主收件人和次收件人都不知道的情况下，向第三方发送邮件副本。
接下来的两个字段“ From：”和“ Sender：”分别指出邮件的撰写者与邮件的发送者，这二者不一定相同。例如，一个公司经理撰写了一个邮件，但她的助理可能是实际发送该邮件的人。在这种情况下，经理被列在“From：”字段中，而她的助理应该出现在“ Sender：”字段。“ From：”字段是必需的，但是，如果“ Sender：”字段与From：字段的值相同，那么可以省略“ Sender：”字段。一旦邮件无法投递井且必须被退回发件人时，这些字段就都是必需的了。
在邮件投递的路径上，每个邮件传输代理都会给该邮件加上一行。该行包含“ Received：”字段，给出了该代理的标识符、接收到此邮件的日期和时间，以及其他一些可用来查找路由系统中错误的信息。“ Return-Path：”字段由最后一个邮件传输代理添加，主要用来指示如何返回至发件人。理论上，这个信息可以从所有的“ Received：”头字段（除了发件人邮箱的名字〉收集得到，但实际上很少填充该字段，它一般只包含发件人的地址。
除了表中列出的字段以外， RFC 5322 消息还包含了各种供用户代理或者收信人使用的字段。下表列出了最常见的一些头字段，它们大部分的含义都不言自明。
有的时候，当邮件的撰写者或者邮件的发送者都不希望看到邮件的回复时，就可以使用“ Reply-To：”字段。例如，市场部经理撰写了一个电子邮件消息，向客户介绍一个新产品。秘书发送了这个消息，但“Reply-To：”字段列出的是销售部门的负责人，因为他可以回答问题并处理订单。当发件人有两个电子邮件账号，并希望消息被回复到其中另一个账号时，这个字段也很有用。
“ Message-Id：”字段是自动产生的，用于链接邮件（比如，当使用“ In-Reply-To：”字段时〉并防止重复传递邮件。RFC 5322 文档明确地指出用户可以发明新的邮件头供自己私人使用，只要这些邮件头（自从RFC 822 以来〉以字符串“X-”开头即可。RFC 822 保证将来的邮件头不会使用以X－作为开头的名字，以免官方邮件头与私用邮件头之间发生冲突。像“ X-Fruit-of-the-Day：”这样的字段，它们都是合法的。在邮件头之后是邮件体。用户可以在这里放置他们想放的任何内容。有些人用精心设计的签名来结束他们的邮件，这些签名包括对大大小小某些权威著作的引用、政治声明以及各种各样的声明。

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 ”头。