第1页
------------------------------ ----------------------------------------------------------------------------
1. INTRODUCTION
1.1. SCOPE
This standard specifies a syntax for text messages that are
sent among computer users, within the framework of "electronic
mail". The standard supersedes the one specified in ARPANET
Request for Comments #733, "Standard for the Format of ARPA Net-
work Text Messages".
In this context, messages are viewed as having an envelope
and contents. The envelope contains whatever information is
needed to accomplish transmission and delivery. The contents
compose the object to be delivered to the recipient. This stan-
dard applies only to the format and some of the semantics of mes-
sage contents. It contains no specification of the information
in the envelope.
However, some message systems may use information from the
contents to create the envelope. It is intended that this stan-
dard facilitate the acquisition of such information by programs.
Some message systems may store messages in formats that
differ from the one specified in this standard. This specifica-
tion is intended strictly as a definition of what message content
format is to be passed BETWEEN hosts.
Note: This standard is NOT intended to dictate the internal for-
mats used by sites, the specific message system features
that they are expected to support, or any of the charac-
teristics of user interface programs that create or read
messages.
A distinction should be made between what the specification
REQUIRES and what it ALLOWS. Messages can be made complex and
rich with formally-structured components of information or can be
kept small and simple, with a minimum of such information. Also,
the standard simplifies the interpretation of differing visual
formats in messages; only the visual aspect of a message is
affected and not the interpretation of information within it.
Implementors may choose to retain such visual distinctions.
The formal definition is divided into four levels. The bot-
tom level describes the meta-notation used in this document. The
second level describes basic lexical analyzers that feed tokens
to higher-level parsers. Next is an overall specification for
messages; it permits distinguishing individual fields. Finally,
there is definition of the contents of several structured fields.
-----------------------------------------------------------------------------------------------------------
1. 介绍
1.1. 范围
这个标准定义了一种在"电子邮件"框架下,让计算机用户之间交互的文
本消息的语法。本标准取代了由于ARPA网络需求而产生的标准RFC733.
整体来看, 消息内容包含信封和信件体. 信封包含的信息用来完成传
送和投递. 信件体是由需要投递给收件人的信息元素组成. 本标准只涉及信
件体,没有定义信封相关的信息(注:熟悉SMTP协议的就清楚,协议上的
MAIL FROM:, RCPT TO:就是信封, 而DATA后的MIME是信件体, 本协议只是定
义信件体)
但是, 有些邮件系统可能会使用信件内容来创建信封(注:如exchange)。
实行本标准可以使程序更容易的通过信件体内容来获得信封需要的信息。
一些邮件系统可能不使用标准定义的格式来储存邮件。本标准主要规
范邮件服务器之间进行交互时的消息格式。
注意：本标准不试图约束站点的内部消息格式，不明确指定邮件服务
器应该支持的特性，也未定义程序应该如何创建或显示邮件内容
我们需要弄清楚什么是"需要的"，什么是"允许的"。消息可能很复杂
，包含大量的格式定义元素(注:如word生成的文档)，也可能小而简单，只
有消息所允许的最小集合。另外，标准简化了几种不同的消息显示格式，
这些定义只影响消息的显示效果，不影响消息内容。实现者可以选择
保留这些可视化特性.
正式的定义分为四层。最底层描述了文档中使用的元符号定义。第二
层定义了基本的词法分析器，把词分解出来传递给更上一层处理。下一层是
消息的全面定义，它允许定义不同的域。最后一层，定义了几种由带有一定
结构的多个域组成的内容。
------------------------------------- ----------------------------------------------------------------------------
第2页
------------------------------------------------------------------------------------------------------------------
1.2. COMMUNICATION FRAMEWORK
Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions
of data compression or to transmission and storage efficiency,
and the standard tends to be free with the number of bits con-
sumed. For example, field names are specified as free text,
rather than special terse codes.
A general "memo" framework is used. That is, a message con-
sists of some information in a rigid format, followed by the main
part of the message, with a format that is not specified in this
document. The syntax of several fields of the rigidly-formated
("headers") section is defined in this specification; some of
these fields must be included in all messages.
The syntax that distinguishes between header fields is
specified separately from the internal syntax for particular
fields. This separation is intended to allow simple parsers to
operate on the general structure of messages, without concern for
the detailed structure of individual header fields. Appendix B
is provided to facilitate construction of these parsers.
In addition to the fields specified in this document, it is
expected that other fields will gain common use. As necessary,
the specifications for these "extension-fields" will be published
through the same mechanism used to publish this document. Users
may also wish to extend the set of fields that they use
privately. Such "user-defined fields" are permitted.
The framework severely constrains document tone and appear-
ance and is primarily useful for most intra-organization communi-
cations and well-structured inter-organization communication.
It also can be used for some types of inter-process communica-
tion, such as simple file transfer and remote job entry. A more
robust framework might allow for multi-font, multi-color, multi-
dimension encoding of information. A less robust one, as is
present in most single-machine message systems, would more
severely constrain the ability to add fields and the decision to
include specific fields. In contrast with paper-based communica-
tion, it is interesting to note that the RECEIVER of a message
can exercise an extraordinary amount of control over the
message's appearance. The amount of actual control available to
message receivers is contingent upon the capabilities of their
individual message systems.
--------------------------------------------------------------------------------------------------------------
1.2. 通讯框架
消息由多行文本组成。对图片、传真、语音或者结构化文本的编码没有
特别限制。对数据压缩，使传输和储存更有效，也基本不用考虑，本标准更
趋向放开对字节数字的限制。例如，域名定义是使用任意的文本，而不是使用
特殊的编码。
消息使用常规的"memo"框架。这个框架规定，消息包含一些已经定义的域，
另外还可以包含一些本标准里没有定义的域。有一些域的语法定义在本文档里
能找到，而这些定义的域中有的必须在所有的消息里都存在。
这种语法区分邮件头不同域的语法，有别于定义内部语法和特殊域。它
能让简单的解析器处理邮件的主要部分，而不是关注于特殊域的结构细节。
附录B提供了完整的语法定义，可供解析器使用。
除了本文档特殊定义的域以外，其他的域也可以一样使用。如果必要，
可以另外定义扩展域的规范，它们将使用和本文档中定义的域一样的结构。
用户也可能希望扩展一套它们自己的域，自己使用。用户自定义的域也是
允许的。
框架严格的约束了文档的颜色和外观，本标准主要用于机构内部通讯，
也可以在多个组织良好的机构之间通讯(注:现在已经是在整个互联网上通讯)。
本标准也适用于一些进程间通讯。一个复杂的框架可能允许多种字体，多种
颜色，多种编码。一个简单的框架，例如在大多数的独立机器上的邮件系统，
可能会更加严格的限制需要添加的域，或者定义另外一些特殊的域。电子邮件
和纸邮件相反，我们很惊奇地发现，邮件的接收者可能看到很多不同的邮件
外观，收件人看到的邮件的样子，和具体的邮件系统有关。
------------------------------------------------------------------------------------------------------------------------