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
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.
このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、そして公開する決定が展開プロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。この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でMX処理アルゴリズムの適用の具体的な解釈、第5節が含まれています。実装者は、彼らが完全なアルゴリズムについては、RFC 2821を参照しなければならないと警告しています。この文書は、あいまいさの場合には、RFC 2821は権威ある、RFC 2821の完全な言い換えとみなされ、すべきではありません。
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とIPv6 SMTP 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の設定は、他のインターネットサービスよりも複雑であるので、一貫してすべてのシステムを構成することは容易ではありません。 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は、IPv6のみであるが、例えば、送信MTAは、IPv4のみです）。このような状況は、どちらかの側デュアルスタックを作ることによってか、どちらかの側が（プロトコルトランスレータの問題については、付録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]に基づいて配信されています。 MX RRはメールアドレスのドメイン部分に関連付けられているのMTAを実行しているホストの名前を取得するために、DNSで検索されています。 DNSルックアップは、IPv4とIPv6の両方のためのクラスで使用し、同様にMXレコードにIPv4とIPv6の両方のためのメールルーティングのために使用されます。 IPv6接続を有し、またメールがIPv6を使用して配信したいホストは、ホスト名のIPv6アドレスだけでなく、IPv4アドレス[トムソン]を定義する必要があります。
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は、2つのパラメータ、嗜好値と宛先ホストの名前を有しています。宛先ホストの名前は、SMTP接続の[ヤマウズラ]を開始するIPアドレスをルックアップするために使用されます。
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。 MX 1 mx1.example.org、IN。 MX 10 mx10.example.org、IN。 mx1.example.org。 AAAA 2001年：DB8：FFFF :: 1 mx10.example.org。 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-サイトのみでのメールの相互運用性を持っていません。移行期間のために、すべてのメールドメインは、IPv4アドレスとIPv6アドレスとMXのターゲットが存在すること、例えば、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。 MX 1 mx1.example.org、IN。 MX 10 mx10.example.org、IN。 mx1.example.org。 AAAA 2001年：DB8：FFFF :: 1のA 192.0.2.1 mx10.example.org。 AAAA 2001年：DB8：192.0.2.2、IN FFFF :: 2
But, not every MX target may support dual-stack operation. Some host entries may have only A RRs or AAAA RRs:
しかし、必ずしもすべてのMXターゲットはデュアルスタック操作をサポートすることができます。いくつかのホストエントリは、唯一のRRまたはAAAA RRを持っていることがあります。
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、IN。 MX 10 mx10.example.org、IN。 mx1.example.org。 AAAA 2001年：DB8：FFFF :: 1 mx10.example.org。 192.0.2.1、IN
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の組み合わせのRR（セクション3）で動作する方法を議論し、受信機は、IPv4とIPv6ネットワーク（セクション4）との間の相互運用性を維持するためにRRを定義する方法。
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。 MX 1 mx1.example.org、IN。 MX 10 mx10.example.org、IN。 mx1.example.org。 192.0.2.1、IN; AAAA 2001年にデュアルスタック：DB8：FFFF :: 1 mx10.example.org。 AAAA 2001年：DB8：FFFF :: 2。 IPv6のみ
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 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.
IPv4宛先のための（a）は、一つ以上のAレコード、IPv6宛先のための（b）1種以上のAAAAレコード、（c）のAとAAAAの混合物：単MXレコードに対して、を含む複数の可能な最終状態があります記録。複数の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オーバーのIPv6配信のためのMXレコードのAAAA検索を含んでいます。 RFCに記載されたIPv4 / v6のデュアルスタック先は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
;送信者のMTAはa.example.orgにIPv4のみ、電子メール配信の場合は、 b.example.orgする配達と同じエラーで失敗しなければなりません。 a.example.org。 MX 1 mx1.a.example.org、IN。 mx1.a.example.org。 AAAA 2001年：DB8：FFFF :: 1。 IPv6のみb.example.org。 MX 1 mx1.b.example.org、IN。 ;アドレスなし
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レコードが返された場合、クエリの結果（明示的なMX）と（2）に進みます。 NODATAは（すなわち、NOERROR（0）RCODEとの空の答え）が返された場合、そこにはMXレコードではありませんが、名前は有効です。以下のようなレコードがあると仮定し、「名前が。MX 0名に。」 （暗黙のMX）と（3）に進みます。 HOST_NOT_FOUND（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レコード内の各ホスト名に（9）〜工程（3）をループ。 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.
(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.
何AなしAAAAレコードが存在しない場合は（5）、（（3）に進みます）次のMXレコードを試してみてください。次の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).
(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ポート（25）へのTCP接続を行うようにしてください。クライアントは、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、IN。 MX 10 mx10.example.org、IN。 MX 100 mx100.example.org、IN。
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のpreferencing機構に基づいて、プライマリMXホストに中継することができません。 （低優先MXホストとmx1.example.orgの間に別の移送機構（単数または複数）がない限り）そのため、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、IN。 ; IPv6のみのMX 10 mx10.example.org、IN。 ; MX 100 mx100.example.org、IN 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
;この構成はうまく動作します。 ;二次MXホストは、プライマリMXに電子メールを中継することができます。何の問題もなくホスト。 example.org。 MX 1 mx1.example.org、IN。 ; MX 10 mx10.example.orgデュアルスタック。 ; MX 100 mx100.example.org、IN IPv4のみ。 ; IPv6のみ
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 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.
これは、プライマリMXホストのために必要ではないかもしれないと下部MX直接IPv4またはIPv6トランスポートと相互に到達するためにホスト。例えば、UUCPまたはIPv4 / v6のトランスレータを用いてルーティング経路を確立することが可能です。 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サーバを固定してください。康弘森下[森下]で文書が誤って設定/誤動作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の改定）の将来の仕様は、例えば（1）追加のRRおよび/またはMXのRRが提案されているAAAA資源レコードの問合せ、及び、このメモに提示IPv6の懸念を含むように更新されるべきである（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.
ルートADDRメールアドレス形式[クロッカー]（[レズニック]または「OBSルート」アドレス形式）は、複数のスコープゾーンにわたって使用されている場合には問題となり得ます。 MTAがスコープゾーンの境界線を越えるルート-addrにメールアドレス形式でメールを拒否する必要があります。
Appendix A. Considerations on Translators
翻訳者の付録A.の考慮事項
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翻訳者からの助けを使用することができます。通常、必要に応じて、翻訳者のための特別なSMTPの考慮事項はありません。 SMTPトラフィックがIPv6からIPv4トランスレーター以上のIPv4 MTAへのIPv6のMTAから存在する場合は、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]のようなプロトコルは、特別な配慮が必要な場合があります。また、SMTP HELO / EHLO「ドメイン」パラメータ（リバース/フォワードDNSルックアップを実行し、「ドメイン」は、実際にSMTPクライアントのIPアドレスに関連付けられている場合を参照）に厳格なチェックを行うMTAがあります。そのような場合には、我々は、翻訳者が（翻訳者のFQDN /アドレスで例えば、オーバーライド「ドメイン」パラメータ）が使用されます特別な配慮を必要とします。
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.
それはIPv4トランスポートを使用して、またはその逆であっても、：さえ翻訳せず、（「HELO [何とかのIPv6]」のような）HELO / EHLOメッセージ内のIPv6アドレスリテラルを送る野生の一部のMTAの実装が存在すると思われます。 SMTPピアがIPv4のみの場合は、それが理解できないだろう「[IPv6の：何とか]」構文とメールを（壊れた）MTAの外に行くことはありません。これらの実装は、修正する必要があります。
Normative References
引用規格
[Mockapetris] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
【Mockapetris] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[Thomson] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[トムソン]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、RFC 3596、2003年10月 "DNSの拡張機能は、IPバージョン6をサポートします"。
[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 2821、2001年4月。
[Crocker] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[クロッカー]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[Resnick] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[レズニック]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001.
[萩野]萩野、J.とH.スナイダー、 "サイト出口ルータでIPv6のマルチホーミングのサポート"、RFC 3178、2001年10月。
[St.Johns] Johns, M. St., "Identification Protocol", RFC 1413, February 1993.
【St.Johns】ジョーンズ、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.
[森下]森下、Y.とT.神明、「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.
この文書は、WIDE研究グループから、日本のIPv6ユーザーとヘルプとの協議に基づいて書かれていました。ここでは、文書に貢献し、人々の（おそらく不完全な）リストは、次のとおりです。グレゴリー・ニールシャピロ、ARNT Gulbrandsenの、モフセンSouissi、JJ・ベーレンス、ジョン・C Klensin、マイケルA.パットン、ロバート・エルツ、ディーンStrik、ペッカSavola、およびロブAusteinと。
Authors' Addresses
著者のアドレス
Motonori NAKAMURA Academic Center for Computing and Media Studies, Kyoto University Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN
コンピューティングとメディア教育元紀中村学術センター、京都大学吉田本町、左京、京都606-8501、JAPAN
Fax: +81-75-753-7450 EMail: motonori@media.kyoto-u.ac.jp
ファックス：+ 81-75-753-7450 Eメール：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
じゅんーいちろ いとじゅん はぎの れせあｒｃｈ ぁぼらとｒｙ、 いんてｒねｔ いにちあちゔぇ じゃぱん いんｃ。 １ー１０５、 かんだ じんぼーちょ、 ちよだーく、ときょ １０１ー００５１、 じゃぱん
Phone: +81-3-5205-6464 Fax: +81-3-5205-6466 EMail: itojun@iijlab.net
電話：+ 81-3-5205-6464ファックス：+ 81-3-5205-6466 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。