Network Working Group V. Cancio
Request for Comments: 3249 Xerox Corporation
Category: Informational M. Moldovan
G3 Nova Technology, Inc.
H. Tamura
Ricoh Company, LTD.
D. Wing
Cisco Systems
September 2002
Network Working Group V. Cancio
Request for Comments: 3249 Xerox Corporation
Category: Informational M. Moldovan
G3 Nova Technology, Inc.
H. Tamura
Ricoh Company, LTD.
D. Wing
Cisco Systems
September 2002
Implementers Guide for Facsimile Using Internet Mail
互联网邮件传真实施指南
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents.
本文档适用于使用RFC 2305和2532向传真机发送电子邮件的软件实施者。本文件为信息性文件，其指南不取代参考文件。
Table of Contents
目录
1. Introduction .................................................. 2
1.1 Organization of this document ................................ 2
1.2 Discussion of this document .................................. 2
2. Terminology ................................................... 3
3. Implementation Issues Specific to Simple Mode ................. 3
3.1 Simple Mode Fax Senders ...................................... 3
3.1.1 Multipart-alternative ...................................... 3
3.2 Simple Mode Fax Receivers .................................... 4
3.2.1 Multipart-alternative and Storage Capacity ................. 4
4. Implementation Issues Specific to Extended Mode ............... 4
4.1 Multipart-alternative ........................................ 4
4.2 Correlation of MDN with Original Message ..................... 4
4.3 Correlation of DSN with Original Message ..................... 5
4.4 Extended Mode Receivers ...................................... 5
4.4.1 Confirmation of receipt and processing from User Agents .... 5
4.4.1.1 Discrepancies in MDN [9] Interpretation .................. 5
1. Introduction .................................................. 2
1.1 Organization of this document ................................ 2
1.2 Discussion of this document .................................. 2
2. Terminology ................................................... 3
3. Implementation Issues Specific to Simple Mode ................. 3
3.1 Simple Mode Fax Senders ...................................... 3
3.1.1 Multipart-alternative ...................................... 3
3.2 Simple Mode Fax Receivers .................................... 4
3.2.1 Multipart-alternative and Storage Capacity ................. 4
4. Implementation Issues Specific to Extended Mode ............... 4
4.1 Multipart-alternative ........................................ 4
4.2 Correlation of MDN with Original Message ..................... 4
4.3 Correlation of DSN with Original Message ..................... 5
4.4 Extended Mode Receivers ...................................... 5
4.4.1 Confirmation of receipt and processing from User Agents .... 5
4.4.1.1 Discrepancies in MDN [9] Interpretation .................. 5
4.4.1.2 Disposition-Type and body of message in MDN .............. 6
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases ...... 6
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) ... 7
4.4.3.1 Success Case Example ..................................... 7
4.4.3.2 Failure Case Example 1 ................................... 9
4.4.3.3 Failure Case Example 2 ................................... 10
4.4.4 Extended Mode Receivers that are POP3/IMAP4 ................ 11
4.4.4.1 Success Case Example ..................................... 11
4.4.4.2 Failure Case Example ..................................... 12
4.4.5 Receiving Multiple Attachments ............................. 13
5. Implementation Issues Specific to the File Format ............. 13
5.1 IFD Placement & Profile-S Constraints ........................ 13
5.2 Precautions for implementers of RFC 2301 [4] ................. 14
5.2.1 Errors encountered during interoperability testing ......... 14
5.2.2 Color Gamut Considerations ................................. 14
5.2.3 File format Considerations ................................. 15
5.2.3.1 Considerations for greater reader flexibility ............ 15
5.2.3.2 Error considerations ..................................... 16
5.3 Content-Type for the file format ............................. 17
6. Implementation Issues for Internet Fax Addressing ............. 17
7. Security Considerations ....................................... 18
8. Acknowledgements .............................................. 18
9. References .................................................... 18
10. Authors' Addresses ........................................... 20
11. Full Copyright Statement ..................................... 21
4.4.1.2 Disposition-Type and body of message in MDN .............. 6
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases ...... 6
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) ... 7
4.4.3.1 Success Case Example ..................................... 7
4.4.3.2 Failure Case Example 1 ................................... 9
4.4.3.3 Failure Case Example 2 ................................... 10
4.4.4 Extended Mode Receivers that are POP3/IMAP4 ................ 11
4.4.4.1 Success Case Example ..................................... 11
4.4.4.2 Failure Case Example ..................................... 12
4.4.5 Receiving Multiple Attachments ............................. 13
5. Implementation Issues Specific to the File Format ............. 13
5.1 IFD Placement & Profile-S Constraints ........................ 13
5.2 Precautions for implementers of RFC 2301 [4] ................. 14
5.2.1 Errors encountered during interoperability testing ......... 14
5.2.2 Color Gamut Considerations ................................. 14
5.2.3 File format Considerations ................................. 15
5.2.3.1 Considerations for greater reader flexibility ............ 15
5.2.3.2 Error considerations ..................................... 16
5.3 Content-Type for the file format ............................. 17
6. Implementation Issues for Internet Fax Addressing ............. 17
7. Security Considerations ....................................... 18
8. Acknowledgements .............................................. 18
9. References .................................................... 18
10. Authors' Addresses ........................................... 20
11. Full Copyright Statement ..................................... 21
This document clarifies published RFCs which standardize facsimile communications using Internet Email. The intent is to prevent implementations that deviate in such a way as to cause interoperability problems.
本文件澄清了已发布的RFC，该RFC标准化了使用互联网电子邮件的传真通信。其目的是防止以导致互操作性问题的方式偏离的实现。
This document contains four sections that clarify, in order, the handling of simple mode fax messages, extended mode fax messages, the file format, and the internet addressing of fax recipients.
本文档包含四个部分，按顺序说明简单模式传真消息、扩展模式传真消息、文件格式和传真收件人的internet地址的处理。
See Section 2 for terminology.
术语见第2节。
Discussion of this document should take place on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC). Please send comments regarding this document to:
本文件的讨论应在互联网邮件联盟（IMC）托管的互联网传真邮件列表上进行。请将有关本文件的意见发送至：
ietf-fax@imc.org
ietf-fax@imc.org
To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org".
要订阅此列表，请向“ietf传真”发送一条正文为“订阅”的消息-request@imc.org".
To see what has gone on before you subscribed, please see the mailing list archive at:
要查看订阅前的情况，请访问邮件列表存档：
http://www.imc.org/ietf-fax/
http://www.imc.org/ietf-fax/
The following terms are used throughout this document:
本文件中使用了以下术语：
DSN - RFC 1894, "An Extensible Message Format for
Delivery Status Notifications" [7]
Extended Mode - RFC 2532, "Extended Facsimile Using
Internet Mail" [3]
MDN - RFC 2298, "An Extensible Message Format for
Message Disposition Notifications" [9]
Simple Mode - RFC 2305, "A Simple Mode of Facsimile
Using Internet Mail" [2]
TIFF - profile S or F of "File Format for Internet Fax" [4]
delivered as "image/tiff"
TIFF-FX - other profiles sent as "image/tiff-fx"
DSN - RFC 1894, "An Extensible Message Format for
Delivery Status Notifications" [7]
Extended Mode - RFC 2532, "Extended Facsimile Using
Internet Mail" [3]
MDN - RFC 2298, "An Extensible Message Format for
Message Disposition Notifications" [9]
Simple Mode - RFC 2305, "A Simple Mode of Facsimile
Using Internet Mail" [2]
TIFF - profile S or F of "File Format for Internet Fax" [4]
delivered as "image/tiff"
TIFF-FX - other profiles sent as "image/tiff-fx"
In examples, "C:" is used to indicate lines sent by the client, and "S:" to indicate those sent by the server.
在示例中，“C:”表示客户端发送的行，“S:”表示服务器发送的行。
Issues specific to Simple Mode [2] are described below:
简单模式[2]的特定问题描述如下：
Although a requirement of MIME compliance (16, Section 5.1.4), some email client implementations are not capable of correctly processing messages with a MIME Content-Type of "multipart/alternative". If a sender is unsure if the recipient is able to correctly process a message with a Content-Type of "multipart/alternative", the sender should assume the worst and not use this MIME Content-Type.
尽管有MIME合规性的要求（16，第5.1.4节），但一些电子邮件客户端实现无法正确处理MIME内容类型为“多部分/备选”的邮件。如果发件人不确定收件人是否能够正确处理内容类型为“multipart/alternative”的邮件，则发件人应假设最坏的情况，而不使用此MIME内容类型。
Devices with little storage capacity are unable to cache previous parts of a multipart/alternative message. In order for such devices to correctly process only one part of a multipart/alternative message, such devices may simply use the first part of a multipart/alternative message it is capable of processing.
存储容量很小的设备无法缓存多部分/备用消息的以前部分。为了使这些设备仅正确处理多部分/备选消息的一部分，这些设备可以简单地使用其能够处理的多部分/备选消息的第一部分。
This behavior means that even if subsequent, higher-fidelity parts could have been processed, they will not be used.
此行为意味着，即使后续的高保真度零件可以被处理，它们也不会被使用。
This behavior can cause user dissatisfaction because when two high-fidelity but low-memory devices are used with each other, the lowest-fidelity part of the multipart/alternative will be processed.
这种行为可能会导致用户不满意，因为当两个高保真但低内存的设备相互使用时，将处理多部分/备选方案的最低保真部分。
The solution to this problem is for the sender to determine the capability of the recipient and send only high fidelity parts. However, a mechanism to determine the recipient capabilities prior to an initial message sent to the recipient doesn't yet exist on the Internet.
此问题的解决方案是由发送方确定接收方的能力，并仅发送高保真部分。但是，Internet上尚不存在在向收件人发送初始邮件之前确定收件人能力的机制。
After an initial message is sent, the Extended Mode mechanism, described in RFC 2532 [3], Section 3.3, enables a recipient to include its capabilities in a delivery and/or a disposition notification: in a DSN, if the recipient device is an RFC 2532/ESMTP [3] compliant server or in an MDN if the recipient is a User Agent.
发送初始消息后，RFC 2532[3]第3.3节中描述的扩展模式机制使收件人能够在传递和/或处置通知中包括其功能：在DSN中，如果收件人设备是RFC 2532/ESMTP[3]兼容的服务器，或者在MDN中，如果收件人是用户代理。
Issues specific to Extended Mode [3] fax are described below. Note that any Extended Mode device also needs to consider issues specific to Simple Mode (Section 3 of this document).
扩展模式[3]传真特有的问题如下所述。注意，任何扩展模式设备也需要考虑特定于简单模式的问题（本文档第3节）。
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
第3.1.1节和第3.2.1节也适用于该模式。
To re-iterate a paragraph from section 2.1, RFC 2298 [9]:
重述RFC 2298[9]第2.1节中的段落：
A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header, as specified in RFC 822 [10]. This will permit automatic correlation of MDNs with original messages by user agents.
如RFC 822[10]中所述，包含对消息头的处置通知的消息还应包含消息ID消息头。这将允许用户代理自动将MDN与原始消息关联起来。
Similar to the requirement to correlate an MDN, above, DSNs also need to be correlated. This is best done using the ENVID parameter in the "MAIL" command. See Sections 3 and 5.4 of RFC 1891 [5] for details.
与上面关联MDN的要求类似，DSN也需要关联。这最好使用“MAIL”命令中的ENVID参数来完成。详见RFC 1891[5]第3节和第5.4节。
Confirmation that the facsimile image (attachment) was delivered and successfully processed is an important aspect of the extended mode of the facsimile using Internet mail. This section describes implementation issues with several types of confirmations.
确认传真图像（附件）已交付并成功处理是使用互联网邮件的传真扩展模式的一个重要方面。本节介绍了几种确认类型的实现问题。
When a message is received with the "Disposition-Notification-To" header and the receiver has determined whether the message can be processed, it may generate a:
当接收到带有“处置通知”标题的消息，并且接收方已确定是否可以处理该消息时，它可能会生成：
a) Negative MDN in case of error, or
a) 错误情况下的负MDN，或
b) Positive MDN in case of success
b) 成功情况下的积极MDN
The purpose of receiving a requested MDN acknowledgement from an Extended Mode recipient is the indication of success or failure to process the file attachment that was sent. The attachment, not the body, constitutes the facsimile message. Therefore an Extended Mode sender would expect, and it is recommended that the Extended Mode receiver send (with an MDN), an acknowledgement of the success or failure to decode and process the file attachment.
从扩展模式收件人接收请求的MDN确认的目的是表示处理发送的文件附件成功或失败。传真信息由附件而非正文构成。因此，扩展模式发送方期望并且建议扩展模式接收方（使用MDN）发送对解码和处理文件附件成功或失败的确认。
Implementers of the Extended Mode [3] should be consistent in the feedback provided to senders in the form of error codes and/or failure/success messages.
扩展模式[3]的实施者应以错误代码和/或失败/成功消息的形式向发送者提供一致的反馈。
An Extended Mode sender must be aware that RFC 2298 [9] does not distinguish between the success or failure to decode the body-content part of the message and the success or failure to decode a file attachment. Consequently MDNs may be received which do not reflect the success or failure to decode the attached file, but rather to decode the body-content part of the message.
扩展模式发送方必须知道，RFC 2298[9]没有区分对邮件正文内容部分解码的成功或失败与对文件附件解码的成功或失败。因此，可以接收不反映解码所附文件的成功或失败，而是反映解码消息的正文内容部分的mdn。
If the receiver of an MDN request is an RFC 2532 compliant device that automatically prints the received Internet mail messages and attachments, or forwards the attachment via GSTN fax, it should, in the case of success:
如果MDN请求的接收者是RFC 2532兼容设备，该设备自动打印收到的Internet邮件消息和附件，或通过GSTN传真转发附件，则在成功的情况下应：
a) Use a "disposition-type" of "dispatched" (with no "disposition-modifier") in the MDN, and
a) 在MDN中使用“dispatched”（不带“disposition modifier”）的“disposition type”，以及
b) Use text similar to the following in the body of the message:
b) 在邮件正文中使用类似于以下内容的文本：
"This is a Return Receipt for the mail that you sent to [above, or below, or this address, etc]. The message and attached files[s] may have been printed, faxed or saved. This is no guarantee that the message has been read or understood".
“这是您发送到[上方、下方或此地址等]的邮件的回执。邮件和附件可能已打印、传真或保存。这并不保证邮件已被阅读或理解。”。
and in the case of failure:
如果出现故障：
a) Use a "disposition-type" of "processed" and disposition-modifier of "error", and
a) 使用“已处理”的“处置类型”和“错误”的处置修饰符，以及
b) Use text similar to the following in the body of the message:
b) 在邮件正文中使用类似于以下内容的文本：
"This is a Return Receipt for the mail that you sent to [above, or below, or this address, etc]. An error occurred while attempting to decode the attached file[s]".
“这是您发送到[上方、下方或此地址等]的邮件的回执。尝试解码所附文件时出错。”。
This recommendation adheres to the definition in RFC 2298 [9] and helps to distinguish the returned MDNs for proper handling.
本建议符合RFC 2298[9]中的定义，有助于区分返回的MDN，以便正确处理。
Implementers may wish to consider sending messages in the language of the sender (by utilizing a header field from the original message) or including multiple languages, by using multipart/alternative for the text portion of the MDN.
实现者可能希望考虑通过发送者的语言（通过利用来自原始消息的头字段）或包含多个语言来发送消息，通过使用多部分/备选的MDN文本部分。
Because legacy e-mail applications do not parse the machine-readable headers, e-mail users depend on the human-readable parts of the MDN to recognize the type of acknowledgement that is received.
由于传统电子邮件应用程序不解析机器可读的头，因此电子邮件用户依赖MDN的人类可读部分来识别接收到的确认类型。
Examples:
示例：
MDN: Subject: Your message was processed successfully. (MDN) Subject: Your message has been rejected. (MDN)
主题：您的邮件已成功处理。（MDN）主题：您的邮件已被拒绝。（MDN）
DSN: Subject: Your message was delivered successfully. (DSN) Subject: Your message could not be delivered. (DSN) Subject: Your message is delayed. (DSN)
DSN:主题：您的邮件已成功传递。（DSN）主题：无法传递您的邮件。（DSN）主题：您的邮件被延迟。（DSN）
SMTP server-based implementations are strongly encouraged to implement the "SMTP Service Extension for Returning Enhanced Error Codes" [8]. This standard is easy to implement and it allows detailed standardized success and error indications to be returned to the sender by the submitting MTA.
强烈建议基于SMTP服务器的实现实现“用于返回增强错误代码的SMTP服务扩展”[8]。该标准易于实施，允许提交MTA将详细的标准化成功和错误指示返回给发件人。
The following examples, are provided as illustration only. They should not be interpreted as limiting the protocol or the DSN form. If the examples conflict with the definitions in the standards (RFC 1891[5]/1893[6]/1894[7]/2034[8]), the standards take precedence.
以下示例仅作为说明提供。它们不应被解释为限制协议或DSN形式。如果示例与标准（RFC 1891[5]/1893[6]/1894[7]/2034[8]）中的定义相冲突，则以标准为准。
In the following example the sender <jean@example.com> sends a message to the receiver <ifax@example.net> which is an ESMTP server and the receiver successfully decodes the message.
在下面的示例中，发送方<jean@example.com>向接收者发送消息<ifax@example.net>这是一个ESMTP服务器，接收方成功解码了消息。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
example.org example.net
SMTP Sequence:
SMTP序列：
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 2.0.0 Goodbye
DSN (to jean@example.com):
DSN（至jean@example.com):
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@example.net
Message-ID: <19991212190157.01234@example.net>
To: jean@example.com
Subject: Your message was delivered successfully. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121854870001
Date: Mon, 12 Dec 1999 19:01:57 +0900
From: postmaster@example.net
Message-ID: <19991212190157.01234@example.net>
To: jean@example.com
Subject: Your message was delivered successfully. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121854870001
--JUK199912121854870001 Content-type: text/plain
--JUK199912121854870001内容类型：文本/普通
Your message (id MM123456) was successfully delivered to ifax@example.net.
您的邮件（id MM123456）已成功送达ifax@example.net.
--JUK199912121854870001 Content-type: message/delivery-status
--JUK199912121854870001内容类型：消息/传递状态
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 2.1.5
Recipient <ifax@example.net> ok
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
Action: delivered
Status: 2.1.5 (Destination address valid)
Diagnostic-Code: smtp; 250 2.1.5
Recipient <ifax@example.net> ok
--JUK199912121854870001 Content-type: message/rfc822
--JUK199912121854870001内容类型：消息/rfc822
[headers of returned message go here.]
[返回消息的标题位于此处。]
--JUK199912121854870001--
--JUK199912121854870001--
In this example, the receiver determines it is unable to decode the attached file AFTER it has received the SMTP message. The receiver then sends a 'failure' DSN.
在本例中，接收方在收到SMTP消息后确定无法解码所附文件。然后，接收器发送“故障”DSN。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
SMTP Sequence:
SMTP序列：
This is the same as the case a). After the sequence, a decode error occurs at the receiver, so instead of a 'success' DSN, a 'failure' DSN is sent.
这与案例a）相同。序列结束后，接收器出现解码错误，因此发送的不是“成功”DSN，而是“失败”DSN。
DSN (to jean@example.com):
DSN（至jean@example.com):
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@example.net
Message-ID: <19991212193120.87652@example.net>
To: jean@example.com
Subject: Your message could not be delivered. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121934240002
Date: Mon, 12 Dec 1999 19:31:20 +0900
From: postmaster@example.net
Message-ID: <19991212193120.87652@example.net>
To: jean@example.com
Subject: Your message could not be delivered. (DSN)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=JUK199912121934240002
--JUK199912121934240002 Content-type: text/plain
--JUK199912121934240002内容类型：文本/普通
Your message (id MM123456) to ifax@example.net resulted in an error while attempting to decode the attached file.
您的邮件（id MM123456）发送至ifax@example.net在尝试解码附加文件时导致错误。
--JUK199912121934240002 Content-type: message/delivery-status
--JUK199912121934240002内容类型：消息/传递状态
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
Action: Failed
Status: 5.6.1 (Media not supported)
Diagnostic-Code: smtp; 554 5.6.1 Decode error
Reporting-MTA: dns; example.net
Original-Envelope-ID: MM123456
Final-Recipient: rfc822;ifax@example.net
Action: Failed
Status: 5.6.1 (Media not supported)
Diagnostic-Code: smtp; 554 5.6.1 Decode error
--JUK199912121934240002 Content-type: message/rfc822
--JUK199912121934240002内容类型：消息/rfc822
[headers of returned message go here.]
[返回消息的标题位于此处。]
--JUK199912121934240002--
--JUK199912121934240002--
In this example, the receiver determines it is unable to decode the attached file BEFORE it accepts the SMTP transmission.
在本例中，接收方在接受SMTP传输之前确定无法解码所附文件。
SMTP sequence:
SMTP序列：
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 554 5.6.1 Media not supported
C: QUIT
S: 221 2.0.0 Goodbye
S: 220 example.net SMTP service ready
C: EHLO example.org
S: 250-example.net
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456
S: 250 2.1.0 Originator <jean@example.com> ok
C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \
ORCPT=rfc822;ifax@example.net
S: 250 2.1.5 Recipient <ifax@example.net> ok
C: DATA
S: 354 Send message, ending in <CRLF>.<CRLF>
C:
C: [Message goes here.]
C:
C: .
S: 554 5.6.1 Media not supported
C: QUIT
S: 221 2.0.0 Goodbye
DSN:
DSN：
Note: In this case, the previous MTA generates the DSN that is forwarded to the original sender. The receiving MTA has not accepted delivery and therefore can not generate a DSN.
注意：在这种情况下，前一个MTA将生成转发给原始发件人的DSN。接收MTA未接受传递，因此无法生成DSN。
NOTE: This document does not define new disposition-types or disposition-modifiers. Those used below are defined in RFC 2298[9]. This section provides examples on how POP3/IMAP4 devices may use the already defined values.
注意：本文档不定义新的处置类型或处置修饰符。RFC 2298[9]中定义了以下使用的工具。本节提供了POP3/IMAP4设备如何使用已定义值的示例。
These examples are provided as illustration only. They should not be interpreted as limiting the protocol or the MDN form. If the examples conflict with the MDN [9] standard, the standard takes precedence.
这些示例仅作为说明提供。它们不应被解释为限制协议或MDN形式。如果示例与MDN[9]标准冲突，则以该标准为准。
If the original sender receives an MDN which has "displayed", "dispatched" or "processed" disposition-type without disposition-modifier, the receiver may have received or decoded the attached file that it sent. The MDN does not guarantee that the receiver displays, prints or saves the attached file. See Section 4.4.1.1, Discrepancies in MDN Interpretation.
如果原始发送方收到的MDN具有“已显示”、“已发送”或“已处理”的处置类型，且没有处置修改器，则接收方可能已接收或解码其发送的附加文件。MDN不保证接收方显示、打印或保存所附文件。见第4.4.1.1节，MDN解释中的差异。
NOTE: This example does not include the third component of the MDN.
注意：此示例不包括MDN的第三个组件。
Date: 14 Dec 1999 17:48:44 +0900
From: ken_recipient@example.com
Message-ID: <19991214174844.98765@example.com>
Subject: Your message was processed successfully. (MDN)
To: mary@example.net
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="61FD1001_IFAX"
Date: 14 Dec 1999 17:48:44 +0900
From: ken_recipient@example.com
Message-ID: <19991214174844.98765@example.com>
Subject: Your message was processed successfully. (MDN)
To: mary@example.net
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="61FD1001_IFAX"
--61FD1001_IFAX
Content-Type: text/plain
--61FD1001_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to "ken_recipient@example.com". The message and attached files may have been printed, faxed or saved. This is no guarantee that the message has been read or understood.
这是您发送给“ken”的邮件的回执_recipient@example.com". 邮件和附件可能已打印、传真或保存。这并不能保证信息已被阅读或理解。
--61FD1001_IFAX Content-Type: message/disposition-notification
--61FD1001_IFAX内容类型：消息/处置通知
Reporting-UA: ken-ifax.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <19991214174010O.mary@example.net>
Disposition: automatic-action/MDN-sent-automatically; dispatched
Reporting-UA: ken-ifax.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <19991214174010O.mary@example.net>
Disposition: automatic-action/MDN-sent-automatically; dispatched
--61FD1001_IFAX--
--61FD1001_IFAX--
If the original sender receives an MDN with an "error" or "warning" disposition-modifier, it is possible that the receiver could not receive or decode the attached file. Currently there is no mechanism to associate the disposition-type with the handling of the main content body of the message or the attached file.
如果原始发送方收到带有“错误”或“警告”处置修改器的MDN，则接收方可能无法接收或解码所附文件。目前没有将处置类型与消息或附加文件的主要内容体的处理相关联的机制。
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@example.com
Message-ID: <19991214194844.67325@example.com>
Subject: Your message has been rejected. (MDN)
To: mary@example.net
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="84FD1011_IFAX"
Date: 14 Dec 1999 19:48:44 +0900
From: ken_recipient@example.com
Message-ID: <19991214194844.67325@example.com>
Subject: Your message has been rejected. (MDN)
To: mary@example.net
Mime-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification; boundary="84FD1011_IFAX"
--84FD1011_IFAX
Content-Type: text/plain
--84FD1011_IFAX
Content-Type: text/plain
This is a Return Receipt for the mail that you sent to "ken_recipient@example.com". An error occurred while attempting to decode the attached file[s]".
这是您发送给“ken”的邮件的回执_recipient@example.com". 尝试解码附加文件[s]时出错。”。
--84FD1011_IFAX Content-Type: message/disposition-notification
--84FD1011\u IFAX内容类型：消息/处置通知
Reporting-UA: ken-ifax.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <199912141823123.mary@example.net>
Disposition: automatic-action/MDN-sent-automatically;
processed/error
Reporting-UA: ken-ifax.example.com; barmail 1999.10
Original-Recipient: rfc822;ken_recipient@example.com
Final-Recipient: rfc822;ken_recipient@example.com
Original-Message-ID: <199912141823123.mary@example.net>
Disposition: automatic-action/MDN-sent-automatically;
processed/error
--84FD1011_IFAX Content-Type: message/rfc822
--84FD1011_IFAX内容类型：消息/rfc822
[original message goes here]
[原文如下]
--84FD1011_IFAX--
--84FD1011_IFAX--
A received email message could contain multiple attachments and each distinct attachment could use TIFF or TIFF-FX with different encodings or resolutions, and these could be mixed with other file types.
收到的电子邮件可以包含多个附件，每个不同的附件可以使用具有不同编码或分辨率的TIFF或TIFF-FX，并且可以与其他文件类型混合使用。
There is currently no mechanism to identify, in a returned MDN, the attachments that were successfully decoded from those that could not be decoded.
在返回的MDN中，目前没有机制来识别成功解码的附件和无法解码的附件。
If the Extended Mode recipient is unable to decode any of the attached files, it is recommended that the Extended Mode recipient return a decoding error for the entire message.
如果扩展模式收件人无法解码任何附加文件，建议扩展模式收件人返回整个邮件的解码错误。
a) An IFD is required, by TIFF 6.0, to begin on a word boundary, however, there is ambiguity with regard to the defined size of a word. A word should be interpreted as a 2-byte quantity. This
a) TIFF 6.0要求IFD从单词边界开始，但是，单词的定义大小存在歧义。一个字应解释为2字节的数量。这
recommendation is based on examination of Figure 1 and the definition of IFD Entry, Bytes 8-11, found in Section 2 of TIFF 6.0.
建议基于对图1的检查和TIFF 6.0第2节中IFD条目字节8-11的定义。
b) Low memory devices, which support resolutions greater than the required Profile-S, may be memory-constrained, such that those devices cannot properly handle arbitrary placement of TIFF IFDs within a TIFF file.
b) 支持大于所需配置文件的分辨率的低内存设备可能受到内存限制，因此这些设备无法在TIFF文件中正确处理TIFF IFD的任意放置。
To interoperate with a receiver that is constrained, it is strongly recommended that senders always place the IFD at the beginning of the image file when using any of the Profiles defined in [4].
要与受限制的接收器进行互操作，强烈建议发送者在使用[4]中定义的任何配置文件时，始终将IFD放在图像文件的开头。
The TIFF/RFC 2301 [4] errors listed below were encountered during interoperability testing and are provided so that implementers of TIFF readers and writers can take precautionary measures.
以下列出的TIFF/RFC 2301[4]错误是在互操作性测试期间遇到的，提供这些错误是为了使TIFF读写器的实现者能够采取预防措施。
a) Although Profile S of TIFF [4] specifies that files should be in little-endian order, during testing it was found that some common TIFF writers create big-endian files. If possible, the TIFF reader should be coded to handle big-endian files. TIFF writers should always create little-endian files to be compliant with the standard and to allow interoperation with memory-constrained devices.
a) 尽管TIFF[4]的概要文件S规定文件应以小尾端顺序排列，但在测试过程中发现，一些常见的TIFF编写器会创建大尾端文件。如果可能，应该对TIFF阅读器进行编码，以处理big-endian文件。TIFF编写器应始终创建符合标准的小端文件，并允许与内存受限的设备进行互操作。
b) Bytes 0-1 of the Image File Header are supposed to be set to "II" (4949h) or "MM" (4d4dh) to indicate the byte order. During testing, other values were encountered. Readers should handle cases where the byte order field contains values other than "II" or "MM", and writers should ensure the correct value is used.
b) 图像文件头的字节0-1应设置为“II”（4949h）或“MM”（4dh），以指示字节顺序。在测试过程中，遇到了其他值。读卡器应处理字节顺序字段包含“II”或“MM”以外的值的情况，写卡器应确保使用正确的值。
The ITULAB encoding (PhotometricInterpretation = 10) allows choosing a gamut range for L*a*b* (see the TIFF field Decode), which in turn provides a way to place finer granularity on the integer values represented in this colorspace. But consequently, an inadequate gamut choice may cause a loss in the preservation of colors that don't fall within the space of colors bounded by the gamut. As such, it is worth commenting on this.
ITULAB编码（PhotometricInterpretation=10）允许为L*a*b*选择一个色域范围（参见TIFF字段解码），这反过来又提供了一种在该颜色空间中表示的整数值上放置更精细粒度的方法。但因此，色域选择不当可能会导致不在色域范围内的颜色的保存损失。因此，这一点值得评论。
The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was chosen to accommodate most scan devices, which are typically acquired from a hardcopy source. It wasn't chosen to deal with the range of color from camera input or sRGB monitor data. In fact, when dealing with images from the web and other display oriented sources, the color range for a scanned hardcopy may likely be inadequate. It is important to use a gamut that matches the source of the image data.
iTurab默认色域L[0100]a[-85,85]b[-75125]被选择用于容纳大多数扫描设备，这些设备通常从硬拷贝源获取。它不是用来处理摄像机输入或sRGB监视器数据的颜色范围的。事实上，在处理来自web和其他面向显示的源的图像时，扫描硬拷贝的颜色范围可能不够。使用与图像数据源匹配的色域非常重要。
The following guidelines are recommended:
建议采用以下准则：
1. When acquiring input from a printed hardcopy source, without modification, the ITU-T Recommendation T.42 default ITULAB gamut should be appropriate.
1. 当从打印硬拷贝源获取输入时，未经修改，ITU-T建议T.42默认ITULAB色域应适当。
2. For an sRGB source, the ITU-T Recommendation T.42 default ITULAB gamut is not appropriate. A more appropriate gamut to consider is: L [0,100], a [-88,99] and b [-108.8,95.2]. These may be realized by using the following Decode values for 8-bit data: (0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
2. 对于sRGB源，ITU-T建议T.42默认ITULAB色域不适用。要考虑的更合适的范围是：L〔0100〕，[-88，99 ]和B[-108，95.2]。这些可以通过对8位数据使用以下解码值来实现：（0/1100/1，-22440/255，25245/255，-27744/255，24276/255）。
3. If the range of L*a*b* value can be precomputed efficiently before converting to ITULAB, then you may get the best result by picking a gamut that is custom to this range.
3. 如果L*a*b*值的范围可以在转换到ITULAB之前有效地预计算，那么您可以通过选择一个自定义到该范围的色域来获得最佳结果。
Implementers should make sure of the contents in the following two sections.
实施者应确保以下两个部分的内容。
a) Readers are able to handle cases where IFD offsets point beyond the end of the file, while writers ensure that the IFD offset does not point beyond the end of the file.
a) 读卡器可以处理IFD偏移量超出文件末尾的情况，而写卡器可以确保IFD偏移量不超出文件末尾。
b) Readers are able to handle the first IFD offset being on a non-word boundary, while writers ensure that the first IFD offset is on a word boundary.
b) 读卡器可以处理位于非单词边界上的第一个IFD偏移，而写卡器可以确保第一个IFD偏移位于单词边界上。
c) Readers are flexible and able to accommodate: IFDs that are not presented in ascending page order; IFDs that are not placed at a location that precedes the image which the IFD describes; next IFD offsets that precede the current IFD, the current IFDs' field data, or the current IFDs' image data. Writers on the other hand should generate files with IFDs presented in ascending page order; IFDs placed at a location that precedes the image which the IFD describes; the next IFD should always follow the current IFD and all of its data.
c) 读者是灵活的，能够适应：不以升序页面顺序显示的IFD；未放置在IFD描述的图像之前位置的IFD；下一个IFD偏移位于当前IFD、当前IFD字段数据或当前IFD图像数据之前。另一方面，编写者应该生成IFD以升序显示的文件；放置在IFD描述的图像之前位置的IFD；下一个IFD应始终遵循当前IFD及其所有数据。
d) Writers generate tags with the appropriate type of data (for example RATIONAL instead of SRATIONAL). Readers are flexible with those types of misrepresentations that may be readily accommodated (for example SHORT instead of LONG) and lead to enhanced robustness.
d) 编写器使用适当类型的数据生成标记（例如，RATIONAL而不是SRATIONAL）。读者可以灵活地处理那些容易接受的误传类型（例如短而不是长），从而增强鲁棒性。
e) The appropriate count is associated with the tags (it is not 0 and matches the tag requirement), while readers are flexible with these types of misrepresentations, which may be readily accommodated and lead to enhanced robustness.
e) 适当的计数与标签相关联（它不是0，与标签要求相匹配），而读卡器可以灵活地处理这些类型的误报，这可能很容易适应，并提高鲁棒性。
f) Tags appear in the correct order in the IFD and readers are flexible with these types of misrepresentations.
f) 标签以正确的顺序出现在IFD中，读卡器可以灵活处理这些类型的误报。
a) Readers only accept files with bytes 2-3 of the Image File Header equal to 42 (2Ah), the "magic number", as being valid TIFF or TIFF-FX files, while writers only generate files with the appropriate magic number.
a) 读卡器仅接受图像文件头字节2-3等于42（2Ah）的文件，即“幻数”，作为有效的TIFF或TIFF-FX文件，而写卡器仅生成具有适当幻数的文件。
b) Files are not generated with missing field entries, and readers reject any such files.
b) 不会生成缺少字段条目的文件，读卡器会拒绝任何此类文件。
c) The PageNumber value is based on the order within the Primary IFD chain. The ImageLayer values are based on the layer order and the image order within the layer respectively. Readers may reject the pages where the PageNumber or ImageLayer values are not consistent with the number of Primary IFDs, number of layers or number of images within the layers.
c) PageNumber值基于主IFD链中的顺序。ImageLayer值分别基于层顺序和层内的图像顺序。如果页码或ImageLayer值与主IFD数、层数或层内图像数不一致，读者可能会拒绝这些页面。
d) Tags are unique within an IFD and readers may reject pages where this is not the case.
d) 标签在IFD中是唯一的，如果不是这样，读者可能会拒绝页面。
e) Strip data does not overlap other file data and the reader may error appropriately.
e) 条带数据不会与其他文件数据重叠，读卡器可能会相应出错。
f) The strip offset does not point outside the file, under these conditions readers may reject the page where this is the case.
f) 条带偏移量不会指向文件外部，在这种情况下，读者可能会拒绝页面。
g) The strip offset + StripByteCounts does not point outside the file, under these conditions the reader may error appropriately.
g) 条带偏移量+条带字节数不会指向文件外部，在这些情况下，读卡器可能会相应出错。
h) Only one endian order is used within the file otherwise the rendered file will be corrupted.
h) 文件中仅使用一个endian顺序，否则渲染文件将损坏。
i) Tag values are consistent with the data contained within the image strip. For example, a bi-level black mark on a white background image strip with a PhotometricInterpretation tag value of "1" (bit value of "0" means black) will result in the rendering of the image as white marks on a black background (reverse video).
i) 标记值与图像条中包含的数据一致。例如，光度测量解释标记值为“1”（位值为“0”表示黑色）的白色背景图像条上的双层黑色标记将导致将图像渲染为黑色背景上的白色标记（反向视频）。
j) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters used for transformations are correct and compliant with the specification.
j) 对于特殊颜色空间（ITULAB、YCBCR、CMYK），用于转换的参数正确且符合规范。
k) The XPosition and YPosition values are consistent with the horizontal and vertical offsets of the top-left of the IFD from the top-left of the Primary IFD, in units of the resolution. To do otherwise results in misplacement of the rendered image.
k) XPosition和YPosition值与IFD左上角相对于主IFD左上角的水平和垂直偏移一致，以分辨率为单位。否则会导致渲染图像的错位。
l) All combinations of tag values are correct, with special attention being given to the sets: XResolution, YResolution and ImageWidth; PhotometricInterpretation, SamplesPerPixel, and BitsPerSample. Any appropriate combinations will likely result in image distortion or an inability to render the image.
l) 标签值的所有组合都是正确的，需要特别注意集合：X分辨率、Y分辨率和图像宽度；测光解释、每像素采样和位采样。任何适当的组合都可能导致图像失真或无法渲染图像。
m) The appropriate Compression types are used for the image layers within a Profile M file, such as a bi-level coder for the mask layers (i.e. odd numbered layers) and multi-level (color) coders for the background and foreground layers. Readers should reject files where this is not true.
m) 适当的压缩类型用于简档M文件内的图像层，例如用于遮罩层（即奇数编号层）的双层编码器和用于背景和前景层的多级（颜色）编码器。如果不是这样，读者应该拒绝文件。
The content-type "image/tiff" should only be used for Profiles S and F. Some existing implementations based on [4] may use "image/tiff" for other Profiles. However, this usage is now deprecated. Instead, the content-type "image/tiff-fx", whose registration is being defined in [17] should be used.
内容类型“image/tiff”应仅用于配置文件S和F。基于[4]的一些现有实现可能会将“image/tiff”用于其他配置文件。但是，这种用法现在已被弃用。相反，应使用[17]中定义的内容类型“image/tiff fx”。
To maximize interworking with devices that are only capable of rendering Profile S or F, "image/tiff" SHOULD be used when transporting Profile S or F.
为了最大限度地与仅能够渲染配置文件S或F的设备交互，在传输配置文件S或F时应使用“图像/tiff”。
The "+" and "=" characters are valid within message headers, but must be encoded within some ESMTP commands, most notably ORCPT [5]. Implementations must take special care that ORCPT (and other ESMTP values) are properly encoded.
“+”和“=”字符在消息头中有效，但必须在某些ESMTP命令中进行编码，尤其是ORCPT[5]。实现必须特别注意ORCPT（和其他ESMTP值）是否正确编码。
For example, the following header is valid as-is:
例如，以下标题按原样有效：
To: Home Fax <FAX=+390408565@example.com>
To: Home Fax <FAX=+390408565@example.com>
but when used with ORCPT, the "=" and "+" must be encoded like this:
但与ORCPT一起使用时，“=”和“+”必须按如下方式编码：
RCPT TO:<FAX=+390408565@example.com> \
ORCPT=FAX+3D+2B390408565@example.com
RCPT TO:<FAX=+390408565@example.com> \
ORCPT=FAX+3D+2B390408565@example.com
Note the "=" and "+" are valid inside the forward-path, but must be encoded when used within the esmtp value.
注意“=”和“+”在转发路径内有效，但在esmtp值内使用时必须进行编码。
See [5] for details on this encoding.
有关此编码的详细信息，请参见[5]。
With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 in RFC 2532 [3] apply.
关于本文件，RFC 2305[2]第5节和RFC 2532[3]第4节适用。
The authors gratefully acknowledge the following persons who contributed or made comments on earlier versions of this memo: Claudio Allocchio, Richard Coles, Ryuji Iwazaki, Graham Klyne, James Rafferty, Kensuke Yamada, Jutta Degener and Lloyd McIntyre.
作者衷心感谢对本备忘录早期版本做出贡献或发表评论的以下人士：克劳迪奥·阿洛奇、理查德·科尔斯、岩崎良二、格雷厄姆·克莱恩、詹姆斯·拉弗蒂、山田贤介、朱塔·德杰纳和劳埃德·麦金太尔。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter，L.，“因特网传真的术语和目标”，RFC 25421999年3月。
[2] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3205, March 1998.
[2] 丰田章男，K.，大野，H.，村井，J.和D.荣，“使用互联网邮件的简单传真模式”，RFC3205，1998年3月。
[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[3] Masinter，L.和D.Wing，“使用互联网邮件的扩展传真”，RFC 25321999年3月。
[4] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[4] McIntyre，L.，Zilles，S.，Buckley，R.，Venable，D.，Parsons，G.和J.Rafferty，“互联网传真的文件格式”，RFC 2301，1998年3月。
[5] Moore, K., "SMTP Service Extension for Delivery Status Notification", RFC 1891, January 1996.
[5] Moore，K.，“传递状态通知的SMTP服务扩展”，RFC 18911996年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[6] Vaudreuil，G.“增强邮件系统状态代码”，RFC 1893，1996年1月。
[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[7] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 1894，1996年1月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8] 弗里德，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[9] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[9] Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC 2298，1998年3月。
[10] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[11] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[12] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[12] Allocchio，C.，“互联网邮件中的最小GSTN地址格式”，RFC3191，2001年10月。
[13] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[13] Allocchio，C.，“因特网邮件中的最小传真地址格式”，RFC3192，2001年10月。
[14] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000
[14] Allocchio，C.，“电子邮件服务中的GSTN地址元素扩展”，RFC 28462000年6月
[15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, D., "SMTP Service Extensions", RFC 2846, November 1995
[15] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，D.，“SMTP服务扩展”，RFC 28461995年11月
[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] McIntyre, L., Parsons, G. and J. Rafferty, "Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration", RFC 3250, September 2002.
[17] McIntyre，L.，Parsons，G.和J.Rafferty，“标签图像文件格式传真扩展（TIFF-FX）-图像/TIFF-FX MIME子类型注册”，RFC 3250，2002年9月。
[18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] 《简单邮件传输协议》，RFC 28212001年4月。
[19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[19] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Vivian Cancio 103 Cuesta Drive Los Altos, CA 94022
维维安·坎西奥加利福尼亚州洛斯阿尔托斯库埃斯塔大道103号，邮编94022
Phone: +1-650-948-3135
EMail: vcancio@pacbell.net
Phone: +1-650-948-3135
EMail: vcancio@pacbell.net
Mike Moldovan G3 Nova Technology Inc. 5743 Corsa Avenue, Suite 122 Westlake Village, CA 91362
Mike Mordan G3 Nova Technology Inc.加利福尼亚州西湖村Corsa大道5743号122室，邮编：91362
Phone: (818) 865-6600 Ext.113 EMail: mmoldovan@g3nova.com
电话：（818）865-6600分机113电子邮件：mmoldovan@g3nova.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku Tokyo 143-8555 Japan
Hiroshi Tamura Ricoh株式会社，1-3-6中谷国美，日本东京大田143-8555
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@toda.ricoh.co.jp
Phone: +81-3-3777-8124
Fax: +81-3-5742-8859
EMail: tamura@toda.ricoh.co.jp
Dan Wing Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 USA
Dan Wing Cisco Systems，Inc.美国加利福尼亚州圣何塞塔斯曼大道西170号，邮编95134-1706
Phone: +1-408-525-5314
Fax: +1-408-527-8083
EMail: dwing@cisco.com
Phone: +1-408-525-5314
Fax: +1-408-527-8083
EMail: dwing@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。