Network Working Group M. Nakamura
Request for Comments: 3974 Kyoto University
Category: Informational J. Hagino
IIJ Research Laboratory
January 2005
Network Working Group M. Nakamura
Request for Comments: 3974 Kyoto University
Category: Informational J. Hagino
IIJ Research Laboratory
January 2005
SMTP Operational Experience in Mixed IPv4/v6 Environments
SMTP在IPv4/v6混合环境中的操作经验
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年）。
IESG Note:
IESG注：
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，并特别指出，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本RFC的读者应谨慎评估其实施和部署价值。
This document contains a specific interpretation of the applicability of the MX processing algorithm in RFC 2821, Section 5, to dual-stack environments. Implementors are cautioned that they must reference RFC 2821 for the full algorithm; this document is not to be considered a full restatement of RFC 2821, and, in case of ambiguity, RFC 2821 is authoritative.
本文件包含RFC 2821第5节中MX处理算法适用于双堆栈环境的具体解释。提醒实施者，他们必须参考RFC 2821了解完整的算法；在RF2821的情况下，本文件被视为不完整的RF2821。
Abstract
摘要
This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.
本文档讨论IPv4/v6双堆栈环境中的SMTP操作经验。随着支持IPv6的SMTP服务器的部署，显然MX记录的某些配置对于稳定的双堆栈（IPv4和IPv6）SMTP操作是必要的。本文档澄清了IPv4 SMTP和IPv6 SMTP之间过渡期间存在的问题。它还定义了稳定的IPv4/v6 SMTP操作的操作要求。
This document does not define any new protocol.
本文件未定义任何新协议。
Delivery of mail messages to the final mail drop is not always done by direct IP communication between the submitter and final receiver, and there may be some intermediate hosts that relay the messages. So it is difficult to know at message submission (also at receiver side) that all intermediate relay hosts are properly configured. It is not easy to configure all systems consistently since the DNS configuration used by mail message delivery systems is more complex than other Internet services. During the transition period from IPv4 to IPv6, more care should be applied to IPv4/v6 interoperability.
将邮件消息传递到最终邮件投递并不总是通过提交者和最终接收者之间的直接IP通信来完成，并且可能存在一些中继邮件的中间主机。因此，在消息提交时（也在接收方）很难知道所有中间中继主机都已正确配置。要一致地配置所有系统并不容易，因为邮件消息传递系统使用的DNS配置比其他Internet服务更复杂。在从IPv4到IPv6的过渡期间，应更加注意IPv4/v6的互操作性。
This document talks about SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation.
本文档介绍IPv4/v6双堆栈环境中SMTP的操作经验。随着支持IPv6的SMTP服务器的部署，显然MX记录的某些配置对于稳定的双堆栈（IPv4和IPv6）SMTP操作是必要的。
This document does not discuss the problems encountered when the sending MTA and the receiving MTA have no common protocol (e.g., the sending MTA is IPv4-only while the receiving MTA is IPv6-only). Such a situation can be resolved by making either side dual-stack or by making either side use a protocol translator (see Appendix A on issues with protocol translator).
本文档不讨论发送MTA和接收MTA没有通用协议时遇到的问题（例如，发送MTA仅为IPv4，而接收MTA仅为IPv6）。这种情况可以通过使任意一方成为双栈或使任意一方使用协议转换器来解决（参见附录a关于协议转换器问题）。
Mail messages on the Internet are typically delivered based on the Domain Name System [Mockapetris]. MX RRs are looked up in DNS to retrieve the names of hosts running MTAs associated with the domain part of the mail address. DNS lookup uses IN class for both IPv4 and IPv6, and similarly IN MX records will be used for mail routing for both IPv4 and IPv6. Hosts which have IPv6 connectivity and also want to have the mails delivered using IPv6 must define IPv6 addresses for the host name as well as IPv4 addresses [Thomson].
互联网上的邮件通常基于域名系统[Mockapetris]进行传递。在DNS中查找MX RRs，以检索运行与邮件地址的域部分关联的MTA的主机的名称。DNS查找在类中用于IPv4和IPv6，类似地，在MX中，记录将用于IPv4和IPv6的邮件路由。具有IPv6连接并希望使用IPv6发送邮件的主机必须为主机名以及IPv4地址定义IPv6地址[Thomson]。
An MX RR has two parameters, a preference value and the name of destination host. The name of the destination host will be used to look up an IP address to initiate an SMTP connection [Partridge].
MX RR有两个参数，一个首选项值和目标主机的名称。目标主机的名称将用于查找IP地址以启动SMTP连接[Partridge]。
For example, an IPv6-only site may have the following DNS definitions:
例如，仅限IPv6的站点可能具有以下DNS定义：
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2
In the transition period from IPv4 to IPv6, there are many IPv4-only sites, and such sites will not have mail interoperability with IPv6- only sites. For the transition period, all mail domains should have MX records such that MX targets with IPv4 and IPv6 addresses exist, e.g.,
在从IPv4到IPv6的过渡期间，有许多只使用IPv4的站点，这些站点将无法与只使用IPv6的站点进行邮件互操作。对于过渡期，所有邮件域都应具有MX记录，以便存在具有IPv4和IPv6地址的MX目标，例如。，
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
IN A 192.0.2.1
mx10.example.org. IN AAAA 2001:db8:ffff::2
IN A 192.0.2.2
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN AAAA 2001:db8:ffff::1
IN A 192.0.2.1
mx10.example.org. IN AAAA 2001:db8:ffff::2
IN A 192.0.2.2
But, not every MX target may support dual-stack operation. Some host entries may have only A RRs or AAAA RRs:
但是，并非每个MX目标都支持双堆栈操作。某些主机条目可能只有RRs或AAAA RRs：
example.org. IN MX 1 mx1.example.org. IN MX 10 mx10.example.org. mx1.example.org. IN AAAA 2001:db8:ffff::1 mx10.example.org. IN A 192.0.2.1
example.org。在MX 1 mx1.example.org中。在MX 10 mx10.example.org中。mx1.example.org。在AAAA 2001:db8:ffff:：1 mx10.example.org中。在192.0.2.1中
The following sections discuss how the sender side should operate with IPv4/v6 combined RRs (section 3), and how the receiver should define RRs to maintain interoperability between IPv4 and IPv6 networks (section 4).
以下各节讨论发送方应如何使用IPv4/v6组合RRs（第3节），以及接收方应如何定义RRs以保持IPv4和IPv6网络之间的互操作性（第4节）。
In a dual-stack environment, MX records for a domain resemble the following:
在双堆栈环境中，域的MX记录类似于以下内容：
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1 ; dual-stack
IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only
example.org. IN MX 1 mx1.example.org.
IN MX 10 mx10.example.org.
mx1.example.org. IN A 192.0.2.1 ; dual-stack
IN AAAA 2001:db8:ffff::1
mx10.example.org. IN AAAA 2001:db8:ffff::2 ; IPv6-only
For a single MX record, there are multiple possible final states, including: (a) one or more A records for the IPv4 destination, (b) one or more AAAA records for the IPv6 destination, (c) a mixture of A
对于单个MX记录，有多个可能的最终状态，包括：（a）IPv4目标的一个或多个a记录，（b）IPv6目标的一个或多个AAAA记录，（c）以下状态的混合
and AAAA records. Because multiple MX records may be defined using different preference values, multiple addresses must be traversed based on multiple MXs. Domains without MX records and failure recovery cases must be handled properly as well.
和AAAA记录。由于可以使用不同的首选项值定义多个MX记录，因此必须基于多个MX遍历多个地址。没有MX记录的域和故障恢复案例也必须正确处理。
The algorithm for a dual-stack SMTP sender is basically the same as that for an IPv4-only sender, but it now includes AAAA lookups of MX records for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be treated just like multihomed destinations, as described in RFC 2821 [Klensin], section 5. When there is no destination address record found (i.e., the sender MTA is IPv4-only and there are no A records available), the case should be treated just like MX records without address records, and deliveries should fail.
双栈SMTP发送方的算法基本上与仅IPv4发送方的算法相同，但它现在包括针对SMTP-over-IPv6传递的MX记录的AAAA查找。IPv4/v6双栈目的地应与多宿目的地一样对待，如RFC 2821[Klensin]第5节所述。如果没有找到目标地址记录（即，发件人MTA仅为IPv4，没有可用的A记录），则应将该情况视为没有地址记录的MX记录，并且传递应失败。
; if the sender MTA is IPv4-only, email delivery to a.example.org
; should fail with the same error as deliveries to b.example.org.
a.example.org. IN MX 1 mx1.a.example.org.
mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only
b.example.org. IN MX 1 mx1.b.example.org. ; no address
; if the sender MTA is IPv4-only, email delivery to a.example.org
; should fail with the same error as deliveries to b.example.org.
a.example.org. IN MX 1 mx1.a.example.org.
mx1.a.example.org. IN AAAA 2001:db8:ffff::1 ; IPv6-only
b.example.org. IN MX 1 mx1.b.example.org. ; no address
An algorithm for a dual-stack SMTP sender is as follows:
双堆栈SMTP发件人的算法如下所示：
(1) Lookup the MX record for the destination domain. If a CNAME record is returned, go to the top of step (1) with replacing the destination domain by the query's result. If any MX records are returned, go to step (2) with the query's result (explicit MX). If NODATA (i.e., empty answer with NOERROR(0) RCODE) is returned, there is no MX record but the name is valid. Assume that there is a record like "name. IN MX 0 name." (implicit MX) and go to step (3). If HOST_NOT_FOUND (i.e., empty answer with NXDOMAIN(3) RCODE) is returned, there is no such domain. Raise a permanent email delivery failure. Finish. If SERVFAIL is returned, retry after a certain period of time.
(1) 查找目标域的MX记录。如果返回CNAME记录，请转到步骤（1）顶部，用查询结果替换目标域。如果返回了任何MX记录，请转到步骤（2）并显示查询结果（显式MX）。如果返回NODATA（即带有NOERROR（0）RCODE的空应答），则没有MX记录，但名称有效。假设存在类似“name.IN MX 0 name.”（隐式MX）的记录，并转至步骤（3）。如果未找到主机（即，返回带有NXDOMAIN（3）RCODE的空答案），则不存在此类域。引发永久性电子邮件传递失败。完成如果返回SERVFAIL，请在一段时间后重试。
(2) Compare each host name in MX records with the names of the sending host. If there is match, drop MX records which have an equal or larger value than the lowest-preference matching MX record (including itself). If multiple MX records remain, sort the MX records in ascending order based on their preference values. Loop over steps (3) to (9) on each host name in MX records in a sequence. If no MX records remain, the sending host must be the primary MX host. Other routing rules should be applied. Finish.
(2) 将MX记录中的每个主机名与发送主机的名称进行比较。如果存在匹配项，则删除值等于或大于最低首选项匹配MX记录（包括其本身）的MX记录。如果仍有多条MX记录，请根据其首选项值按升序对MX记录进行排序。按顺序在MX记录中的每个主机名上循环步骤（3）到（9）。如果没有MX记录保留，则发送主机必须是主MX主机。应应用其他路由规则。完成
(3) If the sending MTA has IPv4 capability, lookup the A records. Keep the resulting addresses until step (5).
(3) 如果发送MTA具有IPv4功能，请查找A记录。将结果地址保留到步骤（5）。
(4) If the sending MTA has IPv6 capability, lookup the AAAA records.
(4) 如果发送MTA具有IPv6功能，请查找AAAA记录。
NOTE: IPv6 addresses for hosts defined by MX records may be informed in an additional information section of the DNS queries' result as well as IPv4 addresses. If there is no additional address information for the MX hosts, separate queries for A or AAAA records should be sent. There is no way to query A and AAAA records at once in current DNS implementation.
注意：由MX记录定义的主机的IPv6地址可能会在DNS查询结果的附加信息部分以及IPv4地址中通知。如果没有MX主机的其他地址信息，则应发送对A或AAAA记录的单独查询。在当前DNS实现中，无法同时查询A和AAAA记录。
(5) If there is no A and no AAAA record present, try the next MX record (go to step (3)). Note that the next MX record could have the same preference.
(5) 如果没有A和AAAA记录，请尝试下一条MX记录（转至步骤（3））。请注意，下一个MX记录可能具有相同的首选项。
NOTE: If one or more address records are found, an implementation may sort addresses based on the implementation's preference of A or AAAA records. To encourage the transition from IPv4 SMTP to IPv6 SMTP, AAAA records should take precedence. The sorting may only reorder addresses from MX records of the same preference. RFC 2821 section 5 paragraph 4 suggests randomization of destination addresses. Randomization should only happen among A records, and among AAAA records (do not mix A and AAAA records).
注意：如果找到一个或多个地址记录，则实现可以根据实现对A或AAAA记录的首选项对地址进行排序。为了鼓励从IPv4 SMTP过渡到IPv6 SMTP，应优先考虑AAAA记录。排序只能从相同首选项的MX记录中重新排序地址。RFC 2821第5节第4段建议对目的地址进行随机化。随机化只应发生在A记录和AAAA记录之间（不要混合A和AAAA记录）。
(6) For each of the addresses, loop over steps (7) to (9).
(6) 对于每个地址，循环步骤（7）到（9）。
(7) Try to make a TCP connection to the destination's SMTP port (25). The client needs to follow timeouts documented in RFC 2821 section 4.5.3.2. If successful, go to step (9).
(7) 尝试与目标SMTP端口建立TCP连接（25）。客户需要遵守RFC 2821第4.5.3.2节中记录的超时。如果成功，请转至步骤（9）。
(8) If unsuccessful and there is another available address, try the next available address. Go to step (7). If all addresses are not reachable and if a list of MX records is being traversed, try the next MX record (go to step (3)). If there is no list of MX records, or if the end of the list of MX records has been reached, raise a temporary email delivery failure. Finish.
(8) 如果不成功且存在其他可用地址，请尝试下一个可用地址。转至步骤（7）。如果无法访问所有地址，并且正在遍历MX记录列表，请尝试下一条MX记录（转至步骤（3））。如果没有MX记录列表，或者如果已到达MX记录列表的末尾，则引发临时电子邮件发送失败。完成
(9) Attempt to deliver the email over the connection established, as specified in RFC 2821. If a transient failure condition is reported, try the next MX record (go to step (3)). If an error condition is reported, raise a permanent email delivery error, and do not try further MX records. Finish. If successful, SMTP delivery has succeeded. Finish.
(9) 按照RFC 2821中的规定，尝试通过已建立的连接发送电子邮件。如果报告了瞬态故障情况，请尝试下一个MX记录（转至步骤（3））。如果报告了错误情况，请引发永久性电子邮件传递错误，并且不要尝试进一步的MX记录。完成如果成功，SMTP传递已成功。完成
If a site has dual-stack reachability, the site should configure both A and AAAA records for its MX hosts (NOTE: MX hosts can be outside of the site). This will help both IPv4 and IPv6 senders in reaching the site efficiently.
如果站点具有双堆栈可访问性，则站点应为其MX主机配置a和AAAA记录（注意：MX主机可以在站点外部）。这将有助于IPv4和IPv6发送方高效地到达站点。
When registering MX records in a DNS database in a dual-stack environment, reachability between MX hosts must be considered carefully. Suppose all inbound email is to be gathered at the primary MX host, "mx1.example.org.":
在双堆栈环境中在DNS数据库中注册MX记录时，必须仔细考虑MX主机之间的可达性。假设所有入站电子邮件都收集在主MX主机“mx1.example.org”上：
example.org. IN MX 1 mx1.example.org. IN MX 10 mx10.example.org. IN MX 100 mx100.example.org.
example.org。在MX 1 mx1.example.org中。在MX 10 mx10.example.org中。在MX 100 mx100.example.org中。
If "mx1.example.org" is an IPv6-only node, and the others are IPv4- only nodes, there is no reachability between the primary MX host and the other MX hosts. When email reaches one of the lower MX hosts, it cannot be relayed to the primary MX host based on MX preferencing mechanism. Therefore, mx1.example.org will not be able to collect all the emails (unless there is another transport mechanism(s) between lower-preference MX hosts and mx1.example.org).
如果“mx1.example.org”是仅限IPv6的节点，而其他节点是仅限IPv4的节点，则主MX主机和其他MX主机之间不存在可访问性。当电子邮件到达一个较低的MX主机时，它无法基于MX首选机制中继到主MX主机。因此，mx1.example.org将无法收集所有电子邮件（除非在较低偏好的MX主机和mx1.example.org之间存在另一种传输机制）。
; This configuration is troublesome. ; No secondary MX can reach mx1.example.org. example.org. IN MX 1 mx1.example.org. ; IPv6-only IN MX 10 mx10.example.org. ; IPv4-only IN MX 100 mx100.example.org. ; IPv4-only
; 这种配置很麻烦；没有辅助MX可以访问mx1.example.org。example.org。在MX 1 mx1.example.org中；仅在MX 10 mx10.example.org中使用IPv6；仅在MX 100 mx100.example.org中使用IPv4；仅IPv4
The easiest possible configuration is to configure the primary MX host as a dual-stack node. By doing so, secondary MX hosts will have no problem reaching the primary MX host.
最简单的配置是将主MX主机配置为双堆栈节点。通过这样做，辅助MX主机在到达主MX主机时不会出现问题。
; This configuration works well.
; The secondary MX hosts are able to relay email to the primary MX
; host without any problems.
example.org. IN MX 1 mx1.example.org. ; dual-stack
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv6-only
; This configuration works well.
; The secondary MX hosts are able to relay email to the primary MX
; host without any problems.
example.org. IN MX 1 mx1.example.org. ; dual-stack
IN MX 10 mx10.example.org. ; IPv4-only
IN MX 100 mx100.example.org. ; IPv6-only
It may not be necessary for the primary MX host and lower MX hosts to directly reach one another with IPv4 or IPv6 transport. For example, it is possible to establish a routing path with UUCP or an IPv4/v6
主MX主机和较低级别的MX主机可能不需要通过IPv4或IPv6传输直接相互连接。例如，可以使用UUCP或IPv4/v6建立路由路径
translator. It is also possible to drop messages into a single mailbox with shared storage using NFS or something else offered by a dual-stack server. It is the receiver site's responsibility that all messages delivered to MX hosts arrive at the recipient's mail drop. In such cases, a dual-stack MX host may not be listed in the MX list.
翻译还可以使用NFS或双堆栈服务器提供的其他功能将邮件放入具有共享存储的单个邮箱中。接收方站点负责将所有发送到MX主机的邮件发送到接收方的邮件投递点。在这种情况下，双栈MX主机可能不会列在MX列表中。
Many of the existing IPv6-ready MTA's appear to work in the way documented in section 3.
许多现有的支持IPv6的MTA的工作方式如第3节所述。
There were, however, cases where IPv6-ready MTA's were confused by broken DNS servers. When attempting to obtain a canonical hostname, some broken name servers return SERVFAIL (RCODE 2), a temporary failure on AAAA record lookups. Upon this temporary failure, the email is queued for a later attempt. In the interest of IPv4/v6 interoperability, these broken DNS servers should be fixed. A document by Yasuhiro Morishita [Morishita] has more detail on misconfigured/misbehaving DNS servers and their negative side effects.
然而，在某些情况下，IPv6就绪MTA被损坏的DNS服务器搞混了。当尝试获取规范主机名时，一些断开的名称服务器返回SERVFAIL（RCODE 2），这是AAAA记录查找中的临时故障。一旦出现此临时故障，电子邮件将排队等待稍后的尝试。为了实现IPv4/v6的互操作性，应该修复这些损坏的DNS服务器。森田康弘（Yasuhiro Morishita）[Morishita]的一份文件更详细地介绍了错误配置/行为不当的DNS服务器及其负面影响。
o How should scoped addresses (i.e., link-local addresses) in email addresses be interpreted on MTA's? We suggest prohibiting the use of IPv6 address literals in destination specification.
o MTA应如何解释电子邮件地址中的作用域地址（即链接本地地址）？我们建议禁止在目标规范中使用IPv6地址文本。
o A future specification of SMTP (revision of RFC 2821) should be updated to include IPv6 concerns presented in this memo, such as (1) the additional query of AAAA RRs where A RRs and/or MX RRs are suggested, and (2) the ordering between IPv6 destination and IPv4 destination.
o 应更新SMTP的未来规范（RFC 2821的修订版），以包括本备忘录中提出的IPv6问题，例如（1）建议使用RRs和/或MX RRs的AAAA RRs的附加查询，以及（2）IPv6目标和IPv4目标之间的排序。
It could be problematic if the route-addr email address format [Crocker] (or "obs-route" address format in [Resnick]) is used across multiple scope zones. MTAs would need to reject email with route-addr email address formats that cross scope zone borders.
如果路由地址电子邮件地址格式[Crocker]（或[Resnick]中的“obs路由”地址格式）跨多个作用域使用，则可能会出现问题。MTA将需要拒绝使用route addr电子邮件地址格式的跨作用域边界的电子邮件。
IPv6-only MTA to IPv4-only MTA cases could use help from IPv6-to-IPv4 translators such as [Hagino]. Normally there are no special SMTP considerations for translators needed. If there is SMTP traffic from an IPv6 MTA to an IPv4 MTA over an IPv6-to-IPv4 translator, the IPv4 MTA will consider this normal IPv4 SMTP traffic.
仅限IPv6的MTA到仅限IPv4的MTA案例可以使用来自IPv6到IPv4转换器（如[Hagino]）的帮助。通常，对于所需的翻译人员，没有特殊的SMTP注意事项。如果在IPv6到IPv4转换器上存在从IPv6 MTA到IPv4MTA的SMTP业务，则IPv4 MTA将考虑此正常IPv4 SMTP业务。
Protocols like IDENT [St.Johns] may require special consideration when translators are used. Also, there are MTAs which perform strict checks on the SMTP HELO/EHLO "domain" parameter (perform reverse/forward DNS lookups and see if the "domain" really associates to the SMTP client's IP address). In such a case, we need a special consideration when translators will be used (for instance, override "domain" parameter by translator's FQDN/address).
在使用翻译器时，像IDENT[St.Johns]这样的协议可能需要特别考虑。此外，还有MTA对SMTP HELO/EHLO“domain”参数执行严格检查（执行反向/正向DNS查找，查看“domain”是否真的与SMTP客户端的IP地址关联）。在这种情况下，我们需要特别考虑何时使用转换器（例如，通过转换器的FQDN/地址覆盖“domain”参数）。
Even without a translator, it seems that there are some MTA implementations in the wild which send IPv6 address literals in a HELO/EHLO message (like "HELO [IPv6:blah]"), even when it is using IPv4 transport, or vice versa. If the SMTP peer is IPv4-only, it won't understand the "[IPv6:blah]" syntax and mails won't go out of the (broken) MTA. These implementations have to be corrected.
即使没有转换器，在野外似乎也有一些MTA实现在HELO/EHLO消息中发送IPv6地址文本（如“HELO[IPv6:blah]”），即使它使用IPv4传输，反之亦然。如果SMTP对等方仅为IPv4，它将无法理解“[IPv6:blah]”语法，邮件也不会从（损坏的）MTA中发出。必须纠正这些实现。
Normative References
规范性引用文件
[Mockapetris] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[Mockapetris]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[Thomson] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[Thomson]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[Partridge] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986.
[鹧鸪]鹧鸪，C.，“邮件路由和域系统”，STD 10，RFC 974，1986年1月。
[Klensin] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[Klensin]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[Crocker] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[Crocker]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[Resnick] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[Resnick]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001.
[Hagino]Hagino，J.和H.Snyder，“站点出口路由器的IPv6多主支持”，RFC 3178，2001年10月。
[St.Johns] Johns, M. St., "Identification Protocol", RFC 1413, February 1993.
[圣约翰]约翰，M.圣约翰，“识别协议”，RFC 1413，1993年2月。
Informative References
资料性引用
[Morishita] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS Queries for IPv6 Addresses", Work in Progress, June 2003.
[Morishita]Morishita，Y.和T.Jinmei，“针对IPv6地址DNS查询的常见错误行为”，正在进行的工作，2003年6月。
Acknowledgements
致谢
This document was written based on discussions with Japanese IPv6 users and help from the WIDE research group. Here is a (probably incomplete) list of people who contributed to the document: Gregory Neil Shapiro, Arnt Gulbrandsen, Mohsen Souissi, JJ Behrens, John C Klensin, Michael A. Patton, Robert Elz, Dean Strik, Pekka Savola, and Rob Austein.
本文档是根据与日本IPv6用户的讨论以及广域研究小组的帮助编写的。以下是一份（可能不完整）参与该文件的人员名单：格雷戈里·尼尔·夏皮罗、阿恩特·古尔布兰森、莫森·苏伊西、JJ·贝伦斯、约翰·C·克莱辛、迈克尔·a·巴顿、罗伯特·埃尔兹、迪安·斯特里克、佩卡·萨沃拉和罗伯·奥斯汀。
Authors' Addresses
作者地址
Motonori NAKAMURA Academic Center for Computing and Media Studies, Kyoto University Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN
日本京都本岛大学本岛计算研究中心
Fax: +81-75-753-7450
EMail: motonori@media.kyoto-u.ac.jp
Fax: +81-75-753-7450
EMail: motonori@media.kyoto-u.ac.jp
Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. 1-105, Kanda Jinbo-cho, Chiyoda-ku,Tokyo 101-0051, JAPAN
Jun ichiro itojun HAGINO研究实验室，日本互联网倡议公司，日本千代田区神田金波町1-105号，东京101-0051
Phone: +81-3-5205-6464
Fax: +81-3-5205-6466
EMail: itojun@iijlab.net
Phone: +81-3-5205-6464
Fax: +81-3-5205-6466
EMail: itojun@iijlab.net
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 at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见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编辑功能的资金目前由互联网协会提供。