RFC 3974 - SMTP Operational Experience in Mixed IPv4/v6 Environments 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3974
タイトル : RFC 3974 - IPv4/v6 混合環境における SMTP の運用経験
翻訳編集 : 自動生成

[要約] RFC 3974は、IPv4とIPv6の混在環境でのSMTPの運用経験に関する情報を提供しています。このRFCの目的は、IPv4とIPv6の両方をサポートするSMTPシステムの設計と運用に関するガイドラインを提供することです。

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

IPv4/v6 混合環境における SMTP の運用経験

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も指定しません。このメモの配布は無制限です。

著作権表示

著作権 (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 は、どのレベルのインターネット標準の候補でもありません。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 を参照する必要があることに注意してください。この文書は 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 サーバーが展開されるにつれて、安定したデュアルスタック (IPv4 および IPv6) SMTP 動作には MX レコードの特定の構成が必要であることが明らかになりました。この文書は、IPv4 SMTP と IPv6 SMTP の間の移行期間における既存の問題を明らかにします。また、安定した IPv4/v6 SMTP 動作のための動作要件も定義します。

This document does not define any new protocol.

この文書は新しいプロトコルを定義するものではありません。

1. Introduction

1. はじめに

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 サーバーが展開されるにつれて、安定したデュアルスタック (IPv4 および IPv6) SMTP 動作には MX レコードの特定の構成が必要であることが明らかになりました。

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 を参照)。

2. Basic DNS Resource Record Definitions for Mail Routing

2. メールルーティングのための基本的な DNS リソースレコード定義

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 は DNS で検索され、メールアドレスのドメイン部分に関連付けられた MTA を実行しているホストの名前が取得されます。DNS ルックアップでは、IPv4 と IPv6 の両方で IN クラスが使用され、同様に、IPv4 と IPv6 の両方のメールルーティングには IN MX レコードが使用されます。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 には、プリファレンス値と宛先ホストの名前という 2 つのパラメーターがあります。宛先ホストの名前は、SMTP 接続を開始するための IP アドレスの検索に使用されます [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

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

But, not every MX target may support dual-stack operation. Some host entries may have only A RRs or AAAA RRs:

ただし、すべての MX ターゲットがデュアルスタック動作をサポートしているわけではありません。一部のホストエントリには、A 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

例.org。IN 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 を組み合わせた RR でどのように動作するか (セクション 3)、受信側が IPv4 と IPv6 ネットワーク間の相互運用性を維持するために RR を定義する方法 (セクション 4) について説明します。

3. SMTP Sender Algorithm in a Dual-Stack Environment

3. デュアルスタック環境における SMTP 送信者アルゴリズム

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

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.

単一の MX レコードの場合、次のような複数の最終状態が考えられます: (a) IPv4 宛先の 1 つ以上の A レコード、(b) IPv6 宛先の 1 つ以上の AAAA レコード、(c) A と 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

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 レコードはありませんが、名前は有効です。「name.IN MX 0 name」のようなレコードがあったとします。(暗黙的な 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 レコードの各ホスト名に対して手順 (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 アドレスは、IPv4 アドレスと同様に、DNS クエリの結果の追加情報セクションで通知される場合があります。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).

注: 1 つ以上のアドレスレコードが見つかった場合、実装では 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 ポート (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 配信は成功しています。仕上げる。

4. MX Configuration in the Recipient Domain

4. 受信者ドメインの MX 構成

4.1. Ensuring Reachability for Both Protocol Versions

4.1. 両方のプロトコルバージョンの到達可能性を確保する

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 の両方の送信者が効率的にサイトに到達できるようになります。

4.2. Reachability Between the Primary and Secondary MX

4.2. プライマリ MX とセカンダリ MX 間の到達可能性

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.

例.org。IN 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 に到達できません。例.org。IN MX 1 mx1.example.org。;IPv6 のみ IN MX 10 mx10.example.org。;IPv4 のみ IN MX 100 mx100.example.org。;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

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 リストに表示されないことがあります。

5. Operational Experience

5. 運用経験

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 サーバーによって混乱するケースがありました。正規のホスト名を取得しようとすると、一部の壊れたネームサーバーは、AAAA レコード検索の一時的な失敗である SERVFAIL (RCODE 2) を返します。この一時的な失敗が発生すると、電子メールは後の試行のためにキューに入れられます。IPv4/v6 の相互運用性を確保するには、これらの壊れた DNS サーバーを修正する必要があります。森下泰弘 [森下] によるドキュメントには、DNS サーバーの構成ミスや動作不良とその悪影響について詳しく記載されています。

6. Open Issues

6. 未解決の問題

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) A RR および/または MX RR が提案される AAAA RR の追加クエリなど、このメモで提示されている IPv6 の懸念事項を含むように更新される必要があります。IPv6 宛先と IPv4 宛先間の順序付け。

7. Security Considerations

7. セキュリティに関する考慮事項

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.

Route-addr 電子メールアドレス形式 [Crocker] (または [Resnick] の "obs-route" アドレス形式) が複数のスコープゾーンにわたって使用されている場合、問題が発生する可能性があります。MTA は、スコープゾーンの境界を越える、route-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 へのケースでは、[Hagino] などの IPv6 から IPv4 への変換者の支援を利用できます。通常、トランスレータに関して SMTP に関する特別な考慮事項は必要ありません。IPv6 から IPv4 へのトランスレータを介して IPv6 MTA から IPv4 MTA への 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] のようなプロトコルでは、トランスレーターを使用するときに特別な考慮が必要になる場合があります。また、SMTP HELO/EHLO の「ドメイン」パラメータを厳密にチェックする MTA もあります (DNS 逆引き/正引き検索を実行し、「ドメイン」が本当に SMTP クライアントの IP アドレスに関連付けられているかどうかを確認します)。このような場合、トランスレータを使用する際には特別な考慮が必要です (たとえば、トランスレータの 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/EHLO メッセージ (「HELO [IPv6:blah]」など) で IPv6 アドレスリテラルを送信する、またはその逆の MTA 実装が世に出ているようです。。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 1035、1987 年 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.

[Partridge] Partridge, C.、「メールルーティングとドメインシステム」、STD 10、RFC 974、1986 年 1 月。

[Klensin] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[Klensin] Klensin, J.、「Simple Mail Transfer Protocol」、RFC 2821、2001 年 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.

[ハギノ] ハギノ、J.、H. スナイダー、「サイト出口ルータでの IPv6 マルチホーミングサポート」、RFC 3178、2001 年 10 月。

[St.Johns] Johns, M. St., "Identification Protocol", RFC 1413, February 1993.

[St.Johns] Johns, M. St.、「Identification Protocol」、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. 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 ユーザーとの議論と WIDE 研究グループの支援に基づいて作成されました。以下は、この文書に貢献した人々の (おそらく不完全な) リストです: Gregory Neil Shapiro、Arnt Gulbrandsen、Mohsen Souissi、JJ Behrens、John C Klensin、Michael A. Patton、Robert Elz、Dean Strik、Pekka Savola、Rob Austein。

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

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

Full Copyright Statement

完全な著作権に関する声明

著作権 (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 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ 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 エディター機能の資金は現在、インターネット協会によって提供されています。