|
Network Working Group Request for Comments: 1123 |
Internet Engineering Task Force R. Braden, Editor October 1989 |
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 の使用における規則を提供することに注意されたい。これらのプロトコルを使用する他の環境では、自身の規則を持つことを求めてもよい。
このセクションは、RFC-821 と RFC-822 の両方をカバーしている。
RFC-821 の SMTP 規定は明確であり、沢山の例を含んでいるので、実装者は理解が困難だと思わないはずである。このセクションは現在の使用方法に適合させるために、RFC-821 の一部に更新、あるいは注釈を簡単に施している。
RFC-822 は長く緻密なドキュメントであり、豊富なシンタックスを定義している。不幸にも、不完全もしくは欠陥のある RFC-822 の実装体が一般的である。実際、RFC-822 の数多くの形式のほぼ全てが使用されているので、実装体は通常 RFC-822 シンタックスの全てを認識し、正しく解釈する必要がある。
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)。
送信側 SMTP が MAIL と RCPT コマンドで送信するドメイン名は、"正規化" されていなければならない (MUST)。つまり省略されていない主要名か文字通りドメインでなければならず、ニックネームやドメインの省略名であってはならない。正規化された名前は、直接ホストを識別するか、MX 名であるかのいずれかであり、CNAME ではない。
受信側 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
は重要なプライバシーや、セキュリティの暴露にさえ相当すると考えている。
SMTP は、メッセージをユーザの端末に送信するためのコマンド: SEND, SOML, SAML を実装してもよい (MAY)。
DISCUSSION:
MX レコードを通じてメールを中継することは、メッセージをユーザの端末に即座に直接送信するための SEND
の意図と一貫しないことが指摘されている。しかし、ユーザの端末に直接書き込むことができない SMTP
受信側は、恐らく配送が遅延することを発行者に知らせるために、SEND に続く RCPT に対して
"251 ユーザはローカルでない (User Not Local)" 応答を返却することができる。
送信側 SMTP は、HELO コマンドの <domain> パラメタが、クライアントホストの正しい主要なホストドメイン名であることを保証しなければならない (MUST)。その結果、受信側 SMTP は、HELO パラメタの正当性を確認するために、この名前に対して MX の解決を実行する必要はない
HELO 受信側は、HELO パラメタが送信側の IP アドレスに実際に対応するか照合してもよい (MAY)。しかし、たとえ送信側の HELO コマンドの照合が失敗しても、受信側はメッセージの受け付けを拒否してはならない (MUST NOT)。
DISCUSSION:
HELO パラメタを照合するにはドメイン名検索が必要であり、従ってかなり時間がかかるかもしれない。偽りのメール送信元を突きとめるための替わりのツールは、後段で提案されている
("DATA コマンド" 参照)。
HELO アーギュメントは Received: 行に現れるので、依然として正しい <domain> シンタックスを持つ必要があることに注意されたい。正しくなければ、501 エラーが送信される。
IMPLEMENTATION:
HELO パラメタの照合が失敗したら、提案されている手続きは、送信側の信用未知に関する注記をヘッダ (例えば "Received:" 行) に挿入することである。
我々は、メールの (蓄積と) 転送を三つのタイプに区別する。
メッセージを転送するが異なるメール環境間のゲートウェイではないインターネットホスト (すなわち 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:<joe@GAMMA>"
を使用して、メッセージを GAMMA に直接転送しようと試みるべきである。このホストは中継をサポートしていないので、反転パスを更新する必要はない。
ある人は、障害周りで手動でメールをルーティングするために、送信元ルーティングが時々必要になるかもしれないと提案している。しかし、この必要性の実際と重要性は議論の余地がある。この目的での明示的な SMTP メール中継の使用は推奨されず、実際は、多くのホストシステムがサポートしていないので、うまく行かないだろう。あるものは、この目的で "%-hack" (セクション 5.2.16 参照) を使用している。
受信側 SMTP をサポートするホストは、予約されたメールボックス "Postmaster" をサポートしなければならない (MUST)。
受信側 SMTP は、到着時に RCPT パラメタを照合してもよい (MAY) が、妥当な時間 (セクション 5.3.2 参照) を超えて RCPT 応答を遅らせてはならない (MUST NOT)。
従って、RCPT に対する "250 OK" 応答は、必ずしも配送アドレスが正しいことを必ずしも意味していない。メッセージを受け付けた後で検出されたエラーは、適切なアドレスに通知メッセージをメールで送ることによって報告される (セクション 5.3.3 参照)。
DISCUSSION:
RCPT パラメタを即座に確認できる条件のセットは、技術的な設計の選択である。メールが送信される前に送信側 SMTP
に宛先メールボックスエラーを報告することは、一般に時間と帯域を節約するために望ましい。しかし、もし RCPT の照合が長ければ、この利点は失われる。
例えば、受信側は一つのローカルに登録されたメールボックス等の単純なローカル参照を、即座に照合することができる。一方、"妥当な時間" の限定は通常、メッセージが送信され受け付けられた後までメーリングリストの照合が遅れることを意味する。なぜなら、大規模なメーリングリストの照合は、非常に長い時間がかかるからである。実装体は、ローカルでなく、そのために DNS 検索を必要とするアドレスの照合を遅らせることを選択してもしなくてもよい。もし DNS 検索を実行したが、ソフトドメインシステムエラー (例えばタイムアウト) が発生したら、正当性が想定されるはずである。
全ての受信側 SMTP (単に "中継や最終的な配送のためにメッセージを受け付ける" [SMTP:1] だけではない) は、"Received:" 行をメッセージを先頭に挿入しなければならない (MUST)。RFC-821 で "タイムスタンプ行" とよばれるこの行には、以下が適用される。
インターネットメールプログラムは、メッセージヘッダにあらかじめ追加されている 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: 行で渡してもよい。
RFC-821 で示されている MAIL FROM: コマンドのシンタックスは、空のパス "MAIL FROM: <>" (RFC-821 ページ 15 参照) のケースを省略している。空の反転パスはサポートしなければならない (MUST)。
受信側 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 で説明されている応答コードの理論に従うと、これは合法的である。
実装者は、メールシステムがメッセージの透過性を保証するために、ピリオドを常に追加したり削除することを確実に行わなければならない (MUST)。
RFC-974 [SMTP:3] は、申し出された各々のメールターゲットが実際に SMTP をサポートしていることを確かめるために、ドメインシステムに WKS ("Well-Known Service") レコードのキュエリを発行することを推奨している。後の経験によると、WKS は広くサポートされてはいないことが分かっている。従って、MX 処理における WKS ステップは使用すべきではない (SHOULD NOT)。
以降は、RFC-822 に対する注意書きであり、そのドキュメントのセクションでまとめている。
Return-path 行として示されているシンタックスは、空の返却パスの可能性を省略している。空の返却パスは、エラー通知のループを避けるために使用される (セクション 5.3.3 参照)。完全なシンタックスは:
return = "Return-path" ":" route-addr
/ "Return-path" ":" "<" ">"
オプションのヘッダフィールドのセットは、ここで RFC-1049 [SMTP:7] で定義されている Content-Type フィールドを含むために拡張されている。このフィールドは、"メール読み込みシステムが構造を持ったメッセージ本体を自動的に識別し、それに応じて表示するために処理することを可能にする" [SMTP:7]。ユーザエージェントは、このフィールドをサポートしてもよい (MAY)。
日付のシンタックスは、ここで以下のように変更される。
date = 1*2DIGIT month 2*4DIGIT
メールソフトウェアは全て、次世紀への移行を容易にするために日付で 4 つの数字の年を使用すべきである (SHOULD)。
数字のタイムゾーン指定を使おうとする強い傾向があり、実装体はタイムゾーン名ではなく、数字のタイムゾーンを使用すべきである (SHOULD)。しかし全ての実装体は、いずれかの記述方法を受け入れなければならない (MUST)。もしタイムゾーン名が使用されたら、厳密に RFC-822 で定義された通りでなければならない (MUST)。
軍用のタイムゾーンは、RFC-822 で誤って規定されており、UT から誤った方法で計算している (記号が逆である)。その結果、RFC-822 ヘッダの軍用タイムゾーンは何の情報も提供していない。
最後に、付録 D のシンタックス要約にある "zone" の定義には、タイプミスがあることに注意されたい。正しい定義は RFC-822 のセクション 3 である。
RFC-822 にある "mailbox" のシンタックスの定義をここで以下のものに変更する。
mailbox = addr-spec ; simple address
/ [phrase] route-addr ; name & addr-spec
すなわち、経路アドレスの前のフレーズは今や任意である (OPTIONAL)。この変更により、例えば以下のようなヘッダフィールドは正しい。
From: <craig@nnsc.nsf.net>
基本的なメールボックスのアドレス規定は、"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" を解析することが許される
メーラは、中身 ("dtext"、RFC-822 参照) がドット付き数字のホストアドレスであるインターネットドメインリテラルを、受け付けて解析できなければならない (MUST)。これは、メールの場合におけるセクション 2.1 の要件を満たす。
SMTP は、自分の如何なる IP アドレスのドメインリテラルも受け付けて、認識しなければならない (MUST)。
822 アドレスの形式化時や解析時のエラーは、不幸にもよくあることである。このセクションは、最も一般的なエラーについてのみ言及する。ユーザエージェントは、全ての正しい RFC-822 アドレス形式を受け付けなければならず (MUST)、不正なアドレスシンタックスを生成してはならない (MUST NOT)。
DISCUSSION:
RFC-822 は、ドメインの中では略したドメイン名をローカルに使用することを許しているが、インターネットメールにおける RFC-822
のアプリケーションは、これを許さない。インターネットホストは、アドレスフィールドの中に略されたドメイン名を含む SMTP
メッセージヘッダを送信してはならないということが、その意図である。これによって、セクション 5.2.6
で要求されているように、インターネット中でヘッダのアドレスフィールドを変更せずに渡すことが可能になる。
@relay1,@relay2,@relay3:user@domain.
インターネットホストソフトウェアは、明示的な送信元経路付きのアドレスを含む RFC-822 ヘッダを生成すべきでない (SHOULD NOT)。しかし、古いシステムとの互換性のために、そのようなヘッダを受け付けなければならない (MUST)。
DISCUSSION:
控えめに、RFC-822 は "明示的な送信元経路は推奨されない" と述べている。多くのホストは RFC-822
送信元経路を誤って実装したので、実際にそのシンタックスを曖昧なく使用することができない。多くのユーザはそのシンタックスを醜いと感じている。明示的な送信元経路は、配送のためのメールエンペロープには必要無い
(セクション 5.2.6 参照)。これら全ての理由により、RFC-822
記法を使用する明示的な送信元経路は、インターネットメールヘッダでは使用しない。
セクション 5.2.16 で述べられているように、メールを明示的な送信元振り分けが必要な別の環境へゲートウェイすることを可能にするために、例えば "%-hack" を使用して、明示的な送信元経路をアドレスのローカルパートに埋め込める必要がある。注意深く見ると、ユーザエージェントが、宛先がインターネットの中にいる時に暗黙的な送信元振り分けの使用を検出して防ぐための方法が無いことが分かるだろう。我々は、不要で望ましくないものとして、インターネット内のあらゆる種類の送信元振り分けも非推奨とすることしかできない。
ホスト SMTP 実装体の共通的な構造は、ユーザのメールボックスや配送中にメッセージをキューイングするための一つ以上の領域、メールを送受信するための一つ以上のデーモンプロセスを含んでいる。その正確な構造は、ホスト上のユーザの必要性やホストによってサポートされるメーリングリストの個数とサイズによって変わるだろう。効果的であることが分かっている、特に高いトラフィックレベルをサポートしているメーラで効果的な幾つかの最適化について示す。
如何なるキューイング方法も、以下を含まなければならない (MUST)。
送信側 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)。
マルチホーム化されたホストの異なるアドレスの使用については、以下で論じる。
受信側 SMTP は、常に SMTP ポートをペンディングリッスンし続けようと試みるべきである (SHOULD)。これは、SMTP の複数の入力 TCP コネクションのサポートを必要とする。多少の制限を課してもよい (MAY)。
IMPLEMENTATION:
受信側 SMTP は、ある特定のホストアドレスからメールを受信する時、そのホストアドレスに対してペンディング中の全てのメールをリトライするよう送信側
SMTP に通知することができる。
送信側 SMTP でタイムアウトするためのアプローチは二つ存在する。(a) 各々の SMTP コマンドに対して別々に時間を制限する。(b) 一つのメールメッセージの各々の SMTP の会話全体に対して時間を制限する。送信側 SMTP は、コマンド毎のタイムアウトであるオプション (a) を使用すべきである (SHOULD)。タイムアウトは、なるべく SMTP コードを再コンパイルせず、簡単に再設定可能にすべきである (SHOULD)。
DISCUSSION:
タイムアウトは SMTP 実装の主要な機能である。もしタイムアウトが長過ぎたら (なお悪いことにタイムアウトが無かったら)、SMTP
プロセスがインターネット通信障害や受信側 SMTP
プログラムのバグに永久的に縛られる可能性がある。もしタイムアウトが短過ぎたら、メッセージ配送の過程におけるタイムアウトの試みで、資源が浪費されるだろう。
もしオプション (b) が使用されたら、タイムアウトはかなり大規模なメーリングリストを展開できる時間とするために、例えば 1 時間等、非常に大きくなければならない。また、非常に大きなメッセージを送信するための時間を考慮して、メッセージのサイズに比例してタイムアウトを増やす必要があるかもしれない。大きな固定のタイムアウトは、二つの問題を招く。それは、やはり失敗によって送信側が長い時間縛られることと、非常に大きなメッセージは依然として誤ってタイムアウトされるかもしれない (それは非常に無駄な障害だ!) ことである。
推奨されたオプション (a) を使用すると、タイマは各 SMTP コマンドとデータ転送の各バッファに対して設定される。後者は、全体的なタイムアウトがメッセージのサイズに本質的に比例することを意味している。
多忙なメール中継ホストにおける広範な経験に基づいて、コマンド毎の最小限のタイムアウト値は、以下とすべきである (SHOULD)。
受信側 SMTP は送信側からの次のコマンドを待つ間、少なくとも 5 分のタイムアウトを持つべきである (SHOULD)。
受信側 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:<user@d>" に送信すべきである。
メッセージが SMTP に受け付けられた後、幾つかの配送障害は避けられないだろう。例えば、"ソフト" ドメインシステムエラーやターゲットがメーリングリストであるために、受信側 SMTP が RCPT コマンド中の全ての配送アドレスを確認することが不可能かもしれない (前の RCPT の議論参照)。
タイムアウトの結果で重複メッセージの受信を避けるために、受信側 SMTP は、メッセージ転送を終える最後の "." に応答するために必要な時間を、最小限に留めなければならない (MUST)。この問題の議論については、RFC-1047 [SMTP:4] を参照されたい。
メッセージを送信するために、送信側 SMTP は、エンベロープ中の宛先アドレスからターゲットホストの IP アドレスを決める。特に送信側 SMTP は、"@" マークの右側の文字列を IP アドレスにマッピングする。このマッピングや転送自身はソフトエラーで失敗するかもしれない。その場合、送信側 SMTP は、セクション 5.3.1.1 で要求されているように、後のリトライのために出力メールを再度キューイングする。
もし成功した場合、そのマッピングによって単一のアドレスではなく、結果的に代替の配送アドレスの一覧を受け取るかもしれない。それは、(a) MX レコードが複数あるから、(b) マルチホーム化しているから、あるいはその両方のためである。信頼できるメール送信を提供するために、送信側 SMTP は配送の試みが成功するまで、この一覧中の各々のアドレスを順番通りにトライ (またはリトライ) できなければならない (MUST)。しかし、トライできる代替アドレスの個数に設定可能な制限が存在してもよい (MAY)。いずれにせよ、ホストは少なくとも二つのアドレスをトライすべきである (SHOULD)。
以下の情報は、ホストアドレスをランク付けするために使用する。
DISCUSSION:
複数の代替アドレスをトライする能力は必要とされるが、特定のインストールにおいて代替アドレスの使用を制限するか無効にすることを望む状況があるかもしれない。送信者が、マルチホーム化されたホストの別のアドレスを使用してリトライを試みるべきか否かの問題は、ずっと議論されてきている。複数のアドレスを使用することの主な論点は、時を得た配送確率、時には実際にあらゆる配送確率を最大限にするということである。それに対する論点は、結果的に不要な資源の使用を招くということである。
資源の使用は、セクション 5.3.1 で論じられている送信戦略によっても強く決まることに注意されたい。
SMTP の実装体は、ドメイン名と IP アドレスをマッピングするために、セクション 6.1 で定義されたメカニズムを使用しなければならない (MUST)。これは、全てのインターネット SMTP はインターネット DNS のサポートを含まなければならない (MUST) ことを意味する。
特に、送信側 SMTP は MX レコードスキーム [SMTP:3] をサポートしなければならない (MUST)。SMTP におけるドメイン名のサポートに関する情報については、[DNS:2] のセクション 7.4 も参照されたい。
SMTP 機能を持ったホストは、複数配送のためのアドレス展開の別名とリスト形式の両方をサポートすべきである (SHOULD)。展開されたリスト形式の各々のアドレスにメッセージを配送、あるいは転送する時、エンベロープ ("MAIL FROM:") 中の返却アドレスは、そのリストを管理している人のアドレスに変更しなければならない (MUST) が、メッセージヘッダは変更せずにおかなければならない (MUST)。特に、メッセージの "From" フィールドは変更しない。
DISCUSSION:
重要なメール機能は、疑似メールボックスアドレスを宛先メールボックスアドレスのリストに変更、もしくは
"展開" することによって、単一メッセージを複数の宛先へ配送するためのメカニズムである。このような疑似メールボックス (時々 "爆撃者"
と呼ばれる) にメッセージを送信すると、展開されたリストにある各々のメールボックスに、複製が転送あるいは再配布される。我々は、このような疑似メールボックスを、以下の展開規則によって
"別名"、あるいは "リスト" として分類している。
異なるメール環境、すなわち異なるメール形式やプロトコル間でメールをゲートウェイすることは複雑であり、容易に標準化できない。例として、[SMTP:5a], [SMTP:5b] を参照されたい。しかし、インターネットと他のメール環境間をゲートウェイするための、一般的な要件はある。
DISCUSSION:
これは、セクション 5.2.16 で提案されているように、宛先アドレスのローカル部の解析を伴ってもよい。
インターネットにゲートウェイする他のメールシステムは。通常 RFC-822 ヘッダのサブセットを使用するが、それらのうち幾つかは SMTP エンベロープと同等なものを持っていない。従って、メッセージがインターネット環境から出る時、SMTP のエンベロープ情報をメッセージヘッダに混ぜ込む必要があるかもしれない。考えられる解決方法は、エンベロープ情報を運ぶための新しいヘッダフィールド (例えば "X-SMTP-MAIL:" や "X-SMTP-RCPT:") を作成することである。しかし、これは外部環境のメールプログラムに変更が必要になるだろう。
DISCUSSION:
この要件は、セクション 5.2.8 の 一般的な "Received:" 行要件のサブセットであり、強調するために、ここで再度述べている。
他の環境から発行するメッセージの Received: フィールドは、RFC-822 に正確に適合していなくてもよい。しかし、Received: 行の最も重要な用途はメール障害のデバッグであり、Received: 行を "修正" しようとする、善意のゲートウェイがデバッグのひどい妨げになり得る。
ゲートウェイは、供給される Received フィールドの "via" 節で環境やプロトコルを示すことが、強く推奨される。
DISCUSSION:
リモート環境のアドレスへの変換を簡単にするために、メールゲートウェイで受け付けるアドレスの範囲を制限しようとする誘惑にしばしば駆られる。これを行うことは、メールユーザはメーラがメールゲートウェイに送信したアドレスを管理しているという仮定に基づく。しかし実際には、ユーザは最終的に送信したアドレスをほとんど管理しておらず、メーラがアドレスを正しい
RFC-822 形式に自由に変更している。
DISCUSSION:
インターネットメールリストは大抵、エンベロープの中にメールリストの管理者のアドレスを置いているが、元のメッセージヘッダを (元の送信者を含む "From:"
フィールド付きで) そのまま残している。これは、ヘッダに返信するとメールリスとの管理者にではなく元の送信者に送られることを、普通の受信者が期待する振舞いを生む。しかし、エラーは
(問題を改修できる) 管理者に送信し、(恐らく改修できない) 送信者には送らない。
メーラソフトウェアは、長さが (ヘッダを含め) 少なくとも 64K バイトのメッセージを送受信できなければならず (MUST)、これよりもずっと大きな最大長は非常に望ましい。
DISCUSSION:
SMTP はメッセージの最大長を定義していないが、多くのシステムは実装上の制限を課している。
インターネットにおいて制限の現在のデファクトの最小値が 64K バイトである。しかし電子メールは、ずっと大きなメッセージを作成する様々な目的で用いられる。例えばメールは、ASCII ファイルをを送信するために、特にドキュメント全体を送信するために、しばしば FTP の代わりで使われる。結果的に、メッセージは 1 メガバイトかそれ以上になり得る。参考までに、本ドキュメントは下位層のペアと合わせて 0.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
-----------------------------------------------|----------|-|-|-|-|-|--
| | | | | | |
受信側-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 | | | | | | |
ユーザが <route> アドレス入力可能 |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| | | | |
全てのホストは、ドメイン名システム (DNS) のためのリゾルバを実装しなければならず (MUST)、この DNS リゾルバを使用してホスト名を IP アドレスに変換したり、その逆を行うメカニズムを実装しなければならない (MUST)。[DNS:1], [DNS:2]
DNS に加えて、ホストはローカルのインターネットホストテーブルを検索するホスト名変換メカニズムを実装してもよい (MAY)。このオプションに関する詳細情報は、セクション 6.1.3.8 を参照されたい。
DISCUSSION:
インターネットホスト名変換は、全てのホストのテーブルのローカルコピーを検索することによって任意に実行される。このテーブルは適宜更新し配布するにはあまりにも大きくなり、多くのホストに適応させるにも大き過ぎる。そこで、DNS が発明された。
DNS は分散データベースを作成し、主にホスト名とホストアドレス間の変換のために使用される。DNS ソフトウェアの実装が必要である。DNS は二つの論理的に異なる部品、ネームサーバとリゾルバで構成される (実装体はしばしば、効率のためにこれらの二つの論理的な部分を併用するが)。[DNS:2]
ドメインネームサーバは、データベースとデータに関する応答キュエリのあるセクションについて、権威のあるデータを格納する。ドメインリゾルバは、ユーザプロセスのためにデータに関してドメインネームサーバに問いかける。従って、全てのホストは DNS リゾルバが必要であり、あるホストマシンはドメインネームサーバを実行する必要もあるだろう。ネームサーバは完全な情報を持たないので、一般にキュエリを解決するために一つ以上のネームサーバから情報を獲得する必要がある。
実装者は、参照 [DNS:1] と [DNS:2] を注意深く調べなければならない。それらは、理論やプロトコル、ドメイン名システムの実装について詳細な説明を提供しており、数年に渡る経験を反映している。
全ての DNS ネームサーバとリゾルバは、ゼロの TTL を持つ RR を適切に扱わなければならない (MUST)。ゼロの場合クライアントに RR を返却するが、それをキャッシュしない。
DISCUSSION:
ゼロの TTL 値は、RR
が実行中のトランザクションでのみ使用でき、キャッシュすべきでないことを意味するものと解釈される。それは、極めて変わりやすいデータのために効果的である。
"QCLASS=*" を持つキュエリは、要求者が一つ以上のクラスからデータを求めているのでなければ使用すべきでない (SHOULD NOT)。特に、もし要求者がインターネットデータタイプにのみ興味があるならば、QCLASS=IN を使用しなければならない (MUST)。
キュエリや応答メッセージ中の未使用フィールドは、ゼロでなければならない (MUST)。
ネームサーバは、応答で圧縮を使用しなければならない (MUST)。
DISCUSSION:
圧縮は UDP データグラムの氾濫を避けるために必要不可欠である。セクション 6.1.3.2 を参照されたい。
再帰ネームサーバと完全サービスリゾルバは通常、ルートやローカルのネームサーバの場所に関するヒントを含む幾つかの構成情報を持つ。実装体は、応答にこれらの如何なるヒントも含めてはならない (MUST NOT)。
DISCUSSION:
多くの実装者は、これらのヒントをあたかもキャッシュされたデータであるかのように格納するのは効果的であることを見出したが、あるものは、この
"キャッシュされたデータ"
を応答に含めないことの保証を怠っていた。これは、ヒントが廃止されて不正になった時に、インターネットに重大な問題を招いた。
もしホストが同時処理をサポートしているならば、ネームリゾルバは複数の同時要求を発行可能にすべきである (SHOULD)。
DNS リゾルバを実装する際、二つの異なるモデル、完全サービスリゾルバかスタブリゾルバのうち一つを任意で選択してもよい (MAY)。
(A) 完全サービスリゾルバ
完全サービスリゾルバはリゾルバサービスの完全な実装体であり、通信障害、個々のネームサーバの障害、指定された名前に対する適切なネームサーバの場所等を取り扱うことが可能である。以下の要件を満たさなければならない。
(B) スタブリゾルバ
"スタブリゾルバ" は、接続されたネットワーク上の再帰ネームサーバや "近くの"
ネットワークのサービスに頼る。このスキームは、ホストがリゾルバ機能の負担を別のホスト上のネームサーバに渡すことを可能にする。このモデルは、例えば
PC 等の能力の低いホストに必要不可欠であり、ホストがローカルネットワーク上の複数のワークステーションの一つである場合に、推奨されもする。なぜなら、ワークステーションの全てで再帰ネームサーバのキャッシュを分散することが可能になり、それによってローカルネットワークから出されるドメイン要求の数を減らすことができる。
最低限、スタブリゾルバは要求を冗長なネームサーバに向けることができなければならない (MUST)。再帰的なネームサーバは、引き受ける要求の送信元を制限することが許されていることに注意されたい。よって、ホスト管理者はサービスが提供されるか照合しなければならない。スタブリゾルバは、もし選択するならばキャッシュを実装してもよい (MAY) が、実装するならばキャッシュされた情報をタイムアウトしなければならない (MUST)。
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
アドレスを知らなくても、近くのネームサーバの位置を突き止める方法を提供できる。しかし、再帰キュエリの一般的なブロードキャストは、過渡で不必要な負荷をネットワークとサーバの両方にかける可能性がある。
サーバとリゾルバに対する以下の要件は、インターネット全体の健全を保つために非常に重要である。DNS サービスが、メーラのような上位レベルの自動サーバによって繰り返し起動される場合は、特に重要である。
DISCUSSION:
これは、 (このドキュメントのセクション 2.2 に反して) ソフト障害を即座に再試行するアプリケーションが、過度の
DNS トラフィックを生み出すことを回避するだろう。
IMPLEMENTATION:
初期再送間隔を算出するために、(利用できるならば) 計測された RTT と平方偏差を使用すべきである。もしこの情報を利用できないならば、5
秒程度のデフォルト値を使用すべきである。実装体は再送間隔を制限してもよいが、この制限は、インターネットの最大セグメント生存時間の二倍にネームサーバのサービス遅延を加えた値より大きくなければならない。
IMPLEMENTATION:
その割合を減らすための推奨動作の一つは、もし利用できるものが存在するならば、次のキュエリ要求を別のサーバに送信することである。もう一つはの推奨動作は、同じサーバに対する再送間隔をバックオフすることである。
ホスト名からアドレスへの変換機能が複数のアドレスを持つホストに遭遇した場合、直近に接続されたネットワーク番号や他の適用可能なパフォーマンス、履歴情報の知識を使用して、アドレスをランク付けするかソートすべきである (SHOULD)。
DISCUSSION:
マルチホームホストの異なるアドレスは、一般に異なるインターネットパスを意味し、あるパスは別のパスよりもパフォーマンスや信頼性、管理上の制限において望ましいかもしれない。ドメインシステムが最善のパスを決定するための一般的な方法は存在しない。推奨されたアプローチは、この決定がシステム管理者によって設定されたローカルな設定情報に基づくことである。
IMPLEMENTATION:
以下のスキームが正常に使用されている。
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] で定義されている正しいインターネットホスト名のシンタックスを、わずかに制約を解いている。
ネームサーバは、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 が存在することを当てにすることができない。
ネットワークの接続性や他の問題によって、ルートサーバや他のサーバが利用できない環境で、DNS ソフトウェアを運用する必要があるかもしれない。この状況において、DNS ネームサーバとリゾルバは、名前空間の到達可能な部分のためにサービスを提供し続けなければならない (MUST)。一方、到達不能な部分に対しては一時的障害とする。
DISCUSSION:
DNS は、主に接続されたインターネットで使用することを意図しているが、インターネットに接続されていないネットワークで、そのシステムを使用することは可能なはずである。従って、実装体はローカルネームのサービスを提供する前に、ルートサーバへのアクセスに頼ってはならない。
DISCUSSION:
ホストは、バックアップや DNS
への補足としてローカルホストテーブルを使用してもよい。この場合、どれを優先するかという問題が生じる。最も柔軟なアプローチは、これを設定オプションにすることだろう。
一般に、このような補足のホストテーブルの内容は、サイトによってローカルに決められる。しかし、インターネットホストの公に利用可能なテーブルは、[DNS:4] でドキュメント化されている形式で DDN ネットワーク情報センター (DDN NIC) によって維持される。このテーブルは、[DNS:5] で規定されているプロトコルを使用して DDN NIC から取り込むことができる。このテーブルは、全てのインターネットホストのうちの小さな一部分しか含んでいないことに注意しなければならない。DDN NIC テーブルを取り込むためのこのプロトコルを使用するホストは、ALL コマンドでテーブル全体を要求する前に、テーブルが変更されたか否かをチェックするために VERSION コマンドを使用すべきである。VERSION 識別子は任意の文字列として扱い、一致するかをテストすべきである。数字の並びを仮定しない方がよい。
DDN NIC ホストテーブルは、ホスト運用では必要とされず、そのために DNS データベースに現在含まれていない管理情報、例えばネットワークとゲートウェイのエントリを含んでいる。しかし、この付加情報の大半は将来 DNS に追加されるだろう。逆に言えば、DNS は DDN NIC ホストテーブルからは利用できない本質的なサービス (特に MX レコード) を提供している。
このドキュメントは管理上の、あるいは運用上の問題ではなく、ホストソフトウェアの設計と実装の問題に関係している。しかし、この大規模な分散データベースの特定の部分におけるエラーが、多くのサイトで貧弱な、あるいは異常なパフォーマンスを引き起こし得るので、管理上の問題は DNS においては特に重要である。これらの問題は、[DNS:6] と [DNS:7] で論じられている。
ホスト上で動作している全てのアプリケーションプログラムで、ホストは DNS にインタフェースを提供しなければならない (MUST)。このインタフェースは通常、リゾルバ機能 [DNS:1, 6.1:2] の実行をシステムプロセスに要求する。
最低限、基本インタフェースは、特定の名前と結び付いた特定のタイプとクラスの全ての情報に対する要求をサポートしなければならず (MUST)、要求された情報の全て、ハードエラーコード、ソフトエラー指示のいずれかを返却しなければならない (MUST)。エラーが無い場合、基本インタフェースは新しいデータタイプに適応させるために変更する必要は無いので、基本インタフェースは完全な応答情報を修正や削除、整理せずに返却する。
DISCUSSION:
DNS から特定の情報に常にアクセス可能であるとは限らないので、ソフトエラー指示はインタフェースの本質的な部分である。セクション 6.1.3.3
を参照されたい。
ホストは特定の機能に仕立てられ、生のドメインデータをこれらの機能に、より適切な形式に変換する他の DNS インタフェースを提供してもよい (MAY)。特にホストは、ホストアドレスとホスト名間の変換を容易にするための DNS インタフェースを提供しなければならない (MUST)。
ユーザインタフェースは、ユーザが共通的に使用される名前の省略名を入力する方法を提供してもよい (MAY)。そのような方法の定義は、DNS 規定の範囲外であるが、ある規則は、これらの方法が DNS ネーム空間全体へのアクセスを可能にすることを保証し、インターネットリソースの過度の使用を避けるために必要である。
もし省略方法が提供されるならば、
DISCUSSION:
例えば、もし省略名がメールプログラムで宛先に対して使用されていたら、その省略名を完全ドメイン名に展開し、既に完全であるという指示付きでキューイングされたメッセージに格納すべきである。さもなくば、ユーザではなくメールシステム検索リストで省略名が展開されるかもしれない。あるいは、ワイルドカードを持つ内部動作の正規化の試みが繰り返されるために、名前が大きくなるかもしれない。
最も一般的な省略方法は、以下の二つである。
(1) インタフェースレベルの別名
インタフェースレベルの別名は、別名/ドメイン名のペアのリストとして概念的に実装される。そのリストはユーザ毎かホスト毎に持つことができ、別々のリストを異なる機能に割り当てることができる。例えば、あるリストはホスト名からアドレスへの変換のためのリストで、また別のリストはメールドメインのためのリストである。ユーザが名前を入力すると、インタフェースはその名前をリストエントリの別名要素と一致するか調べ、もし一致するエントリが見つかったら、その名前をペアで見つかったドメイン名に置き換える。
インタフェースレベルの別名と CNAME は、完全に別個のメカニズムである。CNAME は DNS 実装の必要な一部で、インターネット全般の別名メカニズムであるが、インタフェースレベルの別名はローカルマターである。
(2) 検索リスト
検索リストは、ドメイン名の順序付けられたリストとして概念的に実装される。ユーザが名前を入力すると、望まれた関連データを持つドメイン名が見つかるか、あるいは検索リストが無くなるまで、検索リスト内のドメイン名を、ユーザが付与した名前へのサフィックスとして一つずつ使用する。検索リストは大抵、ローカルホストの親ドメインか他の祖先ドメインの名前を含んでいる。検索リストは大抵、ユーザ毎かプロセス毎である。
管理者が DNS 検索リスト機能を無効にすることを可能にすべきである (SHOULD)。管理上の否認は、DNS の悪用を防ぐためにあるケースで正当な理由を持つかもしれない。
ユーザ入力が完全なドメイン名であるかをテストし、完了を示す最後のピリオドが無い場合に、検索リストメカニズムがルートサーバに向けて過度のキュエリを生成することは危険である。検索リストメカニズムは、これを避けるために以下の二つの備えのうち一つは持たなければならず (MUST)、両方とも持つべきである (SHOULD)。
DISCUSSION:
この要件の内容は、検索リストをテストする時にユーザでの過度の遅延を避けることであり、より重要な点としてルートや他の上位レベルサーバとの過度のトラフィックを防ぐことである。例えば、もしユーザが名前
"X" を付与し、検索リストがルートを要素として含んでいたら、次の検索リストの代替を試みる前に、キュエリはルートサーバを調べなければならない。その結果、ルートサーバやルートの近くのゲートウェイに起こる負荷は、インターネットのホストの数だけ増加するだろう。
否認キュッシュアルゴリズムは、名前が使用される最初の影響を制限する。内部ドット規則も同様な実装であるが、幾つかのトップレベルの名前の使用を防ぐことができる。
| | | | |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. あるリゾルバとあるサーバとの間で、私的な合意が無いならば。
このセクションは、接続されたネットワークを経由した、あるいはより汎用的にインターネットパスを経由したホストソフトウェアの起動について論じる。これはディスクレスホストのために必要であり、ディスクドライブを持つホストで任意に使用してもよい。ディスクレスホストでは、この起動処理は "ネットワークブーティング" と呼ばれ、ブート ROM に入れられたブートストラッププログラムによって制御される。
ネットワークを経由してディスクレスホストを起動するために、二つの異なるフェーズがある。
ディスクを持つホストは最初のステップ、動的設定を実行してもよい。これは、フロッピーディスク中のネットワーク設定情報が、誤って一つ以上のホストと重複する可能性がある小型コンピュータで重要である。また、設定情報を中央サーバから自動的に獲得できれば、新しいホストのインストールがかなり簡単になり、管理者の時間を節約し、間違える可能性を減らす。
動的設定のために、数多くのプロトコル規定が作成されている。
動的設定のための提案されたアプローチは、RFC-1084 "BOOTP ベンダ情報拡張" [BOOT:3] で定義されている、拡張 BOOTP プロトコルを使うことである。RFC-1084 は、重要で汎用的な (ベンダー固有ではない) 幾つかの拡張を定義している。特にこれらの拡張は、アドレスマスクを BOOTP で付与できるようにする。我々は、このやり方でアドレスマスクを付与することを推奨する (RECOMMEND)。
DISCUSSION:
歴史的に、サブネット化は IP のずっと後で定義されたので、アドレスマスクをホストに与えるための別のメカニズム (ICMP アドレスマスクメッセージ)
が設計された。しかし、IP アドレスマスクとそれに対応する IP アドレスは概念的にペアを形成しており、運用を容易にするために、設定ファイルであれ
BOOTP のような動的メカニズムであれ、それらは同時に同じメカニズムで定義すべきである。
BOOTP は、マルチホーム化されたホストの全てのインタフェースの設定を指定するのに、十分に汎用的ではないことに注意されたい。マルチホーム化されたホストは、各々のインタフェースのためにそれぞれ別個に BOOTP を使用するか、ローディングを実行するために一つのインタフェースを BOOTP を使用して設定し、後でファイルから完全な初期化を実行するかのいずれかを行わなければならない。
アプリケーション層の設定情報は、システムコードをロードした後でファイルから取得することが期待される。
ローディングフェーズのために提案されているアプローチは、BOOTP によって確立された IP アドレス間で TFTP を使用することである。[BOOT:1]
セクション 4.2.3.5 で説明されている理由により、ブロードキャストアドレスへの TFTP は使用すべきではない (SHOULD NOT)。
インターネット社会は最近、ネットワーク管理プロトコルの開発にかなり努力している。その結果、二つのアプローチに分岐している [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)。
MIB はホストとゲートウェイの両方をカバーすることを意図している。ただし、両者の MIB アプリケーションには詳細な相違はあるかもしれない。このセクションはホストの MIB の適切な解釈を含んでいる。MIB の最近バージョンは、更に多くのホスト管理のためのエントリを含んでいるかもしれない。
管理対象のホストは、次の MIB オブジェクト定義のグループを実装しなければならない: System, Interfaces, Address Translation, IP, ICMP, TCP, UDP。
以下の特定の解釈がホストに適用される。
DISCUSSION:
現在の MIB は ipRouteEntry の中にサービスタイプを含んでいないが、将来のバージョンではこれが追加されることが期待される。
さらに、MIB がアプリケーションのリモート管理を可能にするよう (例えば、メールシステムの設定を部分的に変更可能にするなど) 拡張されることが期待される。従って、メールシステムなどのネットワークサービスアプリケーションは、リモート管理のための "フック" 付きで書かれるべきである。
| | | | |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| | | |
このセクションは、全ての実装者が詳細に精通していなければならない主な参照を一覧化している。また、追加として読むことが提案される副次的な参照も一覧化している。
導入の参照:
[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