Network Working Group L. Masinter
Request for Comments: 2532 Xerox Corporation
Category: Standards Track D. Wing
Cisco Systems
March 1999
Network Working Group L. Masinter
Request for Comments: 2532 Xerox Corporation
Category: Standards Track D. Wing
Cisco Systems
March 1999
Extended Facsimile Using Internet Mail
使用因特网邮件的扩展传真
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes extensions to "Simple Mode of Facsimile Using Internet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.
本文档描述了“使用互联网邮件的简单传真模式”[RFC2305]的扩展，并描述了其他功能，包括增强文档特征（更高分辨率、颜色）的传输以及交付和处理的确认。
These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.
这些附加功能旨在提供与现有和未来符合标准的电子邮件基础架构和邮件用户代理的最高级别的互操作性，同时提供与传真用户当前享受的服务级别接近的服务级别。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html>.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请参阅中的在线权利主张列表<http://www.ietf.org/ipr.html>.
This document notes a number of enhancements to the "Simple Mode of Facsimile Using Internet Mail" [RFC2305] that may be combined to create an extended mode of facsimile using Internet mail.
本文件注意到对“使用互联网邮件的简单传真模式”[RFC2305]的一些增强，这些增强可以结合起来创建使用互联网邮件的扩展传真模式。
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and take advantage of existing standards for advanced functionality such as positive delivery confirmation and disposition notification. The
新功能旨在与现有的邮件传输代理（MTA）和邮件用户代理（MUA）基础互操作，并利用现有的标准实现高级功能，如正向传递确认和处置通知。这个
enhancements described in this document utilize the messaging infrastructure, where possible, instead of creating fax-specific features which are unlikely to be implemented in non-fax messaging software.
本文档中描述的增强功能尽可能利用消息传递基础结构，而不是创建非传真消息传递软件中不可能实现的传真特定功能。
This document standardizes the following two features.
本文档标准化了以下两个功能。
* Delivery confirmation (Section 2) (required) * Additional document features (Section 3) (optional)
* 交付确认（第2节）（必需）*附加文件功能（第3节）（可选）
These features are fully described in another document titled "Terminology and Goals for Internet Fax" [RFC2542].
这些功能在另一份名为“互联网传真的术语和目标”[RFC2542]的文件中有详细描述。
The term "processing" indicates the action of rendering or transmitting the contents of the message to a printer, display device, or fax machine.
术语“处理”表示将消息内容呈现或发送到打印机、显示设备或传真机的操作。
The term "processing confirmation" is an indication by the recipient of a message that it is able to process the contents of that message.
术语“处理确认”是指消息接收者表示其能够处理该消息的内容。
The term "recipient" indicates the device which performs the processing function. For example, a recipient could be implemented as a traditional Mail User Agent on a PC, a standalone device which retrieves mail using POP3 or IMAP, an SMTP server which prints incoming messages (similar to an LPR server).
术语“接收者”表示执行处理功能的设备。例如，收件人可以实现为PC上的传统邮件用户代理，一个使用POP3或IMAP检索邮件的独立设备，一个打印传入邮件的SMTP服务器（类似于LPR服务器）。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The behavior of gateways from GSTN fax to SMTP ("onramps") and from SMTP to GSTN fax ("offramps") are not described in this document. However, such gateways SHOULD have the behavior characteristics of senders and recipients as described in this document.
本文档中未描述从GSTN传真到SMTP（“入站”）和从SMTP到GSTN传真（“出站”）的网关行为。但是，此类网关应具有本文档中描述的发送者和接收者的行为特征。
In traditional GSTN-based realtime facsimile, the receiving terminal acknowledges successful receipt and processing of every page [T.30].
在传统的基于GSTN的实时传真中，接收终端确认成功接收和处理了每一页[T.30]。
In Internet Mail, the operations of Delivery (to the mailbox) and Disposition (to paper or a screen) may be separated in time (due to store and forwarding of messages) and location (due to separation of delivery agent (MTA) and user agent (MUA)). The confirmation of
在Internet邮件中，传递（到邮箱）和处置（到纸张或屏幕）的操作可能在时间（由于邮件的存储和转发）和位置（由于传递代理（MTA）和用户代理（MUA）的分离）上分离。确认
these two operations are supplied by two different standards-track mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) [RFC2298], respectively.
这两种操作分别由两种不同的标准跟踪机制提供：传递状态通知（DSN）[RFC1891，RFC1894]和消息处置通知（MDN）[RFC2298]。
This section defines requirements for devices or services that are to be considered compliant with this document.
本节定义了被视为符合本文件要求的设备或服务的要求。
Because delivery failure may occur (over disk quota, user no longer exists, malconfigured mailer), a delivery failure message (in the format described by [RFC1894] or otherwise) may be sent to the envelope-from address specified by the sender. Thus, the envelope-from address supplied by the sender MUST be able to properly handle such delivery failure messages.
由于可能会发生传递失败（超过磁盘配额，用户不再存在，邮件配置错误），因此传递失败消息（采用[RFC1894]或其他方式描述的格式）可能会从发送方指定的地址发送到信封。因此，发件人提供的信封发件人地址必须能够正确处理此类传递失败消息。
If the sender desires delivery confirmation, the sender MUST request Delivery Status Notification by including the the esmtp-keyword NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]).
如果发送方希望发送确认，则发送方必须通过包含esmtp关键字NOTIFY和esmtp值SUCCESS（RFC1891）来请求发送状态通知。
If the sender desires processing confirmation, the sender MUST request Message Disposition Notification ([RFC2298] section 2) when sending the message itself.
如果发送方希望处理确认，则发送方必须在发送消息本身时请求消息处置通知（[RFC2298]第2节）。
Because a recipient may silently ignore a request for an MDN (section 2.1 of [RFC2298]) at any time:
因为接收者可以在任何时候默默地忽略MDN请求（RFC2298第2.1节）：
* MDNs MUST NOT be used for delivery confirmation, but are only useful for disposition ("processing") notification.
* MDN不得用于交付确认，但只能用于处置（“处理”）通知。
* the sender MUST NOT assume the recipient will respond to an MDN request in a subsequent message, even if the recipient has done so in the past.
* 发件人不得假设收件人将在后续邮件中响应MDN请求，即使收件人过去已这样做。
The address provided by the sender on the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages [RFC2298] and SHOULD be able to receive messages that are not in the Message Disposition Notification format (due to the existence of legacy systems that generate non-RFC2298-compliant responses to the Disposition-Notification-To field). The Disposition-Notification-To address and the envelope-from address SHOULD match to allow automated responses to MDN requests (section 2.1 of [RFC2298]).
发件人在“处置通知收件人”字段中提供的地址必须能够接收消息处置通知消息[RFC2298]，并且应该能够接收非消息处置通知格式的消息（由于遗留系统的存在，这些系统会生成不符合RFC2298的对处置通知至字段的响应）。处置通知至地址和信封自地址应匹配，以允许自动响应MDN请求（RFC2298第2.1节）。
Recipients SHOULD implement Message Disposition Notifications [RFC2298] and SHOULD indicate supported media features in DSN and MDN messages per [RFC2530].
收件人应实施邮件处置通知[RFC2298]，并应根据[RFC2530]在DSN和MDN邮件中指明支持的媒体功能。
If the recipient is an SMTP server, it behaves as part of the receiver infrastructure and is therefore subject to the "Receiver Infrastructure" requirements of this document.
如果收件人是SMTP服务器，则其行为是收件人基础结构的一部分，因此受本文档“收件人基础结构”要求的约束。
See also "Recipient Recommendations" in section 5.
另见第5节中的“收件人建议”。
Recipients MUST be configurable to silently ignore a request for an MDN (section 2.1 of [RFC2298]).
收件人必须可配置为静默忽略MDN请求（RFC2298第2.1节）。
If the recipient is an automated message processing system which is not associated with a person, the device MAY be configurable to always respond to MDN requests, but in all cases MUST be configurable to never generate MDNs.
如果收件人是与个人无关的自动消息处理系统，则设备可以配置为始终响应MDN请求，但在所有情况下都必须配置为从不生成MDN。
A recipient MUST NOT generate an unsolicited MDN to indicate successful processing. A recipient MAY generate an unsolicited MDN (sent to the envelope-from (Return-Path:) address) to indicate processing failure, but subject to the [RFC2298] requirement that it MUST always be possible for an operator to disable unsolicited MDN generation.
收件人不得生成未经请求的MDN以表示处理成功。收件人可能会生成一个未经请求的MDN（从（返回路径：）地址发送到信封），以指示处理失败，但需遵守[RFC2298]要求，即操作员必须始终能够禁用未经请求的MDN生成。
A recipient using POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve its mail MUST NOT generate a Delivery Status Notification message [RFC1894] because such a notification, if it was requested, would have already been issued by the MTA on delivery to the POP3 or IMAP4 message store.
使用POP3[RFC1939]或IMAP4[RFC2060]检索邮件的收件人不得生成传递状态通知邮件[RFC1894]，因为MTA在将此类通知发送到POP3或IMAP4邮件存储时已发出此类通知（如果请求）。
The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, "Bcc:" fields, or any other fields containing header recipient information to determine the ultimate destination mailbox or addressee, and SHOULD NOT use other RFC822 or MIME fields for making such determinations.
收件人不得使用RFC822“收件人：”字段、“抄送：”字段、“密件抄送：”字段或包含标题收件人信息的任何其他字段来确定最终目标邮箱或收件人，也不得使用其他RFC822或MIME字段来进行此类确定。
This section explains the requirements of the SMTP messaging infrastructure used by the sender and receiver. This infrastructure is commonly provided by the ISP or a company's internal mailers but can actually be provided by another organization with appropriate service contracts.
本节介绍发送方和接收方使用的SMTP消息传递基础结构的要求。这种基础设施通常由ISP或公司的内部邮件服务商提供，但实际上可以由另一个具有适当服务合同的组织提供。
Support for DSN [RFC1891] MUST be provided by the mail submission server [RFC2476] used by the sender and MUST be provided up to the mailer responsible for communicating with external (Internet) mailers.
对DSN[RFC1891]的支持必须由发件人使用的邮件提交服务器[RFC2476]提供，并且必须提供给负责与外部（互联网）邮件发送者通信的邮件发送者。
Also see section 5.1 of this document.
另见本文件第5.1节。
Support for DSN [RFC1891] MUST be provided by the external (Internet-accessible) mailer, and MUST be provided by each mailer between the external mailer and the recipient. If the recipient is implemented as an SMTP server it MUST also support DSN [RFC1891].
对DSN[RFC1891]的支持必须由外部（互联网可访问）邮件程序提供，并且必须由外部邮件程序和收件人之间的每个邮件程序提供。如果收件人实现为SMTP服务器，则它还必须支持DSN[RFC1891]。
Section 4 of "A Simple Mode of Facsimile Using Internet Mail" [RFC2305] allows sending only the minimum subset of TIFF for Facsimile "unless the sender has prior knowledge of other TIFF fields or values supported by the recipient."
“使用互联网邮件的简单传真模式”[RFC2305]第4节允许仅发送传真TIFF的最小子集，“除非发送方事先知道接收方支持的其他TIFF字段或值。”
A recipient MAY support any or all (or any combination) of the TIFF profiles defined in RFC 2301, in addition to profile S. A recipient which supports additional profiles SHOULD indicate this support as per section 3.2 or 3.3 of this document. As a consequence, a sender MAY use those additional TIFF profiles when sending to a recipient with the corresponding capabilities.
除档案S外，接收人可支持RFC 2301中定义的TIFF档案的任何或全部（或任何组合）。支持其他档案的接收人应根据本文件第3.2节或第3.3节的规定指出该支持。因此，发送方在发送给具有相应功能的接收方时可能会使用这些附加TIFF配置文件。
A sender SHOULD be able to recognize and process the feature tags as defined in [RFC2531] when reviewing the capabilities presented by a potential recipient. The capability matching rules indicated there (by reference to [RFC2533]) allow for the introduction of new features that may be unrecognized by older implementations.
当审查潜在接收者提供的功能时，发送者应能够识别并处理[RFC2531]中定义的功能标签。此处指出的功能匹配规则（参考[RFC2533]）允许引入旧实现可能无法识别的新功能。
A sender MAY send a message containing both the minimum subset of TIFF for Facsimile (as specified in [RFC2305]) and a higher quality TIFF using multipart/alternative.
发送方可发送包含传真TIFF最小子集（如[RFC2305]中规定）和使用多部分/备选方案的更高质量TIFF的消息。
Three methods for the sender to acquire such knowledge are described:
发送方获取此类知识的三种方法如下：
1. Sender manual configuration 2. Capabilities in Directory 3. Capabilities returned in MDN or DSN
1. 发送器手动配置2。目录3中的功能。在MDN或DSN中返回的功能
Method (3) SHOULD be used.
应使用方法（3）。
An implementation may cache capabilities locally and lose synchronization with the recipient's actual capabilities. A mechanism SHOULD be provided to allow the sender to override the locally-stored cache of capabilities. Also note section 4.1 of this document.
实现可能会在本地缓存功能，并与接收方的实际功能失去同步。应提供一种机制，允许发送方覆盖本地存储的功能缓存。另请注意本文件第4.1节。
One way a sender can send a document which exceeds the minimum subset allowed by [RFC2305] is for the user controlling the sender to manually override the default settings, usually on a per-recipient basis. For example, during transmission a user could indicate the recipient is capable of receiving high resolution images or color images.
发送方发送超过[RFC2305]允许的最小子集的文档的一种方式是，控制发送方的用户手动覆盖默认设置，通常是基于每个收件人。例如，在传输期间，用户可以指示接收者能够接收高分辨率图像或彩色图像。
While awkward and not automatic, this mechanism reflects the current state of deployment of configuration for extended capabilities to ordinary Internet email users.
这种机制虽然笨拙且不自动，但它反映了普通Internet电子邮件用户扩展功能配置的当前部署状态。
A future direction for enhanced document features is to create a directory structure of recipient capabilities, deployed, for example, through LDAP or DNS. The directory would provide a mechanism by which a sender could determine a recipient's capabilities before message construction or transmission, using a directory lookup. Such mechanisms are not defined in this document.
增强文档功能的未来方向是创建收件人功能的目录结构，例如通过LDAP或DNS进行部署。该目录将提供一种机制，通过该机制，发送方可以在构建或传输消息之前使用目录查找来确定接收方的能力。本文件未定义此类机制。
There is active investigation within the IETF to develop a solution to this problem, which would resolve a wide range of issues with store-and-forward messaging.
IETF内部正在积极调查，以开发解决该问题的解决方案，该解决方案将解决存储和转发消息的广泛问题。
As outlined in section 2 of this document, a sender may request a positive DSN or an MDN.
如本文件第2节所述，发送方可请求正面DSN或MDN。
If the recipient implements [RFC2530], the DSN or MDN that is returned can contain information describing the recipient's capabilities. The sender can use this information for subsequent communications with that recipient.
如果收件人实现[RFC2530]，则返回的DSN或MDN可以包含描述收件人能力的信息。发件人可以使用此信息与收件人进行后续通信。
The advantage of this approach is that additional infrastructure is not required (unlike section 3.2), and the information is acquired automatically (unlike section 3.1).
这种方法的优点是不需要额外的基础设施（与第3.2节不同），信息是自动获取的（与第3.1节不同）。
A sender MUST NOT send a message with no processable content to attempt to elicit an MDN/DSN capability response. Doing so with a message with no processable content (such as a message containing only a request for capabilities or a blank message) will confuse a recipient not already designed to understand the semantics of such a message.
发送方不得发送没有可处理内容的消息，以尝试引发MDN/DSN功能响应。如果对没有可处理内容的消息（例如仅包含功能请求的消息或空白消息）执行此操作，将使尚未设计为理解此类消息语义的收件人感到困惑。
A recipient SHOULD indicate the profiles and features supported, even if the recipient supports only Tiff Profile S (the minimum set for fax as defined by [RFC2305]) [RFC2531]. This allows a sender to determine that the recipient is compliant with this Extended Facsimile Using Internet Mail specification.
收件人应指明支持的配置文件和功能，即使收件人仅支持Tiff配置文件（传真的最小设置由[RFC2305]定义）[RFC2531]。这允许发件人使用Internet邮件规范确定收件人是否符合此扩展传真。
As this document is an extension of [RFC2305], the Security Considerations section of [RFC2305] applies to this document.
由于本文件是[RFC2305]的扩展，[RFC2305]的安全注意事项部分适用于本文件。
The following additional security considerations are introduced by the new features described in this document.
本文档中描述的新功能引入了以下附加安全注意事项。
Inaccurate capability information (section 3) could cause a denial of service. The capability information could be inaccurate due to many reasons, including compromised or improperly configured directory server, improper manual configuration of sender, compromised DNS, or spoofed MDN. If a sender is using cached capability information, there SHOULD be a mechanism to allow the cached information to be ignored or overridden if necessary.
不准确的能力信息（第3节）可能导致拒绝服务。由于多种原因，功能信息可能不准确，包括目录服务器受损或配置不当、发送方手动配置不当、DNS受损或伪造MDN。如果发送方正在使用缓存的功能信息，则应该有一种机制，允许在必要时忽略或覆盖缓存的信息。
Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can provide incorrect information to a sender.
[RFC1892、RFC1894、RFC2298]中所述的伪造DSN或MDN可能会向发送方提供不正确的信息。
This section contains notes to implementors.
本节包含对实现者的注释。
In some installations the generally available submit server may not support DSNs. In such circumstances, it may be useful for the sender to implement [RFC974] mail routing as well as additional submission server functions [RFC2476] so that the installation is not constrained by limitations of the incumbent submission server.
在某些安装中，通常可用的提交服务器可能不支持DSN。在这种情况下，发送方实施[RFC974]邮件路由以及附加的提交服务器功能[RFC2476]可能是有用的，以便安装不受现有提交服务器的限制。
To provide a high degree of reliability, it is desirable for the sender to know that a recipient could not process a message. The inability to successfully process a message may be detectable by the recipient's MTA or MUA.
为了提供高度的可靠性，发送方希望知道接收方无法处理消息。收件人的MTA或MUA可能会检测到无法成功处理邮件。
If the recipient's MTA determines the message cannot be processed, the recipient's MTA is strongly encouraged to reject the message with a [RFC1893] status code of 5.6.1. This status code may be returned in response to the end-of-mail-data indicator if the MTA supports reporting of enhanced error codes [RFC2034], or after message reception by generating a delivery failure DSN ("bounce").
如果收件人的MTA确定无法处理邮件，强烈建议收件人的MTA拒绝状态代码为5.6.1的邮件[RFC1893]。如果MTA支持报告增强的错误代码[RFC2034]，或者在收到邮件后生成传递失败DSN（“跳出”），则可以返回此状态代码以响应邮件结束数据指示器。
Note: Providing this functionality in the MTA, via either of the two mechanisms described above, is superior to providing the function using MDNs because MDNs must generally be requested by the sender (and the request may, at any time, be ignored by the receiver). Message rejection performed by the MTA can always occur without the sender requesting such behavior and without the receiver circumventing the behavior.
注意：通过上述两种机制之一在MTA中提供此功能优于使用MDN提供此功能，因为MDN通常必须由发送方请求（并且接收方可能随时忽略该请求）。MTA执行的邮件拒绝始终可以在发送方未请求此类行为且接收方未规避该行为的情况下发生。
If the message contains an MDN request and the recipient's MUA determines the message cannot be processed, the recipient's MUA is strongly encouraged to repond to an MDN request and indicate that processing failed with the disposition-type "processed" or "displayed" and disposition-modifier "error" or "warning" [RFC2298].
如果邮件包含MDN请求，且收件人的MUA确定无法处理该邮件，则强烈建议收件人的MUA回复MDN请求，并指示处理失败，处置类型为“已处理”或“已显示”，处置修饰符为“错误”或“警告”[RFC2298]。
The authors would like to acknowledge the members of the IETF Internet Fax working group, and especially the following contributors who provided assistance and input during the development of this document:
作者要感谢IETF互联网传真工作组的成员，特别是在本文件编制过程中提供帮助和投入的以下贡献者：
Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and Greg Vaudreuil.
Vivian Cancio、Richard Coles、David Crocker、Ned Freed、Graham Klyne、MAEDA Toru、Geoff Marshall、Lloyd McIntyre、Keith Moore、George Pajari、James Rafferty、Mike Ruhl、Richard Shockey、Brian Stafford和Greg Vaudreuil。
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[RFC2533]Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for Internet Fax", RFC 2531, March 1999.
[RFC2531]McIntyre，L.和G.Klyne，“互联网传真的内容特征模式”，RFC 25311999年3月。
[RFC2530] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[RFC2530]Wing，D.，“使用DSN和MDN的扩展指示支持的媒体功能”，RFC2530，1999年3月。
[RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996.
[RFC1891]Moore，K.“用于传递状态通知的SMTP服务扩展”，RFC18911996年1月。
[RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[RFC1893]Vaudreuil，G.，“增强邮件系统状态代码”，RFC1893，1996年1月。
[RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[RFC1894]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034]Freed，N，“用于返回增强错误代码的SMTP服务扩展”，RFC 20341996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[RFC2298]Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC2298，1998年3月。
[RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[RFC2301]McIntyre，L.，Zilles，S.，Buckley，R.，Venable，D.，Parsons，G.和J.Rafferty，“互联网传真的文件格式”，RFC 2301，1998年3月。
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.
[RFC2305]丰田章男，K.，大野，H.，Murai，J.和D.Wing，“使用互联网邮件的简单传真模式”，RFC 2305，1998年3月。
[RFC974] Partridge. C., "Mail routing and the domain system", STD 14, RFC 974, January 1986.
[RFC974]鹧鸪。C.，“邮件路由和域系统”，STD 14，RFC 974，1986年1月。
[RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476]Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[RFC2542]Masinter，L.，“互联网传真的术语和目标”，RFC2542，1999年3月。
[T.30] "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996.
[T.30]“通用交换电话网中文件传真传输的程序”，ITU-T（CCITT），建议T.30，1996年7月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.
[RFC2060]Crispin，M.，“互联网消息访问协议-版本4Rev1”，RFC20601996年12月。
Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA
美国加利福尼亚州帕洛阿尔托郊狼山路3333号帕洛阿尔托研究中心
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣克鲁斯库珀街101号，邮编95060
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: dwing@cisco.com
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: dwing@cisco.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。