RFC974 日本語訳
0974 Mail routing and the domain system. C. Partridge. January 1986. (Format: TXT=18581 bytes) (Obsoleted by RFC2821) (Also STD0010) (Status: HISTORIC)
RFC一覧
英語原文
Network Working Group Craig Partridge
Request for Comments: 974 CSNET CIC BBN Laboratories Inc
January 1986
MAIL ROUTING AND THE DOMAIN SYSTEM
メールルーティングとドメインシステム
このメモの位置づけ
このRFCは、どのようにしてインターネット上のメールシステムがRFC 882,
883 および 973に記述されるドメインシステムからの情報に基づいて、メッ
セージを送るルートを選んでほしいかを記述したものを与える。このメモ
の配布は無制限です。
はじめに
このメモの目的は、与えられたインターネットドメイン名宛のメッセージ
を送るルートを選ぶ方法をどのようにメーラが決定するかを説明すること
です。これは、どのようにメーラが MX RRを解釈するかの議論を含む。こ
のメモは、メーラがメールボックス名を解釈するために使用される MBおよ
び MG RRを処理する方法に関する声明を行わないことに注意しなさい。
RFC-882および RFC-883のもとで、メールアドレスに関する一定の仮定は変
更されている。今に至るまで、普通もしメッセージがメールボックスへ宛
てられているならば、例えば、LOKI.BBN.COMでは、LOKI.BNN.COMへSMTP接
続をちょうど開始し、それを通してメッセージを渡すことを仮定すること
ができた。このシステムは、直接インターネットに属しないある種のUUCP
およびCSNETホストに対するようなある状況において、停止した。しかし、
これらのホストは設定ファイルで特別な場合として処理されることができ
た(例えば、多くのメーラはCSNET宛のメールをCSNET-RELAY.ARPAへ自動的
に転送するように設定されていた)。
ドメインのもとでは、単純にLOKI.BNN.COMへ接続を開始することかできな
い。代わりに、何処へLOKI.BNN.COMへのメッセージが配達されるべきかを
ドメインシステムに照会しなければならない。また、SH.CS.NETのように、
ドメインシステムはメーラがメッセージを全く違ったホストへ配達するよ
うに指図するかもしれない。あるいは、より複雑な場合、メーラは、
LOKI.BNN.COM へのルートの選択を行うことを習得できるかもしれない。
このメモは本質的に、メーラがこれより複雑な世界でどのように振る舞う
べきかのガイドラインの集合です。
読者は、RFC 882, 883およびそれらを更新したもの(例えば、RFC-973)を
熟知してほしい。
何をドメインサーバは知っているか
ドメインサーバは、リソースレコード(RR)の列として情報を格納する。RR
の各々は与えられたドメイン名(これは普通、常にではないが、ホスト)に
関するある一つの情報を含む。RRのことを想像するための最も単純な方法
は、直接関係するデータと組み合わされたドメイン名つまりデータのタイ
プされたペアです。またいつシステムが RRが直接関係するかを決定するの
に役立ついくつかの付加的な種類の情報とともに格納される。メッセージ
のルート決定の目的のために、システムは MX RRとして知られている RRを
格納する。各々の MXは、二個のデータつまり優先値(符号無し16-Bit整数)
およびホストの名前をドメイン名に適合させる。優先値は、どんな順番で
MXホストへ配達することを試みるべきかを示すために使用される。最も低
い値の MXが最初に試すためのものである。同じ優先値を持つ複数の MXは
許可され同じ優先度を持つ。
メール情報に加えて、サーバは、メーラが遭遇するあるいは使用すること
を選択するかもしれない RRの情報のある他の種類を格納する。これらは:
正統の名前(CNAME) RR、これはこれに対して要求されるドメイン名が実際
は適当なあるいは正統の名前であるのドメイン名に対するエリアスである
ことを単純に述べる; および、よく知られたサービス(WKS) RR、これは与
えられたドメイン名がサポートする(SMTPのような)ネットワークサービス
に関する情報を格納するものです。
一般ルーティングガイドライン
どのようにメーラがメールルーティングをしてほしいかの詳細な議論を調
査する前に、どのようにこのメモが、ルーティングが引き起こす問題を扱
うかの簡潔な概要を与えるための意識をつくろうと思う。
第一の重要な原理は、MXレコードの優先値フィールドの定義から引き出さ
れ、また、メールがループするのを阻止するために意図される。もしメー
ラが目的ホストに対する MXとしてリストされるホスト上にあるならば、メー
ラはそれ自身のホストよりも低い優先値を持つ MXへ配達することのみがで
きるかもしれない。
ルーティング情報が期日を過ぎたあるいは不完全であるためにメールのルー
プか起こることはやはり有り得ます。ドメインテーブルが変更されたとき、
期日を過ぎた情報は単に問題です。その変更は、それらのリゾルバのキャ
シュがタイムアウトするまで、全ての影響があるホストに知られないだろ
う。要求するメーラおよびそれらのリゾルバに常にそれらの照会(queries)
を権限を持つサーバ(authortative server)へ送ることを要求すること、お
よびキャシュに格納されたデータをけっして使用しないこと除いて、それ
が起こらないということを保証する方法はない。リゾルバのキャシュを無
視することが、メールを送ることを過度に高価にするので、これは実現困
難な解決法です。さらに、期日を過ぎた RRの問題は、もしドメインテーブ
ルが変更れたときに(MXのリスト上の)影響のあるホストがそれらのリゾル
バのキャシュをフラッシュするならば、起こらないにばすです。言いかえ
れば、与えられた適切な予防措置、メーラに権権のあるサーバに照会する
ことなしに、ドメイン情報の結果としてメールがループすることは回避可
能に違いない。(適切な予防措置は、ホストをMXのリストへ加えるまえに、
そのホストの管理者が点検することです)。
ドメイン照会を処理するとき、不完全なデータの問題もまたいくつかの配
慮を必要とする。もし照会の回答セクションが不完全ならば、決定的に重
要な MX RRは抜けるかもしれない。これは、メールがループするあるいは
メッセージが誤って配達不可能のラベルを張られることに帰着するかもし
れない。その結果として、メーラは完全な回答セクションを持つドメイン
システムからの応答を受理することのみでよい。この問題全体は、照会の
ために仮想回線を使用することによってのみ、回避されることができる。
しかし、この状況が非常に希であろうしまたデータグラムがドメインシス
テムと相互に動作するための望ましい方法であることから、イプリメント
する人たちは、もし万一切り詰めビット(truncation bit)がいつかセット
されたら、かれらのメーラが仮想回線で照会を繰り返すだろうということ
を多分本当に保証するに違いない。
メッセージの送付先の決定
メッセージを送るルートを選ぶ方法をどのように決定するべきかの説明は、
ドメイン名 REMOTE宛のメッセージを配送しようとしているドメイン名 LOCAL
のホスト上のメーラの問題の点から議論される。LOCALと REMOTEの両方は、
構文上正しいドメイン名であると仮定される。なお、さらにLOCALはメーラ
の在るホストの公式の名前であると仮定される(すなわち、これはエリアス
ではない)。
照会(Query)の発行
LOCALのメーラの最初のステップは、REMOTEをあらわす MX RRに対する照会
を発行することです。このステップが毎回メーラがメッセージを送ること
を試みるときに行われることは強く勧める。ドメインデータベースの変更
がメーラによって迅速に使用されることを希望する。また、従ってドメイ
ン管理者は、それらのドメインデータベースを単に変更することによって
欠陥のあるホストへの移送できないメッセージを送るルートを再び決める
ことができるだろう。
照会へのある種の応答はエラーであると考えられる:
照会への応答が得られない。メーラが照会されたドメインサーバが何も
送り返さない。(これは、照会への回答を含まない回答と区別される、
これはエラーではない)。
ヘッダの切り詰めフィールドがセットされた応答を得ること。(上記の
不完全な照会についての議論を思い起こせ)。メーラは、この種の応答
を使用してはいけない。また、データグラムの代わりに仮想回線を使用
して照会を繰り返すべきです。
応答コードがゼロでない応答を得ること。
メーラは、エラーに直面して理にかなったことをしてほしい。各種エラー
に対する振る舞いは、ここでは指定しない。しかし、イプリメントする人
は、異なる種類のエラーは多分異なるように取り扱われるべきであること
に注意すべきです。例えば、"non-existent domain"の応答コードは多分、
無効であるとしてメッセージを差出人へ返すことを起こすに違いない。一
方、"server failure"は多分、メッセージをあとで再び試されることを起
こすに違いない。
他の特別な場合が一つある。もし応答が CNAME RRである回答を含むならば、
REMOTEが実際にいくつかの他のドメイン名に対するエリアスであることを
明示する。照会は、正統のドメイン名で繰り返されるに違いない。
もし応答がエラー応答を含まず、またエリアスを含まなければ、これの回
答セクションは、ドメイン名 REMOTE(あるいはもし REMOTEがエリアスなら
ば、REMOTEの本当の名前)に対する(もしかすると長さゼロの) MX RRのリス
トであるべきです。次のセクションは、どのようにこのリストが解釈され
るかを記述する。
MX RRのリストの解釈
注意: このセクションは、RRの情報のリストからの働きで、どのようにし
てメーラがメッセージを配達することを試す送り先の名前を選ぶかについ
てのみ議論する。これは、どのようにしてメーラが実際に配達を行うかに
ついて議論しない。リモートサイトに対するドメイン名を与えられて、一
体何処へメッセージを配達するかは言及される。意味したものすべては、
メーラはそれがリモートサイトへメッセージを転送するために行う必要が
あるものは何でも行うべきだということです。(例えば、SMTPメーラはドメ
イン名に対するアドレスを得ることを試すだろう。これはドメインシステ
ムへのある他の照会を含む。またそして、もしそれがアドレスを得たなら
ば、SMTP TCPポートへ接続する)。与えられたドメイン名に関係するアドレ
スへネットワークを越えてメッセージを実際に転送する機構は、このメモ
の範中ではない。
照会への応答における MXのリストが空であることは可能です。これは特別
な場合です。もしリストが空なら、メーラは、あたかもそれが一つの RR、
0の優先値と REMOTEのホスト名をもつ MX RRを含んでいるように取り扱う
べきです。(つまり、REMOTEは単にそれの MXです)。つけくわえて、メーラ
は、リスト上の処理をさらにするべきではない。しかし、REMOTEへメッセー
ジを配達することを試みるべきです。ここでのアイデアは、もしドメイン
が特定の名前に関する情報を広告することを失敗したならば、私たちは疑
わしい点はこれを有利に解釈し、配達を試みるいうことです。
もしリストが空でないなら、メーラは続くステップに従うリストから無関
係の RRの情報を取り除くはずです。順序が重要であることに注意しなさい。
各 MXに対して、WKS照会は、実際にリストに載せられたドメイン名が要
求されたメールサービスをサポートしているかをみるために、発行され
るに違いない。このステップはオプションですが、強く奨励される。
もしドメイン名 LOCALが MX RRとしてリストに載せられたならば、LOCAL
の優先値以上の優先値を持つ全ての MX RRは廃棄されなければならない。
無関係の RRを取り除いたあとで、リストは再び空になることがある。これ
は、いまエラー条件であり、また何らかの方法で起こることがある。最も
単純な場合は、WKS照会がリストに載せられたホストが要求されたメール
サービスをサポートしないことを明らかにしたことです。メッセージが返
るまえに極端に永続的なメールシステムが REMOTEのアドレスへ(存在すれ
ば)配達することを試そうとするかもしれないけれども、メッセージは従っ
て配達不可能であると考えられる。もう一方、さらに危険だが、ドメイン
システムが LOCALが REMOTEへのメッセージを処理していることを信頼し、
しかし、LOCAL上のメーラは REMOTEへのメッセージを処理するように設定
されていないことは可能です。例えば、もしドメインシステムが REMOTEの
ただ一つの MXとして LOCALをリストに載せたならば、LOCALはリスト中の
全てのエントリを削除する。しかし、LOCALは REMOTE宛のメッセージを処
理するために何をしたらいいか知らないので、LOCALはおそらくドメインシ
ステムに照会している。明らかになにかが悪い。どのようにメーラがこれ
らの状況を処理することを選択するかは、インプリメンテーション依存の
範囲に合わせる。また、従ってイプリメントする人の慎重な判断に委ねら
れる。
もし MX RRのリストが空でないなら、メーラは(最低の優先値が最初に試さ
れる)順序で MXへメッセージを配達することを試すべきです。メーラは最
も低い値の MXへ配達しようと試みることを要求される。イプリメントする
人たちはMXの一つがメッセージを受理する、あるいは全ての MXが試される
まで、それらが順番に MXを試すように、メーラを書くことを奨励される。
あるMXの固定された値が試される幾分少ない要求をするシステムもまた道
理にあっている。複数の MXが同じ優先値を持ってもよいことに注意しなさ
い。この場合、全て試される。つけくわえて、最も低い優先値をもついく
つかの MXがある特別な場合、メッセージが配達不可能であると考えられる
前に、それらの全ては試されるべきです。
マイナーな特別な問題
議論を複雑にしたので、先のセクションから省かれた二つの特別な問題が
ある。これらはここで順不同で取り扱われる。
ワイルドカード名、それらの中に文字 '*'を含んでいる、はメールルーティ
ングに対して使用されるかもしれない。あるドメインへの任意のメールが
中継を通して送られることを単純に述べるネットワーク上のサーバが多分
あるだろう。例えば、このRFCが書かれているこのときに、ドメイン IL中
のホストへの全てのメールは、RELAY.CS.NETを通って送られる。これは
*.ILが RELAY.CS.NETの MXを持つことを述べるワイルドカード RRを創るこ
とによって行われる。ドメインサーバはこのワイルドカードの適合を隠す
ので、これはメーラに透過されるべきです。(もしこれが、例えば HUJI.IL
が *.ILに適合したならば、ドメインサーバは *.ILではなく HUJI.ILを含
む RRをかえす)。もしなんらかの事故によってメーラがこの名前あるいは
データセクション中でワイルドカードドメイン名をもつ RRを受け取ったな
らば、それはこの RRを廃棄するべきです。
もしLOCALがエリアスを持ちこのエリアスがREMOTEに対するMXレコードにリ
ストされたならば、無関係のRRを削除するアルゴリズムは停止することに
注意しなさい。(例、REMOTEはALIASのMXを持つ、このALIASはLOCALのCNAME
を持つ)。もしエリアスがMX RRのデータセクションのにおいて決して使用
されないならば、これは回避することができる。
イプリメントする人は、照会および照会の解釈は REMOTEに対してのみ行わ
れることを理解するべきです。これはREMOTEのためにリストされたMX RRに
対して繰り返して行わない。MXのチェーンを作成することによってさらに
途方もないメールルーティングをサポートことを試してはならない。(例、
UNIX.BBN.COMはRELAY.CS.NETのMXです。また、RELAY.CS.NETは .ILの全ホ
ストに対するMXです。しかし、これはUNIX.BBN.COMが .ILへのメールに対
する責任を受理することを意味しない)。
最後に、これがインターネット上のルーティングについての基準であるこ
とは注意されるべきです。複数のネットワークに横たわるホストにサービ
スするメーラは、おそらくどのネットワークを通して送るかに関するいく
つかの決定をしなければならないだろう。メーラが決定することに役立つ
ドメインシステムをよく用いるかもしれないが、この決定の過程はこのメ
モの範囲外です。しかしながら、一度メーラがインターネット経由でメッ
セージを配達することを決めたならば、それはメッセージを送るルートを
決めるためのこれらの規則を適用しなければならない。
例
上記の議論を例証するために、ここには、どのようにしてメーラがメッ
セージを送るルートを決めるかの三つの例がある。
A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG
A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG
A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP
B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG
B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG
B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP
C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP
D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG
D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG
D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP
第一の例では、D.EXAMPLE.ORG上のSMTPメーラは、A.EXAMPLE.ORG宛のメッ
セージを配達することを試している。それの照会への応答から、それは、
A.EXAMPLE.ORGが三つのMX RRsを持つことを知る。D.EXAMPLE.ORGは MX RR
の一つでなく、また、三つの MX全てはSMTPメールをサポートする(WKSエン
トリがら決定される)、その MXは削除されない。メーラは、最も低い値の
MXとしてA.EXAMPLE.ORGへ配達することを試みることを義務づけられる。
もしA.EXAMPLE.ORGへ近づくことができなければ、それはB.EXAMPLE.ORGを
試すことができる(しかし、することを要求されない)。また、もし
B.EXAMPLE.ORGが応答していないならば、それはC.EXAMPLE.ORGを試すこと
ができる。
第二の例では、メーラはB.EXAMPLE.ORG上にあり、また、再び A.EXAMPLE.ORG
宛のメッセージを配達することを試している。もう一度 A.EXAMPLE.ORGに
対する三つの MX RRがある。しかしこの場合、メーラは自分自身のおよび
C.EXAMPLE.ORGの(C.EXAMPLEの MX RRがB.EXAMPLE.ORGの RRよりも高い優先
値を持つので) RRを廃棄しなければならない。それは A.EXAMPLE.ORGの RR
のみが残される、また、A.EXAMPLE.ORGへ配達することのみができる。
第三の場合は、D.EXAMPLE.ORGへメッセージを配達することを試みている
A.EXAMPLE.ORG上のメーラを考える。この場合、両方とも同じ優先値を持つ
ただ二つの MX RRがある。いずれかの MXはD.EXAMPLE.ORGへのメッセージ
を受理するだろう。メーラは、一つの MXを最初に試すべきです
(D.EXAMPLE.ORGが最も妥当であると思われるが、その一つはメーラ次第で
す)。また、もしその配達が失敗したら、他の MXを試すべきです(例えば、
C.EXAMPLE.ORG)。
一覧
スポンサーリンク
