Network Working Group K. Toyoda
Request for Comments: 2305 H. Ohno
Category: Standards Track J. Murai
WIDE Project
D. Wing
Cisco
March 1998
Network Working Group K. Toyoda
Request for Comments: 2305 H. Ohno
Category: Standards Track J. Murai
WIDE Project
D. Wing
Cisco
March 1998
A Simple Mode of Facsimile Using Internet Mail
一种使用Internet邮件的简单传真方式
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
SUMMARY
总结
This specification provides for "simple mode" carriage of facsimile data over the Internet. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Facsimile [5,6,19]. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.
本规范规定了互联网上传真数据的“简单模式”传输。随后将对本文件进行扩展。当前规范采用标准协议和文件格式，如TCP/IP、互联网邮件协议[1,2,3]、MIME[4,16,17]和传真TIFF[5,6,19]。它不仅可以将图像发送到其他具有互联网意识的传真设备，还可以发送到互联网本机系统，例如带有普通电子邮件阅读器的PC，这些阅读器可以处理MIME邮件和传真数据的TIFF。该规范促进了现有传真设备、Internet邮件代理以及连接它们的网关之间的通信。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [7].
本文件中的关键词“必须”、“应该”、“不应该”和“可能”应按照[7]中所述进行解释。
1 SCOPE
1范围
This specification defines a message-based facsimile communication over the Internet. It describes a minimum set of capabilities, taking into account those of typical facsimile devices and PCs that can generate facsimile data.
本规范定义了互联网上基于消息的传真通信。它描述了一组最小的功能，考虑到典型传真设备和可生成传真数据的PC的功能。
A G3Fax device has substantial restrictions due to specifications in the standards, such as for timers. This specification defines a profile for Internet mail, rather than creating a distinct "facsimile over the Internet" service. The semantics resulting from the profile are designed to be compatible with facsimile operation over the general switched telephone network, so that gateways between facsimile and Internet mail can operate with very high fidelity.
G3Fax设备由于标准中的规范（如计时器）而受到很大限制。本规范定义了Internet邮件的配置文件，而不是创建独特的“Internet传真”服务。该配置文件产生的语义设计为与通用交换电话网络上的传真操作兼容，因此传真和互联网邮件之间的网关可以高保真地运行。
The reason for developing this capability as an email profile is to permit interworking amongst facsimile and email users. For example it is intended that existing email users be able to send normal messages to lists of users, including facsimile-based recipients, and that other email recipients shall be able to reply to the original and continue to include facsimile recipients. Similarly it is intended that existing email software work without modification and not be required to process new, or different data structures, beyond what is normal for Internet mail users. Existing email service standards are used, rather than replicating mechanisms which are more tailored to existing facsimile standards, to ensure this compatibility with existing email service.
将此功能开发为电子邮件配置文件的原因是允许传真和电子邮件用户之间进行交互。例如，现有电子邮件用户能够向用户列表发送普通邮件，包括基于传真的收件人，其他电子邮件收件人应能够回复原件并继续包括传真收件人。类似地，现有的电子邮件软件可以不经修改地工作，并且不需要处理新的或不同的数据结构，这超出了互联网邮件用户的正常工作范围。使用现有电子邮件服务标准，而不是复制更适合现有传真标准的机制，以确保与现有电子邮件服务的兼容性。
A facsimile-capable device that uses T.4 [8] and the general switched telephone network (GSTN) is called a "G3Fax device" in this specification. An "IFax device" is an Internet- accessible device capable of sending, receiving or forwarding Internet faxes. A message can be sent to an IFax device using an Internet mail address. A message can be sent to a G3Fax device using an Internet mail address; the message MAY be forwarded via an IFax offramp gateway.
使用T.4[8]和通用交换电话网（GSTN）的具有传真功能的设备在本规范中称为“G3Fax设备”。“IFax设备”是一种可访问互联网的设备，能够发送、接收或转发互联网传真。可以使用Internet邮件地址将消息发送到IFax设备。可以使用Internet邮件地址向G3传真设备发送消息；该消息可通过IFax出口网关转发。
This specification provides for communication between each of the following combinations:
本规范规定了以下各组合之间的通信：
Internet mail => Network printer
Internet mail => Offramp gateway (forward to
G3Fax)
Network scanner => Network printer
Network scanner => Offramp gateway (forward to
G3Fax)
Network scanner => Internet mail
Internet mail => Network printer
Internet mail => Offramp gateway (forward to
G3Fax)
Network scanner => Network printer
Network scanner => Offramp gateway (forward to
G3Fax)
Network scanner => Internet mail
2 COMMUNICATION PROTOCOLS
2通信协议
The set of conventions necessary to achieve facsimile- compatible service covers basic data transport, document data formats, message (document) addressing, delivery confirmation, and message security. In this section, the first 4 are covered. The remainder are covered in following sections, along with additional details for addressing and formats.
实现传真兼容服务所需的一系列约定包括基本数据传输、文档数据格式、消息（文档）寻址、传递确认和消息安全。在本节中，将介绍前4部分。其余部分将在以下部分中介绍，以及有关寻址和格式的其他详细信息。
This section describes mechanisms involved in the transport between IFAX devices.
本节描述了IFAX设备之间传输所涉及的机制。
Data transfer MAY be achieved using standard Internet mail transfer mechanisms[1, 3]. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards [1, 2, 3].
可以使用标准的Internet邮件传输机制实现数据传输[1,3]。地址的格式必须符合RFC 821<addr spec>和RFC 822<mailbox>互联网邮件标准[1,2,3]。
A gateway translates between dissimilar environments. For IFax, a gateway connects between Internet mail and the T.4/GSTN facsimile. Gateways can service multiple T.4/GSTN facsimile users or can service only one. In the former case, they serve as a classic "mail transfer agent" (MTA) and in the latter as a classic "mail user agent" (UA).
网关在不同的环境之间转换。对于IFax，互联网邮件和T.4/GSTN传真之间有一个网关连接。网关可以为多个T.4/GSTN传真用户提供服务，也可以仅为一个用户提供服务。在前一种情况下，它们充当经典的“邮件传输代理”（MTA），在后一种情况下充当经典的“邮件用户代理”（UA）。
An onramp is a gateway which connects from T.4/GSTN facsimile to Internet mail. An offramp is a gateway which connects from Internet mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for this specification.
入口是从T.4/GSTN传真到Internet邮件的网关。出口是一个从互联网邮件连接到T.4/GSTN传真的网关。入口匝道的行为超出本规范的范围。
This specification describes the Internet mail service portion of offramp addressing, confirmation and failure notification. Details are provided in later sections.
本规范描述了出口寻址、确认和故障通知的互联网邮件服务部分。详情将在后面的章节中提供。
An offramp gateway that operate as an MTA serving multiple users SHOULD use SMTP; a gateway that operates as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP or IMAP [9, 10].
作为MTA为多个用户提供服务的出口网关应使用SMTP；作为UA为单个邮件收件人提供服务的网关可以使用邮箱访问协议，如POP或IMAP[9,10]。
NOTE: An offramp gateway that relays mail based on addressing information needs to ensure that it uses addresses supplied in the MTA envelope, rather than from elsewhere, such as addresses listed in the message content headers.
注意：根据地址信息中继邮件的出站网关需要确保使用MTA信封中提供的地址，而不是来自其他地方的地址，如邮件内容标题中列出的地址。
IFax devices MUST be compliant with RFC 822 and RFC1123, which define the format of mail headers. The header of an IFax message SHOULD include Message-ID and MUST include all fields required by [2, 3], such as DATE and FROM.
IFax设备必须符合RFC 822和RFC1123，它们定义了邮件头的格式。IFax消息的标题应包括消息ID，并且必须包括[2,3]所需的所有字段，例如日期和起始日期。
IFax devices MUST be compliant with MIME [4], except as noted in Appendix A.
IFax设备必须符合MIME[4]，除非附录A中另有说明。
The data format of the facsimile image is based on the minimum set of TIFF for Facsimile[6], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [19]. Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
传真图像的数据格式基于传真的最小TIFF集[6]，也称为S配置文件。通过使用image/TIFF子类型将此类传真数据包括在MIME对象中[19]。对于基于消息的互联网传真应用程序，将TIFF用于传真的其他规则将在后面定义。
A single multi-page document SHOULD be sent as a single multi- page TIFF file, even though recipients MUST process multipart/mixed containing multiple TIFF files. If multipart content is present and processing of any part fails, then processing for the entire message is treated as failing, per [Processing failure] below.
单个多页文档应作为单个多页TIFF文件发送，即使收件人必须处理包含多个TIFF文件的多部分/混合文件。如果存在多部分内容，且任何部分的处理失败，则根据下面的[processing failure]将整个消息的处理视为失败。
This section describes existing requirements for Internet mail, rather than indicating special requirements for IFax devices.
本节描述了互联网邮件的现有要求，而不是IFax设备的特殊要求。
In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN. [14,15]
在发生继电器故障的情况下，发送继电器必须生成故障消息，该消息应采用DSN格式。[14,15]
NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices [Also see section 5.2.6]
注：通过SMTP传输的互联网邮件必须包含适用于发送退货通知的邮寄地址[另请参见第5.2.6节]
IFax devices with limited capabilities might be unable to process the content of a message. If this occurs it is important to ensure that the message is not lost without any notice. Notice MAY be provided in any appropriate fashion, and the exact handling is a local matter. (Also see Appendix A, second bullet.)
功能有限的IFax设备可能无法处理消息内容。如果发生这种情况，务必确保消息不会在没有任何通知的情况下丢失。通知可以以任何适当的方式提供，具体的处理是当地的事情。（另见附录A，第二个项目符号。）
3 ADDRESSING
3寻址
Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints.
发送给普通Internet邮件收件人的邮件将使用标准Internet邮件地址，不受其他限制。
G3Fax devices are accessed via an IFAX offramp gateway, which performs any authorized telephone dial-up.
G3Fax设备通过IFAX出口网关访问，该网关执行任何授权电话拨号。
When a G3Fax device is identified by a telephone number, the entire address used for the G3fax device, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate.
当G3Fax设备由电话号码标识时，G3Fax设备使用的整个地址（包括号码和出口主机参考）必须包含在标准Internet邮件传输字段中，如RCPT TO和mail FROM[1,3]。地址可以包含在消息内容字段中，如<authentic>和<destination>[2,3]，视情况而定。
As for all Internet mail addresses, the left-hand-side (local- part) of an address is not to be interpreted except by the MTA that is named on the right-hand-side (domain).
对于所有Internet邮件地址，地址的左侧（本地部分）不可解释，除非由在右侧（域）命名的MTA解释。
The telephone number format SHOULD conform to [11, 12]. Other formats MUST be syntactically distinct from [11, 12].
电话号码格式应符合[11,12]。其他格式必须在语法上与[11,12]不同。
4 IMAGE FILE FORMAT
4图像文件格式
Sending IFax devices MUST be able to write minimum set TIFF files, per the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile) [6], which is also compatible with the specification for the minimum subset of TIFF-F in [5]. Receiving IFax devices MUST be able to read minimum set TIFF files.
发送IFax设备必须能够按照TIFF中定义的用于传真的最小设置TIFF文件创建规则（S配置文件）[6]写入最小设置TIFF文件，该规则也符合[5]中TIFF-F最小子集的规范。接收IFax设备必须能够读取最小设置的TIFF文件。
A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Facsimile unless the sender has prior knowledge of other TIFF fields or values supported by the recipient. The mechanism for determining capabilities of recipients is beyond the scope of this document.
除非发送方事先知道接收方支持的其他TIFF字段或值，否则发送方不应在传真中使用TIFF最小子集以外的TIFF字段和值。确定收件人能力的机制超出了本文档的范围。
5 SECURITY CONSIDERATIONS
5安全考虑
This specification is based on use of existing Internet mail. To maintain interoperability with Internet mail, any security to be provided should be part of the of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
本规范基于对现有互联网邮件的使用。为了保持与Internet邮件的互操作性，所提供的任何安全性都应该是Internet安全基础架构的一部分，而不是Internet基础架构之外的新机制或其他机制。
Both Internet mail and G3Fax standards and operational services have their own set of threats and countermeasures. This section attends only to the set of additional threats which ensue from integrating the two services. This section reviews relevant concerns about Internet mail for IFax environments, as well as considering the potential problems which can result of integrating the existing G3Fax service with Internet mail.
互联网邮件和G3传真标准以及运营服务都有自己的一套威胁和对策。本节仅讨论集成这两个服务所带来的一系列附加威胁。本节回顾了有关IFax环境下Internet mail的相关问题，并考虑了将现有G3Fax服务与Internet mail集成可能导致的潜在问题。
The actual sender of the message might not be the same as that specified in the Sender or From fields of the message content headers or the MAIL FROM address from the SMTP envelope.
邮件的实际发件人可能与“发件人”或“邮件内容头”字段中指定的发件人或SMTP信封中的“邮件发件人”地址不同。
In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. The usual solution is through encryption-based authentication, either for the channel or associated with the object, as discussed below.
在严格约束的环境中，充分的物理和软件控制可能能够确保防止此问题。通常的解决方案是通过基于加密的身份验证，无论是针对通道还是与对象关联，如下所述。
It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication. End-to-end approaches such as S/MIME and PGP/MIME are currently being developed within the IETF. These technologies can provide such authentication.
应该认识到，SMTP实现不提供邮件发件人的固有身份验证，站点也没有义务提供此类身份验证。IETF目前正在开发端到端方法，如S/MIME和PGP/MIME。这些技术可以提供这种认证。
In addition to the resources normally consumed for email (CPU cycles and disk), offramp facsimile causes an outdial which often imposes significant resource consumption, such as financial cost. Techniques
除了通常用于电子邮件的资源（CPU周期和磁盘）外，离线传真还会导致外拨，这通常会造成大量资源消耗，如财务成本。技巧
for establishing authorization of the sender are essential to those offramp facsimile services that need to manage such consumption.
对于需要管理此类消费的出口传真服务而言，建立发送方授权至关重要。
Due to the consumption of these resources by dialout, unsolicited bulk email which causes an outdial is undesirable.
由于拨出会消耗这些资源，因此不希望出现导致拨出的未经请求的批量电子邮件。
Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp. There are no standard techniques for authorization using Internet protocols.
出口网关应提供以某种方式授权发送方的能力，以防止未经授权使用出口。没有使用Internet协议进行授权的标准技术。
Typical solutions use simple authentication of the originator to establish and verify their identity and then check the identity against a private authorization table.
典型的解决方案使用发起人的简单身份验证来建立和验证其身份，然后根据私有授权表检查身份。
Originator authentication entails the use of weak or strong mechanisms, such as cleartext keywords or encryption-based data-signing, respectively, to determine and validate the identify of the sender and assess permissions accordingly.
发起人身份验证需要使用弱或强机制，例如明文关键字或基于加密的数据签名，分别确定和验证发送者的身份，并相应地评估权限。
Other control mechanisms which are common include source filtering and originator authentication. Source filtering entails offramp gateway verification of the host or network originating the message and permitting or prohibiting relaying accordingly.
其他常见的控制机制包括源过滤和发起人身份验证。源过滤需要对发出消息的主机或网络进行出口网关验证，并相应地允许或禁止中继。
Confidential information about the sender necessary to dial a G3Fax recipient, such as sender's calling card authorization number, might be disclosed to the G3Fax recipient (on the cover page), such as through parameters encoded in the G3Fax recipients address in the To: or CC: fields.
有关发送人拨打G3Fax收件人所需的保密信息，如发送人的电话卡授权号码，可能会通过G3Fax收件人地址中编码的参数在收件人：或抄送：字段中披露给G3Fax收件人（在封面上）。
Senders SHOULD be provided with a method of preventing such disclosure. As with mechanisms for handling unsolicited faxes, there are not yet standard mechanisms for protecting such information. Out-of-band communication of authorization information or use of encrypted data in special fields are the available non-standard techniques.
应向发件人提供防止此类披露的方法。与处理未经请求的传真的机制一样，目前还没有保护此类信息的标准机制。授权信息的带外通信或在特殊领域使用加密数据是可用的非标准技术。
Typically authorization needs to be associated to specific senders and specific messages, in order to prevent a "replay" attack which causes and earlier authorization to enable a later dial-out by a different (and unauthorized) sender. A non-malicious example of such a replay would be to have an email recipient reply to all original recipients -- including an offramp IFax recipient -- and have the original sender's authorization cause the reply to be sent.
通常，授权需要与特定的发件人和特定的邮件相关联，以防止“重播”攻击，该攻击会导致早期授权，从而使不同（且未经授权）的发件人能够稍后拨出。此类重播的一个非恶意示例是，让电子邮件收件人回复所有原始收件人（包括offramp IFax收件人），并让原始发件人授权发送回复。
In many countries, there is a legal requirement that the "sender" be disclosed on a facsimile message. Email From addresses are trivial to fake, so that using only the MAIL FROM [1, 3] or From [2, 3] header is not sufficient.
在许多国家，法律要求在传真信息中披露“发件人”。来自地址的电子邮件很容易伪造，因此仅使用来自[1,3]或[2,3]的邮件头是不够的。
Offramps SHOULD ensure that the recipient is provided contact information about the offramp, in the event of problems.
出口匝道应确保在出现问题时向收件人提供出口匝道的联系信息。
The G3Fax recipient SHOULD be provided with sufficient information which permits tracing the originator of the IFax message. Such information might include the contents of the MAIL FROM, From, Sender and Reply-To headers, as well as Message-Id and Received headers.
应向G3传真收件人提供足够的信息，以便追踪IFax报文的发起人。此类信息可能包括来自、来自、发件人和回复邮件头的内容，以及邮件Id和收到的邮件头。
Users of G3Fax devices have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements.
G3Fax设备的用户期望消息隐私级别高于未经安全增强的Internet邮件提供的级别。
This expectation of privacy by G3Fax users SHOULD be preserved as much as possible.
G3传真用户对隐私的期望应尽可能得到保护。
Sufficient physical and software control may be acceptable in constrained environments. The usual mechanism for ensuring data confidentially entail encryption, as discussed below.
在受限环境中，可以接受充分的物理和软件控制。确保数据机密性的通常机制需要加密，如下所述。
With email, bounces (delivery failures) are typically returned to the sender and not to a publicly-accessible email account or printer. With facsimile, bounces do not typically occur. However, with IFax, a bounce could be sent elsewhere (see section [Delivery Failure]), such as a local system administrator's account, publicly-accessible account, or an IFax printer (see also [Traffic Analysis]).
对于电子邮件，退回（传递失败）通常会返回给发件人，而不是可公开访问的电子邮件帐户或打印机。使用传真，通常不会发生反弹。但是，使用IFax，可以将跳转发送到其他地方（请参阅[交付失败]一节），例如本地系统管理员帐户、可公开访问的帐户或IFax打印机（另请参阅[流量分析]）。
Eavesdropping of senders and recipients is easier on the Internet than GSTN. Note that message object encryption does not prevent traffic analysis, but channel security can help to frustrate attempts at traffic analysis.
在互联网上窃听发件人和收件人比在GSTN上更容易。请注意，消息对象加密不会阻止流量分析，但通道安全性有助于阻止流量分析尝试。
There are two, basic approaches to encryption-based security which support authentication and privacy:
有两种基本的基于加密的安全方法支持身份验证和隐私：
As with all email, an IFax message can be viewed as it traverses internal networks or the Internet itself.
与所有电子邮件一样，IFax邮件可以通过内部网络或互联网本身查看。
Virtual Private Networks (VPN) which make use of encrypted tunnels, such as via IPSec technology [18] or transport layer security, can be used to prevent eavesdropping of a message as it traverses such networks. It also provides some protection against traffic analysis, as described above.
虚拟专用网络（VPN）利用加密隧道，例如通过IPSec技术[18]或传输层安全，可用于防止消息在穿越此类网络时被窃听。如上所述，它还提供了一些针对流量分析的保护。
As with all email, an IFax message can be viewed while it resides on, or while it is relayed through, an intermediate Mail Transfer Agent.
与所有电子邮件一样，当IFax邮件驻留在中间邮件传输代理上或通过中间邮件传输代理进行中继时，可以查看该邮件。
Message encryption, such as PGP-MIME [13] and S/MIME, can be used to provide end-to-end encryption.
消息加密，如PGP-MIME[13]和S/MIME，可用于提供端到端加密。
6 REFERENCES
6参考文献
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August l982.
[2] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[3] Braden, R., 1123 "Requirements for Internet hosts - application and support", RFC 1123, October 1989.
[3] Braden，R.，1123“互联网主机的要求——应用和支持”，RFC 1123，1989年10月。
[4] Borenstein, N., and N. Freed, " Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 2049, November 1996.
[4] N.Borenstein和N.Freed，“多用途互联网邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[5] Parsons, G., and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.
[5] Parsons，G.和J.Rafferty，“标签图像文件格式（TIFF）——传真的F配置文件”，RFC 2306，1998年3月。
[6] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[6] McIntyre，L.，Zilles，S.，Buckley，R.，Venable，D.，Parsons，G.，和J.Rafferty，“互联网传真的文件格式”，RFC 2301，1998年3月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[8] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.
[8] ITU-T（CCITT），“用于文件传输的第3组传真设备的标准化”，ITU-T（CCITT），建议T.4。
[9] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[9] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[10] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.
[10] Crispin，M.，“互联网消息访问协议-版本4Rev1”，RFC 2060，1996年12月。
[11] Allocchio, C., "Minimal PSTN address format for Internet mail", RFC 2303, March 1998.
[11] Allocchio，C.，“因特网邮件的最小PSTN地址格式”，RFC 2303，1998年3月。
[12] Allocchio, C., "Minimal fax address format for Internet mail", RFC 2304, March 1998.
[12] Allocchio，C.，“因特网邮件的最小传真地址格式”，RFC 2304，1998年3月。
[13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[13] Elkins，M.，“具有良好隐私的MIME安全性（PGP）”，RFC 2015，1996年10月。
[14] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[14] Moore，K.和G.Vaudreuil，“传递状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[15] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[15] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[16] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[16] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[17] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Three: Representation of Non-ASCII Text in Internet ge Headers", RFC 2047, November 1996.
[17] Moore，K.，“多用途Internet邮件扩展（MIME）第三版：Internet ge标题中非ASCII文本的表示”，RFC 2047，1996年11月。
[18] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.
[18] 阿特金森，R.，“互联网协议的安全架构”，RFC 1825，海军研究实验室，1995年8月。
[19] Parsons, G. and Rafferty, J. "Tag Image File Format (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, March 1998.
[19] Parsons，G.和Rafferty，J.“标签图像文件格式（TIFF）——图像/TIFF:MIME子类型注册”，RFC 2302，1998年3月。
7 ACKNOWLEDGEMENTS
7致谢
This specification was produced by the Internet Engineering Task Force Fax Working Group, over the course of more than one year's online and face-to-face discussions. As with all IETF efforts, many people contributed to the final product.
本规范由互联网工程任务组传真工作组在一年多的在线和面对面讨论过程中制定。与所有IETF工作一样，许多人为最终产品做出了贡献。
Active for this document were: Steve Huston, Jeffrey Perry, Greg Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James Rafferty.
活跃于本文件的有：史蒂夫·休斯顿、杰弗里·佩里、格雷格·沃德鲁伊、理查德·肖基、查尔斯·吴、格雷厄姆·克莱恩、罗伯特·A·罗森博格、拉里·马斯特、戴夫·克罗克、赫尔曼·西尔比格、詹姆斯·拉弗蒂。
8 AUTHORS' ADDRESSES
8作者地址
Kiyoshi Toyoda Matsushita Graphic Communication Systems, Inc. 2-3-8 Shimomeguro, Meguro-ku Tokyo 153 Japan Fax: +81 3 5434 7166 Email: ktoyoda@rdmg.mgcs.mei.co.jp
丰田清吉松下图形通信系统有限公司2-3-8 Shimomeguro，Meguro ku Tokyo 153日本传真：+81 3 5434 7166电子邮件：ktoyoda@rdmg.mgcs.mei.co.jp
Hiroyuki Ohno Tokyo Institute of Technology 2-12-1 O-okayama, Meguro-ku Tokyo 152 Japan FAX: +81 3 5734 2754 Email: hohno@is.titech.ac.jp
大野广幸东京理工学院2-12-1日本东京市冈山区Meguro 152传真：+81 3 5734 2754电子邮件：hohno@is.titech.ac.jp
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan Fax: +81 466 49 1101 Email: jun@wide.ad.jp
村上庆应大学5322藤泽神奈川县Endo 252日本传真：+81 466 49 1101电子邮件：jun@wide.ad.jp
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Phone: +1 408 457 5200 Fax: +1 408 457 5208 Email: dwing@cisco.com
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣克鲁斯库珀街101号电话：+1 408 457 5200传真：+1 408 457 5208电子邮件：dwing@cisco.com
9 APPENDIX A: Exceptions to MIME
9附录A：MIME的例外情况
* IFax senders are NOT REQUIRED to be able to send text/plain messages (RFC 2049 requirement 4), although IFax recipients are required to accept such messages, and to process them.
* IFax发送者不需要能够发送文本/普通消息（RFC 2049要求4），尽管IFax接收者需要接受并处理此类消息。
* IFax recipients are NOT REQUIRED to offer to put results in a file. (Also see 2.3.2.)
* IFax收件人无需提供将结果放入文件中的服务。（另见2.3.2。）
* IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049.
* 如RFC 2049所示，IFax收件人可以直接打印/传真收到的信息，而不是“显示”它。
10 Full Copyright Statement
10完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。