RFC1123 日本語訳
1123 Requirements for Internet Hosts - Application and Support. R.Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates RFC0822) (Updated by RFC1349, RFC2181, RFC5321) (Also STD0003) (Status: STANDARD)
RFC一覧
英語原文
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" シグナル
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 と RRC-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 の "要件" は、既に標準プロトコルドキュメ
ントで述べられているか、含まれている。よってここに含めることは、あ
る意味冗長である。しかし、幾つかの過去の実装は誤った選択をし、相互
接続性やパフォーマンス、頑強性に問題を引き起こしたことがあるので、
それらを含めている。
このドキュメントは、数多くの要件や推奨についての議論や説明を含んで
いる。要件を簡単に一覧化することは危険である。なぜなら、
o ある必要な機能は他の機能よりも重要であり、ある機能はオプション
である。
o 制限されたコンテキストで設計された特定のベンダ製品が、異なる規
定の使用を選択したことは、正当な理由があるかもしれない。
しかし、このドキュメントの規定は、多種多様で複雑なインターネットシ
ステム全体で、任意のホストの相互運用の一般的な目標に適合するために
従わなければならない。現在の大半の実装は、あるものはメジャーな、ま
たあるものはマイナーな様々な点でこれらの要件に適合していないが、こ
の規定は我々が移行する必要のある考え方である。
これらの要件は、インターネット体系の現在のレベルに基づいている。こ
のドキュメントは、追加の説明を提供したり、規定が依然として発展して
いる分野における追加の情報を含めるために、必要に応じて更新されるだ
ろう。
この導入部のセクションは、ホストソフトウェアベンダへの幾つかの一般
的なアドバイスから始め、ドキュメントの残りを読むにあたってのガイダ
ンスを示している。セクション 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 モードに出入りするための規則は以下の通り。
o Server は、クライアントが DET であることを認識する
ために、端末タイプオプション [TELNET:10] を使用する。
o 両端が EOR オプション [TELNET:9] を折衝することは伝
統的であるが、必須要件ではない。
o ネイティブ DET モードに入るために、両端はバイナリオ
プション [TELNET:3] を折衝する。
o 一方の終端がバイナリモードから出るよう折衝したら、
もう一方の終端も出て、モードは通常 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 N と TYPE T に相違が無いホストは、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 と RRC-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)。
o よくあるエラーは、グループ識別子の後のセミコロンを抜かす
ことである。
o あるシステムは、生成するメッセージ中に完全に正式なドメイ
ン名が無い。ヘッダアドレスフィールドの "@" 記号の右側は、
完全に正式なドメイン名でなければならない (MUST)。
例えば、あるシステムは From: アドレスが完全に正式なドメ
イン名でない。これは、ユーザインタフェースにおける "
reply" コマンドで、自動的に返送アドレスを生成することを
妨げる。
DISCUSSION:
RFC-822 は、ドメインの中では略したドメイン名をロー
カルに使用することを許しているが、インターネットメ
ールにおける RFC-822 のアプリケーションは、これを許
さない。インターネットホストは、アドレスフィールド
の中に略されたドメイン名を含む SMTP メッセージヘッ
ダを送信してはならないということが、その意図である。
これによって、セクション 5.2.6 で要求されているよう
に、インターネット中でヘッダのアドレスフィールドを
変更せずに渡すことが可能になる。
o あるシステムは、以下のような複数ホップの明示的な送信元経
路を誤って解釈する。
@relay1,@relay2,@relay3:user@domain.
o あるシステムは、アドレスやメッセージ 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)。
o 全ての作業をタイムアウトする。セクション 5.3.2 参照。
o エラーメッセージに対する応答でエラーメッセージを送信しな
い。
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)。
o 最初の 220 メッセージ: 5 分
送信側 SMTP プロセスは、TCP コネクションの障害と最初の
220 挨拶メッセージの受信時の遅延を区別する必要がある。多
くの受信側 SMTP は、TCP コネクションを受諾しても、システ
ムの負荷が更にメールを処理できるようになるまで 220 メッ
セージの送信を遅らせるだろう。
o MAIL コマンド: 5 分
o RCPT コマンド: 5 分
メーリングリストや別名の処理がメッセージを受け付けた後ま
で保留されないならば、タイムアウトの時間をより長くする必
要がある。
o DATA 開始: 2 分
これは DATA コマンドに対する "354 Start Input" 応答を待
つ間である。
o データブロック: 3 分
これは、データの塊を送信する各々 TCP SEND 呼び出しの完了
を待つ間である。
o DATA 完了: 10 分
これは、"250 OK" 応答を待つ間である。受信側は、メッセー
ジデータを終了する最後のピリオドを受信する時、通常はユー
ザのメールボックスにメッセージを配送するための処理を実行
する。メッセージは正常に送信されているので、この時点で誤
ったタイムアウトが起こるのは非常に無駄である。
受信側 SMTP は送信側からの次のコマンドを待つ間、少なくとも 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) 完全サービスリゾルバ
完全サービスリゾルバはリゾルバサービスの完全な実装体
であり、通信障害、個々のネームサーバの障害、指定され
た名前に対する適切なネームサーバの場所等を取り扱うこ
とが可能である。以下の要件を満たさなければならない。
o リゾルバは、個々の要求に対するリモートアクセスの
繰り返しを避けるために、ローカルなキャッシング機
能を実装しなければならず (MUST)、キャッシュ内の
情報をタイムアウトしなければならない (MUST)。
o リゾルバは、複数のルートネームサーバや、ローカル
ドメインのための複数のネームサーバを指している開
始情報を設定可能とすべきである (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) ホスト設定データに、優先ネットワークリストを組み
込む。それは、ネットワークの優先順の単なる一覧で
ある。優先順位が無ければ、このリストは空でもよい。
(a) ホスト名を 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 動的設定
動的設定のために、数多くのプロトコル規定が作成されている。
o ICMP 情報要求/応答メッセージ
この廃止されたメッセージの組み合わせは、接続されてい
るネットワークの番号をホストが検出できるようにするた
めに設計された。不幸にも、これはホストが IP アドレス
のホスト番号部を既に知っている場合にしか効果が無く、
その情報は動的設定を必要とするホストは滅多に持なたい。
o 逆アドレス解決プロトコル (RARP) [BOOT:4]
RARP はブロードキャスト媒体でのリンク層プロトコルであ
り、ホストがリンク層アドレスに付与された自分の IP ア
ドレスを見つけることを可能にする。不幸にも、RARP は
IP ゲートウェイ越しには動作しないので、全てのネットワ
ーク上に RARP サーバが必要である。さらに、RARP は他の
如何なる情報も提供しない。
o ICMP アドレスマスク要求/応答メッセージ
これらの ICMP メッセージは、ホストがある特定のネット
ワークインタフェースのアドレスマスクを知ることを可能
にする。
o 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。
以下の特定の解釈がホストに適用される。
o ipInHdrErrors
エラー "生存時間超過" は、送信元経路付きのデータグラムを
転送する時にのみホストで発生することに注意されたい。
o ipOutNoRoutes
このオブジェクトは、経路を見つけられなかったために破棄し
たデータグラムを数える。もしホストに設定された全てのデフォ
ルトゲートウェイが停止していれば、ホストでこれが起こるか
もしれない。
o ipFragOKs, ipFragFails, ipFragCreates
意図的なな分割 ([INTRO:1] の "分割" セクション参照) を実
装していないホストは、これらの三つのオブジェクトで 0 の
値を返却しなければならない (MUST)。
o icmpOutRedirects
ホストはリダイレクトを送信しないので、ホストではこのオブ
ジェクトは常に 0 でなければならない (MUST)。
o icmpOutAddrMaskReps
もしホストがアドレスマスク情報の権威ある送信元でないなら
ば、ホストではこのオブジェクトは常に 0 でなければならな
い (MUST)。
o ipAddrTable
ホストでは、"IP アドレステーブル" オブジェクトは実際上、
論理インタフェースのテーブルである。
o 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
Phone: (213) 822 1511
EMail: Braden@ISI.EDU
一覧
スポンサーリンク
