Network Working Group K. Mimura
Request for Comments: 4161 K. Yokoyama
Category: Informational T. Satoh
K. Watanabe
C. Kanaide
TOYO Communication Equipment
August 2005
Network Working Group K. Mimura
Request for Comments: 4161 K. Yokoyama
Category: Informational T. Satoh
K. Watanabe
C. Kanaide
TOYO Communication Equipment
August 2005
Guidelines for Optional Services for Internet Fax Gateways
Internet传真网关可选服务指南
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.
为了实现通用交换电话网络传真服务（GSTN传真）和基于电子邮件的互联网传真服务（i-fax）之间的连接，需要一个“互联网传真网关”。本文档为Internet传真网关的可选功能提供了指南。在这种情况下，“出口网关”提供从i-fax到GSTN fax的传真数据传输；反之亦然，“入口网关”提供从GSTN传真到i-fax的数据传输。本文件中的建议适用于综合服务，包括互联网传真终端、互联网上带有i-Fax软件的计算机以及GSTN上的GSTN传真终端。
This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.
本文档补充了有关Internet传真网关最低功能的建议。特别是，它涵盖了丢弃重复传真消息、自动传真重新传输、错误、返回通知和日志处理的技术，以及通过DTMF（双音多频）为入口网关提供的可能授权方法。
An Internet Fax Gateway can be classified as either an offramp gateway or an onramp gateway. This document provides guidelines for optional services and examples of Internet Fax Gateway operations. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways.
Internet传真网关可分为出口网关或入口网关。本文档提供可选服务指南和Internet传真网关操作示例。特别是，它涵盖了丢弃重复传真消息、自动传真重新传输、错误、返回通知和日志处理的技术，以及通过DTMF（双音多频）为入口网关提供的可能授权方法。
A more detailed definition of onramps and offramps is provided in [1]. Recommended behaviors for Internet Fax Gateway functions are defined in [15].
[1]中提供了入口匝道和出口匝道的更详细定义。[15]中定义了Internet传真网关功能的推荐行为。
This document provides recommendations only for the specific cases hereunder:
本文件仅针对以下具体情况提供建议：
1) the operational mode of the Internet Fax is "store and forward", as defined in Section 2.5 of [1].
1) 互联网传真的操作模式为[1]第2.5节中定义的“存储转发”。
2) The format of image data is the data format defined by "simple mode" in [16].
2) 图像数据的格式为[16]中“简单模式”定义的数据格式。
This document does not apply to the gateway functions for "real-time Internet Fax", as described and defined in [18].
本文件不适用于[18]中描述和定义的“实时互联网传真”网关功能。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [17].
本文件中的关键词“必须”、“应该”、“不应该”和“可能”应按照[17]中所述进行解释。
Electronic mail transport agents (MTA) deliver an Internet Fax message into either the recipient's mailbox or an offramp gateway mailbox. Hence, the message is retrieved for further action, which in the case of the offramp gateway, will result in its delivery to the GSTN fax service.
电子邮件传输代理（MTA）将Internet传真消息传送到收件人邮箱或出口网关邮箱。因此，将检索该消息以进行进一步操作，在出口网关的情况下，这将导致将其传送到GSTN传真服务。
The offramp gateway mailbox will thus receive all messages which the gateway will process, regardless of their final, distinct GSTN destinations. As such, addresses like
因此，出口网关邮箱将接收网关将处理的所有消息，而不管它们的最终、不同的GSTN目的地是什么。因此，地址如下
Fax=+12224567654@example.com
Fax=+38155234578@example.com
Fax=+3904567437777@example.com
Fax=+12224567654@example.com
Fax=+38155234578@example.com
Fax=+3904567437777@example.com
will all end up in the offramp gateway mailbox corresponding to the "example.com" domain.
将全部结束在对应于“example.com”域的出口网关邮箱中。
However, the handling of e-mail messages (including those of Internet Faxes) that contain more than one recipient, but are directed to the same final MTA, can be different, depending on the MTA configuration or features. A single message with multiple recipients in the SMTP envelope [19] is likely to be the most common case on the mail transport system, but it may happen that multiple copies of the same message are transmitted, one per recipient. Or it may happen that the final MTA is set to deliver a separate copy of the message per recipient into the final mailbox, supposing it is delivering messages to real mailboxes of distinct endusers.
但是，对于包含多个收件人但指向同一最终MTA的电子邮件（包括Internet传真），其处理方式可能会有所不同，具体取决于MTA配置或功能。SMTP信封[19]中包含多个收件人的单个邮件可能是邮件传输系统中最常见的情况，但可能会传输同一邮件的多个副本，每个收件人一份。或者，如果最终MTA将邮件传递到不同最终用户的真实邮箱，则可能会将最终MTA设置为每个收件人将邮件的单独副本传递到最终邮箱中。
Thus, it may happen that the offramp gateway receives multiple copies of the same Internet Fax message that is to be delivered to different GSTN destinations, which are listed together and repeatedly in the e-mail message headers [20] of the Internet Fax. In such cases, the offramp gateway SHOULD implement techniques to avoid duplicate or multiple transmission over GSTN of the same fax message to the same recipient.
因此，出口网关可能会接收到同一互联网传真消息的多个副本，这些副本将被发送到不同的GSTN目的地，并在互联网传真的电子邮件消息头[20]中反复列出。在这种情况下，出口网关应实施技术，以避免通过GSTN向同一接收者重复或多次传输同一传真消息。
Here are some possible, but non-exclusive, examples of these techniques.
以下是这些技术的一些可能但非排他性的示例。
Using the SMTP [19] envelope destination address given in the "RCPT TO" field is usually the best technique to ensure that a received message is delivered to that address, and to avoid duplicate deliveries.
使用“RCPT TO”字段中给出的SMTP[19]信封目标地址通常是确保将收到的邮件传递到该地址并避免重复传递的最佳技术。
If the offramp gateway has the "RCPT TO" information still available during processing, then it MUST use it to determine the recipients over GSTN fax service.
如果出口网关在处理过程中仍有“RCPT TO”信息可用，则必须使用该信息通过GSTN传真服务确定收件人。
If the SMTP "RCPT TO" information is not available (for example, in the case where the offramp gateway retrieves messages from its mailbox using either POP [21] or IMAP [22]), the message header "Message-ID" (see [20]) MAY be used to check if a message has already been processed, and hence avoid retransmission to all its GSTN recipients handled by the offramp gateway.
如果SMTP“RCPT TO”信息不可用（例如，在出口网关使用POP[21]或IMAP[22]从其邮箱检索邮件的情况下），可使用邮件标题“邮件ID”（参见[20]）检查邮件是否已被处理，从而避免重新传输到由出口网关处理的所有GSTN接收方。
Recoverable errors that happen during GSTN transmission are those where there is good chance that the error may not occur at the next attempt. This category includes "busy signal", "no line/carrier signal", etc.
GSTN传输过程中发生的可恢复错误是指下一次尝试时可能不会发生错误的错误。该类别包括“忙信号”、“无线路/载波信号”等。
For all these errors, the offramp gateway SHOULD re-queue the message and perform a retransmission attempt later on, as specified in Section 2.3.
对于所有这些错误，出口网关应按照第2.3节的规定，对消息重新排队，并在稍后执行重传尝试。
If the error that occurs during GSTN transmission is likely non-recoverable, the offramp gateway SHOULD NOT attempt retransmission, and an error Message Delivery Notification (MDN) with appropriate error codes MUST be generated for the Internet Fax message sender. Examples of non-recoverable errors include paper-related errors (such as a jam, an empty tray, etc.) at a remote device, no response from a remote destination, voice response errors, data modem response errors, and stop event errors.
如果GSTN传输过程中发生的错误可能无法恢复，则出口网关不应尝试重新传输，并且必须为Internet传真消息发送者生成带有适当错误代码的错误消息传递通知（MDN）。不可恢复错误的示例包括远程设备上与纸张相关的错误（如卡纸、空纸盘等）、远程目标没有响应、语音响应错误、数据调制解调器响应错误和停止事件错误。
An offramp gateway SHOULD implement a function that automatically tries to send facsimile data again if recoverable delivery failure occurs. If this function is implemented, then:
出口网关应实现一项功能，在发生可恢复传送故障时自动尝试再次发送传真数据。如果实现了此功能，则：
- the retry times and retry interval MAY be specified as options by the administrator of the offramp gateway;
- 出口网关管理员可将重试次数和重试间隔指定为选项；
- any error return notice SHOULD be sent only when the maximum number of retries has been completed without success;
- 只有在完成最大重试次数但未成功时，才应发送任何错误返回通知；
- if transmission is suspended due to an error, then the subsequent transmission attempt SHOULD avoid retransmitting the pages already delivered successfully, if any.
- 如果传输因错误而暂停，则后续传输尝试应避免重新传输已成功交付的页面（如果有）。
An offramp gateway can receive an Internet Fax for delivery to multiple GSTN recipients. If errors occur, which require the Internet Fax sender to be informed about them, or if the Internet Fax sender requested delivery notifications, then the offramp gateway has various ways to handle these multiple return notices:
出站网关可以接收互联网传真，以便发送给多个GSTN收件人。如果出现错误，需要通知Internet传真发送者，或者如果Internet传真发送者请求传递通知，则出站网关有多种方法来处理这些多个返回通知：
1) An offramp gateway sends a return notice as soon as an error or a successful delivery occurs, per single GSTN recipient.
1) 一旦发生错误或成功交付，出站网关将向每个GSTN收件人发送返回通知。
2) An offramp gateway gathers all information about the message, but sends a return notice only after all or a number of GSTN recipients have been handled (successfully or not).
2) 出站网关收集有关邮件的所有信息，但仅在处理完所有或多个GSTN收件人（成功或失败）后才发送返回通知。
If Case 2 is implemented, then the offramp gateway MAY also choose to send separate success and failure notices, or to limit the number of GSTN recipients handled per single return note (for example, no more than 10 recipients per return note).
如果实施了案例2，那么出口网关还可以选择发送单独的成功和失败通知，或者限制每个退货通知单处理的GSTN收件人数量（例如，每个退货通知单不超过10个收件人）。
When an offramp gateway fails in the transmission of a return notice, the Internet Fax Gateway SHOULD process the notice in either of the following ways:
当出口网关在发送回执通知时发生故障时，互联网传真网关应通过以下任一方式处理该通知：
1) The return notices SHOULD be re-queued, and delivery retried later. The number of retry attempts and the time interval between them MAY be a feature configured by the offramp gateway administrator. This is the preferred method to implement; however, if all the retransmission attempts fail, processing SHOULD continue as in Case 2.
1) 退回通知应重新排队，稍后重试传递。重试次数和重试之间的时间间隔可能是出口网关管理员配置的功能。这是实施的首选方法；但是，如果所有重传尝试都失败，则处理应继续，如案例2所示。
2) If the gateway does not have enough capabilities to handle notice re-queuing, but has a log information preservation function, the error information SHOULD be recorded to a log, and processing SHOULD end. At this time, the administrator of the gateway system SHOULD be notified of these errors using a specific method (for example, by an e-mail message).
2) 如果网关没有足够的能力来处理通知重新排队，但具有日志信息保存功能，则应将错误信息记录到日志中，并结束处理。此时，应使用特定方法（例如，通过电子邮件）将这些错误通知网关系统的管理员。
3) If the gateway does not even have a log information preservation function, the administrator SHOULD be notified about the failure (for example, via an e-mail message), and processing SHOULD end.
3) 如果网关甚至没有日志信息保存功能，则应将故障通知管理员（例如，通过电子邮件），并结束处理。
An offramp gateway SHOULD have a function that keeps information listed as a log, either specific to the fax gateway or in a log file that exists locally on the gateway or remotely. If the fax gateway or the remote system are equipped with recording media, the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed.
出站网关应具有将信息作为日志列出的功能，该日志特定于传真网关或存在于网关本地或远程的日志文件中。如果传真网关或远程系统配备了记录介质，则应将日志信息保存为日志文件。作为最后手段，如果没有可用的记录介质，可以打印日志。
The information listed in the log MAY be the following:
日志中列出的信息可能如下所示：
- Date and time when the Internet Fax is received - Sender address - Recipient address(es) - Start date and time of transmission over GSTN - End date and time of transmission over GSTN - Number of actually transmitted pages - Number of actually transmitted bytes - Fax resolution used - Error codes/text that occurred during transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice
- 收到Internet传真的日期和时间-发件人地址-收件人地址-通过GSTN传输的开始日期和时间-通过GSTN传输的结束日期和时间-实际传输的页数-实际传输的字节数-使用的传真解析-传输期间发生的错误代码/文本-传输尝试（重试）次数-传输的日期和时间（最终）交货通知
An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit a facsimile into the Internet fax service. For example, user authorization may be accomplished by getting a user ID and password received by DTMF, or via a local authorization table based on the GSTN caller-ID. The following subsections give some possible examples, but other methods are also possible.
入口网关可以具有用户授权功能，以确认用户被授权将传真发送到因特网传真服务。例如，用户授权可以通过获取DTMF接收到的用户ID和密码，或者通过基于GSTN呼叫者ID的本地授权表来完成。以下小节给出了一些可能的示例，但也可以使用其他方法。
The most simple method to authenticate and authorize a GSTN fax service user is to use the GSTN caller-ID. If available, in fact, the caller-ID is generated by the GSTN network service itself, and it is quite difficult to produce fake caller-IDs. In other words, the security related to this authentication method relies on the confidence that the GSTN caller-ID service is secure by itself.
对GSTN传真服务用户进行身份验证和授权的最简单方法是使用GSTN呼叫者ID。如果可用，事实上，呼叫者ID是由GSTN网络服务本身生成的，很难生成假呼叫者ID。换句话说，与此身份验证方法相关的安全性依赖于GSTN呼叫者ID服务本身安全的信心。
The GSTN sender MAY be authorized via a lookup into a table managed by the onramp gateway administrator, via complete or partial (wildcard) matches.
GSTN发送方可以通过完全或部分（通配符）匹配，通过查找入站网关管理员管理的表来获得授权。
During the initial GSTN fax service negotiation, the sender fax can send various information to the onramp gateway, including the "station ID" alphanumeric string. This string MAY be used to transmit authentication and authorization information for subsequent lookup by the onramp gateway. Thus, user ID and an eventual password MAY be sent inside this string.
在初始GSTN传真服务协商期间，发送方传真可以向入口匝道网关发送各种信息，包括“站点ID”字母数字字符串。该字符串可用于传输认证和授权信息，以供入站网关进行后续查找。因此，用户ID和最终密码可以在该字符串中发送。
However, if used as the only authentication, this method is much less secure than the caller-ID one because the user of the calling GSTN station can decide which string to send, and the string travels in clear form over the GSTN. Given this security warning, this method allows more flexibility to the GSTN user: in fact, it is not tied to a single GSTN fax terminal, and authorization can be obtained from anywhere, provided the sender has the possibility to configure the "station ID" on the device being used.
但是，如果用作唯一的身份验证，此方法的安全性远低于呼叫者ID方法，因为呼叫GSTN站的用户可以决定发送哪个字符串，并且字符串以清晰的形式在GSTN上移动。鉴于此安全警告，此方法为GSTN用户提供了更大的灵活性：事实上，它不绑定到单个GSTN传真终端，只要发送方能够在所使用的设备上配置“站点ID”，就可以从任何地方获得授权。
A combination of caller-ID and station ID checks MAY, on the other hand, result in a greatly improved level of security.
另一方面，呼叫者ID和站点ID检查的组合可以大大提高安全级别。
An onramp gateway MAY implement the Authorization function by requesting that a user ID and password information are sent over GSTN via DTMF. For example, this function MAY be accomplished by requesting that the DTMF information is sent immediately after the connection over GSTN is established, before starting the GSTN fax negotiation; but other methods are also possible.
入口网关可通过请求通过DTMF通过GSTN发送用户ID和密码信息来实现授权功能。例如，该功能可通过请求在通过GSTN建立连接后，在开始GSTN传真协商之前立即发送DTMF信息来实现；但其他方法也是可能的。
An onramp gateway SHOULD have a function that keeps information listed as a log, either specific to the fax gateway or in a log file that exists locally on the gateway or remotely. If the fax gateway or the remote system are equipped with recording media, the log information SHOULD be saved as a log file. As a last resort, if no recording media are available, the log MAY be printed.
入站网关应具有将信息作为日志列出的功能，该日志特定于传真网关或存在于网关本地或远程的日志文件中。如果传真网关或远程系统配备了记录介质，则应将日志信息保存为日志文件。作为最后手段，如果没有可用的记录介质，可以打印日志。
The information listed in the log MAY be the following:
日志中列出的信息可能如下所示：
- Start date and time of transmission from GSTN - End date and time of transmission from GSTN - Number of actually received pages - Number of actually received bytes - Fax resolution used - Sender address (if available) - Recipient address(es) - Date and time when the Internet Fax is sent - Error codes/text that occurred during Internet Fax transmission - Number of transmission attempts (retries) - Date and time of transmission of the (eventual) delivery notice
- 从GSTN传输的开始日期和时间-从GSTN传输的结束日期和时间-实际接收的页数-实际接收的字节数-使用的传真解析-发件人地址（如果可用）-收件人地址-发送互联网传真的日期和时间-互联网传真传输过程中出现的错误代码/文本-传输尝试（重试）次数-传输（最终）送达通知的日期和时间
Refer to Section 3.1 ("User Authorization") for authentication for an onramp gateway. In particular, sending user IDs and passwords in clear, as described in Section 3.1.2, can pose high security risks, and thus is NOT RECOMMENDED.
请参阅第3.1节（“用户授权”），了解入口网关的身份验证。特别是，如第3.1.2节所述，以明文形式发送用户ID和密码可能会带来高安全风险，因此不建议这样做。
S/MIME [2][11][12][13][14] and OpenPGP [3][10] can also be used to encrypt an Internet Fax message. A signed or encrypted message is protected while transported along the network; however, when a message reaches an Internet Fax Gateway, either onramp or offramp, this kind of protection cannot be applied anymore. In this situation, security must rely on trusted operations of the gateway itself. A gateway might have its own certificate/key to improve security operations when sending Internet Faxes, but, as with any gateway, it breaks the end-to-end security pattern of both S/MIME and OpenPGP.
S/MIME[2][11][12][13][14]和OpenPGP[3][10]也可用于加密Internet传真消息。签名或加密的消息在网络上传输时受到保护；但是，当消息到达Internet传真网关时，无论是入站还是出站，都无法再应用这种保护。在这种情况下，安全性必须依赖于网关本身的可信操作。网关可能有自己的证书/密钥来改进发送Internet传真时的安全操作，但与任何网关一样，它打破了S/MIME和OpenPGP的端到端安全模式。
Other security mechanisms, like IPsec [4][5][6][7][8] or TLS [9] also do not ensure a secure gateway operation.
其他安全机制，如IPsec[4][5][6][7][8]或TLS[9]也不能确保安全的网关操作。
Denial-of-service attacks are beyond the scope of this document. Host compromise caused by flaws in the implementation is beyond the scope of this document.
拒绝服务攻击超出了本文档的范围。由实现中的缺陷导致的主机泄露超出了本文档的范围。
Thanks to Claudio Allocchio (Consortium GARR, Italy) for its final review of this document, and for contributing the authorization and security sections of this document.
感谢Claudio Allocchio（意大利加尔财团）对本文件的最终审查，以及对本文件授权和安全部分的贡献。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter，L.，“因特网传真的术语和目标”，RFC 25421999年3月。
[2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[2] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[3] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[3] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[6] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[6] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[7] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[7] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[8] R.Thayer、N.Doraswamy和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[9] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[9] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[10] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[10] Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[11] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[11] Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[12] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[13] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[14] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[14] Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[15] Mimura, K., Yokoyama, K., Satoh, T., Kanaide, C., and C. Allocchio, "Internet Fax Gateway Requirements", RFC 4160, August 2005.
[15] Mimura，K.，Yokoyama，K.，Satoh，T.，Kanaide，C.，和C.Allocchio，“互联网传真网关要求”，RFC 41602005年8月。
[16] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[16] 丰田章男，K.，大野，H.，村井，J.，和D.Wing，“使用互联网邮件的简单传真模式”，RFC 3965，2004年12月。
[17] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[17] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[18] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998.
[18] “通过IP网络进行实时第3组传真通信的程序”，ITU-T建议T.38，1998年6月。
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[19] 《简单邮件传输协议》，RFC 28212001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[21] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[21] Myers，J.和M.Rose，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[22] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[22] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
Authors' Addresses
作者地址
Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
胜彦三村东洋通信设备有限公司2-1-1，日本神奈川县小川町，小山町
Fax: +81 467 74 5743
EMail: mimu@miyabi-labo.net
Fax: +81 467 74 5743
EMail: mimu@miyabi-labo.net
Keiichi Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
日本神奈川县小泽町小川町，日本横山庆一东洋通信设备有限公司2-1-1
Fax: +81 467 74 5743
EMail: keiyoko@msn.com
Fax: +81 467 74 5743
EMail: keiyoko@msn.com
Takahisa Satoh TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
高久佐藤东洋通信设备有限公司2-1-1，日本神奈川县小川町小山口
Fax: +81 467 74 5743
EMail: zsatou@t-ns.co.jp
Fax: +81 467 74 5743
EMail: zsatou@t-ns.co.jp
Ken Watanabe TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
渡边健东洋通信设备有限公司2-1-1，日本神奈川县小川町小山口
Fax: +81 467 74 5743
EMail: knabe@ad.cyberhome.ne.jp
Fax: +81 467 74 5743
EMail: knabe@ad.cyberhome.ne.jp
Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa-pref., Japan
Chie Kanaide TOYO通信设备有限公司2-1-1 Koyato，日本神奈川县小泽町
Fax: +81 467 74 5743
EMail: icemilk77@yahoo.co.jp
Fax: +81 467 74 5743
EMail: icemilk77@yahoo.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。