Network Working Group Internet Engineering Task Force Request for Comments: 1123 R. Braden, Editor October 1989 Requirements for Internet Hosts -- Application and Support Status of This Memo この RFC は、インターネット社会のための公式の規定である。これは、ホストに関 連する基本的なプロトコル標準のドキュメントを参照、改正、修正、補足することに よって編入している。このドキュメントの配布は制限されない。 Summary この RFC は、インターネットホストソフトウェアの要件をを定義し議論するペアの 一つである。この RFC は、アプリケーションとサポートプロトコルをカバーしてい る。もう一方の RFC-1123 は、通信プロトコル層: リンク層、IP 層、トランスポー ト層をカバーしている。 Table of Contents 1. 導入 1.1 インターネット体系 1.2 一般的な考慮 1.2.1 発展し続けるインターネット 1.2.2 頑強さの指針 1.2.3 エラーのログ採取 1.2.4 設定 1.3 このドキュメントを読む 1.3.1 構成 1.3.2 要件 1.3.3 用語 1.4 謝辞 2. 一般的な問題 2.1 ホスト名と番号 2.2 ドメイン名サービスの使用 2.3 マルチホーム化されたホスト上のアプリケーション 2.4 サービスタイプ 2.5 一般的なアプリケーション要件の要約 3. リモートログイン -- TELNET プロトコル 3.1 導入 3.2 プロトコルウォークスルー 3.2.1 オプション折衝 3.2.2 Telnet Go-Ahead 機能 3.2.3 制御機能 3.2.4 Telnet "Synch" Signal 3.2.5 NVT プリンタとキーボード 3.2.6 Telnet コマンド構造 3.2.7 Telnet バイナリオプション 3.2.8 Telnet 端末タイプオプション 3.3 特定の問題 3.3.1 Telnet 行端規定 3.3.2 データ登録端末 3.3.3 オプション要件 3.3.4 オプションの起動 3.3.5 Telnet 行モードオプション 3.4 Telnet/ユーザ間のインタフェース 3.4.1 文字セットの透過性 3.4.2 Telnet コマンド 3.4.3 TCP コネクションエラー 3.4.4 デフォルトでない Telnet 接続ポート 3.4.5 出力のフラッシュ 3.5. Telnet 要件要約 4. ファイル転送 4.1 ファイル転送プロトコル -- FTP 4.1.1 導入 4.1.2 プロトコルウォークスルー 4.1.2.1 ローカルタイプ 4.1.2.2 Telnet フォーマット制御 4.1.2.3 ページ構造 4.1.2.4 データ構造変換 4.1.2.5 データコネクション管理 4.1.2.6 PASV コマンド 4.1.2.7 LIST と NLIST コマンド 4.1.2.8 SITE コマンド 4.1.2.9 STOU コマンド 4.1.2.10 Telnet 行端コード 4.1.2.11 FTP 応答 4.1.2.12 コネクション 4.1.2.13 最小限の実装 4.1.3 特定の問題 4.1.3.1 非標準コマンドの動作 4.1.3.2 アイドルタイムアウト 4.1.3.3 データと制御の協調 4.1.3.4 FTP 再開メカニズム 4.1.4 FTP/ユーザインタフェース 4.1.4.1 パス名の規定 4.1.4.2 "QUOTE" コマンド 4.1.4.3 ユーザへの応答表示 4.1.4.4 同期の維持 4.1.5 FTP 要件要約 4.2 簡易ファイル転送プロトコル -- TFTP 4.2.1 導入 4.2.2 プロトコルウォークスルー 4.2.2.1 転送モード 4.2.2.2 UDP ヘッダ 4.2.3 特定の問題 4.2.3.1 魔法使いの弟子シンドローム 4.2.3.2 タイムアウトアルゴリズム 4.2.3.3 拡張 4.2.3.4 アクセス制御 4.2.3.5 ブロードキャスト要求 4.2.4 TFTP 要件要約 5. 電子メール -- SMTP と RFC-822 5.1 導入 5.2 プロトコルウォークスルー 5.2.1 SMTP モデル 5.2.2 正式化 5.2.3 VRFY と EXPN コマンド 5.2.4 SEND, SOML, SAML コマンド 5.2.5 HELO コマンド 5.2.6 メール中継 5.2.7 RCPT コマンド 5.2.8 DATA コマンド 5.2.9 コマンドシンタックス 5.2.10 SMTP 応答 5.2.11 透過性 5.2.12 MX 処理における WKS の使用 5.2.13 RFC-822 メッセージの規定 5.2.14 RFC-822 日付と時間の規定 5.2.15 RFC-822 シンタックスの変更 5.2.16 RFC-822 ローカル部 5.2.17 ドメインリテラル 5.2.18 一般的なアドレス形式のエラー 5.2.19 明示的な送信元経路 5.3 特定の問題 5.3.1 SMTP キューイング方法 5.3.1.1 送信戦略 5.3.1.2 受信戦略 5.3.2 SMTP のタイムアウト 5.3.3 信頼性のあるメール受信 5.3.4 信頼性のあるメール送信 5.3.5 ドメイン名のサポート 5.3.6 メーリングリストと別名 5.3.7 メールゲートウェイ 5.3.8 最大メッセージ長 5.4 SMTP 要件要約 6. サポートサービス 6.1 ドメイン名変換 6.1.1 導入 6.1.2 プロトコルウォークスルー 6.1.2.1 ゼロの TTL を持つリソースレコード 6.1.2.2 QCLASS 値 6.1.2.3 未使用フィールド 6.1.2.4 圧縮 6.1.2.5 構成情報の誤用 6.1.3 特定の問題 6.1.3.1 リゾルバ実装 6.1.3.2 トランスポートプロトコル 6.1.3.3 効率的な資源利用 6.1.3.4 マルチホームホスト 6.1.3.5 拡張性 6.1.3.6 RR タイプの状態 6.1.3.7 頑強性 6.1.3.8 ローカルホストテーブル 6.1.4 DNS ユーザインタフェース 6.1.4.1 DNS 管理 6.1.4.2 DNS ユーザインタフェース 6.1.4.3 インタフェース略語機能 6.1.5 ドメインネームシステム要件要約 6.2 ホスト起動 6.2.1 導入 6.2.2 要件 6.2.2.1 動的設定 6.2.2.2 ローディングフェーズ 6.3 リモート管理 6.3.1 導入 6.3.2 プロトコルウォークスルー 6.3.3 管理要件要約 7. 参照 セキュリティの考慮 作者のアドレス ------------------------------------------------------------------------ 1. 導入 このドキュメントは、インターネットプロトコルスイートのホストシステム実装要件 を定義し議論するペアドキュメントのうちの一つである。この RFC は、アプリケー ション層とサポートプロトコルをカバーしている。もう片方の RFC "インターネット ホスト要件 -- 通信層" [INTRO:1] は、下位層プロトコル: トランスポート層、IP 層、リンク層をカバーしている。 これらのドキュメントは、インターネット通信ソフトウェアのベンダ、実装者、ユー ザ向けにガイダンスを提供することを意図している。それらは、インターネット研究 団体やベンダのコミュニティによって寄与された、大多数の技術上の経験や知識のコ ンセンサスを表している。 この RFC は、インターネットに接続されたホストが使用しなければならない標準プ ロトコルを列挙しており、これらのプロトコルの現在の規定を記述している RFC や 他のドキュメントを参照することによって編入している。それは、参照しているドキ ュメント中の誤りを修正し、実装者のために付加的な議論やガイダンスを追加してい る。 各々のプロトコルに対し、このドキュメントは要件や推奨やオプション等の明示的な セットも含んでいる。このドキュメント中の要件のリストはそれ自身では不完全であ ることを、読者は理解しなければならない。インターネットホストのための完全な要 件は、基本的に標準プロトコルの規定ドキュメントで定義され、この RFC に記述さ れた修正、改正、補足を含む。 注意深く RFC を読み、インターネット技術社会と協調し、適切な通信ソフトウェア 技術の実践に従った上で作成されたプロトコルの誠実な実装は、このドキュメントの 要件との相違はマイナーなものに限られるはずである。従って、多くの場合この RFC の "要件" は、既に標準プロトコルドキュメントで述べられているか、含まれてい る。よってここに含めることは、ある意味冗長である。しかし、幾つかの過去の実装 は誤った選択をし、相互接続性やパフォーマンス、頑強性に問題を引き起こしたこと があるので、それらを含めている。 このドキュメントは、数多くの要件や推奨についての議論や説明を含んでいる。要件 を簡単に一覧化することは危険である。なぜなら、 * ある必要な機能は他の機能よりも重要であり、ある機能はオプションである。 * 制限されたコンテキストで設計された特定のベンダ製品が、異なる規定の使用 を選択したことは、正当な理由があるかもしれない。 しかし、このドキュメントの規定は、多種多様で複雑なインターネットシステム全体 で、任意のホストの相互運用の一般的な目標に適合するために従わなければならな い。現在の大半の実装は、あるものはメジャーな、またあるものはマイナーな様々な 点でこれらの要件に適合していないが、この規定は我々が移行する必要のある考え方 である。 これらの要件は、インターネット体系の現在のレベルに基づいている。このドキュメ ントは、追加の説明を提供したり、規定が依然として発展している分野における追加 の情報を含めるために、必要に応じて更新されるだろう。 この導入部のセクションは、ホストソフトウェアベンダへの幾つかの一般的なアドバ イスから始め、ドキュメントの残りを読むにあたってのガイダンスを示している。セ クション 2 は、全てのアプリケーションとサポートプロトコルに適用可能な一般的 な要件を含んでいる。セクション 3, 4, 5 は、3 つの主要なアプリケーション: そ れぞれ Telnet, ファイル転送、電子メール、に関するプロトコルの要件を含んでい る。セクション 6 はサポートアプリケーション: ドメイン名システム、システム初 期化、管理、をカバーしている。最後に、全ての参照は、セクション 7 に記載され ている。 1.1 インターネット体系 ホストの観点からのインターネット体系の簡潔な概要については、[INTRO:1] のセク ション 1.1 を参照されたい。そのセクションは、インターネット体系の一般的な背 景に関して、お薦めの参照も含んでいる。 1.2 一般的な考慮 インターネットホストソフトウェアのベンダが学び、新たなベンダが真剣に考慮すべ き二つの重要な教訓がある。 1.2.1 発展し続けるインターネット インターネットの膨大な成長は、大きなデータグラムベースのパケット通信システム における、管理と規模の問題を暴露した。これらの問題は取り組まれており、結果的 にこのドキュメントで示される規定も発展し続けるだろう。こうした計画には、ベン ダやネットワークの運用に責任がある組織が広範囲に渡って関係しているので、これ らの変更は慎重に計画、管理される。 成長、発展、改訂は今日のコンピュータネットワークプロトコルの特徴であり、この 状態は数年は続くであろう。インターネットプロトコルスイート (あるいは他の如何 なるプロトコルスイートでも !) のコンピュータ通信ソフトウェアを開発して、その 後の規約の変更に対してそのソフトウェアの保守や更新を行なわないベンダは、不幸 な消費者の跡を残すだろう。インターネットは大規模な通信ネットワークであり、ユ ーザは絶えずそれを通じて接触する。経験からすると、ベンダソフトウェアの欠陥に 関する知識は、インターネット技術社会を通じて急速に伝達されるようである。 1.2.2 頑強さの指針 プロトコルの全ての層において、アプリケーションが頑強さと相互接続性に関して、 莫大な利益をもたらすことができる一般原則がある。それは、 "受信するものには寛大であれ、送信するものには慎重であれ" ソフトウェアは、考えられる異常を、たとえそれがあり得そうに無いものであっても 処理できるよう書かれるべきである。遅かれ早かれ、パケットはある特定のエラーや 属性が組み合わさって入ってくる。もしソフトウェアがそれに備えていなければ、混 乱が起こり得る。一般に、ネットワークは最悪の影響を及ぼすことを意図したパケッ トを送信する、悪意を持ったエンティティが数多く存在するものと想定することが最 善である。大半のインターネットの重大な問題は、低い確率で発生するイベントによ って引き起こされる、予見できないメカニズムが原因ではあるが、この想定は適切な 防御設計につながるだろう。人的悪意だけでは、さほど踏み誤った進路を辿ることは ほとんど無い! 修正に対する適応性は、インターネットホストのソフトウェアの全てのレベルにおい て設計しなければならない。簡単な例だが、特定のヘッダフィールド値の列挙、たと えばタイプフィールドやポート番号、エラーコードを含むプロトコル規約を考慮した 場合、この列挙値は完全ではないと想定しなければならない。従って、もしプロトコ ル規約が 4 つのあり得るエラーコードを定義したら、ソフトウェアは 5 つめのコー ドが現れたときに壊れてはならない。未定義のコードはログに採取してもよいが (後 述)、障害の原因になってはならない。 指針の二番目の部分は、次の点において重要である。他のホスト上のソフトウェア は、正しいが不明確なプロトコル機能の開発を浅はかにする欠陥を含むかもしれな い。面倒な影響を結果的にどこかに及ぼすのは良くないので、明確さや単純さから離 れることは馬鹿げている。この結論は、"誤った動作をするホストに用心せよ" であ る。ホストソフトウェアは、単に他の誤った動作をするホストがあっても生き残るだ けではなく、そうしたホストが原因で起こり得る、共有された通信設備への混乱の量 を限定するために協調することを考慮すべきである。 1.2.3 エラーのログ採取 インターネットは非常に多岐に渡るホストやゲートウェイシステムを伴い、その各々 は多くのプロトコルやプロトコル層を実装しており、これらの幾つかはインターネッ トプロトコルソフトウェアの中にバグや機能誤りを含んでいる。複雑さや多様性や機 能の分散の結果として、ユーザの問題の診断はしばしば非常に困難である。 もしホスト実装が、異常や "奇妙な" プロトコルイベントをログに採取するために、 注意深く設計された機能を含んでいれば、問題の診断に役立つだろう。エラーログを 採取する際に、可能な限り多くの診断を含めることは重要である。特に、エラーの原 因となったパケットのヘッダを記録することはしばしば効果的である。しかし、エラ ーのログ採取が極端に大量の資源を消費したり、さもなくばホスト処理の邪魔になら ないことを保証するよう、注意しなければならない。 異常だが害は無いプロトコルイベントが、エラーのログファイルを溢れさせる傾向が ある。これは "循環" ログを使用するか、あるいは既知の障害を診断する場合にのみ ログの採取を有効にすることによって回避できる。連続して重複したメッセージをフ ィルタにかけて、その回数を数えるのは効果的かもしれない。うまくいきそうな戦略 は、(1) 常に異常事象をカウントし、その数には管理プロトコル (セクション 6.3 参照) を通じてアクセスさせること。(2) 多様なイベントのログ採取を選択可能にす ること。例えば、"全てをログに採る"、あるいは "ホスト X の全てをログに採る" ことができると便利かもしれない。 異なる管理者は、通常時にホストで有効にしたいエラーログの採取量に関して、異な る指針を持つかもしれない。ある者は "もし自分の害にならなければ、それについて 知りたくない" と言うかもしれないし、またある者は、より注意深く積極的にプロト コル異常を検出し除去したいと思うかもしれない。 1.2.4 設定 もしインターネットプロトコルスイートのホスト実装が完全に自己設定できれば、理 想的である。これによって、スイート全体を ROM に実装したり、シリコンに組み込 むことが可能になる。それによってディスクレスワークステーションが単純になり、 システムベンダのみならず、苦しんでいる LAN 管理者にも莫大な恩恵をもたらすだ ろう。我々はまだこの理想には到達していないし、実際近づいてもいない。 このドキュメントの多くの個所に、このパラメタは設定可能なオプションであること という要件が見つかるだろう。そうした要件の背景には、幾つかの異なる理由があ る。幾つかのケースでは、最適値について現在確定していないか同意されておらず、 将来、推奨値を更新する必要があるかもしれない。別のケースでは、値が実際に外部 要因に依存する。例えば、ホストのサイズや通信負荷の分散、隣接するネットワーク の速度やトポロジなどである。そして自己調整アルゴリズムが使用できなかったり、 不十分であるかもしれない。またあるケースでは、管理要件のために設定可能である ことが必要とされる。 最後に、ある設定オプションは、廃止された、あるいはプロトコルの不正な実装体と 通信するために必要である。それらはソース無しで配布され、不幸にもインターネッ トの多くの部分に残っている。正しいシステムをこれらの欠陥システムと共存させる ために、管理者はしばしば、正しいシステムに "誤設定" を施す必要がある。この問 題は、欠陥システムが退くにつれて次第に改善されていくだろう。しかし、ベンダは それを無視することができない。 パラメタが設定可能でなければならないと言う場合、その値が毎回ブート時に設定フ ァイルから明示的に読み込まれる必要があることは意図していない。実装者は各パラ メタにデフォルトを設定することが推奨される。よって設定ファイルは、ある特定の インストールにおいて適切でないデフォルトを、上書きする場合にのみ必要である。 従って、設定を可能にするという要件は、バイナリのみや ROM ベースの製品でさえ も、必要時にデフォルトを上書きすることができることの保証である。 このドキュメントは、幾つかのケースでそうしたデフォルトとして、特定の値を要求 している。デフォルトの選択は、設定項目が既存の欠陥システムへの適応を制御する 場合は、微妙な問題である。もしインターネットが完全な相互接続性に正常に収束す るならば、実装体に組み込まれるデフォルト値は、欠陥システムに便宜を図るための "誤設定" ではなく、公式のプロトコルを実装しなければならない。市場を考慮する と、あるベンダは誤設定のデフォルトを選択するかもしれないが、我々は、この標準 に適合したデフォルトをベンダが選択することを強く推奨する。 最後に、ベンダは全ての設定パラメタや、それらの制限や効果に関して、必要十分な ドキュメントを提供する必要があることを書き留めておく。 1.3 このドキュメントを読む 1.3.1 構成 通常は、各主要なセクションは、以下のサブセクションで構成される。 1. 導入 2. プロトコルウォークスルー -- プロトコル規定のドキュメントをセクション毎 に考察し、誤りを修正し、曖昧な、あるいは不適当に定義された要件に言及 し、さらに明確化し説明を加えている。 3. 特定の問題 -- ウォークスルーに含まれなかったプロトコル設計と実装の問題 について論じる。 4. インタフェース -- 次の上位層へのサービスインタフェースについて論じる。 5. 要約 -- このセクションの要件の要約を含む。 このドキュメント中の多くの個々のトピックの配下に、"DISCUSSION" か "IMPLEMENTATION" というラベルが付いた挿入句的な説明がある。この説明は、この 前の要件テキストを明確化したり、説明を加えることを意図している。また、起こり 得る将来の方向性や開発に対する幾つかの提案も含んでいる。実装説明は、実装者が 考慮する必要のある提案されたアプローチを含む。 要約セクションは、テキストへのガイドとインデクスになることを意図しているが、 かなり短く不完全である。要約は、完全な RFC とは切り離して使用したり参照すべ きではない。 1.3.2 要件 このドキュメントでは、各々の特定の要件の重要性を定義するために使用される単語 は、大文字で記述される。これらの単語とは、 * "MUST" この単語、あるいは形容詞 "REQUIRED" は、その項目は規定の絶対的な要件で あることを意味する。 * "SHOULD" この単語、あるいは形容詞 "RECOMMENDED" は、特定の環境において、この項目 を無視する正当な理由があるかもしれないことを意味する。しかし、完全な実 装について理解すべきであり、異なる方法を選択する前に慎重に比較考察すべ きである。 * "MAY" この単語、あるいは形容詞 "OPTIONAL" は、この項目が本当に任意であること を意味する。あるベンダは、例えば特定の市場が必要としているという理由 で、あるいは製品を拡張したいという理由でその項目を含めることを選択して もよい。また、別のベンダは同じ項目を省略してもよい。 もし実装するプロトコルの一つ以上の MUST 要件を満たさなければ、その実装体は準 拠していない。プロトコルの全ての MUST 要件と SHOULD 要件を満たしている実装体 は、"無条件に準拠" と呼ばれる。プロトコルの MUST 要件は全て満たしているが、 SHOULD 要件は全て満たしているわけではない実装体は、"条件付きで準拠" と呼ばれ る。 1.3.3 用語 このドキュメントは、以下の技術用語を使用する。 セグメント (Segment) セグメントは、TCP プロトコルにおけるエンドツーエンド転送の単位である。 セグメントは、TCP ヘッダとそれに続くアプリケーションデータで構成され る。セグメントは、IP データグラムの中にカプセル化されて送信される。 メッセージ (Message) この用語は、アプリケーションデータ単位として、幾つかのアプリケーション 層プロトコル (特に SMTP) で使用される。 データグラム (Datagram) [UDP] データグラムは、UDP プロトコルにおけるエンドツーエンド転送の単位 である。 マルチホーム (Multihomed) もしホストが、接続されたネットワークで複数の IP アドレスを持っていた ら、それはマルチホームと呼ばれる。 1.4 謝辞 このドキュメントは、大学や研究機関の代表者、ベンダ、政府機関の代理人を含む、 インターネットプロトコルの専門家の大きなグループからの寄与とコメントを反映し ている。基本的には、インターネット技術作業団体 (IETF) のホスト要件作業グルー プによって整理された。 編集者は、特に次の人々の多大な貢献に感謝したい。彼らは、多くの長い会議に参加 し、このドキュメントの検討で、過去 18 ヶ月に及ぶ 3 百万バイトもの電子メール を作成した。Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software)。 加えて、次の人々は成果に主要な寄与を施した。 Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA)。また次の人々は、特定の分野に重要な寄与をもたらした。Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto). この一覧からたまたま漏れているかもしれない寄与者を含め、皆に感謝したい。 2. 一般的な問題 このセクションは、全てのアプリケーション層プロトコルに適用できる一般的な要件 を含んでいる。 2.1 ホスト名と番号 正しいインターネットホスト名のシンタックスは、RFC-952 [DNS:4] で規定されてい る。ホスト名のシンタックスの一面について、ここで修正する。一番目の文字に対す る制限を緩和し、文字か数字のいずれかを認める。ホストソフトウェアは、このより 寛容なシンタックスをサポートしなければならない (MUST)。 ホストソフトウエアは、最大 63 文字のホスト名を扱わなければならず (MUST)、最 大 255 文字までのホスト名を扱うべきである (SHOULD)。 ユーザがインターネットホストの身元を入力する場合は常に、次のいずれかの入力を 可能にすべきである (SHOULD)。(1) ホストドメイン名、(2) ドット付き 10進数字 ("#.#.#.#") 形式の IP アドレス。ホストは、ドット付き 10進数字番号の文字列を ドメイン名システムで検索する前に、シンタックス上のチェックを行うべきである ( SHOULD)。 DISCUSSION: この最後の要件は、ドット付き 10進数字のホスト番号を入力するために、シンタッ クス上完全な形式で指定することを意図していない。それは、ユーザインタフェース の問題だと見なされる。例えば、ドット付き 10進数字番号は、SMTP メールでは " ]" の角括弧で囲まなければならない (セクション 5.2.17 参照)。この表記方法は ホストシステムの中で一般化することができ、ドット付き 10進数字番号のシンタッ クス上のチェックを簡単にする。 もしドット付き 10進数字番号が、そのような区切り文字を明示せずに入力できるな らば、完全なシンタックス上のチェックを行わなければならない。なぜなら、ホスト ドメイン名の節は現在数字で開始することができ、規定上全て数字にしてもよい (セ クション 6.1.2.4 参照)。しかし、少なくとも最上位の要素ラベルはアルファベット になるので、正しいホスト名はドット付き 10進数字形式にはなり得ない。 2.2 ドメイン名サービスの使用 ホストドメイン名は、セクション 6.1 で規定されているように、IP アドレスに変換 しなれけばならない (MUST)。 ドメイン名サービスを使用するアプリケーションは、ソフトエラー状態に対処できな ければならない (MUST)。アプリケーションはソフトエラーによって続けて再試行す る間、程よい間隔だけ待たなければならず (MUST)、ネットワークの問題によって数 時間、あるいは数日の間、サービスが拒否されるかもしれない可能性を考慮しなけれ ばならない (MUST)。 アプリケーションは、ある特定のホストアドレスで、全てのサービスの正確なリスト を含む WKS レコードを配置する能力に頼るべきではない (SHOULD NOT)。なぜなら WKS RR タイプは、インターネットサイトではしばしば使用されないからである。 2.3 マルチホーム化されたホスト上のアプリケーション リモートホストがマルチホーム化されている場合、名前からアドレスへの変換によ り、代替 IP アドレスのリストが返却されるだろう。セクション 6.1.3.4 に規定さ れているように、このリストは優先度の低い順であるべきである。アプリケーション プロトコルの実装は、成功するまでリストからの複数のアドレスを試みる準備をすべ きである (SHOULD)。SMTP のためのより固有の要件は、セクション 5.3.4 に記述さ れている。 ローカルホストがマルチホーム化されている場合、UDP ベースの要求/応答アプリケ ーションは、UDP 要求データグラムの特定宛先アドレスと同じである IP 送信元アド レスで、応答を送信すべきである (SHOULD)。"特定宛先アドレス" は、もう一組の RFC [INTRO:1] の "IP アドレス付け" のセクションで定義されている。 同様に、同じクライアントに複数の TCP コネクションをオープンするサーバアプリ ケーションは、全てに対して同じローカル IP アドレスを使用すべきである ( SHOULD)。 2.4 サービスタイプ アプリケーションはトランスポート層サービスを起動する時に、適切な TOS 値を選 択しなければならず (MUST)、これらの値は設定可能でなければならない (MUST)。 TOS 値は 5 ビットから成り、現在はそのうちの上位 3 ビットしか定義されていない ことに注意されたい。他の 2 ビットは 0 でなければならない (MUST)。 DISCUSSION: サービスタイプを実装するゲートウェイアルゴリズムが開発されたならば、様々なア プリケーションプロトコルで推奨される値が変わるかもしれない。さらに、ユーザと インターネットパスのある特定の組み合わせで、標準でない TOS 値を使用したいこ とがあるかもしれない。これらの理由により、TOS 値は設定可能でなければならな い。 主要なアプリケーションプロトコルで推奨された TOS 値については、"番号割り当て " RFC [INTRO:5] の最新のバージョンを参照されたい。 2.5 一般的なアプリケーション要件の要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -----------------------------------------------|----------|-|-|-|-|-|-- | | | | | | | ユーザインタフェース: | | | | | | | 数字で始まるホスト名を認める |2.1 |x| | | | | 63 文字までのホスト名 |2.1 |x| | | | | 255 文字までのホスト名 |2.1 | |x| | | | ドット付き 10進数字のホスト番号サポート |2.1 | |x| | | | 最初にドット付き形式のシンタックスチェック |2.1 | |x| | | | | | | | | | | セクション 6.1 に従ってドメイン名を対応付け |2.2 |x| | | | | ソフト DNS エラーに対処 |2.2 |x| | | | | 再試行の間に程よい間隔 |2.2 |x| | | | | 長時間の故障を考慮 |2.2 |x| | | | | WKS レコードが利用できることを期待 |2.2 | | | |x| | | | | | | | | マルチホームホストに複数のアドレスをトライ |2.3 | |x| | | | UDP 応答の送信元 addr が要求の特定宛先 addr |2.3 | |x| | | | 関連した TCP コネクションで同じ IP addr 使用 |2.3 | |x| | | | 適切な TOS 値を指定 |2.4 |x| | | | | TOS 値を設定可能 |2.4 |x| | | | | 未使用 TOS ビットを 0 |2.4 |x| | | | | | | | | | | | | | | | | | | 3. リモートログイン -- TELNET プロトコル 3.1 導入 Telnet は、リモートログインするための標準的なインターネットアプリケーション プロトコルである。これは、クライアント ("ユーザ") システム上のユーザのキーボ ード/ディスプレイを、リモートサーバシステム上のコマンドインタプリターと結び 付けるための符号化規則を提供する。Telnet プロトコルのサブセットは他のアプリ ケーションプロトコル、例えば FTP や SMTP の中に組み込まれてもいる。 Telnet は単一の TCP コネクションを使用し、通常のデータストリーム ("ネットワ ーク仮想端末" あるいは "NVT" モード) は、組み込み制御機能へのエスケープシー ケンスを持つ 7 ビット ASCII である。Telnet は、数多くのオプションモードや機 能の折衝も可能である。 基本的な Telnet の規定は RFC-854 [TELNET:1] にあり、オプションは他の多くの RFC で定義されている。参照は、セクション 7 を参照されたい。 3.2 プロトコルウォークスルー 3.2.1 オプション折衝: RFC-854, pp. 2-3 全ての Telnet 実装は、オプションの折衝とサブ折衝 [TELNET:2] を含まなければな らない (MUST)。 ホストはオプション折衝のループを避けるために、RFC-854 の規則に注意深く従わな ければならない (MUST)。ホストは、未サポートのオプションを拒否 (例えば DO/WILL に対して WONT/DONT で応答) しなければならない (MUST)。オプション折衝 は、Telnet コネクションが存続する間はずっと (たとえ全ての要求が拒否されても) 機能し続けるべきである (SHOULD)。 もし全てのオプション折衝が失敗したら、Telnet 実装はデフォルトを NVT にし、こ れをサポートしなければならない (MUST)。 DISCUSSION: たとえより洗練された "端末" やサポートしているオプション折衝が標準的になりつ つあっても、全ての実装体はユーザ-サーバ通信のために、NVT をサポートする準備 ができていなければならない。 3.2.2 Telnet Go-Ahead 機能: RFC-854, p. 5, RFC-858 Telnet コマンドの Go Ahead (GA) を送信しないホストの場合、Telnet サーバは Go Ahead の抑制オプションの折衝 (すなわち "WILL Suppress Go Ahead" の送信) を試 みなければならない (MUST)。ユーザかサーバ Telnet は、Go Ahead の抑制オプショ ンを常に受諾しなければならない (MUST)。 GA が何の意味も持たない全二重端末を制御する場合、ユーザ Telnet の実装は GA コマンドを無視してもよい (MAY)。 DISCUSSION: Go-Ahead メカニズムは半二重 ("ロックされたキーボード") で一度に一行の端末の ために設計されたが、それらはほとんど現場から消えつつある。多くのオペレーティ ングシステムに Go-Ahead シグナルを実装することは難しいことが判明した。ネイテ ィブな半二重端末をサポートする幾つかのシステムでさえもである。難しさの典型的 な例としては、Telnet サーバコードはユーザプロセスが Telnet コネクションから 入力を待って、ブロックされているか否かの情報を得られない、すなわち、いつ GA コマンドを送信するのか確定できないことである。従って、大半の Telnet サーバホ ストは GA コマンドを送信しない。 このセクションの規則の効果により、Telnet コネクションのいずれかの終端は、GA コマンドを拒否できる。 依然として商業的に重要な半二重端末のクラスが存在する。それは全画面方式で対話 型の "データ登録端末" である。しかし、Telnet プロトコルを使用するデータ登録 端末をサポートすることは、Go Ahead シグナルを必要としない。セクション 3.3.2 を参照されたい。 3.2.3 制御機能: RFC-854, pp. 7-8 Telnet コマンドのリストは、EOR (End-of-Record)、コード 239 [TELNET:9] を含む よう拡張されている。 ユーザとサーバの両方の Telnet は、制御機能の EOR, EC, EL, Break をサポートし てもよく (MAY)、AO, AYT, DM, IP, NOP, SB, SE をサポートしなければならない ( MUST)。 ホストは、サポートしていない如何なる Telnet 制御機能も受信して無視できなけれ ばならない (MUST)。 DISCUSSION: サーバ Telnet は、たとえサーバホストが同等な入力ストリーム機能 (例えば多くの システムにある Contrl-C) を持っていても、Telnet IP (Interrupt Process) 機能 をサポートする必要があることに注意されたい。Telnet IP 機能は TCP 緊急データ の帯域外効果を持つので、入力ストリームの中断コマンドよりも強いかもしれない。 EOR 制御機能は、ストリームを区切るために使用してもよい。重要なアプリケーショ ンは、データ登録端末のサポートである (セクション 3.3.2 参照)。EOR は RFC-854 で定義されたので、未知の Telnet コマンドを正しく無視できないホストが、もし EOR を受信したらクラッシュするという懸念があった。そのようなホストを保護する ために、End-of-Record オプション [TELNET:9] が導入された。しかし、適切に実装 された Telnet プログラムはこの保護を必要としない。 3.2.4 Telnet "Synch" シグナル: RFC-854, pp. 8-10 "緊急" TCP データを受信した場合、ユーザかサーバ Telnet は DM (と緊急の終了) が到着するまで、Telnet コマンドを除く全てのデータを破棄しなければならない ( MUST)。 Telnet IP (プロセス中断) を送信した場合、ユーザ Telnet は Telnet "Synch" シ ーケンスを後続させるべきである (SHOULD)。例えば、TCP 緊急データとして "IAC IP IAC DM" を送信する。TCP 緊急ポインタは DM オクテットを指す。 Telnet IP コマンドを受信した場合、サーバ Telnet は出力ストリームをフラッシュ するために、Telnet "Synch" シーケンスをユーザに返送してもよい (MAY)。その選 択は、ローカルユーザがプロセスを中断した時に、サーバオペレーティングシステム が動作する方法と一貫すべきである。 Telnet AO コマンドを受信した時、サーバ Telnet は出力ストリームをフラッシュす るために、Telnet "Synch" シーケンスをユーザに返送しなければならない (MUST)。 Telnet IP を送信した場合、ユーザ Telnet は出力をフラッシュすることが可能であ るべきである (SHOULD)。セクション 3.4.5 も参照されたい。 DISCUSSION: ユーザ Telnet がサーバ出力データのストリームをフラッシュする方法は三つある。 1. IP 後に AO を送信する。 これにより、サーバホストは "flush-buffered-output" シグナルをオペレーテ ィングシステムに送信する。しかし、AO はローカルには効力を生じないかもし れない。すなわち、サーバ Telnet が AO を受信し処理して "Synch" を返送す るまで、ユーザ Telnet の終端で端末出力を停止するかもしれない。 2. IP 後に DO TIMING-MARK [TELNET:7] を送信し、サーバ Telnet から WILL/WONT TIMING-MARK を受信するまで、全ての出力をローカルに破棄する。 DO TIMING-MARK はサーバで IP 後に処理されるので、それに応答することは出 力データストリームの正しい場所にいるはずである。しかし、TIMING-MARK は "flush buffered output" シグナルをサーバオペレーティングシステムに送信 しないかもしれない。これが必要か否かは、サーバオペレーティングシステム に依存する。 3. 両方とも行う Telnet 標準に様々な点で従っていない既存の数多くのサーバホストに適応させ なければならないので、最善の方法は完全には明確でない。最も安全なアプロ ーチは恐らく、(1),(2),(3) を選択できるユーザ制御可能なオプションを提供 することである。 3.2.5 NVT プリンタとキーボード: RFC-854, p. 11 NVT モードでは、Telnet は最上位ビットが 1 の文字を送信すべきではなく (SHOULD NOT)、パリティビットとして送信してはならない (MUST)。最上位ビットをアプリケ ーションに渡す実装体は、バイナリモードを折衝すべきである (SHOULD) (セクショ ン 3.2.6 参照)。 DISCUSSION: 厳密に RFC-854 を読むと、NVT ASCII を期待するクライアントやサーバは、最上位 ビットが設定された文字を無視してもよいことを、実装者は知っておくべきである。 一般には、拡張 (7 ビットを超えた) 文字セットを Telnet の転送で使用するには、 バイナリモードが期待される。 しかし、現在は定義されていないが、8 ビット NVT モードを実際に必要とするアプ リケーションが存在する。これらの既存のアプリケーションは、Telnet コネクショ ンが生きている一部、又は全ての間に、実際に最上位ビットを設定する。バイナリモ ードは 8 ビット NVT モードとは同じでないことに注意されたい。なぜならば、バイ ナリモードは行端処理を無効にするからである。この理由により、最上位ビットに関 する要件は MUST ではなく SHOULD として規定されている。 RFC-854 は、"ネットワーク仮想端末" あるいは NVT の特性のうち、最小限のセット を定義している。これは、実端末の追加機能を除外することは意味していない。 Telnet コネクションは、任意の ASCII 制御文字を含めて全ての 7 ビット ASCII 文 字に完全に透過的である。 例えば、端末は ASCII のエスケープシーケンスとしてコード化された、フルスクリ ーンコマンドをサポートしてもよい。Telnet 実装体は、これらのシーケンスを解釈 されないデータとして渡すだろう。従って、NVT は非常に制限されたデバイスの端末 タイプとして考えるべきではない。 3.2.6 Telnet コマンド構造: RFC-854, p. 13 オプションはデータストリームの如何なるポイントにも現れてよいので、データとし て送信する Telnet エスケープ文字 (IAC として知られ、値 255 を持つ) は二重に しなければならない (MUST)。 3.2.7 Telnet バイナリオプション: RFC-856 バイナリオプションが正常に折衝された時、任意の 8 ビット文字が許される。しか し、データストリームは依然として IAC 文字を検索しなければならず (MUST)、如何 なる組み込み Telnet コマンドにも従わなければならず (MUST)、IAC と等しいデー タバイトは二重にしなければならない (MUST)。他の文字処理 (例えば CR を CR NUL か CR LF に置き換える等) は行ってはならない (MUST NOT)。特に、バイナリモード には行端の規定 (セクション 3.3.1 参照) は存在しない。 DISCUSSION: Telnet コネクションを NVT モードから "バイナリモード" に変更するために、バイ ナリオプションは通常両方向で折衝される。 バイナリモードの Telnet ストリームの中で、データのブロックの範囲を定めるため に、IAC EOR シーケンスを使用できる。 3.2.8 Telnet 端末タイプオプション: RFC-1091 端末タイプオプションは、それらが特定の端末で利用できる場合、番号割り当て RFC [INTRO:5] で公式的に定義された端末タイプ名を使用しなければならない (MUST)。 しかし、端末タイプオプションの受信側は、如何なる名前も受け入れなければならな い (MUST)。 DISCUSSION: RFC-1091 [TELNET:10] は、RFC-930 で定義された以前のバージョンを更新してい る。以前のバージョンは、各々の物理端末が固有のタイプを持つものと仮定して、複 数の端末タイプをサポートできるサーバホストは、特定のクライアント端末のタイプ を知ることを許していた。しかし最近の "端末" は大抵、実際には PC で動いている 端末エミュレータプログラムであり、恐らくある範囲の端末タイプをエミュレートで きるだろう。従って RFC-1091 は、ユーザとサーバ Telnet 間でより一般的な端末タ イプの折衝を可能にするために、規定を拡張している。 3.3 特定の問題 3.3.1 Telnet 行端規定 Telnet プロトコルは、"行端" を意味する CR LF シーケンスを定義している。端末 入力では、これはユーザ端末でコマンド完了か "行端" キーを押下することに相当す る。ASCII 端末ではこれは CR キーであるが、"Return" あるいは "Enter" というラ ベルが付いているかもしれない。 サーバ Telnet が、リモート端末からの入力として Telnet 行端シーケンス CR LF を受信した場合、その効果はユーザがローカル端末で "行端" キーを押下したのと同 じでなければならない (MUST)。ASCII を使用するサーバホスト上では特に、Telnet シーケンス CR LF の受信は、ローカルユーザがローカル端末で CR キーを押下する のと同じ効果を持たなければならない。従って CR LF と CR NUL は、Telnet コネク ション上の入力として受信した場合、ASCII サーバホスト上では同じ効果を持たなけ ればならない (MUST)。 ユーザ Telnet は、CR LF, CR NUL, LF のどの形式も送信できなければならない ( MUST)。ASCII ホスト上のユーザ Telnet は、ユーザが "行端" キーを押下した時に CR LF か CR NUL のいずれかを送信するための、ユーザ指定可能なモードを持つべき であり (SHOULD)、CR LF がデフォルトであるべきである (SHOULD)。 Telnet 行端シーケンス CR LF は、端末からコンピューターへのデータではない Telnet データ (例えば、出力を送信するサーバ Telnet や別のアプリケーションプ ロトコルに組み込まれた Telnet プロトコル等) を送信するために使用しなければな らない (MUST)。 DISCUSSION: 任意の Telnet クライアントとサーバとの間の相互運用を可能にするために、Telnet プロトコルは行の終端の標準的な表現方法を定義した。ASCII 文字セットは明示的な 行端文字を含んでいないので、システムは例えば CR, LF, CR LF シーケンス等、 様々な表現方法を選択した。Telnet プロトコルは、ネットワーク転送の標準として CR LF シーケンスを選択している。 不幸にも、RFC-854 [TELNET:1] の Telnet プロトコル規定は、"行端" キーに対し何 の文字をクライアントからサーバへ送信すべきかについて、幾分曖昧であることが判 明した。その結果は大規模であり、相互運用性の面倒な問題が続いている。そして、 ユーザとサーバ Telnet の両方の様々な欠陥のある実装体によって、更に悪い状態に なっている。 Telnet プロトコルは完全に対称モデルに基づいており、リモートログインセッショ ンでは、端末でのユーザの役割はサーバホストの役割とは異なる。例えば、RFC-854 はサーバからの出力として CR, LF, CR LF の意味を定義しているが、ユーザが端末 上で "行端" キーを押下した時に、ユーザ Telnet が何を送信すべきかについては規 定していない。これが問題点であることが分かっている。 ユーザが "行端" キーを押下した時に、幾つかのユーザ Telnet 実装体は CR LF を 送信し、一方他のものは CR NUL を送信する (RFC-854 の同じ文の解釈が異なること による)。これらは上記で論じられているように、正しく実装された ASCII サーバホ ストと同様である。他のサーバに対してはユーザ Telnet にモードが必要である。 CR が押下された時に CR NUL しか送信しないユーザ Telnet が存在することによ り、非 ASCII ホストにジレンマが生じている。それは、CR NUL を入力中の CR LF と同等に扱うい、"裸" の CR を入力する可能性を除外するか、さもなくば完全な相 互動作を失うかである。 ホスト A 上のユーザがサーバホスト B にログインするために Telnet を使用し、そ の後 B のユーザ Telnet プログラムがサーバホスト C にログインすると仮定する。 B 上のサーバ/ユーザ Telnet の組み合わせは、可能な限り透過的であることが望ま しい。すなわち、あたかも A が直接 C に接続しているように見えることである。特 に正しい実装体は、CR LF を CR NUL、あるいはその逆に変換されるかもしれないこ とを除いて、B に Telnet の行端シーケンスを透過的にさせるだろう。 IMPLEMENTATION: Telnet 行端問題を理解するために、ローカルオペレーティングシステムへの Telnet に関連した、一般的なモデルを少なくとも持たなければならない。サーバ Telnet プ ロセスは通常、擬似端末としてのオペレーティングシステムの端末ドライバソフトウ エアに結合される。サーバ Telnet が受信した Telnet 行端シーケンスは、ローカル に接続された実端末上で行端キーを押下したのと同じ効果を持たなければならない。 対話型で一度に一文字ずつのアプリケーション (例えばエディタ) をサポートしてい るオペレーティングシステムは通常、それらの端末 I/O のための内部モードを持た なければならない。整形モードの場合、行端や他の整形規則のためのローカルな規約 がデータストリームに適用される。"生の" モードの場合、アプリケーションは入力 された通りに全ての文字に直接アクセスする。サーバ Telnet は、これらのモードが ローカル端末と同じ効果をリモートに対して持つように実装しなければならない。例 えば、ASCII ホスト上のサーバ Telnet が CR LF か CR NUL を受信すると仮定す る。生のモードの場合、CR 文字がアプリケーションに渡され、整形モードの場合、 ローカルシステムの行端規約が使用される。 3.3.2 データ登録端末 DISCUSSION: Telnet が設計された行型と文字型の ASCII 端末に加えて、"データ登録端末" ある いは DET として知られているビデオディスプレイ端末の幾つかのファミリが存在す る。IBM 3270 ファミリは、一般によく知られている例である。 一般的な DET をサポートするために、二つのインターネットプロトコルが設計され ている。それは、SUPDUP [TELNET:16], [TELNET:17] と DET オプション [TELNET:18], [TELNET:19] である。DET オプションは、(サブ) 折衝を使用して Telnet コネクション上でデータ登録端末を制御する。SUPDUP は完全に独立した端末 プロトコルであり、折衝によって Telnet から入ることができる。SUPDUP と DET オ プションの両方を、ある特定の環境で正常に使用することができるが、一般には受け 入れられておらず、広く実装されてもいない。 如何なる DET に対しても同じアプローチが適用可能だが、Telnet を通じて IBM 3270 ファミリをサポートするために、対話型 DET への別のアプローチが開発されて いる。考え方は "ネイティブ DET" モードに入ることであり、ネイティブ DET 入出 力ストリームはバイナリデータとして送信される。バイナリストリームの中で論理レ コードの境界 (例えば "画面") を設定するには、Telnet EOR コマンドを使用する。 IMPLEMENTATION: ネイティブ DET モードに出入りするための規則は以下の通り。 * Server は、クライアントが DET であることを認識するために、端末タイプオ プション [TELNET:10] を使用する。 * 両端が EOR オプション [TELNET:9] を折衝することは伝統的であるが、必須要 件ではない。 * ネイティブ DET モードに入るために、両端はバイナリオプション [TELNET:3] を折衝する。 * 一方の終端がバイナリモードから出るよう折衝したら、もう一方の終端も出 て、モードは通常 NVT に戻る。 3.3.3 オプション要件 全ての Telnet 実装体は、バイナリオプション [TELNET:3] と Go Ahead の抑制オプ ション [TELNET:5] をサポートしなければならず (MUST)、エコー [TELNET:4]、状態 [TELNET:6]、レコードの終端 [TELNET:9]、拡張オプションリスト [TELNET:4] オプ ションをサポートすべきである (SHOULD)。 ユーザかサーバ Telnet は、もしローカルのオペレーティングシステムが対応する能 力を提供するならば、ウィンドウサイズオプション [TELNET:12] をサポートすべき である (SHOULD)。 DISCUSSION: レコードの終端オプションは、Telnet がクラッシュせずに Telnet EOR を 受信でき ることのみ示すことに注意されたい。従って、全ての Telnet はレコーザの終端オプ ションの折衝を自発的に受け入れるべきである。セクション 3.2.3 の議論も参照さ れたい。 3.3.4 オプションの起動 Telnet プロトコルをクライアント/サーバ環境で使用する場合、サーバは期待した端 末対話型モードの折衝を起動すべきである (SHOULD)。 DISCUSSION: Telnet プロトコルは完全に対称になるよう定義されたが、そのアプリケーションは 通常非対象である。リモートログインはどちら側も必要な非デフォルトの端末モード の折衝を起動しないので、失敗することがよく知られている。一般に望ましいモード を決定するのはサーバなので、サーバが折衝を起動する必要がある。折衝は対称なの で、ユーザも起動することができる。 クライアント (ユーザ Telnet) は、ユーザがオプション折衝の起動を有効にしたり 無効にするための手段を提供すべきである (SHOULD)。 DISCUSSION: ユーザは時々、制御ストリームのために Telnet を使用するが、Telnet オプション をサポートしないアプリケーションサービス (FTP や SMTP 等) に接続する必要があ る。もしオプション折衝の起動が無効ならば、この目的でユーザ Telnet を使用して もよい。 3.3.5 Telnet 行モードオプション DISCUSSION: 重要な新しい Telnet オプション、LINEMODE [TELNET:12]、が提案された。LINEMODE オプションは、サーバではなくクライアントが端末の文字処理を実行することを、ユ ーザ Telnet とサーバ Telnet が合意するための標準的な方法を提供する。クライア ントがテキストの行を完結する準備をした時に、1 つの TCP パケットをサーバに (通常) 送信する。このオプションは Telnet セッションのパケットコストを大幅に 減らし、輻輳した、あるいは遅延の長いネットワーク上で、より優れたユーザレスポ ンスを提供する。 LINEMODE オプションは、ローカルとリモートの文字処理の動的な切替を可能にす る。例えば、フルスクリーンエディタが動作している間は、Telnet コネクションは 自動的に単一文字モードになるよう折衝し、そしてエディタが終了した時に行モード に戻る。 この RFC がリリースされる時、ホストはこのオプションのクライアント側を実装す べきであり、このオプションのサーバ側を実装してもよいことが期待される。サーバ 側を適切に実装するために、サーバは如何なる入力文字の処理も行わないが、現在の 端末状態を覚えておき、その状態が変わったら必ずサーバ Telnet プロセスに通知す ることを、ローカルシステムに通知できる必要がある。これによって、例えばパスワ ードのエコーやフルスクリーンエディタを適切に扱うことができる。 3.4 Telnet/ユーザ間のインタフェース 3.4.1 文字セットの透過性 ユーザ Telnet の実装体は、如何なる 7 ビット ASCII 文字も送受信できるべきであ る (SHOULD)。可能ならば、ユーザホストのオペレーティングシステムによる如何な る特殊文字の解釈も迂回すべきである (SHOULD)。それにより、これらの文字をコネ クション上で都合良く送受信することができる。 幾つかの文字の値は "コマンドモードへのエスケープ" として予約しなければならな い (MUST)。慣例的にこの文字を二つ合わせることにより、それをデータとして入力 することができる。使用される特殊文字は、ユーザにより選択可能であるべきである (SHOULD)。 バイナリモードコネクションでは、もしホストオペレーティングシステムが、任意の 8 ビット値をキーボードから直接入力できないならば、ユーザ Telnet プログラムが それらの値を入力するために、エスケープメカニズムを提供してもよい (MAY)。 IMPLEMENTATION: 透過性の問題はサーバにはさほど重いものではないが、NVT ASCII だけを期待したプ ログラムや 8 ビットのデータストリームを要求する適切に処理するプログラムに届 く前に、(古く適合していないクライアントによって送信された) パリティビットの マスクを外すような問題の扱いに、実装者は注意を払うべきである。 3.4.2 Telnet コマンド ユーザ Telnet プログラムは、ユーザに Telnet 制御機能 IP, AO, AYT を入力する 手段を提供しなければならず (MUST)、EC, EL Break を入力する手段を提供すべきで ある (SHOULD)。 3.4.3 TCP コネクションエラー ユーザ Telnet プログラムは、トランスポート層に通知された ([INTRO:1] の "TCP/ アプリケーション層インタフェース" のセクション参照) 如何なる TCP エラーもユ ーザに通知すべきである (SHOULD)。 3.4.4 デフォルトでない Telnet 接続ポート ユーザ Telnet プログラムは、ユーザがサーバ Telnet ホストの非標準の接続ポート 番号を任意に指定することを可能にすべきである (SHOULD)。 3.4.5 出力のフラッシュ ユーザ Telnet プログラムは、IP が送信されたときに出力をフラッシュすべきか否 かを指定する手段を、ユーザに提供すべきである (SHOULD)。セクション 3.2.4 を参 照されたい。 サーバから Telnet のシグナルを受信するまで、ユーザ Telnet に出力をローカルに フラッシュさせる如何なる出力フラッシュスキームにおいても、サーバが期待された シグナルを送信できない場合に、ユーザが手動で通常の出力を復元するための方法が 存在すべきである (SHOULD)。 3.5. Telnet 要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | オプション折衝 |3.2.1 |x| | | | | 折衝のループを回避する |3.2.1 |x| | | | | 未サポートのオプションを拒否する |3.2.1 |x| | | | | コネクション上では常に折衝 OK |3.2.1 | |x| | | | デフォルトを NVT にする |3.2.1 |x| | | | | 端末タイプオプションで公式な名前を送信する |3.2.8 |x| | | | | 端末タイプオプションで如何なる名前も受諾する |3.2.8 |x| | | | | バイナリと GA 抑制オプションをサポートする |3.3.3 |x| | | | | エコー、状態、EOL, Ext-Opt-List オプション |3.3.3 | |x| | | | 適切ならばウィンドウサイズオプションをサポート |3.3.3 | |x| | | | サーバがモード折衝を起動する |3.3.4 | |x| | | | ユーザが折衝の起動を有効化/無効化できる |3.3.4 | |x| | | | | | | | | | | Go-Aheads | | | | | | | GA 無しのサーバが GA 抑制オプションを折衝する |3.2.2 |x| | | | | ユーザかサーバが GA 抑制オプションを受諾する |3.2.2 |x| | | | | ユーザ Telnet が GA を無視する |3.2.2 | | |x| | | | | | | | | | 制御機能 | | | | | | | SE NOP DM IP AO AYT SB をサポート |3.2.3 |x| | | | | EOR EC EL Break をサポート |3.2.3 | | |x| | | 未サポートの制御機能を無視する |3.2.3 |x| | | | | ユーザ、サーバが DM まで緊急データを破棄する |3.2.4 |x| | | | | ユーザ Telnet が IP,AO,AYT 後に "Synch" を送信 |3.2.4 | |x| | | | サーバ Telnet が IP に対して Synch を返送 |3.2.4 | | |x| | | サーバ Telnet が AO に対して Synch を返送 |3.2.4 |x| | | | | ユーザ Telnet が IP 送信時に出力をフラッシュ |3.2.4 | |x| | | | | | | | | | | 符号化 | | | | | | | NVT モードで最上位ビットを送信 |3.2.5 | | | |x| | 最上位ビットをパリティビットとして送信 |3.2.5 | | | | |x| 最上ビットをアプリに渡すならばバイナリを折衝 |3.2.5 | |x| | | | IAC データバイトを常に二重にする |3.2.6 |x| | | | | バイナリモードで IAC データバイトを二重にする |3.2.7 |x| | | | | バイナリモードで Telnet コマンドに従う |3.2.7 |x| | | | | バイナリモードで行端を CR NUL に |3.2.7 | | | | |x| | | | | | | | 行端 | | | | | | | サーバでの EOL はローカルの行端と同じ |3.3.1 |x| | | | | ASCII サーバが EOL として CR LF, CR NUL を受諾 |3.3.1 |x| | | | | ユーザ Telnet が CR LF, CR NUL, LF を送信可能 |3.3.1 |x| | | | | ASCII ユーザが CR LF/CR NUL を選択できる |3.3.1 | |x| | | | ユーザ Telnet のデフォルトモードは CR LF |3.3.1 | |x| | | | 非対話型で EOL として CR LF を使用する |3.3.1 |x| | | | | | | | | | | | ユーザ Telnet インタフェース | | | | | | | 7 ビット文字を全て送受信できる |3.4.1 | |x| | | | ローカルの OS の解釈を迂回する |3.4.1 | |x| | | | エスケープ文字 |3.4.1 |x| | | | | エスケープ文字をユーザが設定可能 |3.4.1 | |x| | | | 8 ビット値を入力するためにエスケープする |3.4.1 | | |x| | | IP, AO, AYT を入力できる |3.4.2 |x| | | | | EC, EL, Break を入力できる |3.4.2 | |x| | | | TCP コネクションエラーをユーザに通知する |3.4.3 | |x| | | | 任意の非デフォルトの接続ポート |3.4.4 | |x| | | | IP 送信時に出力をフラッシュするか指定できる |3.4.5 | |x| | | | 出力モードを手動で復元できる |3.4.5 | |x| | | | | | | | | | | 4. ファイル転送 4.1 ファイル転送プロトコル -- FTP 4.1.1 導入 ファイル転送プロトコル FTP は、ファイル転送のための基本的な標準である。現在 の規定は RFC-959 [FTP:1] に含まれている。 FTP は制御とデータ転送のために、別々の同時に存在する TCP コネクションを使用 する。FTP プロトコルは数多くの機能を含み、それらの幾つかは通常は実装されな い。しかし、FTP の全ての機能において少なくとも一つの実装が存在する。RFC-959 で定義された最小限の実装は小さすぎるので、若干大きな最小実装をここで定義す る。 インターネットユーザは、不十分な FTP 実装のために、数年もの間不要な負担を強 いられている。プロトコル実装者は、FTP の実装は小さく平凡な仕事であるべきとい う誤った意見に苛まれていた。FTP はユーザインタフェースを持ち、通信やオペレー ティングシステムの広く多岐に渡る発生するかもしれないエラーを (正しく) 扱わな ければならず、世界中の非常に多種多様な実ファイルシステムを扱わなければならな いので、これは誤りである。 4.1.2. プロトコルウォークスルー 4.1.2.1 ローカルタイプ: RFC-959 セクション 3.1.1.4 FTP プログラムは、TYPE L 8 (論理バイト長 8 の "LOCAL" タイプ) だけでなく、 TYPE I ("IMAGE" またはバイナリタイプ) もサポートしなければならない (MUST)。 メモリが m ビットワードで構成されるマシンで、m が 8 の倍数ではない場合は、 TYPE L m もまたサポートしてもよい (MAY)。 DISCUSSION: コマンド "TYPE L 8" は、メモリが (例えば) 36 ビットワードに構成されるマシン と 8 ビットバイト構成のマシン間で、バイナリデータを転送するためにしばしば必 要になる。8 ビットバイトのマシンでは、TYPE L 8 は IMAGE と同等である。 "TYPE L m" は時々、二つの m ビットワードのマシン上で、あるマシンから別のマシ ンへ、ネイティブモードのバイナリファイルを正しく転送することをを保証するため に FTP プログラムに指定される。しかし、このコマンドは、これらのマシンでの "TYPE I" と同じ効果を持つべきである。 4.1.2.2 Telnet フォーマット制御: RFC-959 セクション 3.1.1.5.2 TYPE T と TYPE I に相違が無いホストは、TYPE T と TYPE N を同一に実装すべきで ある (SHOULD)。 DISCUSSION: この規定により、これを区別するホストとの相互運用が容易になるはずである。 多くのホストは、テキストファイルを内部的に ASCII 文字の列として表し、ファイ ルを印字する時にフォーマットを制御するために、組み込まれた ASCII フォーマッ ト効果文字 (LF, BS, FF, ...) を使用する。そのようなホストは、"印字" ファイル と他のファイルとを区別しない。しかし、レコード構造のファイルを使用するシステ ムは、印字可能なファイル (例えば ASA 改行制御) のために、通常特殊なフォーマ ットが必要である。後者のホストの場合、FTP は TYPE N か TYPE I の選択を可能と している。 4.1.2.3 ページ構造: RFC-959 セクション 3.1.2.3 と 付録 I ページ構造の実装は、一般には推奨されていない (NOT RECOMMENDED)。しかし、もし ホストシステムが、"ランダムアクセス" あるいは "穴明き" ファイルの FTP を本当 に実装する必要があるならば、新しい私的な FTP フォーマットを定義せずに、既に 定義されたページ構造フォーマットを使用しなければならない (MUST)。 4.1.2.4 データ構造変換: RFC-959 セクション 3.1.2 相手ホストで結果を可能な限り有効にするために、レコード構造とファイル構造間の FTP 変換は可逆性を持つべきである (SHOULD) DISCUSSION: RFC-959 はレコード構造とファイル構造間の厳密な可逆性を求めているが、実際は効 率と便宜により妨げられている。従って、この要件は緩和されつつある。ファイル転 送には二つの異なる目的がある。それは相手ホストでファイルを処理するか単に格納 することである。格納においては、厳密な可逆性が重要である。処理においては、相 手ホストで作成されたファイルは、そのホストのアプリケーションプログラムによっ て期待されたフォーマットであることを必要とする。 衝突の例として、各レコードが正確に 80 バイトである幾つかのデータファイルを必 要とするレコード型オペレーティングシステムを想定する。そのホストにファイルを 格納 (STOR) する間、FTP サーバは各々の行かレコードを 80 バイトにパディングで きなければならない。そうようなファイルを後で戻すことは、厳密に可逆性があるは ずがない。 4.1.2.5 データコネクション管理: RFC-959 セクション 3.3 STREAM モードを使用するユーザ FTP は、各々の転送コマンドを発行する前にデフォ ルトでないデータポートを割り当てるために、PORT コマンドを送信すべきである ( SHOULD)。 DISCUSSION: これは、単一の FTP セッションの間に複数の転送を可能にする場合、TCP コネクシ ョンがクローズされた後、ソケットのペアが再利用できるまでの遅延が長いために必 要である。ポートコマンドの送信は、もしストリーム以外の転送モードが使用されて いれば、転送の間、データ転送コネクションをオープンしたままにすることによって 回避できる。 4.1.2.6 PASV コマンド: RFC-959 セクション 4.1.2 サーバ FTP は PASV コマンドを実装しなければならない (MUST)。 もし複数のサードパーティ転送が同一セッション中に実行されたら、ユニークなポー トのペアを獲得するために、各々の転送コマンドの前に新たな PASV コマンドを発行 しなければならない (MUST)。 IMPLEMENTATION: PASV コマンドに対する 227 応答のフォーマットは、うまく標準化されていない。特 に、FTP クライアントは RFC-959 のページ 40 にある括弧が存在するものとは想定 できない (実際、ページ 43 の図 3 では括弧が省略されている)。従って、PASV 応 答を解釈するユーザ FTP プログラムは、ホストとポート番号の一番目の数字につい て、応答を調べなければならない。 ホスト番号 h1,h2,h3,h4 は、その応答を送信するサーバホストの IP アドレスであ り、p1,p2 は PASV が割り当てたデフォルトでないデータ転送ポートであることに注 意されたい。 4.1.2.7 LIST と NLIST コマンド: RFC-959 セクション 4.1.3 NLST コマンドによって返却されたデータは、規定に合ったパス名の簡単なリストの み含まなければならない (MUST)。例えば、続いて起こる個々のファイルに対するデ ータ転送コマンドのアーギュメントとして、サーバが直接使用できるようなものであ る。 LIST や NLST コマンドによって返却されたデータは、もし現在のタイプが EBCDIC でなければ、暗黙的に TYPE AN を使用すべきである (SHOULD)。タイプが EBCDIC で ある場合は、暗黙的に TYPE EN を使用すべきである (SHOULD)。 DISCUSSION: 多くの FTP クライアントは、ワイルドカード指定に一致するファイルを送受信する マクロコマンドをサポートし、パス名のリストを取得するために NLST を使用する。 "複数送信" の拡張はクライアントにローカルであるが、"複数受信" はサーバと協同 する必要がある。 LIST と NLST の暗黙タイプは、既存のユーザ FTP、特に複数受信コマンドとの互換 性を提供するために設計されている。 4.1.2.8 SITE コマンド: RFC-959 セクション 4.1.3 サーバ FTP は標準でない機能に対し、新たな私用コマンドや既存のコマンドの非標 準の拡張を創案せずに、SITE コマンドを使用すべきである (SHOULD)。 4.1.2.9 STOU コマンド: RFC-959 セクション 4.1.3 STOU コマンドは、ユニークな名前が付けられたファイルに格納する。STOU コマンド を受信した場合、サーバ FTP は転送の前の "125 転送開始" や "150 データコネク ションのオープン" メッセージに (RFC-959 で述べられている 250 応答コードは誤 りである)、実際のファイル名を返却しなければならない (MUST)。これらのメッセー ジの正確なフォーマットは、ここでは以下のように定義する。 125 FILE: pppp 150 FILE: pppp 上記の pppp は、書き込まれるファイルのユニークなパス名を表している。 4.1.2.10 Telnet 行端コード: RFC-959, ページ 34 実装者は、制御コネクション上の READ 境界と Telnet EOL シーケンス (CR LF) が 一致すると仮定してはならない (MUST NOT)。 DISCUSSION: 従って、サーバ FTP (あるいはユーザ FTP) は、コマンド (あるいは応答) を処理す る前に、完全な Telnet EOL シーケンスが現れるまで制御コネクションからの文字の 読み込みを続けなければならない。逆に言えば、一回の READ で制御コネクションか ら一つ以上の FTP コマンドが含まれるかもしれない。 4.1.2.11 FTP 応答: RFC-959 セクション 4.2, ページ 35 サーバ FTP は、制御コネクション上で正しいフォーマットの応答を送信しなければ ならない (MUST)。RFC-959 は (FTP 規定の以前のバージョンとは異なり)、"自発的 な" 応答メッセージに対する準備を含んでいないことに注意されたい。 サーバ FTP は適用される場合は常に、RFC-959 で定義された応答コードを使用すべ きである (SHOULD)。しかし、サーバ FTP はセクション 4.2 の一般規則に従う限り において、必要な場合は異なる応答コードを使用してもよい (MAY)。実装者が 4xx と 5xx の応答コードの間を選択した場合、失敗した FTP が数時間後には成功するだ ろうという理に適った可能性がある時は、サーバ FTP は 4xx (一時的失敗) コード を送信すべきである (SHOULD)。 ユーザ FTP は、処理上の決定を行う場合、サーバ FTP が標準でない応答コードを使 う時に問題を避けるために、3 つの数字の応答コードのうち最上位の数字のみを一般 に使用すべきである (SHOULD)。 ユーザ FTP は、複数行の応答を扱えなければならない (MUST)。もし実装体が行数に 制限を課していて、この制限を越えたならば、ユーザ FTP は例えば複数行応答の最 後に達するまで、超えた行を無視すること等によって、復旧しなければならない ( MUST)。 ユーザ FTP は特に、421 応答コード ("サービス利用不可、制御コネクションをクロ ーズ") を解釈すべきではない (SHOULD NOT) が、サーバによる制御コネクションの クローズを検出すべきである (SHOULD)。 DISCUSSION: 応答規則に厳密に従っていないサーバ実装は、しばしば FTP ユーザプログラムのハ ングアップを引き起こす。RFC-959 は、以前の FTP 規定に見られた応答規則の曖昧 さを解消しており、これに従わなければならない。 ファイル転送クライアントデーモンの正常な使用を可能にするために、一時的と永続 的の障害を適切に区別する FTP 応答コードを選択することは重要である。これらの プログラムは、失敗した転送を再試行するか否かを決定するのに応答コードに頼って いる。一時的エラーで永続的失敗コード (5xx) を使用すると、これらのプログラム は不必要に諦めてしまうだろう。 応答の意味が RFC-959 に示されているテキストに正確に一致する場合、RFC-959 の テキストと全く同じ言葉を使用することによって均一性が高まる。しかし、サーバ FTP 実装者は、特定のシステム依存情報を送る応答テキストを適宜選択することが推 奨される。 4.1.2.12 コネクション: RFC-959 セクション 5.2 RFC-959 のこのセクションの二段落目にある "and the port used" という表記は誤 り (旧式) であり、無視すべきである。 マルチホーム化されたサーバホストの場合、デフォルトのデータ転送ポート (L-1) は、ポート L への制御コネクションに対応する同じローカル IP アドレスに割り当 てなければならない (MUST)。 ユーザ FTP は、FTP 制御コネクションに、SYNCH と IP 以外の如何なる Telnet 制 御も送信してはならない (MUST NOT)。特に、制御コネクションで Telnet オプショ ンの折衝を試みてはならない (MUST NOT)。しかし、サーバ FTP は、Telnet 折衝を 受諾したり拒否 (すなわち DONT/WONT を送信) できなければならない (MUST)。 DISCUSSION: RFC は "サーバとユーザの処理は、[制御コネクションでは] Telnet プロトコルの規 定に従うべきである" と述べているが、Telnet オプション折衝が用いられることは 意図していない。 4.1.2.13 最小限の実装: RFC-959 セクション 5.1 以下のコマンドとオプションは、下位のファイルシステムやオペレーティングシステ ムが特定のコマンドを許していないか、サポートしていない場合を除いて、全てのサ ーバ FTP とユーザ FTP がサポートしなければならない (MUST)。 タイプ: ASCII Non-print, IMAGE, LOCAL 8 モード: ストリーム 構造: ファイル、レコード(*) コマンド: USER, PASS, ACCT, PORT, PASV, TYPE, MODE, STRU, RETR, STOR, APPE, RNFR, RNTO, DELE, CWD, CDUP, RMD, MKD, PWD, LIST, NLST, SYST, STAT, HELP, NOOP, QUIT. (*)レコード構造は、ファイルシステムがレコード構造をサポートしているホストの み必要とされる (REQUIRED)。 DISCUSSION: ベンダーは、プロトコルのより大きなサブセットを実装することが推奨される。例え ば、このプロトコルには重要な頑強性を持つ機能 (例えば、再開始、ABOR、ブロック モード) が存在し、それらはインターネットユーザを補助するが、広く実装されては いない。 ファイルシステムにレコード構造を持たないホストでも、STRU R を受け付けて、文 字通りバイトスリームをレコード化してもよい。 4.1.3 特定の問題 4.1.3.1 非標準コマンドの動作 FTP は、"X" で始まる名前を持つ "実験的な" コマンドを許している。もし、これら のコマンドが後に標準として採用されても、"X" 形式を使用する既存の実装が存在し てもよい。現在、ディレクトリコマンドがこれに該当する。 RFC-959 "実験的" MKD XMKD RMD XRMD PWD XPWD CDUP XCUP CWD XCWD 全ての FTP 実装体は、コマンド検索テーブルに余分にエントリを設けて単に等しい とみなすことによって、これらのコマンドの両方の形式を認識すべきである ( SHOULD)。 IMPLEMENTATION: ユーザ FTP が "X" 形式しかサポートしていないサーバへのアクセスを可能にするに は、モード切り替えを実装するか、次の手続きを自動的に使用する。もし上記コマン ドのうちの一つの RFC-959 形式が 500 か 502 の応答コードで拒否されたら、実験 形式を試す。そして、他の如何なる応答もユーザに渡す。 4.1.3.2 アイドルタイムアウト サーバ FTP プロセスは、もしサーバが長い間無活動 (すなわちコマンドやデータ転 送が進行しない) ならば、処理を終了して制御コネクションをクローズするアイドル タイムアウトを持つべきである (SHOULD)。アイドルタイムアウト時間は設定可能で あるべきであり (SHOULD)、デフォルトは少なくとも 5 分にすべきである。 クライアント FTP プロセス (RFC-959 における "User-PI") は、プログラムから起 動された場合に限り、応答に対するタイムアウトを必要とする。 DISCUSSION: タイムアウトが無ければ、もし対応するクライアントが制御コネクションをクローズ せずにクラッシュしたら、サーバ FTP プロセスは永久にペンディングのままかもし れない。 4.1.3.3 データと制御の協調 DISCUSSION: データ転送が進行中にいつでもユーザが STAT コマンドを送信できるべきであること と、サーバ FTP がこれまで転送されたバイト数等の状態を即座に応答することが、 FTP 設計者の意図である。同様に、データ転送中はいつでも ABOR コマンドが可能で あるべきである。 不幸にも、幾つかの小規模マシンのオペレーティグシステムでは、こうした協調プロ グラミングが困難であり、他の幾つかの実装者は最低限の解決方法を求めている。従 って、幾つかの FTP 実装体はデータと制御コネクションの協調して使用できない。 そのような最低限のサーバであっても、データ転送中に到着した STAT や ABOR コマ ンドを受諾する準備をしなければならない。 4.1.3.4 FTP 再開メカニズム RFC-959 のページ 40-41 にある 110 応答の説明は誤りである。正しい説明は次の通 り。受信側 FTP からユーザ FTP への制御コネクション上に送信される再開応答メッ セージは、以下の形式を持つ。 110 MARK ssss = rrrr ここでは、 * ssss は、データストリームの中の再開マーカとして出現するテキスト文字列で あり、送信側のファイルシステムにおける位置を符号化する。 * rrrr は、受信側のファイルシステムで対応する位置を符号化する。 符号化は、あるファイルシステムやネットワーク実装に特定であり、送信側か受信側 のいずれかの同じシステムによって、常に生成され解釈される。 再開を実装した FTP がデータストリーム中に再開マーカを受信した場合、対応する 位置 rrrr を符号化する前に、そのポイントまでのデータを安定したストレージに強 制的に書き込むべきである (SHOULD)。再開マーカを送信する FTP は、110 応答がデ ータと同期して返却されると仮定してはならない (MUST NOT)。すなわち、さらにデ ータを送る前に 110 応答を待ってはならない。 転送の再開で発生したエラーのために、二つの新しい応答コードをここで定義する。 554 Requested action not taken: invalid REST parameter. (要求されたアクションは行われない: 不正な REST パラメタ) 554 応答は、REST コマンドに続く FTP サービスコマンドの結果で返却してもよい。 この応答は、サーバ FTP の既存のファイルは REST で指定された通りに位置を変え ることができないことを示す。 555 Requested action not taken: type or stru mismatch. (要求されたアクションは行われない: type か stru が不整合) 555 応答は、REST コマンドに続く APPE コマンドか FTP サービスコマンドの結果で 返却してもよい。この応答は、現在の転送パラメタ (type か stru) と既存のファイ ルの属性との間に、何らかの不整合があることを示す。 DISCUSSION: FTP 再開メカニズムは、データストリームの中に再開マーカを含めることを可能にす るために、データ転送でブロックモードが圧縮モードを使用する必要があることに注 意されたい。再開マーカの出現頻度は低くできる。 再開マーカはデータストリーム中の場所をマークするが、受信側はストレージに格納 する時に、データに対して何らかの変換を実行してもよい。通常、受信側の符号化 は、FTP データストリームの如何なる点においても、この変換を再開するために必要 な全ての状態情報を含まなければならない。例えば TYPE A 転送では、ある受信側ホ ストは CR LF シーケンスを単一の LF 文字にディスク上に変換する。もし再開マー カがたまたま CR と LF の間にあるならば、受信側は "CR を見つけて破棄する" 状 態で転送を再開しなければならない rrrr で符号化しなければならない。 再開マーカはデータのタイプに関わらず、印字可能な ASCII 文字の文字列として符 号化する必要があることに注意されたい。 RFC-959 は、再開情報は "ユーザに" 返却されると述べている。これは文字通り行う べきではない。通常、ユーザ FTP は再開情報 (ssss,rrrr) を、例えば再開制御ファ イルに追加する等、安定したストレージに保存すべきである。最初に転送が始まった 時に空の再開制御ファイルを作成し、転送が正常に完了した時に自動的に削除すべき である。このファイルは、転送しようとしているファイル名とリモートのホスト名か ら、容易に識別できる方法で導き出された名前を付けることが提案されている。これ は、テキストエディタの多くが "バックアップ" ファイルの名前をつけるために使用 する手段に似ている。 FTP の再開には三つのケースが存在する。 1. ユーザからサーバへの転送 ユーザ FTP は、データストリーム中の都合の良い箇所に再開マーカ を 付ける。サーバ FTP がマーカを受信した時、それより前のデータを全てディス クに書き込み、そのファイルシステムの位置と変換状態を rrrr として符号化 し、"110 MARK ssss = rrrr" 応答を制御コネクション上に返却する。ユーザ FTP は、(ssss,rrrr) の組を再開制御ファイルに追加する。 転送を再開するには、ユーザ FTP は最後の (ssss,rrrr) の組を再開制御ファ イルから取り込み、ssss を使用してローカルファイルシステムの位置と変換状 態を変更し、"REST rrrr" コマンドをサーバ FTP に送信する。 2. サーバからユーザへの転送 サーバ FTP は、データストリーム中の都合の良い箇所に再開マーカ を 付ける。ユーザ FTP がマーカを受信した時、それより前のデータを全てディス クに書き込み、そのファイルシステムの位置と変換状態を rrrr として符号化 し、"110 MARK ssss = rrrr" 応答を制御コネクション上に返却する。ユーザ FTP は、(ssss,rrrr) の組を再開制御ファイルに追加する。 転送を再開するには、ユーザ FTP は最後の (ssss,rrrr) の組を再開制御ファ イルから取り込み、ssss を使用してローカルファイルシステムの位置と変換状 態を変更し、"REST ssss" コマンドをサーバ FTP に送信する。 3. サーバからサーバ ("第三者") への転送 サーバ FTP は、データストリーム中の都合の良い箇所に再開マーカ を 付ける。マーカを受信した時、受信側サーバ FTP はそれより前のデータを全て ディスクに書き込み、そのファイルシステムの位置と変換状態を rrrr として 符号化し、"110 MARK ssss = rrrr" 応答を、ユーザへの制御コネクション上に 返却する。ユーザ FTP は、(ssss,rrrr) の組を再開制御ファイルに追加する。 転送を再開するには、ユーザ FTP は最後の (ssss,rrrr) の組を再開制御ファ イルから取り込み、"REST ssss" コマンドを送信側サーバ FTP に送信し、 "REST rrrr" コマンドを受信側サーバ FTP に送信する。 4.1.4 FTP/ユーザインタフェース このセクションは、ユーザ FTP プログラムのインタフェースを論じる。 4.1.4.1 パス名の規定 FTP は異種環境で使用されることを意図しているので、ユーザ FTP の実装体はリモ ートのパス名を任意の文字列でサポートしなければならない (MUST)。よって、それ らの形式や内容は、ローカルのオペレーティングシステムの約束事によって制限され ない。 DISCUSSION: 特に、リモートのパス名は任意の長さになる可能性があり、空白 (0x20) だけでなく 全ての印字 ASCII 文字も許さなければならない。RFC-959 は、CR と LF を除く如何 なる 7 ビット ASCII 文字も含むことを許可している。 4.1.4.2 "QUOTE" コマンド ユーザ FTP プログラムは、任意の文字列をサーバに渡し、結果として生じた全ての 応答メッセージをユーザに表示する "QUOTE" コマンドを実装しなければならない ( MUST)。 "QUOTE" コマンドを有効にするには、ユーザ FTP は全てのコマンドを保持してデー タ転送が開始した時にのみサーバに送信するのではなく、ユーザが転送制御コマンド を入力した時に、それらをサーバに送信すべきである (SHOULD)。 DISCUSSION: "QUOTE" コマンドは、ユーザがシステム特定のコマンド (SITE や ALLO 等) を必要 とするサーバへのアクセスを可能としたり、ユーザ FTP に実装されていない新しい か任意の機能を呼び出すことを可能にするために重要である。例えば "QUOTE" は、 たとえユーザ FTP がその TYPE を認識しなくても、区別を必要とするホストに印刷 ファイルを送信するために "TYPE A T" を指定するのに使用してもよい。 4.1.4.3 ユーザへの応答表示 ユーザ FTP は、受信した全てのエラーメッセージのテキスト全体をユーザに表示す べきである (SHOULD)。問題の診断のために、送信する全てのコマンドや受信したテ キスト全体と応答コードを表示する "冗長" モードを持つべきである (SHOULD)。 4.1.4.4 同期の維持 ユーザ FTP 中の状態マシンは、サーバとのコマンドの同期を維持するために、応答 メッセージの欠落や期待しない応答を許すべきである (SHOULD)。 4.1.5 FTP 要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -------------------------------------------|---------------|-|-|-|-|-|-- TYPE N と同じなら TYPE T を実装する |4.1.2.2 | |x| | | | 可能ならファイル/レコード変換の可逆性 |4.1.2.4 | |x| | | | ユーザ FTP はストリームモードで PORT 送信 |4.1.2.5 | |x| | | | サーバ FTP は PASV を実装する |4.1.2.6 |x| | | | | 転送毎に PASV |4.1.2.6 |x| | | | | NLST の応答が RETR コマンドで使用可能 |4.1.2.7 |x| | | | | LIST と NLST の暗黙なタイプ |4.1.2.7 | |x| | | | 非標準機能で SITE コマンド |4.1.2.8 | |x| | | | STOU コマンドは規定通りにパス名を返却する |4.1.2.9 |x| | | | | 制御コネクション上で TCP READ 境界を使う |4.1.2.10 | | | | |x| | | | | | | | サーバ FTP は正しい応答形式のみ使う |4.1.2.11 |x| | | | | サーバ FTP は可能なら定義済みの応答を使う |4.1.2.11 | |x| | | | 新しいコードはセクション 4.2 に従う |4.1.2.11 | | |x| | | ユーザ FTP は応答の最上位の数字のみ使う |4.1.2.11 | |x| | | | ユーザ FTP は複数行の応答を処理する |4.1.2.11 |x| | | | | ユーザ FTP は 421 応答を特別に扱う |4.1.2.11 | | | |x| | | | | | | | | デフォルトデータポートは制御 conn と同じIP |4.1.2.12 |x| | | | | ユーザ FTP がSYNCH,IP以外のTelnet cmd 送信 |4.1.2.12 | | | | |x| ユーザ FTP が Telnet オプションを折衝する |4.1.2.12 | | | | |x| サーバ FTP が Telnet オプションを処理する |4.1.2.12 |x| | | | | "実験的な" ディレクトリコマンドを処理する |4.1.3.1 | |x| | | | サーバ FTP にアイドルタイムアウト |4.1.3.2 | |x| | | | アイドルタイムアウトが設定可能 |4.1.3.2 | |x| | | | 再開マーカで受信側チェックポイントデータ |4.1.3.4 | |x| | | | 送信側は 110 応答が同期していると仮定する |4.1.3.4 | | | | |x| | | | | | | | サポートするタイプ: | | | | | | | ASCII - Non-print (AN) |4.1.2.13 |x| | | | | ASCII - Telnet (AT) - もし AN と同じなら |4.1.2.2 | |x| | | | ASCII - キャリッジ制御 (AC) |959 3.1.1.5.2 | | |x| | | EBCDIC - (全形式) |959 3.1.1.2 | | |x| | | IMAGE |4.1.2.1 |x| | | | | LOCAL 8 |4.1.2.1 |x| | | | | LOCAL m |4.1.2.1 | | |x| | |2 | | | | | | | サポートするモード: | | | | | | | ストリーム |4.1.2.13 |x| | | | | ブロック |959 3.4.2 | | |x| | | | | | | | | | サポートする構造: | | | | | | | ファイル |4.1.2.13 |x| | | | | レコード |4.1.2.13 |x| | | | |3 ページ |4.1.2.3 | | | |x| | | | | | | | | サポートするコマンド: | | | | | | | USER |4.1.2.13 |x| | | | | PASS |4.1.2.13 |x| | | | | ACCT |4.1.2.13 |x| | | | | CWD |4.1.2.13 |x| | | | | CDUP |4.1.2.13 |x| | | | | SMNT |959 5.3.1 | | |x| | | REIN |959 5.3.1 | | |x| | | QUIT |4.1.2.13 |x| | | | | | | | | | | | PORT |4.1.2.13 |x| | | | | PASV |4.1.2.6 |x| | | | | TYPE |4.1.2.13 |x| | | | |1 STRU |4.1.2.13 |x| | | | |1 MODE |4.1.2.13 |x| | | | |1 | | | | | | | RETR |4.1.2.13 |x| | | | | STOR |4.1.2.13 |x| | | | | STOU |959 5.3.1 | | |x| | | APPE |4.1.2.13 |x| | | | | ALLO |959 5.3.1 | | |x| | | REST |959 5.3.1 | | |x| | | RNFR |4.1.2.13 |x| | | | | RNTO |4.1.2.13 |x| | | | | ABOR |959 5.3.1 | | |x| | | DELE |4.1.2.13 |x| | | | | RMD |4.1.2.13 |x| | | | | MKD |4.1.2.13 |x| | | | | PWD |4.1.2.13 |x| | | | | LIST |4.1.2.13 |x| | | | | NLST |4.1.2.13 |x| | | | | SITE |4.1.2.8 | | |x| | | STAT |4.1.2.13 |x| | | | | SYST |4.1.2.13 |x| | | | | HELP |4.1.2.13 |x| | | | | NOOP |4.1.2.13 |x| | | | | | | | | | | | ユーザインタフェース: | | | | | | | 任意のパス名 |4.1.4.1 |x| | | | | "QUOTE" コマンドを実装する |4.1.4.2 |x| | | | | 即座に転送制御コマンドを送信 |4.1.4.2 | |x| | | | エラーメッセージをユーザに表示する |4.1.4.3 | |x| | | | 冗長モード |4.1.4.3 | |x| | | | サーバとの同期を維持する |4.1.4.4 | |x| | | | 脚注: 1. 前に示された値に対して 2. m はメモリ単位のビット数 3. レコード構造を持ったファイルシステムを持つホストに必要で、さもなくばオ プションである。 4.2 簡易ファイル転送プロトコル -- TFTP 4.2.1 導入 簡易ファイル転送プロトコル TFTP は、RFC-783 [TFTP:1] で定義されている。 TFTP は簡単な停止/待ちの確認システムを使用し、トランスポートプロトコルとして UDP を用いて信頼性のある送信を提供する。TFTP は実効ウィンドウを 512 オクテッ トのセグメント一つしか持たないので、遅延や帯域が小さい製品のあるパス上でのみ 優れたパフォーマンスを提供できる。TFTP ファイルインタフェースは非常に簡単で あり、アクセス制御やセキュリティは提供しない。 TFTP は EPROM に簡単に実装できるほど単純で小さいので、TFTP の最も重要なアプ リケーションは、ローカルネットワーク上のホストのブートストラップである [BOOT:1], [BOOT:2]。ベンダは、ブート処理のために TFTP をサポートすることが推 奨される。 4.2.2 プロトコルウォークスルー TFTP 規定 [TFTP:1] はオープンスタイルで記述されており、このプロトコルの大部 分を完全には規定していない 4.2.2.1 転送モード: RFC-783, ページ 3 転送モード "mail" をサポートすべきではない (SHOULD NOT)。 4.2.2.2 UDP ヘッダ: RFC-783, ページ 17 UDP ヘッダの Length フィールドが誤って定義されている。これは UDP ヘッダ長 (8) を含む。 4.2.3 特定の問題 4.2.3.1 魔法使いの弟子シンドローム このプロトコル規定には、"魔法使いの弟子シンドローム" として知られる重大なバ グが存在する。これは転送の不正な処理は引き起こさない (もし転送が完了すれば、 ファイルは常に正しく転送される) が、このバグにより過度の再送が発生するかもし れず、それによって転送がタイムアウトになるかもしれない。 実装体は、この問題に対して次の修正を含まなければならない (MUST): 送信側 (す なわち DATA パケットを起動する側) は、重複 ACK 受信時に現在の DATA パケット を再送してはならない。 DISCUSSION: このバグは、古い重複データグラムを受信したら、いずれかの側は現在のデータグラ ムを再送してもよいというプロトコル規則によって発生する。もしパケットがネット ワーク内で遅れたが、いずれかの側でタイムアウトになってパケットを再送した後に 正常に送信されたら、重複した応答の複製が生成されるかもしれない。もし、もう一 方の側がこの重複に自身の重複で応答したら、残りの転送で全てのデータグラムが重 複して送信されるだろう (もし複製が壊れてデータグラムが消失しなければ)。なお 悪いことに、遅延は輻輳によってしばしば発生するので、この重複転送によって更に 輻輳になり、更にバケット遅延を招くだろう。 以下の例は、この問題を明確にする助けになるかもしれない。 TFTP A TFTP B (1) ACK X-1 受信 DATA X 送信 (2) DATA X 受信 ACK X 送信 (ACK X がネットワーク内で遅延し、A がタイムアウト): (3) DATA X 再送 (4) 再度 DATA X 受信 再度 ACK X 送信 (5) (遅れた) ACK X 受信 DATA X+1 送信 (6) DATA X+1 受信 ACK X+1 送信 (7) 再度 ACK X 受信 再度 DATA X+1 送信 (8) 再度 DATA X+1 受信 再度 ACK X+1 送信 (9) ACK X+1 受信 DATA X+2 送信 (10) DATA X+2 受信 ACK X+3 送信 (11) 再度 ACK X+1 受信 再度 DATA X+2 送信 (12) 再度 DATA X+2 受信 再度 ACK X+3 送信 一旦遅れた ACK が到着すると、このプロトコルは、以降の全てのパケット (シーケ ンス 5-8 と 9-12) が重複されることに注意されたい。この問題はいずれかの側がタ イムアウトすることによって引き起こされるのではなく、両方の側が重複を受信した 時に、現在のパケットを再送することにより発生する。 修正は上記で示されているように、再送ループを破ることである。これは、TCP の振 る舞いと似通っている。そして、再送された ACK により何の動作も起こらないの で、受信側で再送タイマを除くことができる。これは、TFTP がブートストラッププ ログラムで使われる場合に簡略化できて効果的である。タイマを残すことも OK であ り、再送された ACK が本当にネットワークで消失されたものに置き換えられるなら ば、便利かもしれない。もちろん、送信側は以前として再送タイマが必要である。 4.2.3.2 タイムアウトアルゴリズム TFTP は適応可能なタイムアウトを使用しなければならない (MUST)。 IMPLEMENTATION: TCP の再送アルゴリズムは、動作の効果的な基礎を提供する。少なくとも、再送タイ ムアウトの指数関数的な緩和は必要である。 4.2.3.3 拡張 転送モードの追加やセキュリティを確保する操作モード (パスワード付き) を含め、 様々な非標準の拡張が TFTP に施されている。これらのどれも標準化されてはいな い。 4.2.3.4 アクセス制御 サーバ TFTP 実装体は、何のパス名が TFTP 運用で許可されているかについて、何ら かの設定可能なアクセス制御を含むべきである (SHOULD)。 4.2.3.5 ブロードキャスト要求 ブロードキャストアドレス宛ての TFTP 要求は、黙って破棄すべきである (SHOULD) 。 DISCUSSION: TFTP はアクセス制御が脆弱であるため、任意のネットワークの TFTP 要求の直接ブ ロードキャストは、重大なセキュリティホールを生む可能性がある。 4.2.4 TFTP 要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -------------------------------------------------|--------|-|-|-|-|-|-- 魔法使いの弟子シンドロームの修正 |4.2.3.1 |x| | | | | 転送モード: | | | | | | | netascii |RFC-783 |x| | | | | octet |RFC-783 |x| | | | | mail |4.2.2.1 | | | |x| | 拡張 |4.2.3.3 | | |x| | | 適応可能なタイムアウトを使用する |4.2.3.2 |x| | | | | 設定可能なアクセス制御 |4.2.3.4 | |x| | | | ブロードキャスト要求を黙って破棄 |4.2.3.5 | |x| | | | -------------------------------------------------|--------|-|-|-|-|-|-- -------------------------------------------------|--------|-|-|-|-|-|-- 5. 電子メール -- SMTP と RFC-822 5.1 導入 TCP/IP プロトコルスイートおいて、RFC-822 [SMTP:2] で規定されている形式の電子 メールは、RFC-821 [SMTP:1] で定義されている簡易メール転送プロトコル (SMTP: Simple Mail Transfer Protocol) を使用して送信される。 SMTP は数年もの間変更されず残っているが、インターネット社会は SMTP を使う方 法に幾つかの変更を施した。特にドメイン名システム (DNS: Domain Name System) への転換によって、アドレス形式やメールルーティングが変更されている。このセク ションでは、セクション 6.1 に要件が記述されている DNS の概念や用語に精通して いるものと仮定する。 RFC-822 は、電子メールメッセージのインターネット標準形式を規定している。 RFC-822 は古い標準の RFC-733 に代わるものである。RFC-733 は廃止されている が、幾つかの場所ではまだ使われているかもしれない。この二つの形式は時々、単に 番号 ("822" と "733") で参照される。 RFC-822 は、SMTP とは別のメール転送プロトコルを用いた非インターネットメール 環境でも幾つか使用されており、また、SMTP は非インターネット環境での使用にも 適応している。このドキュメントは、インターネット環境のみの SMTP と RFC-822 の使用における規則を提供することに注意されたい。これらのプロトコルを使用する 他の環境では、自身の規則を持つことを求めてもよい。 5.2 プロトコルウォークスルー このセクションは、RFC-821 と RFC-822 の両方をカバーしている。 RFC-821 の SMTP 規定は明確であり、沢山の例を含んでいるので、実装者は理解が困 難だと思わないはずである。このセクションは現在の使用方法に適合させるために、 RFC-821 の一部に更新、あるいは注釈を簡単に施している。 RFC-822 は長く緻密なドキュメントであり、豊富なシンタックスを定義している。不 幸にも、不完全もしくは欠陥のある RFC-822 の実装体が一般的である。実際、 RFC-822 の数多くの形式のほぼ全てが使用されているので、実装体は通常 RFC-822 シンタックスの全てを認識し、正しく解釈する必要がある。 5.2.1 SMTP モデル: RFC-821 セクション 2 DISCUSSION: メールは、クライアントの "送信側 SMTP" とサーバの "受信側 SMTP" との間で、一 連の要求/応答トランザクションによって送信される。これらのトランザクション は、(1) ヘッダと本体から成る適切なメッセージと (2) "エンベロープ" と呼ばれる SMTP 送信元と宛先アドレスを渡す。 SMTP プログラムは、X.400 のメッセージ転送エージェント (MTAs: Message Transfer Agents) に類似している。RFC-822 メッセージヘッダを生成したり分析す ることに責任のある、よりエンドユーザに近いプロトコルソフトウェアの別のレベル が存在する。この要素は X.400 では "ユーザエージェント" として知られておれ、 我々はその用語をこのドキュメントで使用する。それらはプロトコルの異なるレベル を処理するので、ユーザエージェントと SMTP 実装体との間には、はっきりとした論 理的な区別が存在する。しかしながら、この区別はインターネットメールの一般的な 実装体の構造を正確に反映しなくてもよいことに注意されたい。SMTP に加え、幾つ かのユーザエージェント機能も実装した "メーラー" と呼ばれるプログラムはよくあ る。残りのユーザエージェント機能は、メールを読み書きするために使用されるユー ザインタフェースに含まれる。 SMTP エンベロープは発行元のサイトで作成される。通常は、送信側 SMTP プログラ ムがメッセージを最初にキューイングする時に、ユーザエージェントによって行われ る。エンベロープアドレスは、メッセージヘッダの情報から取りだしてもよいし、ユ ーザインタフェース (bcc: 要求を実装する等) によって補充してもよいし、ローカ ルな設定情報から取り出してもよい (メーリングリストの拡張など)。SMTP エンベロ ープは通常、メッセージ配送の後のステージでヘッダから再度取り出しできないの で、エンベロープは SMTP の MAIL と RCPT コマンドを使用して、メッセージ自身と は別に送信される。 RFC-821 のテキストは、メールをホストで個々のユーザに配送することを提案してい る。ドメインシステムとメール交換 (MX) リソースレコードを用いたメールルーティ ングの出現により、ある特定のホストの有無に関わらず、実装者はドメインでユーザ にメールを配送することを考慮すべきである。このことは、SMTP がホストツーホス トのメール交換プロトコルであるという事実を変更してはいない (DOES NOT)。 5.2.2 正式化: RFC-821 セクション 3.1 送信側 SMTP が MAIL と RCPT コマンドで送信するドメイン名は、"正式化" されて いなければならない (MUST)。つまり省略されていない主要名か文字通りドメインで なければならず、ニックネームやドメインの略語であってはならない。正式化された 名前は、直接ホストを識別するか、MX 名であるかのいずれかであり、CNAME ではな い。 5.2.3 VRFY と EXPN コマンド: RFC-821 セクション 3.3 受信側 SMTP は VRFY を実装しなければならず (MUST)、EXPN を実装すべきである ( SHOULD) (この要件は RFC-821 を無効にする)。しかし、個々のインストールで VRFY と EXPN を無効にする設定情報が存在してもよい (MAY)。さらに、選択したリストに 対して EXPN を無効にできてもよい。 VRFY コマンドに、以下の新しい応答コードが定義される。 252 Cannot VRFY user (e.g., info is not local), but will take message for this user and attempt delivery. 「ユーザを VRFY できない (情報はローカルでない等) が、 このユーザに対してメッセージを取得して配送を試みる」 DISCUSSION: SMTP ユーザと管理者は、メール配送の問題の原因を診断するために、これらのコマ ンドを定期的に使用する。複数レベルのメーリングリスト展開の使用が増えるにつれ て (時には 2 レベル以上)、EXPN は不注意なメールループの原因を突き止めるため にますます重要になる。逆にある人は、EXPN は重要なプライバシーや、セキュリテ ィの暴露にさえ相当すると考えている。 5.2.4 SEND, SOML, SAML コマンド: RFC-821 セクション 3.4 SMTP は、メッセージをユーザの端末に送信するためのコマンド: SEND, SOML, SAML を実装してもよい (MAY)。 DISCUSSION: MX レコードを通じてメールを中継することは、メッセージをユーザの端末に即座に 直接送信するための SEND の意図と一貫しないことが指摘されている。しかし、ユー ザの端末に直接書き込むことができない SMTP 受信側は、恐らく配送が遅延すること を発行者に知らせるために、SEND に続く RCPT に対して "251 ユーザはローカルで ない (User Not Local)" 応答を返却することができる。 5.2.5 HELO コマンド: RFC-821 セクション 3.5 送信側 SMTP は、HELO コマンドの パラメタが、クライアントホストの正 しい主要なホストドメイン名であることを保証しなければならない (MUST)。その結 果、受信側 SMTP は、HELO パラメタの正当性を確認するために、この名前に対して MX の解決を実行する必要はない HELO 受信側は、HELO パラメタが送信側の IP アドレスに実際に対応するか照合して もよい (MAY)。しかし、たとえ送信側の HELO コマンドの照合が失敗しても、受信側 はメッセージの受け付けを拒否してはならない (MUST NOT)。 DISCUSSION: HELO パラメタを照合するにはドメイン名検索が必要であり、従ってかなり時間がか かるかもしれない。偽りのメール送信元を突きとめるための替わりのツールは、後段 で提案されている ("DATA コマンド" 参照)。 HELO アーギュメントは Received: 行に現れるので、依然として正しい シ ンタックスを持つ必要があることに注意されたい。正しくなければ、501 エラーが送 信される。 IMPLEMENTATION: HELO パラメタの照合が失敗したら、提案されている手続きは、送信側の信用未知に 関する注記をヘッダ (例えば "Received:" 行) に挿入することである。 5.2.6 メール中継: RFC-821 セクション 3.6 我々は、メールの (蓄積と) 転送を三つのタイプに区別する。 1. 簡単な転送者、あるいは "メール交換者" は、受信者に関するプライベートな 知識を使用してメッセージを転送する。RFC-821 のセクション 3.2 を参照され たい。 2. SMTP メール "中継" は、(RFC-821 のセクション 3.6 に定義されているよう に) 明示的な送信元経路の結果として、SMTP メール環境の範囲内でメッセージ を転送する。SMTP 中継機能は、RFC-822 より (以下のセクション 5.2.19 参 照)、"@...:" という送信元経路の形式を使用する。 3. メール "ゲートウェイ" は、異なる環境の間でメッセージを受け渡す。メール ゲートウェイのための規則は、以下のセクション 5.3.7 で論じられている。 メッセージを転送するが異なるメール環境間のゲートウェイではないインターネット ホスト (すなわち 1 か 2 に該当する) は、セクション 5.2.8 で求められているよ うに適切な Received: 行を追加するが、如何なるヘッダフィールドも変更すべきで はない (SHOULD NOT)。 送信側 SMTP は、"@...:" アドレス形式を使用した明示的な送信元経路を含む RCPT TO: コマンドを送信すべきではない (SHOULD NOT)。従って、RFC-821 のセクション 3.6 で定義された中継機能を使用すべきでない。 DISCUSSION: その意図は送信元ルーティングを全て避けることと、インターネット環境でメール配 送における明示的な送信元ルーティングを廃止することである。送信元ルーティング は不要であり、単純なターゲットアドレスである "user@domain" で常に十分なはず である。これは、メールにおいて送信元ルーティングではなく共通的な名前を使うと いう、明確で体系立てられた決定の結果である。従って、SMTP はエンドツーエンド の接続性を提供し、DNS は世界共通で位置に依存しない名前を提供する。MX レコー ドは、それが無ければ送信元ルーティングが必要な主要なケースを扱っている。 受信側 SMTP は、エンベロープの明示的な送信元経路のシンタックスを受け入れなけ ればならない (MUST) が、RFC-821 のセクション 3.6 で定義されている中継機能を 実装してもよい (MAY)。もし中継機能を実装しないならば、最も右側の "@" 記号の 右側のホストに直接メッセージの配送を試みるべきである (SHOULD)。 DISCUSSION: 例えば、中継機能を実装していないホストが、"RCPT TO:<@ALPHA,@BETA:joe@GAMMA>" の SMTP コマンドを持つメッセージを受信すると仮定する。この場合、ALPHA, BETA, GAMMA はドメイン名を示している。RFC-821 のページ 20 で提案されているように、 550 のエラー応答でメッセージを即座に拒否するのではなく、ホストは "RCPT TO:" を使用して、メッセージを GAMMA に直接転送しようと試みるべき である。このホストは中継をサポートしていないので、反転パスを更新する必要はな い。 ある人は、障害周りで手動でメールをルーティングするために、送信元ルーティング が時々必要になるかもしれないと提案している。しかし、この必要性の実際と重要性 は議論の余地がある。この目的での明示的な SMTP メール中継の使用は推奨されず、 実際は、多くのホストシステムがサポートしていないので、うまく行かないだろう。 あるものは、この目的で "%-hack" (セクション 5.2.16 参照) を使用している。 5.2.7 RCPT コマンド: RFC-821 セクション 4.1.1 受信側 SMTP をサポートするホストは、予約されたメールボックス "Postmaster" を サポートしなければならない (MUST)。 受信側 SMTP は、到着時に RCPT パラメタを照合してもよい (MAY) が、妥当な時間 (セクション 5.3.2 参照) を超えて RCPT 応答を遅らせてはならない (MUST NOT)。 従って、RCPT に対する "250 OK" 応答は、必ずしも配送アドレスが正しいことを必 ずしも意味していない。メッセージを受け付けた後で検出されたエラーは、適切なア ドレスに通知メッセージをメールで送ることによって報告される (セクション 5.3.3 参照)。 DISCUSSION: RCPT パラメタを即座に確認できる条件のセットは、技術的な設計の選択である。メ ールが送信される前に送信側 SMTP に宛先メールボックスエラーを報告することは、 一般に時間と帯域を節約するために望ましい。しかし、もし RCPT の照合が長けれ ば、この利点は失われる。 例えば、受信側は一つのローカルに登録されたメールボックス等の単純なローカル参 照を、即座に照合することができる。一方、"妥当な時間" の限定は通常、メッセー ジが送信され受け付けられた後までメーリングリストの照合が遅れることを意味す る。なぜなら、大規模なメーリングリストの照合は、非常に長い時間がかかるからで ある。実装体は、ローカルでなく、そのために DNS 検索を必要とするアドレスの照 合を遅らせることを選択してもしなくてもよい。もし DNS 検索を実行したが、ソフ トドメインシステムエラー (例えばタイムアウト) が発生したら、正当性が想定され るはずである。 5.2.8 DATA コマンド: RFC-821 セクション 4.1.1 全ての受信側 SMTP (単に "中継や最終的な配送のためにメッセージを受け付ける" [SMTP:1] だけではない) は、"Received:" 行をメッセージを先頭に挿入しなければ ならない (MUST)。RFC-821 で "タイムスタンプ行" とよばれるこの行には、以下が 適用される。 * FROM フィールドは、次の両方を含むべきである (SHOULD)。(1) HELO コマンド 中にあった送信元ホストの名前、(2) TCP コネクションから決まる送信元の IP アドレスを含んでいるドメインリテラル。 * ID フィールドは、RFC-822 で提案されているように "@" を含んでもよい ( MAY)。しかし、これは必須要件ではない。 * FOR フィールドは複数の RCPT コマンドが指定された場合、 エントリの リストを含んでもよい (MAY)。 インターネットメールプログラムは、メッセージヘッダにあらかじめ追加されている Received: 行を変更してはならない (MUST NOT)。 DISCUSSION: 送信元ホストと IP 送信元アドレスを Received: 行に含めることは、不正なメール の送信元を調査したり、HELO パラメタを明示的に照合する必要性を無くすのに十分 な情報を提供する。 Received: 行は、メールの経路を人間が調査することや、主に障害の診断を基本的に 意図している。以下のセクション 5.3.7 の議論も参照されたい。受信側 SMTP がメ ッセージの "最終配送" を行う時、エラー通知メッセージを後で送信しなければなら ない場合に使用するために (セクション 5.3.3 参照)、そのメッセージの SMTP エン ベロープから MAIL FROM: アドレスを渡さなければならない (MUST)。インターネッ トから異なるメール環境にゲートウェイする場合も似通った要件がある。セクション 5.3.7 を参照されたい。 DISCUSSION: DATA コマンドに対する最後の応答は、正常なメッセージの送信と格納のみに関係す ることに注意されたい。宛先アドレスに有する問題は、(1) RCPT コマンドに対する SMTP エラー応答で報告されるか、(2) 後で発行者にメールされるエラーメッセージ で報告されるかのいずれかである。 IMPLEMENTATION: MAIL FROM: の情報はパラメタで渡してもよいし、メッセージの先頭に挿入された Return-Path: 行で渡してもよい。 5.2.9 コマンドシンタックス: RFC-821 セクション 4.1.2 RFC-821 で示されている MAIL FROM: コマンドのシンタックスは、空のパス "MAIL FROM: <>" (RFC-821 ページ 15 参照) のケースを省略している。空の反転パスはサ ポートしなければならない (MUST)。 5.2.10 SMTP 応答: RFC-821 セクション 4.2 受信側 SMTP は、RFC-821 のセクション 4.2.2 かこのドキュメントでリスト化され ている応答コードのみ送信すべきである (SHOULD)。受信側 SMTP は、適切ならば常 に RFC-821 の例で示されているテキストを使用すべきである (SHOULD)。 送信側 SMTP はテキストによってではなく (251 と 551 応答は除く)、応答コードの みによって動作を決めなければならない (MUST)。テキストが全く無いことを含め、 如何なるテキストも受け付けることができなければならない。応答コードに続く空白 (blank) はテキストの一部と見なす。可能ならば常に、送信側 SMTP は RFC-821 の 付録 E で規定されているように、応答コードの一番目の数字のみ検査すべきである (SHOULD)。 DISCUSSION: 相互接続性の問題は、RFC-821 のセクション 4.3 で明示的にリスト化されていない 応答コードを使用した SMTP システムで起きた。しかし、付録 E で説明されている 応答コードの理論に従うと、これは合法的である。 5.2.11 透過性: RFC-821 セクション 4.5.2 実装者は、メールシステムがメッセージの透過性を保証するために、ピリオドを常に 追加したり削除することを確実に行わなければならない (MUST)。 5.2.12 MX 処理における WKS の使用: RFC-974, p. 5 RFC-974 [SMTP:3] は、申し出された各々のメールターゲットが実際に SMTP をサポ ートしていることを確かめるために、ドメインシステムに WKS ("Well-Known Service") レコードのキュエリを発行することを推奨している。後の経験によると、 WKS は広くサポートされてはいないことが分かっている。従って、MX 処理における WKS ステップは使用すべきではない (SHOULD NOT)。 以降は、RFC-822 に対する注意書きであり、そのドキュメントのセクションでまとめ ている。 5.2.13 RFC-822 メッセージの規定: RFC-822 セクション 4 Return-path 行として示されているシンタックスは、空の返却パスの可能性を省略し ている。空の返却パスは、エラー通知のループを避けるために使用される (セクショ ン 5.3.3 参照)。完全なシンタックスは: return = "Return-path" ":" route-addr / "Return-path" ":" "<" ">" オプションのヘッダフィールドのセットは、ここで RFC-1049 [SMTP:7] で定義され ている Content-Type フィールドを含むために拡張されている。このフィールドは、 "メール読み込みシステムが構造を持ったメッセージ本体を自動的に識別し、それに 応じて表示するために処理することを可能にする" [SMTP:7]。ユーザエージェント は、このフィールドをサポートしてもよい (MAY)。 5.2.14 RFC-822 日付と時間の規定: RFC-822 セクション 5 日付のシンタックスは、ここで以下のように変更される。 date = 1*2DIGIT month 2*4DIGIT メールソフトウェアは全て、次世紀への移行を容易にするために日付で 4 つの数字 の年を使用すべきである (SHOULD)。 数字のタイムゾーン指定を使おうとする強い傾向があり、実装体はタイムゾーン名で はなく、数字のタイムゾーンを使用すべきである (SHOULD)。しかし全ての実装体 は、いずれかの記述方法を受け入れなければならない (MUST)。もしタイムゾーン名 が使用されたら、厳密に RFC-822 で定義された通りでなければならない (MUST)。 軍用のタイムゾーンは、RFC-822 で誤って規定されており、UT から誤った方法で計 算している (記号が逆である)。その結果、RFC-822 ヘッダの軍用タイムゾーンは何 の情報も提供していない。 最後に、付録 D のシンタックス要約にある "zone" の定義には、タイプミスがある ことに注意されたい。正しい定義は RFC-822 のセクション 3 である。 5.2.15 RFC-822 シンタックスの変更: RFC-822 セクション 6.1 RFC-822 にある "mailbox" のシンタックスの定義をここで以下のものに変更する。 mailbox = addr-spec ; simple address / [phrase] route-addr ; name & addr-spec すなわち、経路アドレスの前のフレーズは今や任意である (OPTIONAL)。この変更に より、例えば以下のようなヘッダフィールドは正しい。 From: 5.2.16 RFC-822 ローカル部: RFC-822 セクション 6.2 基本的なメールボックスのアドレス規定は、"local-part@domain" という形式を持 つ。ここでの "local-part" は時々アドレスの "左側" と呼ばれ、ドメインに依存す る。 メッセージを転送するが、右側の "domain" によって示される宛先ホストではないホ ストは、アドレスの "local-part" を解析、あるいは修正してはならない (MUST NOT)。 メールがインターネットメール環境から外部のメール環境にゲートウェイされる時 ( セクション 5.3.7 参照)、外部環境のためのルーティング情報をアドレスの "local-part" 内に埋め込んでもよい (MAY)。そして、ゲートウェイは外部メール環 境に適切にこのローカル部を解析してもよい (MAY)。 DISCUSSION: 送信元経路はインターネット内では推奨されていないが (セクション 5.2.6 参照)、 配送メカニズムが実際に送信元経路に頼る非インターネットのメール環境は存在す る。インターネット外の環境のための送信元経路は、インターネットを通過する際に 一般的にアドレスの "local-part" に埋め込むことができる (セクション 5.2.16 参 照)。メールが適切なインターネットメールゲートウェイに到着した時、ゲートウェ イはローカル部を解析して、ターゲットのメール環境に必要なアドレスか経路を生成 する。 例えば、インターネットホストは "a!b!c!user@gateway-domain" にメールを送信し てもよい。複雑なローカル部 "a!b!c!user" はインターネットドメインの中では解析 されないが、指定されたメールゲートウェイによって解析され理解されるだろう。 埋め込まれた送信元経路は時々、右結合のルーティング演算子として "%" を用いて "local-part" で符号化される。例えば、以下のように、 user%domain%relay3%relay2@relay1 "%" 記法は、メールが "relay1" から "relay2", "relay3" を通って、最終的に "domain" の "user" に振り分けられることを意味する。これは、一般に "%-hack" として知られている。"%" は、ローカル部に隠された他のルーティング演算子 (例え ば "!") よりも優先度を低くすることが提案されている。例えば "a!b%c" は "(a!b)%c" と解釈される。 ターゲットホストのみ (この場合 "relay1") が、ローカル部である "user%domain%relay3%relay2" を解析することが許される 5.2.17 ドメインリテラル: RFC-822 セクション 6.2.3 メーラは、中身 ("dtext"、RFC-822 参照) がドット付き数字のホストアドレスであ るインターネットドメインリテラルを、受け付けて解析できなければならない ( MUST)。これは、メールの場合におけるセクション 2.1 の要件を満たす。 SMTP は、自分の如何なる IP アドレスのドメインリテラルも受け付けて、認識しな ければならない (MUST)。 5.2.18 一般的なアドレス形式のエラー: RFC-822 セクション 6.1 822 アドレスの形式化時や解析時のエラーは、不幸にもよくあることである。このセ クションは、最も一般的なエラーについてのみ言及する。ユーザエージェントは、全 ての正しい RFC-822 アドレス形式を受け付けなければならず (MUST)、不正なアドレ スシンタックスを生成してはならない (MUST NOT)。 * よくあるエラーは、グループ識別子の後のセミコロンを抜かすことである。 * あるシステムは、生成するメッセージ中に完全に正式なドメイン名が無い。ヘ ッダアドレスフィールドの "@" 記号の右側は、完全に正式なドメイン名でなけ ればならない (MUST)。 例えば、あるシステムは From: アドレスが完全に正式なドメイン名でない。こ れは、ユーザインタフェースにおける "reply" コマンドで、自動的に返送アド レスを生成することを妨げる。 DISCUSSION: RFC-822 は、ドメインの中では略したドメイン名をローカルに使用することを許して いるが、インターネットメールにおける RFC-822 のアプリケーションは、これを許 さない。インターネットホストは、アドレスフィールドの中に略されたドメイン名を 含む SMTP メッセージヘッダを送信してはならないということが、その意図である。 これによって、セクション 5.2.6 で要求されているように、インターネット中でヘ ッダのアドレスフィールドを変更せずに渡すことが可能になる。 * あるシステムは、以下のような複数ホップの明示的な送信元経路を誤って解釈 する。 @relay1,@relay2,@relay3:user@domain. * あるシステムは、アドレスやメッセージ ID の中に幾つか、あるいは全てのド メイン名の後ろにドットを付け足すことによって、正式ドメイン名が余分であ る。 5.2.19 明示的な送信元経路: RFC-822 セクション 6.2.7 インターネットホストソフトウェアは、明示的な送信元経路付きのアドレスを含む RFC-822 ヘッダを生成すべきでない (SHOULD NOT)。しかし、古いシステムとの互換 性のために、そのようなヘッダを受け付けなければならない (MUST)。 DISCUSSION: 控えめに、RFC-822 は "明示的な送信元経路は推奨されない" と述べている。多くの ホストは RFC-822 送信元経路を誤って実装したので、実際にそのシンタックスを曖 昧なく使用することができない。多くのユーザはそのシンタックスを醜いと感じてい る。明示的な送信元経路は、配送のためのメールエンペロープには必要無い (セクシ ョン 5.2.6 参照)。これら全ての理由により、RFC-822 記法を使用する明示的な送信 元経路は、インターネットメールヘッダでは使用しない。 セクション 5.2.16 で述べられているように、メールを明示的な送信元振り分けが必 要な別の環境へゲートウェイすることを可能にするために、例えば "%-hack" を使用 して、明示的な送信元経路をアドレスのローカルパートに埋め込める必要がある。 注意深く見ると、ユーザエージェントが、宛先がインターネットの中にいる時に暗黙 的な送信元振り分けの使用を検出して防ぐための方法が無いことが分かるだろう。 我々は、不要で望ましくないものとして、インターネット内のあらゆる種類の送信元 振り分けも非推奨とすることしかできない 5.3 特定の問題 5.3.1 SMTP キューイング方法 ホスト SMTP 実装体の共通的な構造は、ユーザのメールボックスや配送中にメッセー ジをキューイングするための一つ以上の領域、メールを送受信するための一つ以上の デーモンプロセスを含んでいる。その正確な構造は、ホスト上のユーザの必要性やホ ストによってサポートされるメーリングリストの個数とサイズによって変わるだろ う。効果的であることが分かっている、特に高いトラフィックレベルをサポートして いるメーラで効果的な幾つかの最適化について示す。 如何なるキューイング方法も、以下を含まなければならない (MUST)。 * 全ての作業をタイムアウトする。セクション 5.3.2 参照。 * エラーメッセージに対する応答でエラーメッセージを送信しない。 5.3.1.1 送信戦略 送信側 SMTP の一般的なモデルは、出力メールの送信を定期的に試みる一つ以上のプ ロセスである。代表的なシステムでは、メッセージを作成するプログラムは、新たな 出力メールの一部に即座に注意を払うことを求めるための幾つかの方法を持つ。一 方、送信側は即座に送信できないメールをキューに入れて、定期的にリトライしなけ ればならない (MUST)。メールキューエントリは、メッセージ自身だけでなくエンベ ロープ情報も含むだろう。 送信側は一回の試みが失敗した後、ある特定の宛先のリトライを遅らさなければなら ない (MUST)。通常、リトライ間隔は少なくとも 30 分であるべき (SHOULD) だが、 送信側 SMTP が配送しない理由を決めることが可能な場合、より洗練された可変の方 法が有益だろう。 リトライはメッセージが送信されるか、あるいは送信側が諦めるまで続く。諦める時 間は、通常少なくとも 4, 5 日は必要である。リトライアルゴリズムへのパラメタは 設定可能でなければならない (MUST)。 送信側はキューイングされたメールアイテムを単にリトライするだけでなく、到達で きず対応するタイムアウトが発生したホストの一覧を保持すべきである (SHOULD)。 DISCUSSION: 経験によると、障害は通常一時的である (ターゲットシステムが壊れた)。二つのコ ネクションの望ましい指針は、メッセージがキューに入れられてから一時間目に試 み、その後二、三時間毎に一回に緩めることである。 送信側 SMTP は、受信側 SMTP と協調することによってキューイングの遅れを短縮で きる。特に、もし特定のアドレスからメールを受信したら、そのホスト向けにキュー イングされた全てのメールは、今送信できる良い証拠である。 方法は配送時間と資源利用を最適化するために、ホスト毎に複数のアドレスの結果で 更に修正してもよい (セクション 5.3.4 参照)。 送信側 SMTP は、各々の利用できない宛先ホストに対して、メッセージの大きなキュ ーを持ってもよい。そしてもしリトライ周期毎にこれらのメッセージを全てリトライ したら、過度にインターネットのオーバヘッドが発生し、デーモンは長期間ブロック されるだろう。SMTP は通常、一分以上のタイムアウトの後にしか配送の試みが失敗 したことを決定できないことに注意されたい。もし何十、あるいは何百ものキューイ ングされたメッセージに対して繰り返されたら、コネクションにつき一分のタイムア ウトが非常に大きな遅延を招くだろう。 同じホスト上の複数のユーザに同じメッセージが配送される時、メッセージのコピー を一つだけ送信すべきである (SHOULD)。すなわち、送信側 SMTP は RCPT, DATA, RCPT, DATA,... RCPT, DATA のコマンドシーケンスではなく、RCPT, RCPT,... RCPT, DATA のコマンドシーケンスを使用すべきである。この効率化機能の実装は、強く推 奨される。 同様に、送信側 SMTP は時宜を得た配送を達成するために、複数の同じ出力メールト ランザクションをサポートしてもよい (MAY)。しかし、ホストが全ての資源をメール に割り当てることを防ぐために、多少の制限を課すべきである (SHOULD)。 マルチホーム化されたホストの異なるアドレスの使用については、以下で論じる。 5.3.1.2 受信戦略 受信側 SMTP は、常に SMTP ポートをペンディングリッスンし続けようと試みるべき である (SHOULD)。これは、SMTP の複数の入力 TCP コネクションのサポートを必要 とする。多少の制限を課してもよい (MAY)。 IMPLEMENTATION: 受信側 SMTP は、ある特定のホストアドレスからメールを受信する時、そのホストア ドレスに対してペンディング中の全てのメールをリトライするよう送信側 SMTP に通 知することができる。 5.3.2 SMTP のタイムアウト 送信側 SMTP でタイムアウトするためのアプローチは二つ存在する。(a) 各々の SMTP コマンドに対して別々に時間を制限する。(b) 一つのメールメッセージの各々 の SMTP の会話全体に対して時間を制限する。送信側 SMTP は、コマンド毎のタイム アウトであるオプション (a) を使用すべきである (SHOULD)。タイムアウトは、なる べく SMTP コードを再コンパイルせず、簡単に再設定可能にすべきである (SHOULD) 。 DISCUSSION: タイムアウトは SMTP 実装の主要な機能である。もしタイムアウトが長過ぎたら (な お悪いことにタイムアウトが無かったら)、SMTP プロセスがインターネット通信障害 や受信側 SMTP プログラムのバグに永久的に縛られる可能性がある。もしタイムアウ トが短過ぎたら、メッセージ配送の過程におけるタイムアウトの試みで、資源が浪費 されるだろう。 もしオプション (b) が使用されたら、タイムアウトはかなり大規模なメーリングリ ストを展開できる時間とするために、例えば 1 時間等、非常に大きくなければなら ない。また、非常に大きなメッセージを送信するための時間を考慮して、メッセージ のサイズに比例してタイムアウトを増やす必要があるかもしれない。大きな固定のタ イムアウトは、二つの問題を招く。それは、やはり失敗によって送信側が長い時間縛 られることと、非常に大きなメッセージは依然として誤ってタイムアウトされるかも しれない (それは非常に無駄な障害だ!) ことである。 推奨されたオプション (a) を使用すると、タイマは各 SMTP コマンドとデータ転送 の各バッファに対して設定される。後者は、全体的なタイムアウトがメッセージのサ イズに本質的に比例することを意味している。 多忙なメール中継ホストにおける広範な経験に基づいて、コマンド毎の最小限のタイ ムアウト値は、以下とすべきである (SHOULD)。 * 最初の 220 メッセージ: 5 分 送信側 SMTP プロセスは、TCP コネクションの障害と最初の 220 挨拶メッセー ジの受信時の遅延を区別する必要がある。多くの受信側 SMTP は、TCP コネク ションを受諾するが、システムの負荷が更にメールを処理できるまで 220 メッ セージの送信を遅らせる。 * MAIL コマンド: 5 分 * RCPT コマンド: 5 分 メーリングリストや別名の処理が、メッセージを受け付けた後に回されないな らば、タイムアウトの時間をより長くする必要がある。 * DATA 開始: 2 分 これは DATA コマンドに対する "354 Start Input" 応答を待つ間である。 * データブロック: 3 分 これは、データの塊を送信する各々 TCP SEND 呼び出しの完了を待つ間であ る。 * DATA 完了: 10 分 これは、"250 OK" 応答を待つ間である。受信側は、メッセージデータを終了す る最後のピリオドを受信する時、通常はユーザのメールボックスにメッセージ を配送するための処理を実行する。メッセージは正常に送信されているので、 この時点で誤ったタイムアウトが起こるのは非常に無駄である。 受信側 TCP は送信側からの次のコマンドを待つ間、少なくとも 5 分のタイムアウト を持つべきである (SHOULD)。 5.3.3 信頼性のあるメール受信 受信側 SMTP は、(DATA のに対する応答で "250 OK" メッセージを送信することによ って) メールの一部を受け付ける時、そのメッセージを配送したり中継する責任を受 け入れる。この責任は真剣に負わなければならない。すなわち例えばホストが後で壊 れたり、予測可能な資源不足等のつまらない理由でメッセージを失ってはならない ( MUST NOT)。 もしメッセージを受け付けた後に配送障害が発生したら、受信側 SMTP は通知メッセ ージを作成してメールで送らなければならない (MUST)。その通知は、エンベロープ の中にヌル ("<>") の反転パスを使って送信しなければならない (MUST)。RFC-821 のセクション 3.6 を参照されたい。この通知の受信者は、エンベロープの返却パス (あるいは Return-Path: 行) から取得したアドレスとすべきである (SHOULD)。しか し、もしこのアドレスがヌル ("<>") ならば、受信側 SMTP は通知を送信してはなら ない (MUST NOT)。もしそのアドレスが明示的な送信元経路ならば、経路を取り除い て最終ホップにすべきである (SHOULD)。 DISCUSSION: 例えば、エラー通知を "MAIL FROM:<@a,@b:user@d>" で到着したメッセージに対して 送信しなければならないと仮定する。その通知メッセージは、"RCPT TO:" に送信すべきである。 メッセージが SMTP に受け付けられた後、幾つかの配送障害は避けられないだろう。 例えば、"ソフト" ドメインシステムエラーやターゲットがメーリングリストである ために、受信側 SMTP が RCPT コマンド中の全ての配送アドレスを確認することが不 可能かもしれない (前の RCPT の議論参照)。 タイムアウトの結果で重複メッセージの受信を避けるために、受信側 SMTP は、メッ セージ転送を終える最後の "." に応答するために必要な時間を、最小限に留めなけ ればならない (MUST)。この問題の議論については、RFC-1047 [SMTP:4] を参照され たい。 5.3.4 信頼性のあるメール送信 メッセージを送信するために、送信側 SMTP は、エンベロープ中の宛先アドレスから ターゲットホストの IP アドレスを決める。特に送信側 SMTP は、"@" マークの右側 の文字列を IP アドレスにマッピングする。このマッピングや転送自身はソフトエラ ーで失敗するかもしれない。その場合、送信側 SMTP は、セクション 5.3.1.1 で要 求されているように、後のリトライのために出力メールを再度キューイングする。 もし成功した場合、そのマッピングによって単一のアドレスではなく、結果的に代替 の配送アドレスの一覧を受け取るかもしれない。それは、(a) MX レコードが複数あ るから、(b) マルチホーム化しているから、あるいはその両方のためである。信頼で きるメール送信を提供するために、送信側 SMTP は配送の試みが成功するまで、この 一覧中の各々のアドレスを順番通りにトライ (またはリトライ) できなければならな い (MUST)。しかし、トライできる代替アドレスの個数に設定可能な制限が存在して もよい (MAY)。いずれにせよ、ホストは少なくとも二つのアドレスをトライすべきで ある (SHOULD)。 以下の情報は、ホストアドレスをランク付けするために使用する。 1. 複数の MX レコード これらは、分類するために使用すべき優先度指定を含む。もし同じ優先度を持 つ複数の宛先が存在し、一方を好む明白な理由 (例えばアドレスの優先度など) が無いならば、送信側 SMTP は特定の組織に対する複数のメール交換に負荷を 分散させるために、無作為に一つを抽出すべきである (SHOULD)。これは [DNS:3] の手続きの改善であることに注意されたい。 2. マルチホーム化されたホスト 宛先ホスト (恐らく優先度の高い MX レコードから取得された) は、マルチホ ーム化してもよい。その場合、ドメイン名リゾルバは代替の IP アドレスの一 覧を返却するだろう。この一覧を優先度の高い順に並べるのは、ドメイン名リ ゾルバインタフェースの責任であり (以下のセクション 6.1.3.4 参照)、SMTP は提示された順序に従ってトライしなければならない (MUST)。 DISCUSSION: 複数の代替アドレスをトライする能力は必要とされるが、特定のインストールにおい て代替アドレスの使用を制限するか無効にすることを望む状況があるかもしれない。 送信者が、マルチホーム化されたホストの別のアドレスを使用してリトライを試みる べきか否かの問題は、ずっと議論されてきている。複数のアドレスを使用することの 主な論点は、時を得た配送確率、時には実際にあらゆる配送確率を最大限にするとい うことである。それに対する論点は、結果的に不要な資源の使用を招くということで ある。 資源の使用は、セクション 5.3.1 で論じられている送信戦略によっても強く決まる ことに注意されたい。 5.3.5 ドメイン名のサポート SMTP の実装体は、ドメイン名と IP アドレスをマッピングするために、セクション 6.1 で定義されたメカニズムを使用しなければならない (MUST)。これは、全てのイ ンターネット SMTP はインターネット DNS のサポートを含まなければならない ( MUST) ことを意味する。 特に、送信側 SMTP は MX レコードスキーム [SMTP:3] をサポートしなければならな い (MUST)。SMTP におけるドメイン名のサポートに関する情報については、[DNS:2] のセクション 7.4 も参照されたい。 5.3.6 メーリングリストと別名 SMTP 機能を持ったホストは、複数配送のためのアドレス展開の別名とリスト形式の 両方をサポートすべきである (SHOULD)。展開されたリスト形式の各々のアドレスに メッセージを配送、あるいは転送する時、エンベロープ ("MAIL FROM:") 中の返却ア ドレスは、そのリストを管理している人のアドレスに変更しなければならない ( MUST) が、メッセージヘッダは変更せずにおかなければならない (MUST)。特に、メ ッセージの "From" フィールドは変更しない。 DISCUSSION: 重要なメール機能は、疑似メールボックスアドレスを宛先メールボックスアドレスの リストに変更、もしくは "展開" することによって、単一メッセージを複数の宛先へ 配送するためのメカニズムである。このような疑似メールボックス (時々 "爆撃者" と呼ばれる) にメッセージを送信すると、展開されたリストにある各々のメールボッ クスに、複製が転送あるいは再配布される。我々は、このような疑似メールボックス を、以下の展開規則によって "別名"、あるいは "リスト" として分類している。 a. 別名 別名を展開するために、受信側のメーラはエンベロープ中の疑似メールボック スアドレスを、展開されたアドレスの各々に順に単に置き換える。エンベロー プの残りとメッセージ本体は変更しないままである。そしてメッセージは、 各々の展開されたアドレスに配送、あるいは転送される。 b. リスト メーリングリストは "転送" によっては無く、"再配布" によって処理されると 言ってもよい。リストを展開するために、受信側のメーラはエンベロープ中の 疑似メールボックスアドレスを、展開されたアドレスの各々に順に単に置き換 える。最終配送者によって生成された全てのエラーメッセージは、メッセージ の起草者ではなくリスト管理者に返すように、エンベロープ中の返却アドレス を変更する。メッセージの起草者は一般にリストの内容を管理しておらず、エ ラーメッセージを煩わしく思うだろう。 5.3.7 メールゲートウェイ 異なるメール環境、すなわち異なるメール形式やプロトコル間でメールをゲートウェ イすることは複雑であり、容易に標準化できない。例として、[SMTP:5a], [SMTP:5b] を参照されたい。しかし、インターネットと他のメール環境間をゲートウェイするた めの、一般的な要件はある。 A. メッセージがメール環境の境界を渡って生成される時に必要ならば、ヘッダフ ィールドを書き直してもよい (MAY)。 DISCUSSION: これは、セクション 5.2.16 で提案されているように、宛先アドレスのローカル部の 解析を伴ってもよい。 インターネットにゲートウェイする他のメールシステムは。通常 RFC-822 ヘッダの サブセットを使用するが、それらのうち幾つかは SMTP エンベロープと同等なものを 持っていない。従って、メッセージがインターネット環境から出る時、SMTP のエン ベロープ情報をメッセージヘッダに混ぜ込む必要があるかもしれない。考えられる解 決方法は、エンベロープ情報を運ぶための新しいヘッダフィールド (例えば "X-SMTP-MAIL:" や "X-SMTP-RCPT:") を作成することである。しかし、これは外部環 境のメールプログラムに変更が必要になるだろう。 B. インターネット環境へ、あるいはインターネット環境からメッセージを転送す る時、Received: 行を付加しなければならない (MUST)。しかし、既にヘッダ中 にある Received: 行は如何なる変更も行ってはならない (MUST NOT)。 DISCUSSION: この要件は、セクション 5.2.8 の 一般的な "Received:" 行要件のサブセットであ り、強調するために、ここで再度述べている。 他の環境から発行するメッセージの Received: フィールドは、RFC-822 に正確に適 合していなくてもよい。しかし、Received: 行の最も重要な用途はメール障害のデバ ッグであり、Received: 行を "修正" しようとする、善意のゲートウェイがデバッグ のひどい妨げになり得る。 ゲートウェイは、供給される Received フィールドの "via" 節で環境やプロトコル を示すことが、強く推奨される。 C. インターネット側から、ゲートウェイは SMTP コマンド中の全ての正しいアド レス形式と、全ての正しい RFC-822 メッセージを受け付けるべきである ( SHOULD)。ゲートウェイは、RFC-822 ヘッダの中かエンベロープの中のいずれか にある、RFC-822 の明示的な送信元経路 ("@...:" 形式) を受け付けなければ ならないが、送信元経路に基づいて動作してもしなくてもよい (MAY)。セクシ ョン 5.2.6 とセクション 5.2.19 を参照されたい。 DISCUSSION: リモート環境のアドレスへの変換を簡単にするために、メールゲートウェイで受け付 けるアドレスの範囲を制限しようとする誘惑にしばしば駆られる。これを行うこと は、メールユーザはメーラがメールゲートウェイに送信したアドレスを管理している という仮定に基づく。しかし実際には、ユーザは最終的に送信したアドレスをほとん ど管理しておらず、メーラがアドレスを正しい RFC-822 形式に自由に変更してい る。 D. ゲートウェイは、インターネットに転送するメッセージの全てのヘッダフィー ルドが、インターネットメールの要件に合っていることを保証しなければなら ない (MUST)。特に "From:", "To:", "Cc:" 等のフィールド中の全てのアドレ スは、RFC-822 シンタックスを満たすために、(必要ならば) 変換しなければな らず、それらは返事を送るために有効かつ有用でなければならない。 E. メールをインターネットプロトコルから別の環境のプロトコルに変換するアル ゴリズムは、外部のメール環境からのエラーメッセージを、RFC-822 メッセー ジの "From:" フィールドにリスト化された送信者にではなく、SMTP エンベロ ープから取得した返却パスに配送することを保証しようとすべきである ( SHOULD)。 DISCUSSION: インターネットメールリストは大抵、エンベロープの中にメールリストの管理者のア ドレスを置いているが、元のメッセージヘッダを (元の送信者を含む "From:" フィ ールド付きで) そのまま残している。これは、ヘッダに返信するとメールリスとの管 理者にではなく元の送信者に送られることを、普通の受信者が期待する振舞いを生 む。しかし、エラーは (問題を改修できる) 管理者に送信し、(恐らく改修できない) 送信者には送らない。 F. 同様に、他のメール環境からインターネットにメッセージを転送する時、ゲー トウェイは、もしあれば外部環境で提供されたエラーメッセージの返却アドレ スに合った返却パスを、エンベロープに設定すべきである (SHOULD)。 5.3.8 最大メッセージ長 メーラソフトウェアは、長さが (ヘッダを含め) 少なくとも 64K バイトのメッセー ジを送受信できなければならず (MUST)、これよりもずっと大きな最大長は非常に望 ましい。 DISCUSSION: SMTP はメッセージの最大長を定義していないが、多くのシステムは実装上の制限を 課している。 インターネットにおいて制限の現在のデファクトの最小値が 64K バイトである。し かし電子メールは、ずっと大きなメッセージを作成する様々な目的で用いられる。例 えばメールは、ASCII ファイルをを送信するために、特にドキュメント全体を送信す るために、しばしば FTP の代わりで使われる。結果的に、メッセージは 1 メガバイ トかそれ以上になり得る。参考までに、本ドキュメントは下位層のペアと合わせて 0.5 メガバイト程ある。 5.4 SMTP 要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -----------------------------------------------|----------|-|-|-|-|-|-- | | | | | | | 受信側-SMTP: | | | | | | | VRFY の実装 |5.2.3 |x| | | | | EXPN の実装 |5.2.3 | |x| | | | EXPN, VRFY が設定可能 |5.2.3 | | |x| | | SEND, SOML, SAML の実装 |5.2.4 | | |x| | | HELO パラメタの照合 |5.2.5 | | |x| | | 不当な HELO でのメッセージの拒否 |5.2.5 | | | | |x| エンベロープの明示的な送信元経路受け付け |5.2.6 |x| | | | | "postmaster" のサポート |5.2.7 |x| | | | | (リストを除いて) RCPT を受信時に処理する |5.2.7 | | |x| | | RCPT 応答の長い遅延 |5.2.7 | | | | |x| | | | | | | | Received: 行の追加 |5.2.8 |x| | | | | Received: 行がドメインリテラルを含む |5.2.8 | |x| | | | 前の Received: 行の変更 |5.2.8 | | | | |x| 返却パス情報 (最終配送/ゲートウェイ) を渡す |5.2.8 |x| | | | | 空の反転パスのサポート |5.2.9 |x| | | | | 正式な応答コードのみ送信 |5.2.10 | |x| | | | 適切な場合 RFC-821 のテキスト送信 |5.2.10 | |x| | | | 透過性のために "." を削除 |5.2.11 |x| | | | | 自分自身のドメインリテラルを受け付けて認識 |5.2.17 |x| | | | | | | | | | | | エラーメッセージに対してエラーメッセージ |5.3.1 | | | | |x| SMTP ポートのペンディングリッスンを継続 |5.3.1.2 | |x| | | | 同時受信を制限する |5.3.1.2 | | |x| | | 次の送信側コマンドを少なくとも 5 分待つ |5.3.2 | |x| | | | "250 OK" 後に回避可能な配送障害 |5.3.3 | | | | |x| 受諾した後にエラー通知メッセージ送信 |5.3.3 |x| | | | | ヌル返却パスを用いて送信 |5.3.3 |x| | | | | エンベロープの返却パスに送信 |5.3.3 | |x| | | | ヌルアドレスに送信 |5.3.3 | | | | |x| 明示的な送信元経路を除去 |5.3.3 | |x| | | | 受諾遅延 (RFC-1047) を最小限にする |5.3.3 |x| | | | | -----------------------------------------------|----------|-|-|-|-|-|-- | | | | | | | 送信側-SMTP: | | | | | | | MAIL, RCPT で正式化されたドメイン名 |5.2.2 |x| | | | | SEND, SOML, SAML の実装 |5.2.4 | | |x| | | HELO で正しい主要なホスト名の送信 |5.2.5 |x| | | | | RCPT TO: で明示的な送信元経路送信 |5.2.6 | | | |x| | 動作を決めるのに応答コードのみ使用 |5.2.10 |x| | | | | 可能ならば、応答コードの最上位数字のみ使用 |5.2.10 | |x| | | | 透過性のために "." を追加 |5.2.11 |x| | | | | | | | | | | | ソフト障害後にメッセージをリトライ |5.3.1.1 |x| | | | | リトライ前に遅らせる |5.3.1.1 |x| | | | | リトライパラメタを設定可能 |5.3.1.1 |x| | | | | キューの各宛先ホスト毎に一回リトライ |5.3.1.1 | |x| | | | 同じ DATA で複数の RCPT |5.3.1.1 | |x| | | | 複数の同時トランザクションをサポート |5.3.1.1 | | |x| | | 同時実行を制限する |5.3.1.1 | |x| | | | | | | | | | | 全ての作業に対してタイムアウト |5.3.1 |x| | | | | コマンド毎にタイムアウト |5.3.2 | |x| | | | タイムアウトを容易に設定可能 |5.3.2 | |x| | | | タイムアウトの推奨値 |5.3.2 | |x| | | | 代替アドレスを順にトライ |5.3.4 |x| | | | | 代替へのトライの制限を設定可能 |5.3.4 | | |x| | | 少なくとも二つの代替にトライ |5.3.4 | |x| | | | 同位の MX 代替に対して負荷分散 |5.3.4 | |x| | | | ドメイン名システムを使用 |5.3.5 |x| | | | | MX レコードをサポート |5.3.5 |x| | | | | MX 処理で WKS レコードを使用 |5.2.12 | | | |x| | -----------------------------------------------|----------|-|-|-|-|-|-- | | | | | | | メール転送: | | | | | | | 既存のヘッダフィールドを変更する |5.2.6 | | | |x| | RFC- 821/セクション 3.6 の中継機能を実装 |5.2.6 | | |x| | | もし実装しないなら最も右側のドメインに配送 |5.2.6 | |x| | | | アドレスの 'local-part' を解析 |5.2.16 | | | | |x| | | | | | | | メーリングリストと別名 | | | | | | | 両方ともサポート |5.3.6 | |x| | | | メールリストエラーをローカル管理者に通知 |5.3.6 |x| | | | | | | | | | | | MAIL GATEWAYS: | | | | | | | 外部のメール経路をローカル部に埋め込み |5.2.16 | | |x| | | 必要時にヘッダフィールドを書き直す |5.3.7 | | |x| | | Received: 行を付加 |5.3.7 |x| | | | | 既存の Received: 行を変更 |5.3.7 | | | | |x| インターネット側で RFC-822 を全て受諾 |5.3.7 | |x| | | | RFC-822 の明示的な送信元経路に基づいて動作 |5.3.7 | | |x| | | インターネット側で正しい RFC-822 のみ送信 |5.3.7 |x| | | | | エンベロープアドレスにエラーメッセージを配送 |5.3.7 | |x| | | | エラー返却アドレスから env. 返却パスに設定 |5.3.7 | |x| | | | | | | | | | | ユーザエージェント -- RFC-822 | | | | | | | ユーザが アドレス入力可能 |5.2.6 | | | |x| | RFC-1049 Content Type フィールドをサポート |5.2.13 | | |x| | | 4 つの数字の年を使用 |5.2.14 | |x| | | | 数字のタイムゾーンを生成 |5.2.14 | |x| | | | 全てのタイムゾーンを受け付ける |5.2.14 |x| | | | | RFC-821 の非数字タイムゾーンを使用 |5.2.14 |x| | | | | route-addr の前のフレーズを省略 |5.2.15 | | |x| | | ドット付き数字のドメインリテラルを受諾し解釈 |5.2.17 |x| | | | | 全ての RFC-822 アドレス形式を受諾 |5.2.18 |x| | | | | 不正な RFC-822 アドレス形式を生成 |5.2.18 | | | | |x| ヘッダに完全に正式なドメイン名 |5.2.18 |x| | | | | ヘッダに明示的な送信元経路を生成 |5.2.19 | | | |x| | ヘッダの明示的な送信元経路を受諾 |5.2.19 |x| | | | | | | | | | | | 少なくとも 64KB メッセージを送受信 |5.3.8 |x| | | | | 6. サポートサービス 6.1 ドメイン名変換 6.1.1 導入 全てのホストは、ドメイン名システム (DNS) のためのリゾルバを実装しなければな らず (MUST)、この DNS リゾルバを使用してホスト名を IP アドレスに変換したり、 その逆を行うメカニズムを実装しなければならない (MUST)。[DNS:1], [DNS:2] DNS に加えて、ホストはローカルのインターネットホストテーブルを検索するホスト 名変換メカニズムを実装してもよい (MAY)。このオプションに関する詳細情報は、セ クション 6.1.3.8 を参照されたい。 DISCUSSION: インターネットホスト名変換は、全てのホストのテーブルのローカルコピーを検索す ることによって任意に実行される。このテーブルは適宜更新し配布するにはあまりに も大きくなり、多くのホストに適応させるにも大き過ぎる。そこで、DNS が発明され た。 DNS は分散データベースを作成し、主にホスト名とホストアドレス間の変換のために 使用される。DNS ソフトウェアの実装が必要である。DNS は二つの論理的に異なる部 品、ネームサーバとリゾルバで構成される (実装体はしばしば、効率のためにこれら の二つの論理的な部分を併用するが)。[DNS:2] ドメイン名サーバは、データベースとデータに関する応答キュエリのあるセクション について、権威のあるデータを格納する。ドメインリゾルバは、ユーザプロセスのた めにデータに関してドメイン名サーバに問いかける。従って、全てのホストは DNS リゾルバが必要であり、あるホストマシンはドメイン名サーバを実行する必要もある だろう。ネームサーバは完全な情報を持たないので、一般にキュエリを解決するため に一つ以上のネームサーバから情報を獲得する必要がある。 6.1.2 プロトコルウォークスルー 実装者は、参照 [DNS:1] と [DNS:2] を注意深く調べなければならない。それらは、 理論やプロトコル、ドメイン名システムの実装について詳細な説明を提供しており、 数年に渡る経験を反映している。 6.1.2.1 ゼロの TTL を持つリソースレコード: RFC-1035 セクション 3.2.1 全ての DNS ネームサーバとリゾルバは、ゼロの TTL を持つ RR を適切に扱わなけれ ばならない (MUST)。ゼロの場合クライアントに RR を返却するが、それをキャッシ ュしない。 DISCUSSION: ゼロの TTL 値は、RR が実行中のトランザクションでのみ使用でき、キャッシュすべ きでないことを意味するものと解釈される。それは、極めて変わりやすいデータのた めに効果的である。 6.1.2.2 QCLASS 値: RFC-1035 セクション 3.2.5 "QCLASS=*" を持つキュエリは、要求者が一つ以上のクラスからデータを求めている のでなければ使用すべきでない (SHOULD NOT)。特に、もし要求者がインターネット データタイプにのみ興味があるならば、QCLASS=IN を使用しなければならない ( MUST)。 6.1.2.3 未使用フィールド: RFC-1035 セクション 4.1.1 キュエリや応答メッセージ中の未使用フィールドは、ゼロでなければならない ( MUST)。 6.1.2.4 圧縮: RFC-1035 セクション 4.1.4 ネームサーバは、応答で圧縮を使用しなければならない (MUST)。 DISCUSSION: 圧縮は UDP データグラムの氾濫を避けるために必要不可欠である。セクション 6.1.3.2 を参照されたい。 6.1.2.5 構成情報の誤用: RFC-1035 セクション 6.1.2 再帰ネームサーバと完全サービスリゾルバは通常、ルートやローカルのネームサーバ の場所に関するヒントを含む幾つかの構成情報を持つ。実装体は、応答にこれらの如 何なるヒントも含めてはならない (MUST NOT)。 DISCUSSION: 多くの実装者は、これらのヒントをあたかもキャッシュされたデータであるかのよう に格納するのは効果的であることを見出したが、あるものは、この "キャッシュされ たデータ" を応答に含めないことの保証を怠っていた。これは、ヒントが廃止されて 不正になった時に、インターネットに重大な問題を招いた。 6.1.3 特定の問題 6.1.3.1 リゾルバ実装 もしホストが同時処理をサポートしているならば、ネームリゾルバは複数の同時要求 を発行可能にすべきである (SHOULD)。 DNS リゾルバを実装する際、二つの異なるモデル、完全サービスリゾルバかスタブリ ゾルバのうち一つを任意で選択してもよい (MAY)。 (A) 完全サービスリゾルバ 完全サービスリゾルバはリゾルバサービスの完全な実装体であり、通信障害、個々の ネームサーバの障害、指定された名前に対する適切なネームサーバの場所等を取り扱 うことが可能である。以下の要件を満たさなければならない。 * リゾルバは、個々の要求に対するリモートアクセスの繰り返しを避けるため に、ローカルなキャッシング機能を実装しなければならず (MUST)、キャッシュ 内の情報をタイムアウトしなければならない (MUST)。 * リゾルバは、複数のルートネームサーバや、ローカルドメインのための複数の ネームサーバを指している開始情報を設定可能とすべきである (SHOULD)。これ は、正常な場合にリゾルバが名前空間全体をアクセスでき、もしローカルネッ トワークがインターネットの他の箇所からアクセスできないならば、ローカル のドメイン情報にアクセスできることを保証する。 (B) スタブリゾルバ "スタブリゾルバ" は、接続されたネットワーク上の再帰ネームサーバや "近くの" ネットワークのサービスに頼る。このスキームは、ホストがリゾルバ機能の負担を別 のホスト上のネームサーバに渡すことを可能にする。このモデルは、例えば PC 等の 能力の低いホストに必要不可欠であり、ホストがローカルネットワーク上の複数のワ ークステーションの一つである場合に、推奨されもする。なぜなら、ワークステーシ ョンの全てで再帰ネームサーバのキャッシュを分散することが可能になり、それによ ってローカルネットワークから出されるドメイン要求の数を減らすことができる。 最低限、スタブリゾルバは要求を冗長なネームサーバに向けることができなければな らない (MUST)。再帰的なネームサーバは、引き受ける要求の送信元を制限すること が許されていることに注意されたい。よって、ホスト管理者はサービスが提供される か照合しなければならない。スタブリゾルバは、もし選択するならばキャッシュを実 装してもよい (MAY) が、実装するならばキャッシュされた情報をタイムアウトしな ければならない (MUST)。 6.1.3.2 トランスポートプロトコル DNS リゾルバと再帰サーバは、(ゾーン無し転送の) キュエリを送信するために UDP をサポートしなければならず (MUST)、TCP をサポートすべきである (SHOULD)。特 に、ゾーン無し転送キュエリを送信する DNS リゾルバやサーバは、UDP キュエリを 最初に送信しなければならない (MUST)。もし応答の回答セクションが切られてお り、要求者が TCP をサポートしているならば、TCP を使用して再度キュエリを試み るべきである (SHOULD)。 DNS サーバは、UDP キュエリをサービスできなければならず (MUST)、TCP キュエリ をサービスできるべきである (SHOULD)。ネームサーバは TCP キュエリに割り当てる 資源を制限してもよい (MAY) が、UDP で成功するだろうという理由だけで TCP キュ エリのサービスを拒否すべきではない (SHOULD NOT)。 切られた応答は保存 (キャッシュ) してはならず、それが切られたという事実を失う ような方法で、後で使用してはならない (MUST NOT)。 DISCUSSION: キュエリは TCP よりも UDP の方が望ましい。なぜなら UDP キュエリは、パケット 数とコネクション状態の両方において、オーバヘッドがずっと小さいからである。 UDP の使用は負荷の高いサーバ、特にルートサーバには必須である。リゾルバは一つ の TCP キュエリのコストで、幾つかの UDP キュエリを異なるサーバに試みることが できるので、UDP は付加的な頑強性も提供する。 現在のインターネット DNS では稀にしか発生しないが、DNS 応答を切ることは可能 である。実際は、切除はデータ依存なので予想することはできない。その依存性は回 答中の RR の個数や各 RR のサイズ、名前圧縮アルゴリズムによって実現される空間 の節約を含む。経験則では、NS と MX リストの切除は、15 かそれ以下の RR しか含 んでいない回答には発生しないはずである。 切られた回答を使用可能か否かはアプリケーションに依存する。メーラは、メールル ープを招くかもしれないので、切られた MX 応答を使用してはならない。 責任ある実践により、大多数のケースで UDP で十分となり得る。ネームサーバは、 応答で圧縮を使用しなければならない。リゾルバは応答の追加セクションの切除 (余 分な情報のみ失う) を、回答セクションの切除 (MX レコードの場合は、メーラがそ の応答を使用できなくなる) と区別しなければならない。データベース管理者はネー ムサーバのリストに、MX の代替など効率的な個数の主要な名前のみリスト化すべき である。 しかし、将来定義される幾つかの新しい DNS レコードタイプは、UDP に適用される 512 バイト制限を超える情報を含むだろう。この場合は TCP が必要になる。従っ て、リゾルバとネームサーバは、将来 TCP サービスが必要になるだろうという認識 を持って、UDP の代替として TCP サービスを実装すべきである。 プライベートな合意により、ネームサーバとリゾルバは、それらの間の全てのトラフ ィックで TCP を使用するよう取り決めてもよい (MAY)。ゾーン転送のために TCP を 使用しなければならない (MUST)。 DNS サーバは、オープンされた TCP コネクション上で応答を待つ間かゾーン転送を 実行する間、UDP キュエリの処理を継続できるよう、十分に内部協調しなければなら ない (MUST)。[DNS:2] サーバは、IP ブロードキャストかマルチキャストアドレスを使用して配送する UDP キュエリをサポートしてもよい (MAY)。しかし、マルチキャストされるキュエリに再 帰要求ビットを設定してはならず (MUST NOT)、ブロードキャストかマルチキャスト アドレス経由でキュエリを受信するネームサーバは、無視しなければならない ( MUST)。ブロードキャストかマルチキャスト DNS キュエリを送信するホストは、たま にプローブするためだけに送信すべきである (SHOULD)。応答から取得した IP アド レスをキャッシングすれば、ユニキャストキュエリで普通に送信することができる。 DISCUSSION: ブロードキャストや (特に) IP マルチキャストは、前もって IP アドレスを知らな くても、近くのネームサーバの位置を突き止める方法を提供できる。しかし、再帰キ ュエリの一般的なブロードキャストは、過渡で不必要な負荷をネットワークとサーバ の両方にかける可能性がある。 6.1.3.3 効率的な資源利用 サーバとリゾルバに対する以下の要件は、インターネット全体の健全を保つために非 常に重要である。DNS サービスが、メーラのような上位レベルの自動サーバによって 繰り返し起動される場合は、特に重要である。 1. リゾルバは、通信帯域を浪費しないことを保証するために再送制御を実装しな ければならず (MUST)、一つの要求に対する応答で消費される資源に、有限な限 度を設けなければならない (MUST)。明確な推奨事項については、[DNS:2] のペ ージ 43-44 を参照されたい。 2. 応答が無くキュエリを数回再送した後、実装体は諦めて、ある種のエラーをア プリケーションに返さなければならない (MUST)。 3. 全ての DNS サーバとリゾルバは、分単位のタイムアウト間隔を持って、一時的 な失敗をキャッシュすべきである (SHOULD)。 DISCUSSION: これは、 (このドキュメントのセクション 2.2 に反して) ソフト障害を即座に再試 行するアプリケーションが、過度の DNS トラフィックを生み出すことを回避するだ ろう。 4. 全ての DNS サーバとリゾルバは、[DNS:2] で規定されているように、特定の名 前や特定のタイプのデータが存在しないことを示す否定応答をキャッシュすべ きである (SHOULD)。 5. DNS サーバとリゾルバが UDP キュエリを再送する場合、その再送間隔は指数的 なバックオフアルゴリズムで決めるべきであり (SHOULD)、最大値と最小値も持 つべきである (SHOULD)。 IMPLEMENTATION: 初期再送間隔を算出するために、(利用できるならば) 計測された RTT と平方偏差を 使用すべきである。もしこの情報を利用できないならば、5 秒程度のデフォルト値を 使用すべきである。実装体は再送間隔を制限してもよいが、この制限は、インターネ ットの最大セグメント生存時間の二倍にネームサーバのサービス遅延を加えた値より 大きくなければならない。 6. リゾルバやサーバが発行したキュエリに対して送信元抑止を受信した場合、近 い将来そのサーバにキュエリする割合を減らすステップを踏むべきである ( SHOULD)。サーバは、応答データグラムを送信した結果として受信した送信元抑 止を無視してもよい (MAY)。 IMPLEMENTATION: その割合を減らすための推奨動作の一つは、もし利用できるものが存在するならば、 次のキュエリ要求を別のサーバに送信することである。もう一つはの推奨動作は、同 じサーバに対する再送間隔をバックオフすることである。 6.1.3.4 マルチホームホスト ホスト名からアドレスへの変換機能が複数のアドレスを持つホストに遭遇した場合、 直近に接続されたネットワーク番号や他の適用可能なパフォーマンス、履歴情報の知 識を使用して、アドレスをランク付けするかソートすべきである (SHOULD)。 DISCUSSION: マルチホームホストの異なるアドレスは、一般に異なるインターネットパスを意味 し、あるパスは別のパスよりもパフォーマンスや信頼性、管理上の制限において望ま しいかもしれない。ドメインシステムが最善のパスを決定するための一般的な方法は 存在しない。推奨されたアプローチは、この決定がシステム管理者によって設定され たローカルな設定情報に基づくことである。 IMPLEMENTATION: 以下のスキームが正常に使用されている。 a. ホスト設定データに、優先ネットワークリストを組み込む。それは、ネットワ ークの優先順の単なる一覧である。優先順位が無ければ、このリストは空でも よい。 b. ホスト名を IP アドレスのリストにマッピングする時、優先ネットワークリス トに対応するネットワークと同じ順序に、これらのアドレスをネットワーク番 号順にソートすべきである。優先ネットワークリストに現れないネットワーク を持つアドレスは、リストの最後に置いておくべきである。 6.1.3.5 拡張性 DNS ソフトウェアは、よく知られたクラス無依存の形式 [DNS:2] をサポートしなけ ればならず (MUST)、新しいよく知られたタイプや、ローカルの実験である非標準の タイプの導入に伴う影響を最小限にするよう書くべきである (SHOULD)。 DISCUSSION: DNS によって使用されるデータタイプとクラスは拡張可能である。従って、新しいタ イプを追加したり、古いタイプを削除したり再定義できる。新しいデータタイプを導 入する場合、DNS メッセージ内のドメイン名の圧縮規則と、リソースレコード (RR) の印字可能形式 (例えばマスタファイル) と内部形式との間の変換にのみ依存すべき である。 圧縮規則は、ある特定の RR 内のデータ形式の知識に頼る。従って、圧縮はよく知ら れたクラス無依存の RR の内容に対してのみ使用しなければならず、クラス特定の RR やよく知られていない RR タイプには決して使用してはならない。RR のオーナ名 は常に圧縮してよい。 ネームサーバはサーバが印字可能形式への変換方法を知らない RR を、ゾーン転送を 通じて獲得してもよい。リゾルバは、キュエリの結果として同様の情報を受信でき る。適切な処理ではこのデータを保護しなければならず、従って DNS ソフトウェア は内部記憶装置で原文形式を使うことができないことを、暗に意味する。 DNS は、非常に一般的にドメイン名シンタックスを定義する、それは、各々 63 個ま での 8 ビットオクテットで、ドットで区切られ、全体の最大長が 255 オクテットを 含んでいるラベルの文字列である。DNS の分散によって幾つかのアプリケーションで 一般的な名前の使用が可能になっているが、DNS のある特定のアプリケーションは、 使用するドメイン名のシンタックスにさらに制限を設けることが許されている。特 に、このドキュメントのセクション 2.1 は、RFC-952 [DNS:4] で定義されている正 しいインターネットホスト名のシンタックスを、わずかに制約を解いている。 6.1.3.6 RR タイプの状態 ネームサーバは、MD と MF を除く全ての RR タイプを設定ファイルからロードでき なければならない (MUST)。MD と MF タイプは廃止されており、実装してはならない (MUST NOT)。特にネームサーバは、これらのタイプを設定ファイルからロードしては ならない (MUST NOT)。 DISCUSSION: RR タイプの MB, MG, MR, NULL, MINFO, RP は実験と見なされ、DNS を使用するアプ リケーションは、これらの RR タイプが大半のドメインでサポートされていると期待 することはできない。さらに、これらのタイプは定義し直されやすい。 TXT と WKS RR は、インターネットサイトで幅広く使用されることはなかった。結果 的にアプリケーションは、大半のドメインに TXT や WKS RR が存在することを当て にすることができない。 6.1.3.7 頑強性 ネットワークの接続性や他の問題によって、ルートサーバや他のサーバが利用できな い環境で、DNS ソフトウェアを運用する必要があるかもしれない。この状況におい て、DNS ネームサーバとリゾルバは、名前空間の到達可能な部分のためにサービスを 提供し続けなければならない (MUST)。一方、到達不能な部分に対しては一時的障害 とする。 DISCUSSION: DNS は、主に接続されたインターネットで使用することを意図しているが、インター ネットに接続されていないネットワークで、そのシステムを使用することは可能なは ずである。従って、実装体はローカルネームのサービスを提供する前に、ルートサー バへのアクセスに頼ってはならない。 6.1.3.8 ローカルホストテーブル DISCUSSION: ホストは、バックアップや DNS への補足としてローカルホストテーブルを使用して もよい。この場合、どれを優先するかという問題が生じる。最も柔軟なアプローチ は、これを設定オプションにすることだろう。 一般に、このような補足のホストテーブルの内容は、サイトによってローカルに決め られる。しかし、インターネットホストの公に利用可能なテーブルは、[DNS:4] でド キュメント化されている形式で DDN ネットワーク情報センター (DDN NIC) によって 維持される。このテーブルは、[DNS:5] で規定されているプロトコルを使用して DDN NIC から取り込むことができる。このテーブルは、全てのインターネットホストのう ちの小さな一部分しか含んでいないことに注意しなければならない。DDN NIC テーブ ルを取り込むためのこのプロトコルを使用するホストは、ALL コマンドでテーブル全 体を要求する前に、テーブルが変更されたか否かをチェックするために VERSION コ マンドを使用すべきである。VERSION 識別子は任意の文字列として扱い、一致するか をテストすべきである。数字の並びを仮定しない方がよい。 DDN NIC ホストテーブルは、ホスト運用では必要とされず、そのために DNS データ ベースに現在含まれていない管理情報、例えばネットワークとゲートウェイのエント リを含んでいる。しかし、この付加情報の大半は将来 DNS に追加されるだろう。逆 に言えば、DNS は DDN NIC ホストテーブルからは利用できない本質的なサービス (特に MX レコード) を提供している。 6.1.4 DNS ユーザインタフェース 6.1.4.1 DNS 管理 このドキュメントは管理上の、あるいは運用上の問題ではなく、ホストソフトウェア の設計と実装の問題に関係している。しかし、この大規模な分散データベースの特定 の部分におけるエラーが、多くのサイトで貧弱な、あるいは異常なパフォーマンスを 引き起こし得るので、管理上の問題は DNS においては特に重要である。これらの問 題は、[DNS:6] と [DNS:7] で論じられている。 6.1.4.2 DNS ユーザインタフェース ホスト上で動作している全てのアプリケーションプログラムで、ホストは DNS にイ ンタフェースを提供しなければならない (MUST)。このインタフェースは通常、リゾ ルバ機能 [DNS:1, 6.1:2] の実行をシステムプロセスに要求する。 最低限、基本インタフェースは、特定の名前と結び付いた特定のタイプとクラスの全 ての情報に対する要求をサポートしなければならず (MUST)、要求された情報の全 て、ハードエラーコード、ソフトエラー指示のいずれかを返却しなければならない ( MUST)。エラーが無い場合、基本インタフェースは新しいデータタイプに適応させる ために変更する必要は無いので、基本インタフェースは完全な応答情報を修正や削 除、整理せずに返却する。 DISCUSSION: DNS から特定の情報に常にアクセス可能であるとは限らないので、ソフトエラー指示 はインタフェースの本質的な部分である。セクション 6.1.3.3 を参照されたい。 ホストは特定の機能に仕立てられ、生のドメインデータをこれらの機能に、より適切 な形式に変換する他の DNS インタフェースを提供してもよい (MAY)。特にホスト は、ホストアドレスとホスト名間の変換を容易にするための DNS インタフェースを 提供しなければならない (MUST)。 6.1.4.3 インタフェース略語機能 ユーザインタフェースは、ユーザが共通的に使用される名前のための略語を入力する 方法を提供してもよい (MAY)。そのような方法の定義は、DNS 規定の範囲外である が、ある規則は、これらの方法が DNS ネーム空間全体へのアクセスを可能にするこ とを保証し、インターネットリソースの過度の使用を避けるために必要である。 もし略語方法が提供されるならば、 a. 略語方法を抑止するために、名前が既に完全であることを示すための規約が幾 つか存在しなければならない (MUST)。後続するドットは、通常の方法である。 b. 略語の展開は一回だけ行わなければならず (MUST)、名前が入力されたコンテキ ストで行わなければならない (MUST)。 DISCUSSION: 例えば、もし略語がメールプログラムで宛先に対して使用されていたら、その略語を 完全ドメイン名に展開し、既に完全であるという指示付きでキューイングされたメッ セージに格納すべきである。さもなくば、ユーザではなくメールシステム検索リスト で略語が展開されるかもしれない。あるいは、ワイルドカードを持つ内部動作の正規 化の試みが繰り返されるために、名前が大きくなるかもしれない。 最も一般的な略語方法は、以下の二つである。 (1) インタフェースレベルの別名 インタフェースレベルの別名は、別名/ドメイン名のペアのリストとして概念的に実 装される。そのリストはユーザ毎かホスト毎に持つことができ、別々のリストを異な る機能に割り当てることができる。例えば、あるリストはホスト名からアドレスへの 変換のためのリストで、また別のリストはメールドメインのためのリストである。ユ ーザが名前を入力すると、インタフェースはその名前をリストエントリの別名要素と 一致するか調べ、もし一致するエントリが見つかったら、その名前をペアで見つかっ たドメイン名に置き換える。 インタフェースレベルの別名と CNAME は、完全に別個のメカニズムである。CNAME は DNS 実装の必要な一部で、インターネット全般の別名メカニズムであるが、イン タフェースレベルの別名はローカルマターである。 (2) 検索リスト 検索リストは、ドメイン名の順序付けられてリストとして概念的に実装される。ユー ザが名前を入力すると、望まれた関連データを持つドメイン名が見つかるか、あるい は検索リストが無くなるまで、検索リスト内のドメイン名を、ユーザが付与した名前 へのサフィックスとして一つずつ使用する。検索リストは大抵、ローカルホストの親 ドメインか他の祖先ドメインの名前を含んでいる。検索リストは大抵、ユーザ毎かプ ロセス毎である。 管理者が DNS 検索リスト機能を無効にすることを可能にすべきである (SHOULD)。管 理上の否認は、DNS の悪用を防ぐためにあるケースで正当な理由を持つかもしれな い。 ユーザ入力が完全なドメイン名であるかをテストし、完了を示す最後のピリオドが無 い場合に、検索リストメカニズムがルートサーバに向けて過度のキュエリを生成する ことは危険である。検索リストメカニズムは、これを避けるための以下の二つの備え のうち一つは持たなければならず (MUST)、両方とも持つべきである (SHOULD)。 a. ローカルリゾルバ/ネームサーバは、否定応答のキャッシュ保存を実装すること ができる (セクション 6.1.3.3 を参照されたい)。 b. ローカルでないドメインサーバ、例えばルート向けのキュエリ中の名前を使お うとする前に、検索リストの展開者は生成されたドメイン名の中に二つ以上の 内部ドットを要求できる。 DISCUSSION: この要件の内容は、検索リストをテストする時にユーザでの過度の遅延を避けること であり、より重要な点としてルートや他の上位レベルサーバとの過度のトラフィック を防ぐことである。例えば、もしユーザが名前 "X" を付与し、検索リストがルート を要素として含んでいたら、次の検索リストの代替を試みる前に、キュエリはルート サーバを調べなければならない。その結果、ルートサーバやルートの近くのゲートウ ェイに起こる負荷は、インターネットのホストの数だけ増加するだろう。 否認キュッシュアルゴリズムは、名前が使用される最初の影響を制限する。内部ドッ ト規則も同様な実装であるが、幾つかのトップレベルの名前の使用を防ぐことができ る。 6.1.5 ドメインネームシステム要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -----------------------------------------------|-----------|-|-|-|-|-|-- 一般的な問題: | | | | | | | | | | | | | | DNS 名前からアドレスへの変換を実装 |6.1.1 |x| | | | | DNS アドレスから名前への変換を実装 |6.1.1 |x| | | | | ホストテーブルを用いた変換をサポート |6.1.1 | | |x| | | ゼロ TTL を持つ RR を適切に扱う |6.1.2.1 |x| | | | | 不必要に QCLASS=* を使用 |6.1.2.2 | |x| | | | インターネットクラスで QCLASS=IN を使用 |6.1.2.2 |x| | | | | 未使用フィールドが 0 |6.1.2.3 |x| | | | | 応答で圧縮を使用 |6.1.2.4 |x| | | | | | | | | | | | 応答に設定情報を含める |6.1.2.5 | | | | |x| 全てのよく知られたクラス無依存タイプをサポート |6.1.3.5 |x| | | | | タイプリストを容易に拡張 |6.1.3.5 | |x| | | | (MD と MF を除き) 全ての RR タイプをロード |6.1.3.6 |x| | | | | MD か MF タイプをロード |6.1.3.6 | | | | |x| ルートサーバ等が利用できない時の運用 |6.1.3.7 |x| | | | | -----------------------------------------------|-----------|-|-|-|-|-|-- リゾルバの問題: | | | | | | | | | | | | | | リゾルバが複数の同時要求をサポート |6.1.3.1 | |x| | | | 完全サービスリゾルバ: |6.1.3.1 | | |x| | | ローカルキャッシング |6.1.3.1 |x| | | | | ローカルキャッシュ内の情報をタイムアウトする |6.1.3.1 |x| | | | | 開始情報で設定可能 |6.1.3.1 | |x| | | | スタブリゾルバ: |6.1.3.1 | | |x| | | 冗長な再帰ネームサーバを使用する |6.1.3.1 |x| | | | | ローカルキャッシング |6.1.3.1 | | |x| | | ローカルキャッシュ内の情報をタイムアウトする |6.1.3.1 |x| | | | | リモートのマルチホーム化されたホストのサポート | | | | | | | 複数のアドレスを優先リストでソートする |6.1.3.4 | |x| | | | | | | | | | | -----------------------------------------------|-----------|-|-|-|-|-|-- トランスポートプロトコル: | | | | | | | | | | | | | | UDP キュエリのサポート |6.1.3.2 |x| | | | | TCP キュエリのサポート |6.1.3.2 | |x| | | | 最初に UDP キュエリを使用して送信 |6.1.3.2 |x| | | | |1 UDP 応答が切られていたら TCP で試みる |6.1.3.2 | |x| | | | ネームサーバが TCP キュエリの資源を制限 |6.1.3.2 | | |x| | | 不要な TCP キュエリを拒否 |6.1.3.2 | | | |x| | 切られたデータをあたかもそれが無かった様に使用 |6.1.3.2 | | | | |x| TCP のみ使うことをプライベートに合意 |6.1.3.2 | | |x| | | ゾーン転送で TCP を使用 |6.1.3.2 |x| | | | | TCP の利用が UDP キュエリをブロックしない |6.1.3.2 |x| | | | | broadcast か multicast キュエリをサポート |6.1.3.2 | | |x| | | キュエリに RD ビットを設定 |6.1.3.2 | | | | |x| b'cast/m'cast なら、サーバで RD ビットを無視 |6.1.3.2 |x| | | | | アドレスのプローブとしてのみ時々送信する |6.1.3.2 | |x| | | | -----------------------------------------------|-----------|-|-|-|-|-|-- 資源利用: | | | | | | | | | | | | | | [DNS:2] 毎に転送制御 |6.1.3.3 |x| | | | | 要求毎に有限な限度 |6.1.3.3 |x| | | | | 再試行後の障害 => ソフトエラー |6.1.3.3 |x| | | | | 一時的障害をキャッシュ |6.1.3.3 | |x| | | | 否定応答をキャッシュ |6.1.3.3 | |x| | | | 再試行は指数的なバックオフを使用 |6.1.3.3 | |x| | | | 最大値と最小値を持つ |6.1.3.3 | |x| | | | クライアントが送信元抑止を扱う |6.1.3.3 | |x| | | | サーバが送信元抑止を無視する |6.1.3.3 | | |x| | | -----------------------------------------------|-----------|-|-|-|-|-|-- ユーザインタフェース: | | | | | | | | | | | | | | 全プログラムは DNS アクセスインタフェースを持つ|6.1.4.2 |x| | | | | 所定の名前の全ての情報を要求可能 |6.1.4.2 |x| | | | | 完全な情報かエラーを返却 |6.1.4.2 |x| | | | | 特殊インタフェース |6.1.4.2 | | |x| | | 名前<->アドレス 変換 |6.1.4.2 |x| | | | | | | | | | | | 略語機能: |6.1.4.3 | | |x| | | 完全な名前のための規約 |6.1.4.3 |x| | | | | 一回だけ展開する |6.1.4.3 |x| | | | | 適切なコンテキストで展開 |6.1.4.3 |x| | | | | 検索リスト: |6.1.4.3 | | |x| | | 管理者が無効にできる |6.1.4.3 | |x| | | | 過度のルートキュエリを抑止 |6.1.4.3 |x| | | | | 両方の方法 |6.1.4.3 | |x| | | | -----------------------------------------------|-----------|-|-|-|-|-|-- -----------------------------------------------|-----------|-|-|-|-|-|-- 1. あるリゾルバとあるサーバとの間で、私的な合意が無いならば。 6.2 ホスト起動 6.2.1 導入 このセクションは、接続されたネットワークを経由した、あるいはより汎用的にイン ターネットパスを経由したホストソフトウェアの起動について論じる。これはディス クレスホストのために必要であり、ディスクドライブを持つホストで任意に使用して もよい。ディスクレスホストでは、この起動処理は "ネットワークブーティング" と 呼ばれ、ブート ROM に入れられたブートストラッププログラムによって制御され る。 ネットワークを経由してディスクレスホストを起動するために、二つの異なるフェー ズがある。 1. IP 層の設定 ディスクレスマシンは、ネットワーク設定情報を格納するための常設ストレー ジを普通は持っていないので、続くローディングのフェーズをサポートするた めに、十分な設定情報を動的に獲得しなければならない。この情報は、少なく ともホストとブートサーバの IP アドレスを含んでいなければならない。ゲー トウェイ越しのブートをサポートするためには、アドレスマスクやデフォルト ゲートウェイの一覧も必要である。 2. ホストシステムコードのロード ローディングフェーズの間、システムコードをブートサーバからネットワーク を経由してコピーするために、適切なファイル転送プロトコルが使用される。 ディスクを持つホストは最初のステップ、動的設定を実行してもよい。これは、フロ ッピーディスク中のネットワーク設定情報が、誤って一つ以上のホストと重複する可 能性がある小型コンピュータで重要である。また、設定情報を中央サーバから自動的 に獲得できれば、新しいホストのインストールがかなり簡単になり、管理者の時間を 節約し、間違える可能性を減らす。 6.2.2 要件 6.2.2.1 動的設定 動的設定のために、数多くのプロトコル規定が作成されている。 * ICMP 情報要求/応答メッセージ この廃止されたメッセージの組み合わせは、接続されているネットワークの番 号をホストが検出できるようにするために設計された。不幸にも、これはホス トが IP アドレスのホスト番号部を既に知っている場合にしか効果が無く、そ の情報は動的設定を必要とするホストは滅多に持なたい。 * 逆アドレス解決プロトコル (RARP) [BOOT:4] RARP はブロードキャスト媒体でのリンク層プロトコルであり、ホストがリンク 層アドレスに付与された自分の IP アドレスを見つけることを可能にする。不 幸にも、RARP は IP ゲートウェイ越しには動作しないので、全てのネットワー ク上に RARP サーバが必要である。さらに、RARP は他の如何なる情報も提供し ない。 * ICMP アドレスマスク要求/応答メッセージ これらの ICMP メッセージは、ホストがある特定のネットワークインタフェー スのアドレスマスクを知ることを可能にする。 * BOOTP プロトコル [BOOT:2] このプロトコルは、ホストがローカルホストとブートサーバの IP アドレス や、適切なブートファイルの名前、任意でアドレスマスクとデフォルトゲート ウェイの一覧を決めることを可能にする。BOOTP サーバの場所を知るために、 ホストは BOOTP 要求を UDP を使用してブロードキャストする。ゲートウェイ を通して BOOTP ブロードキャストを転送するために、特別なゲートウェイ拡張 が用いられており、将来は IP マルチキャスト機能がこの目的のための標準的 なメカニズムを提供するだろう。 動的設定のための提案されたアプローチは、RFC-1084 "BOOTP ベンダ情報拡張" [BOOT:3] で定義されている、拡張 BOOTP プロトコルを使うことである。RFC-1084 は、重要で汎用的な (ベンダー固有ではない) 幾つかの拡張を定義している。特にこ れらの拡張は、アドレスマスクを BOOTP で付与できるようにする。我々は、このや り方でアドレスマスクを付与することを推奨する (RECOMMEND)。 DISCUSSION: 歴史的に、サブネット化は IP のずっと後で定義されたので、アドレスマスクをホス トに与えるための別のメカニズム (ICMP アドレスマスクメッセージ) が設計され た。しかし、IP アドレスマスクとそれに対応する IP アドレスは概念的にペアを形 成しており、運用を容易にするために、設定ファイルであれ BOOTP のような動的メ カニズムであれ、それらは同時に同じメカニズムで定義すべきである。 BOOTP は、マルチホーム化されたホストの全てのインタフェースの設定を指定するの に、十分に汎用的ではないことに注意されたい。マルチホーム化されたホストは、 各々のインタフェースのためにそれぞれ別個に BOOTP を使用するか、ローディング を実行するために一つのインタフェースを BOOTP を使用して設定し、後でファイル から完全な初期化を実行するかのいずれかを行わなければならない。 アプリケーション層の設定情報は、システムコードをロードした後でファイルから取 得することが期待される。 6.2.2.2 ローディングフェーズ ローディングフェーズのために提案されているアプローチは、BOOTP によって確立さ れた IP アドレス間で TFTP を使用することである。[BOOT:1] セクション 4.2.3.5 で説明されている理由により、ブロードキャストアドレスへの TFTP は使用すべきではない (SHOULD NOT)。 6.3 リモート管理 6.3.1 導入 インターネット社会は最近、ネットワーク管理プロトコルの開発にかなり努力してい る。その結果、二つのアプローチに分岐している [MGT:1], [MGT:6]。それは、単純 ネットワーク管理プロトコル (SNMP) [MGT:4] と、TCP 上の共通管理情報プロトコル (CMOT) [MGT:5] である。 SNMP か CMOT を使用して管理するために、ホストは適切な管理エージェントを実装 する必要がある。インターネットホストは、SNMP か CMOT のいずれかのエージェン トを含むべきである (SHOULD)。 SNMP と CMOT の両方とも、管理値の集合体を定義する管理情報ベース (MIB) を扱 う。これらの値を読んだり設定することによって、リモートアプリケーションは管理 対象のシステムの状態を尋ねたり変更することができる。 標準 MIB [MGT:3] は、両方の管理プロトコルで使用するために定義されており、 [MGT:2] で定義されている管理情報構造 (SMI) によって定義されたデータ型を使用 している。追加の MIB 変数は、MIB の名前空間 [MGT:2] の "企業" と "実験" のサ ブツリーに導入することができる。 ホスト内の全てのプロトコルモジュールは、関連する MIB 変数を実装すべきである (SHOULD)。ホストは最も最近の標準 MIB で定義された MIB 変数を実装すべきであり (SHOULD)、適切で効果的な場合は他の MIB 変数を実装してもよい (MAY)。 6.3.2 プロトコルウォークスルー MIB はホストとゲートウェイの両方をカバーすることを意図している。ただし、両者 の MIB アプリケーションには詳細な相違はあるかもしれない。このセクションはホ ストの MIB の適切な解釈を含んでいる。MIB の最近バージョンは、更に多くのホス ト管理のためのエントリを含んでいるかもしれない。 管理対象のホストは、次の MIB オブジェクト定義のグループを実装しなければなら ない: System, Interfaces, Address Translation, IP, ICMP, TCP, UDP。 以下の特定の解釈がホストに適用される。 * ipInHdrErrors エラー "生存時間超過" は、送信元経路付きのデータグラムを転送する時にの みホストで発生することに注意されたい。 * ipOutNoRoutes このオブジェクトは、経路を見つけられなかったために破棄したデータグラム を数える。もしホストに設定された全てのデフォルトゲートウェイが停止して いれば、ホストでこれが起こるかもしれない。 * ipFragOKs, ipFragFails, ipFragCreates 意図的なな分割 ([INTRO:1] の "分割" セクション参照) を実装していないホ ストは、これらの三つのオブジェクトで 0 の値を返却しなければならない ( MUST)。 * icmpOutRedirects ホストはリダイレクトを送信しないので、ホストではこのオブジェクトは常に 0 でなければならない (MUST)。 * icmpOutAddrMaskReps もしホストがアドレスマスク情報の権威ある送信元でないならば、ホストでは このオブジェクトは常に 0 でなければならない (MUST)。 * ipAddrTable ホストでは、"IP アドレステーブル" オブジェクトは実際上、論理インタフェ ースのテーブルである。 * ipRoutingTable ホストでは、"IP ルーティングテーブル" オブジェクトは実際上、ホストのル ーティングキャッシュと、[INTRO:1] の "ルーティング出力データグラム" セ クションで説明されている静的経路テーブルの組み合わせである。 各 ipRouteEntry 内の ipRouteMetric1...4 はホストでは通常意味を持たず、 常に -1 とすべきである (SHOULD)。一方、ipRouteType は "remote" という値 を通常持つ。 もし接続されたネットワーク上の宛先が経路キャッシュ ([INTRO:1] の "ルー ティング出力データグラム" セクション参照) に表れなければ、"direct" の ipRouteType を持つエントリは存在しない。 DISCUSSION: 現在の MIB は ipRouteEntry の中にサービスタイプを含んでいないが、将来のバー ジョンではこれが追加されることが期待される。 さらに、MIB がアプリケーションのリモート管理を可能にするよう (例えば、メール システムの設定を部分的に変更可能にするなど) 拡張されることが期待される。従っ て、メールシステムなどのネットワークサービスアプリケーションは、リモート管理 のための "フック" 付きで書かれるべきである。 6.3.3 管理要件要約 | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -----------------------------------------------|-----------|-|-|-|-|-|-- SNMP か CMOT エージェントをサポートする |6.3.1 | |x| | | | 標準 MIB で規定されたオブジェクトをサポートする|6.3.1 | |x| | | | 7. 参照 このセクションは、全ての実装者が詳細に精通していなければならない主な参照を一 覧化している。また、追加として読むことが提案される副次的な参照も一覧化してい る。 導入の参照: [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, October 1989. [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985. [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, RFC-1011, May 1987. このドキュメントは、新しい RFC 番号で定期的に再発行される。最新の版を使用し なければならない。 [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC-980, March 1986. [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May 1987. このドキュメントは、新しい RFC 番号で定期的に再発行される。最新の版を使用し なければならない。 TELNET 参照: [TELNET:1] "Telnet Protocol Specification," J. Postel and J. Reynolds, RFC-854, May 1983. [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, RFC-855, May 1983. [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, RFC-856, May 1983. [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, May 1983. [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. Reynolds, RFC-858, May 1983. [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-859, May 1983. [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, RFC-860, May 1983. [TELNET:8] "Telnet Extended Options List," J. Postel and J. Reynolds, RFC-861, May 1983. [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983. [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, February 1989. このドキュメントは、RFC-930 に代わるものである。 [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, October 1988. [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August 1989. [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, December 1988. [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-1080, November 1988. 副次的な TELNET 参照: [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of Defense, May 1984. このドキュメントは、RFC-854 と同じプロトコルを規定しているはずである。矛盾す る場合は、RFC-854 が優先され、現在あるドキュメントが両ドキュメントよりも優先 される。 [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October 1977. [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS Implementation," A. Yasuda and T. Thompson, RFC-1043, February 1988. FTP 参照: [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC-959, October 1985. [FTP:2] "Document File Format Standards," J. Postel, RFC-678, December 1974. [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of Defense, May 1984. このドキュメントは FTP 規約の以前のバージョン (RFC-765) に基づいており、廃止 された。 TFTP 参照: [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June 1981. メール参照: [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August 1982. [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," D. Crocker, RFC-822, August 1982. このドキュメントは、以前の規約である RFC-733 に代わるものである。 [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986. この RFC は MX レコードの使用について規定しており、メール配送プロセスに対す る必須な拡張である。 [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, February 1988. [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, June 1986. [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. 前の二つの RFC は、インターネットと X.400 環境の間のメールゲートウェイの提案 された標準を定義している。 [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. Department of Defense, May 1984. この規約は RFC-821 と同じプロトコルを規定しているはずである。しかし、 MIL-STD-1781 は完全ではない。特にこれは MX レコード [SMTP:3] を含んでいな い。 [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, RFC-1049, March 1988. ドメインネームシステム参照: [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, RFC-1034, November 1987. このドキュメントと次のドキュメントは、RFC-882, RFC-883, RFC-973 に代わるもの である。 [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, P. Mockapetris, November 1987. [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986. [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, RFC-952, M. Stahl, E. Feinler, October 1985. 副次的な DNS 参照: [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, RFC-953, October 1985. [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November 1987. [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC-1033, November 1987. [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet Protocol Handbook, NIC 50007, SRI Network Information Center, August 1989. システム初期化参照: [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June 1984. [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-951, September 1985. [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-1084, December 1988. 注記: この RFC は RFC-1048 を改訂し、これに代わるものである。 [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. 管理参照: [MGT:1] "IAB Recommendations for the Development of Internet Network Management Standards," V. Cerf, RFC-1052, April 1988. [MGT:2] "Structure and Identification of Management Information for TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, August 1988. [MGT:3] "Management Information Base for Network Management of TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, August 1988. [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, M. Schoffstall, and C. Davin, RFC-1098, April 1989. [MGT:5] "The Common Management Information Services and Protocol over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. [MGT:6] "Report of the Second Ad Hoc Network Management Review Group," V. Cerf, RFC-1109, August 1989. セキュリティの考慮 ホストソフトウェアのアプリケーション/サポートプログラムには、数多くのセキュ リティ上の問題が存在する。しかし、それらを全て議論することは、この RFC の範 囲を超えている。セキュリティ関連の問題は、TFTP に関するセクション (セクショ ン 4.2.1, 4.2.3.4, 4.2.3.5)、SMTP VRFY と EXPN コマンドに関するセクション ( セクション 5.2.3)、SMTP HELO コマンドに関するセクション (セクション 5.2.5)、 SMTP DATA コマンドに関するセクション (セクション 5.2.8) で言及されている。 作者のアドレス Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 ------------------------------------------------------------------------ 前へ 先頭へ