Network Working Group K. Toyoda
Request for Comments: 3965 H. Ohno
Obsoletes: 2305 J. Murai
Category: Standards Track WIDE Project
D. Wing
Cisco
December 2004
Network Working Group K. Toyoda
Request for Comments: 3965 H. Ohno
Obsoletes: 2305 J. Murai
Category: Standards Track WIDE Project
D. Wing
Cisco
December 2004
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. 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、Internet邮件协议、多用途Internet邮件扩展（MIME）和用于传真的标记图像文件格式（TIFF）。它不仅可以将图像发送到其他具有互联网意识的传真设备，还可以发送到互联网本机系统，例如带有普通电子邮件阅读器的PC，这些阅读器可以处理MIME邮件和传真数据的TIFF。该规范促进了现有传真设备、Internet邮件代理以及连接它们的网关之间的通信。
This document is a revision of RFC 2305. There have been no technical changes.
本文件是RFC 2305的修订版。没有任何技术变化。
This specification defines 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.
将此功能开发为电子邮件配置文件的原因是允许传真和电子邮件用户之间进行交互。例如，现有电子邮件用户能够向用户列表发送普通邮件，包括基于传真的收件人，其他电子邮件收件人应能够回复原件并继续包括传真收件人。类似地，现有的电子邮件软件可以不经修改地工作，并且不需要处理新的或不同的数据结构，这超出了Internet邮件用户的正常工作范围。使用现有电子邮件服务标准，而不是复制更适合现有传真标准的机制，以确保与现有电子邮件服务的兼容性。
A facsimile-capable device that uses T.4 [15] 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[15]和通用交换电话网（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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [13].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[13]中所述进行解释。
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). 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.
网关在不同的环境之间转换。对于IFax，互联网邮件和T.4/GSTN传真之间有一个网关连接。网关可以为多个T.4/GSTN传真用户提供服务，也可以仅为一个用户提供服务。在前一种情况下，它们充当经典的“邮件传输代理”（MTA），在后一种情况下充当经典的“邮件用户代理”（UA）。入口是从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 [6] or similar mailbox access protocols.
作为MTA为多个用户提供服务的出口网关应使用SMTP；作为UA为单个邮件收件人提供服务的网关可以使用邮箱访问协议，如POP[6]或类似的邮箱访问协议。
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 2822 and RFC 1123, 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 2822和RFC 1123，它们定义了邮件头的格式。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 [5], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [12]. Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
传真图像的数据格式基于传真的最小TIFF集[5]，也称为S配置文件。通过使用image/TIFF子类型将此类传真数据包括在MIME对象中[12]。对于基于消息的互联网传真应用程序，将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 [9].
在发生继电器故障的情况下，发送继电器必须生成故障消息，该消息应采用DSN[9]的格式。
NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices. (See section 5.2.6.)
注意：通过SMTP传输的Internet邮件必须包含适用于发送退货通知的邮件发件人地址。（见第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. (See Appendix A, second bullet.)
功能有限的IFax设备可能无法处理消息内容。如果发生这种情况，务必确保消息不会在没有任何通知的情况下丢失。通知可以以任何适当的方式提供，具体的处理是当地的事情。（见附录A，第二个项目符号。）
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 [7, 8]. Other formats MUST be syntactically distinct from [7, 8].
电话号码格式应符合[7,8]。其他格式必须在语法上与[7,8]不同。
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) [5], which is also compatible with the specification for the minimum subset of TIFF-F in [14]. Receiving IFax devices MUST be able to read minimum set TIFF files.
发送IFax设备必须能够按照TIFF传真（S配置文件）[5]中定义的创建最小TIFF文件集的规则写入最小TIFF文件集，该规则还与[14]中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字段和值。确定收件人能力的机制超出了本文档的范围。
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 for establishing authorization of the sender are essential to those offramp facsimile services that need to manage such consumption.
除了通常用于电子邮件的资源（CPU周期和磁盘）外，离线传真还会导致外拨，这通常会造成大量资源消耗，如财务成本。建立发送方授权的技术对于那些需要管理此类消费的场外传真服务至关重要。
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), encrypted tunnels, 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）、加密隧道或传输层安全可用于防止消息在穿越此类网络时被窃听。如上所述，它还提供了一些针对流量分析的保护。
At the current time various protocols exist for performing the above functions, and are only mentioned here for information. Such protocols are IPSec [17] and TLS [18].
目前存在用于执行上述功能的各种协议，此处仅作参考。这些协议是IPSec[17]和TLS[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 can be used to provide end-to-end encryption.
消息加密可用于提供端到端加密。
At the current time two protocols are commonly used for message encryption and are only mentioned here for information. The two protocols are PGP-MIME [16] and S/MIME [19].
目前，两种协议通常用于消息加密，此处仅作参考。这两个协议是PGP-MIME[16]和S/MIME[19]。
[1] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[1] Klensin，J.，编辑，“简单邮件传输协议”，RFC 28212001年4月。
[2] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[2] Resnick，P.，编辑，“互联网信息格式”，RFC 2822，2001年4月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，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] Borenstein，N.和N.Freed，“多用途互联网邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, November 2004.
[5] Buckley，R.，Venable，D.，McIntyre，L.，Parsons，G.，和J.Rafferty，“互联网传真的文件格式”，RFC 39492004年11月。
[6] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[6] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[7] Allocchio, C., "Minimal GSTN address format for Internet mail", RFC 3191, October 2001.
[7] Allocchio，C.，“互联网邮件的最小GSTN地址格式”，RFC3191，2001年10月。
[8] Allocchio, C., "Minimal fax address format for Internet mail", RFC 3192, October 2001.
[8] Allocchio，C.，“因特网邮件的最小传真地址格式”，RFC3192，2001年10月。
[9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[11] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[11] Moore，K.“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[12] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.
[12] Parsons，G.和J.Rafferty，“标签图像文件格式（TIFF）-图像/TIFF MIME子类型注册”，RFC3302，2002年9月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[14] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.
[14] Parsons，G.和J.Rafferty，“标签图像文件格式（TIFF）——传真的F配置文件”，RFC 2306，1998年3月。
[15] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.
[15] ITU-T（CCITT），“用于文件传输的第3组传真设备的标准化”，ITU-T（CCITT），建议T.4。
[16] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[16] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[17] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[17] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[18] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[18] Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[19] Ramsdell，B.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
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·罗森博格、拉里·马斯特、戴夫·克罗克、赫尔曼·西尔比格、詹姆斯·拉弗蒂。
Appendix A: Exceptions to MIME
附录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收件人可以直接打印/传真收到的信息，而不是“显示”它。
Appendix B: List of edits to RFC 2305
附录B：RFC 2305的编辑列表
+----+----------+-------------------------------------------------+
| No.| Section | Edit July 27, 2001 |
+----+----------+-------------------------------------------------+
| 1. |Copyright | Updated copyright from "1998" to "1999,2000" |
| |Notice | |
+----+----------+-------------------------------------------------+
| 2. |SUMMARY | Changed the phrase "over the Internet" to |
| | | "using Internet mail" |
+----+----------+-------------------------------------------------+
| 3. |5 | Changed the paragraphs regarding to the |
| | | following references to make them very |
| | | non-normative. |
| | | "OpenPGP Message Format", RFC 2440 |
| | | "Security Architecture for the IP", RFC 2401 |
| | | "SMTP Service Extensions for Secure SMTP over |
| | | TLS", RFC 2487 |
| | | "S/MIME Version 2 Message Specification", |
| | | RFC 2311 |
+----+----------+-------------------------------------------------+
| 4. |REFERENCES| Removed the following references because they |
| | | are non-normative |
| | | "SMTP Service Extensions for Delivery Status |
| | | Notifications", RFC 1891 |
| | | "Internet Message Access Protocol", RFC 2060 |
+----+----------+-------------------------------------------------+
| 5. |REFERENCES| Separated REFERENCES to the normative and |
| | | non-normative |
+----+----------+-------------------------------------------------+
| 6. |Appendix | Changed the phrase from "NOT REQUIRED" to |
| | A | "not required" |
+----+----------+-------------------------------------------------+
| 7. |Appendix | Added "Appendix B List of edits to RFC 2305" |
+----+----------+-------------------------------------------------+
+----+----------+-------------------------------------------------+
| No.| Section | Edit July 27, 2001 |
+----+----------+-------------------------------------------------+
| 1. |Copyright | Updated copyright from "1998" to "1999,2000" |
| |Notice | |
+----+----------+-------------------------------------------------+
| 2. |SUMMARY | Changed the phrase "over the Internet" to |
| | | "using Internet mail" |
+----+----------+-------------------------------------------------+
| 3. |5 | Changed the paragraphs regarding to the |
| | | following references to make them very |
| | | non-normative. |
| | | "OpenPGP Message Format", RFC 2440 |
| | | "Security Architecture for the IP", RFC 2401 |
| | | "SMTP Service Extensions for Secure SMTP over |
| | | TLS", RFC 2487 |
| | | "S/MIME Version 2 Message Specification", |
| | | RFC 2311 |
+----+----------+-------------------------------------------------+
| 4. |REFERENCES| Removed the following references because they |
| | | are non-normative |
| | | "SMTP Service Extensions for Delivery Status |
| | | Notifications", RFC 1891 |
| | | "Internet Message Access Protocol", RFC 2060 |
+----+----------+-------------------------------------------------+
| 5. |REFERENCES| Separated REFERENCES to the normative and |
| | | non-normative |
+----+----------+-------------------------------------------------+
| 6. |Appendix | Changed the phrase from "NOT REQUIRED" to |
| | A | "not required" |
+----+----------+-------------------------------------------------+
| 7. |Appendix | Added "Appendix B List of edits to RFC 2305" |
+----+----------+-------------------------------------------------+
Authors' Addresses
作者地址
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku Fukuoka 812-8531 Japan
丰田清吉松下通信有限公司4-1-62 Minoshima Hakata ku Fukuoka 812-8531日本
Fax: +81 92 477 1389
EMail: toyoda.kiyoshi@jp.panasonic.com
Fax: +81 92 477 1389
EMail: toyoda.kiyoshi@jp.panasonic.com
Hiroyuki Ohno National Institute of Information and Communications Technology 4-2-1, Nukui-Kitamachi, Koganei, Tokyo, 184-8795, Japan
大野广幸国立信息和通信技术研究所4-2-1，日本东京高加内北天町新贵，184-8795
Fax: +81 42 327 7941
EMail: hohno@ohnolab.org
Fax: +81 42 327 7941
EMail: hohno@ohnolab.org
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan
村村俊庆应大学5322日本藤泽神奈川县远藤252
Fax: +81 466 49 1101
EMail: jun@wide.ad.jp
Fax: +81 466 49 1101
EMail: jun@wide.ad.jp
Dan Wing 170 W. Tasman Drive San Jose, CA 95134 USA
Dan Wing 170美国加利福尼亚州圣何塞塔斯曼大道西95134号
Phone: +1 408 525 5314
EMail: dwing@cisco.com
Phone: +1 408 525 5314
EMail: dwing@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。