RFC3974 日本語訳

Network Working Group                                        M. Nakamura
Request for Comments: 3974                              Kyoto University
Category: Informational                                        J. Hagino
                                                 IIJ Research Laboratory
                                                            January 2005

コメントを求めるワーキンググループM.中村の要求をネットワークでつないでください: 3974年の京都大学カテゴリ: 情報のJ.Hagino IIJ研究所2005年1月

       SMTP Operational Experience in Mixed IPv4/v6 Environments

Mixed 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.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはRFC2821のMX処理アルゴリズムの適用性の特定の解釈を含んでいます、セクション5、デュアルスタック環境に。 作成者は彼らは完全なアルゴリズムの参照RFC2821がそうしなければならないと警告されます。 このドキュメントがRFC2821の完全な再声明であることは考えられないことであり、あいまいさの場合にRFC2821は正式です。

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操作のための操作上の要件を定義します。

Nakamura & Hagino            Informational                      [Page 1]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[1ページ]のRFC3974SMTP

   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.

submitterと最終的な受信機とのダイレクト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専用です)行きあたられる問題について議論しません。 どちらのサイドデュアルスタックも作るか、またはどちらの側にもプロトコル翻訳者を使用させることによって、そのような状況を決議できます(プロトコル翻訳者の問題のAppendix 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 RRsは、ホストの名前を検索するために郵便の宛先のドメイン部分に関連しているMTAsを走らせながら、DNSで見上げられます。 DNSルックアップはIPv4とIPv6の両方にINのクラスを使用します、そして、同様に、IN MX記録はIPv4とIPv6の両方のためのメールルーティングに使用されるでしょう。 IPv6の接続性を持って、またIPv6を使用することでメールを送って頂きたいホストは、IPv4アドレス[トムソン]と同様にホスト名のためのIPv6アドレスを定義しなければなりません。

   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アドレスを調べるのに使用されるでしょう。

Nakamura & Hagino            Informational                      [Page 2]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[2ページ]のRFC3974SMTP

   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 MX1mx1.example.org。 IN MX10mx10.example.org. mx1.example.org。 AAAA2001:db8:ffffで:、:1 mx10.example.org。 AAAA2001: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があるMX目標とIPv6アドレスが例えば存在しています。

      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 MX1mx1.example.org。 IN MX10mx10.example.org. mx1.example.org。 AAAA2001:db8:ffffで:、:1 IN A192.0.2.1mx10.example.org。 AAAA2001:db8:ffffで:、:A192.0.2における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 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。 IN MX1mx1.example.org。 IN MX10mx10.example.org. mx1.example.org。 AAAA2001:db8:ffffで:、:1 mx10.example.org。 IN A192.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)をどのように、操作するはずであるか、そして、受信機がIPv4とIPv6ネットワーク(セクション4)の間の相互運用性を維持するためにどのようにRRsを定義するはずであるかを論じます。

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

example.org。 IN MX1mx1.example.org。 IN MX10mx10.example.org. mx1.example.org。 IN A192.0.2、.1。 デュアルスタックIN AAAA2001:db8:ffff:、:1 mx10.example.org。 AAAA2001: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

ただ一つのMX記録のために、である:複数の可能な最終的な州があります。 (a) (b) IPv4の目的地のための1つ以上のA記録、1AAAAがIPv6の目的地、(c)のためにAの混合物を記録します。

Nakamura & Hagino            Informational                      [Page 3]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[3ページ]のRFC3974SMTP

   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記録が異なった好みの値を使用することで定義されるかもしれないので、複数のMXsに基づいて複数のアドレスを横断しなければなりません。 また、適切に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ルックアップを含んでいます。 IPv4/v6デュアルスタックの目的地はまさしく「マルチ-家へ帰」っている目的地のようにRFC2821[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がIPv4専用であるなら、a.example.orgに配送をメールしてください。 配送と同じ誤りに応じて、b.example.org a.example.orgに失敗するべきです。 IN MX1mx1.a. example.org mx1.a. example.org。 AAAA2001:db8:ffffで:、:1 ; IPv6だけb.example.org。 IN MX1mx1.b. example.org。 ; アドレスがありません。

   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記録が全くありませんが、名前は妥当です。 「名前」のような記録があると仮定してください。 「IN MX0名。」 (内在しているMX) そして、(3)を踏みに行ってください。 _ではなく、HOST_であるなら、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)まで結果として起こるアドレスを保管してください。

Nakamura & Hagino            Informational                      [Page 4]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[4ページ]のRFC3974SMTP

   (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記録からの追加注文アドレスだけがそうするかもしれません。 RFC2821部5 パラグラフ4は送付先アドレスの無作為化を示します。 無作為化はA記録の中と、そして、AAAA記録の中で起こるだけであるべきです(AとAAAA記録を混ぜないでください)。

   (6)  For each of the addresses, loop over steps (7) to (9).

(6) それぞれのアドレスには、(9)へのステップ(7)の上で輪にしてください。

   (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)を移植させるようにしてください。 クライアントは、.2にRFC2821部4.5の.3に記録されたタイムアウトに続く必要があります。 うまくいくなら、(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) RFC2821で指定されるように確立された接続の上にメールを送るのを試みてください。 一時障害状態が報告されるなら、次のMX記録を試みてください。((3))を踏みに行ってください。 エラー条件が報告されるなら、永久的なメール配送誤りを上げてください、そして、さらなるMX記録を試みないでください。 終わってください。 うまくいくなら、SMTP配送は成功しました。 終わってください。

Nakamura & Hagino            Informational                      [Page 5]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[5ページ]のRFC3974SMTP

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の間の可到達性

   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。 IN MX1mx1.example.org。 IN MX10mx10.example.org。 IN MX100mx100.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ホストのメール範囲1であるときに、MX preferencingメカニズムに基づく第一の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に達することができません。 IN MX1mx1.example.org。 ; IPv6だけIN MX10mx10.example.org。 ; IPv4だけIN MX100mx100.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

; この構成はうまくいきます。 ; 二次MXホストは第一のMXにメールをリレーできます。 問題なしでどんな. example.orgを接待してください。 IN MX1mx1.example.org。 ; デュアルスタックIN MX10mx10.example.org。 ; IPv4だけIN MX100mx100.example.org。 ; 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

第一のMXホストと下側のMXホストがIPv4かIPv6輸送で直接お互いに連絡するのは必要でないかもしれません。 例えば、UUCPかIPv4/v6と共にルーティング経路を確立するのは可能です。

Nakamura & Hagino            Informational                      [Page 6]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[6ページ]のRFC3974SMTP

   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リストに記載されていないかもしれません。

5.  Operational Experience

5. 運用経験

   Many of the existing IPv6-ready MTA's appear to work in the way
   documented in section 3.

既存のMTAのIPv6持ち合わせのものの多くが、セクション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(RCODE2)(AAAAの記録的なルックアップに関する一時障害)を返します。 この一時障害では、メールは後の試みのために列に並ばせられます。 IPv4/v6相互運用性のために、これらの壊れているDNSサーバは修理されるべきです。 Yasuhiro森下[森下]のそばのドキュメントには、misconfiguredされたかふらちな事をしている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 Eメールアドレスの見られたアドレス(すなわち、ローカルのアドレスをリンクする)は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 (1) A RRs、そして/または、MX RRsが示されるAAAA RRsの追加質問や、(2) IPv6の目的地とIPv4の目的地の間の注文などのこのメモに示されたIPv6関心を含むようにSMTP(RFC2821の改正)の将来の仕様をアップデートするべきです。

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.

ルート-addr Eメールアドレス形式[クロッカー](または、[レズニック]の「obs-ルート」アドレス形式)が複数の範囲ゾーンの向こう側に使用されるなら、問題が多いかもしれません。 MTAsは、範囲のゾーンの境界を越えるルートaddr Eメールアドレス形式でメールを拒絶する必要があるでしょう。

Nakamura & Hagino            Informational                      [Page 7]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[7ページ]のRFC3974SMTP

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.

IPv4だけMTAケースへのIPv6だけMTAは[Hagino]などのIPv6からIPv4への翻訳者から助けを使用できました。 通常、どんな必要である翻訳者にとって、特別なSMTP問題もありません。 IPv6 MTAからIPv6からIPv4の上の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[セントジョンズ]のようなプロトコルは特別の配慮を必要とするかもしれません。 また、SMTP HELO/EHLO「ドメイン」パラメタ(逆の、または、前進のDNSルックアップを実行して、「ドメイン」が本当にSMTPクライアントのIPアドレスと交際するかどうかわかる)に厳しいチェックを実行するMTAsがあります。 翻訳者が使用されるとき(例えば、翻訳者の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.

翻訳者がいなくても、HELO/EHLOメッセージ(「HELO[IPv6: たわごと]」のような)には荒野でのアドレス誤字誤植をIPv6に送るいくつかのMTA実現があるように思えます、IPv4輸送を使用しているか、逆もまた同様ですときにさえ。 SMTP同輩がIPv4専用であるなら、それは、「[IPv6: たわごと]」の構文とメールが(壊れる)のMTAから続かないのを理解しないでしょう。 これらの実現は修正されなければなりません。

Normative References

引用規格

   [Mockapetris] Mockapetris, P., "Domain names - implementation and
                 specification", STD 13, RFC 1035, November 1987.

[Mockapetris]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日

   [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、「DNS拡張子、IPをバージョン6インチ支持してください、RFC3596、2003インチ年10月。

   [Partridge]   Partridge, C., "Mail routing and the domain system",
                 STD 10, RFC 974, January 1986.

[ヤマウズラ] ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、STD10、RFC974、1月1986日

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

[Klensin] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。

   [Crocker]     Crocker, D., "Standard for the format of ARPA Internet
                 text messages", STD 11, RFC 822, August 1982.

[クロッカー]クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。

   [Resnick]     Resnick, P., "Internet Message Format", RFC 2822, April
                 2001.

[レズニック]レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [Hagino]      Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
                 Site Exit Routers", RFC 3178, October 2001.

[Hagino] HaginoとJ.とH.スナイダー、「サイト出口ルータにおけるIPv6マルチホーミングサポート」、RFC3178、2001年10月。

Nakamura & Hagino            Informational                      [Page 8]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[8ページ]のRFC3974SMTP

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

[セントジョンズ]ジョーンズ、M.通り、「識別プロトコル」、RFC1413、1993年2月。

Informative References

有益な参照

   [Morishita]   Morishita, Y. and T. Jinmei, "Common Misbehavior
                 against DNS Queries for IPv6 Addresses", Work in
                 Progress, June 2003.

「IPv6アドレスのためのDNS質問に対する一般的な不正行為」という[森下]の森下、Y.、およびT.Jinmeiは進歩、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研究グループから書かれました。 ここに、ドキュメントに貢献した人々の(たぶん不完全)のリストがあります: グレゴリー・ニール・シャピロ、Arnt Gulbrandsen、モホセンSouissi、JJベーレンス、ジョンC Klensin、マイケル・A.パットン、ロバートElz、ディーンStrik、ペッカSavola、およびロブAustein。

Authors' Addresses

作者のアドレス

   Motonori NAKAMURA
   Academic Center for Computing and Media Studies, Kyoto University
   Yoshida-honmachi, Sakyo, Kyoto 606-8501, JAPAN

コンピューティングのためのMotonori中村Academicのセンターとメディア研究、京都大学吉田-honmachi、Sakyo、京都606-8501、日本

   Fax:   +81-75-753-7450
   EMail: motonori@media.kyoto-u.ac.jp

Fax: +81-75-753-7450 メールしてください: 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

6月-ichiro itojun HAGINO研究所、インターネットイニシアティブ株式会社1-105、神保町、千代田区、東京101-0051、日本神田

   Phone: +81-3-5205-6464
   Fax:   +81-3-5205-6466
   EMail: itojun@iijlab.net

以下に電話をしてください。 +81-3-5205-6464 Fax: +81-3-5205-6466 メールしてください: itojun@iijlab.net

Nakamura & Hagino            Informational                      [Page 9]

RFC 3974            SMTP in Dual Stack Environments         January 2005

デュアルスタック環境2005年1月の中村とHaginoの情報[9ページ]のRFC3974SMTP

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78と、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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Nakamura & Hagino            Informational                     [Page 10]

中村とHagino情報です。[10ページ]