が原著です。 翻訳版は、翻訳からくる間違いがあり得ます。 Yasutaka Kato 加藤泰孝 ----------------------------------------------------------------------  Network Working Group J. Klensin, WG Chair Request For Comments: 1869 MCI STD: 10 N. Freed, Editor Obsoletes: 1651 Innosoft International, Inc. Category: Standards Track M. Rose Dover Beach Consulting, Inc. E. Stefferud Network Management Associates, Inc. D. Crocker Brandenburg Consulting November 1995 SMTP Service Extensions SMTPサービス拡張 この覚書の位置付け この文書はインターネット交流社会のためのインターネット標準過程手順を 特定し、改善への議論と示唆を求めるものです。この手順の標準化状況と位 置付けについては「インターネット公的手順基準」(STD1)の最新の編集を 参照ください。この覚書の配布の制限はありません。 1. 要約 この覚書は、サーバーSMTPがクライアントSMTPにサポートしているサービス 拡張について、伝える手段を定義することで、SMTP拡張の枠組を定義します。 SMTPサービスの拡張はIANAに登録されます。この枠組は既存のSMTPクライア ントとサーバーの修正、サービス拡張機能が請求もしくは提供される必要が ないなら、を必要としません。 2. はじめに 簡潔なメール転送手順(SMTP)は安定し効果的な基盤をメッセージ転送代行 手段に提供してきています。過去十年、SMTPは非常に弾性があることを証明 してきています。それにもかかわらず、多くのプロトコール拡張の要求が明 らかになってきています。これらの拡張を別個の計画性のない実体として記 載するのではなく、この文書は、全ての将来の拡張が単一で首尾一貫した方 法で作り上げることができる枠組を提供すると言う直接的やり方で、SMTPを 拡大します。 3. SMTP拡張の枠組 SMTPサービス拡張の目的で、SMTPは封筒と中味を内容とするメール対象を中 継します。 (1) SMTP封書はまわりくどくなく、一連のSMTP手順単位として送信されま す:それはオリジナルのアドレス(そこへエラー報告は向けられるべき です):配達モード(例えば、受信者メールボックスへの配達):そし て一つ以上の受信アドレス。 (2) SMTP内容は、SMTP DATA 単位で送信され、二つの部分からなっていま す:ヘッダーとボディ。このヘッダーはRFC 822 に従って構造化された field/value組の集積をなし、一方ボディ、構造化されてるなら、は MIME [3] に従って定義されています。この内容は、US-ASCII レパート リーを使って表現された、性質上テキストです。拡張(MIMEのような) は内容ボディのこの制限を緩和しますが、内容ヘッダーは必ずUS- ASCII レパートリーを使って符号化されます。[4] で定義されたアルゴ リスムがUS-ASCII レパートリー以外のヘッダー値、やはり US-ASCII レ パートリーを使ってそれらを符号化、を表現するのに使われます。 SMTPは広く活発に採用されていますが、インターネット交流社会の一部は SMTPサービスの拡張を望んでいます。この覚書は、拡張されたSMTPクライア ントとサーバーがお互いを認識しサーバーがサポートしているサービス拡張 にそのクライアントを知らせることができるような、方法を定義していま す。 SMTPサービス拡張は如何なるものでも軽く考えられべきではありません。基 本的に、SMTPの強力さその簡潔さからきています。多くのプロトコール(手 順)での経験は、以下のことを示しています: オプションが少ないプロトコールは偏在的で、一方 オプションが多いプロトコールは曖昧になりやすい。 これは、各また全ての拡張、その利便性にもかかわらず、装備・配置そして 相互操作性の視点から注意深く吟味されなければならないことを、意味して います。多くの場合、SMTPサービスを拡張するコストは、その利便性を越え たいます。 この環境を与える場合、この覚書に記載されている拡張の枠組は以下の項目 から構成されています: (1) 新しいSMTP命令(セクション 4) (2) SMTPサービス拡張の登録(セクション 5) (3) SMTPメール FROM と RCPT TO 命令の追加的なパラメーター(セクション 6) 4. EHLO 命令 SMTPサービス拡張をサポートしているクライアントSMTPは、HELO 命令でな く、EHLO 命令を発することによってSMTP開始をはじめるべきです。SMTP サービスがSMTPサービス拡張をサポートしているなら、それが成功応答(セ クション4.3を参照)・失敗応答(セクション4.4を参照)もしくはエラー応 答(4.5)を与えます。SMTPサーバーがSMTPサービス拡張をなんらサポート していないなら、それはエラーメッセージを生成します(セクション4.5参 照)。 4.1. STD 10, RFC 821 の変更 この仕様書は、STD 10, RFC 821 を、既存のサービスに衝撃をとにかく与え ないで、拡張することを意図しています。多少の変更が必要で、以下に列挙 します。 4.1.1. 最初の命令(First command) RFC 821 は、SMTP開始での最初の命令は HELO 命令でなければならない、と 宣言しています。この要求は、開始が EHLO もしくは HELO で始まることが できると、ここでは改善されます。 4.1.2. 最大命令行長(Maximum command line length) この仕様書は、追加的なパラメーターとパラメーター値を許すために、 SMTPメール FROM と RCPT TO を拡張します。その結果、SMTPメール FROM と RCPT TO 行が、RFC 821 によって課せられた命令行の 512 文字制限を越 えることが可能です。この制限は、如何なるパラメーターも伴わない命令行 に摘要されるだけです。新しいメール FROM と RCPT TO パラメーターを定 義する各仕様は、拡張セットの装備によってはどの位バッファー空間を位置 付けておくかを知るために、各パラメーターの最大値長も特定しなければな りません。拡張SMTP装備によってサポートされなければならない最大命令長 は、512 プラスサポートされた全ての拡張用の全パラメーター長の合計です。 4.2. 命令構文 この命令の構文は、[2] の ABNF命名法を使って: ehlo-cmd ::= "EHLO" SP domain CR LF 成功すれば、サーバーSMTPはコード250で応答します。失敗すれば、サー バーSMTPはコード550で応答します。エラーに際してはサーバーSMTPはコー ド500・501・502・504もしくは421で応答します。 この命令はHELO 命令に代わって出され、HELO 命令が適切である時に出され るかもしれません。つまり、EHLO命令が出され成功応答が返って来た場合、 次いで引き続くHELO もしくは EHLO 命令はサーバーSMTPにコード503で応答 することになります。クライアントSMTPは、EHLO 命令が成功すれば、返送 される情報を何ら保存してはいけません。つまり、拡張された機能について の情報が必要ならば、クライアントSMTPは各SMTPセッション開始時にEHLO 命令を出さなければなりません。 4.3. 成功応答(Successful response) サーバーSMTPが装備されEHLO 命令を施行できる場合、コード250を返します。 これは、サーバーとクライアントSMTP両者が初期状態、つまり進行中の処理 がなくすべての表やバッファー状態がクリアーであること、を指しています。 普通、この応答は多行の返答です。応答の各行はキワードと一つ以上の任意 のパラメターを内容としています。ポジティブ応答の構文、[2] のABNF命名 法を使って、以下のようになります: ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF / ( "250-" domain [ SP greeting ] CR LF *( "250-" ehlo-line CR LF ) "250" SP ehlo-line CR LF ) ; the usual HELO chit-chat greeting ::= 1* ehlo-line ::= ehlo-keyword *( SP ehlo-param ) ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; syntax and values depend on ehlo-keyword ehlo-param ::= 1* ALPHA ::= DIGIT ::= CR ::= LF ::= SP ::= EHLOキーワードは大文字・小文字・両者混合で特定されていますが、大文字 小文字を区別しないで認識処理されます。これは単にRFC 821 に始まった実 践の延長です。 IANA が SMTPサービス拡張の登録を管理しています。対応するEHLO keyword 値は、各そのような拡張と協調します。 IANA に登録されている各サービス 拡張は RFC で定義されなければなりません。そのような RFC は、標準転送 (standards-track)であるかもしくはIESG-保証試験的手順(IESG-approved experimental protocol)を定義しなければなりません。この定義には、以 下の項目が含まれます: (1) SMTPサービス拡張のテキスト名; (2) 拡張と協調する EHLO keyword 値; (3) EHLO keyword 値と協調するパラメーターの構文と取り得る値; (4) 拡張と協調する追加的なSMTP verb(追加的な verb は通常、しかし必 須ではない、EHLO keyword 値と同じものである); (5) FROM or RCPT TO verbs と協調する拡張の新しいパラメーター; (6) 拡張サポートは、サーバーとクライアントSMTPにどのように影響する か;そして (7) 拡張がRFC 821 で特定されたもの以上に、命令 FROM・RCPT TOもしくは 両者の最大長さを増やしていく、増加量 さらに、大文字もしくは小文字の "X"ではじまるEHLO keyword 値は、ロー カルSMTPサービス拡張を照合し、それは、むしろ標準化でなく、両者の合意 で使用されます。"X"ではじまるKeywordsは、登録されたサービス拡張で使 用されないかもしれません。 "X" ではじまらない EHLO 応答で提示される keyword 値は、どんなもので も IANA に登録された標準・標準-転送(standards-track)もしくは IESG-保証試験的なSMTPサービス拡張と一致しなければなりません。適合 サーバーは、登録された拡張に記載されない、非"X"で前もって固定された keyword 値を提供してはなりません。 追加的な verb は EHLO keywords と同じ規則によって縛られます;特に、 "X" ではじまる verb はローカル拡張で、登録もしくは標準化されていま せん、そして "X" で始まらない verb は必ず登録されなければなりません。 4.4. 失敗応答(Failure response) 何かの理由でサーバーSMTPがサポートしているサービス拡張をリストできな い場合、コード550を返します。 失敗応答の場合、クライアントSMTPは HELO もしくは QUIT 命令を出すべき です。 4.5. 拡張されたサービスからのエラー応答 (Error responses from extended servers) サーバーSMTPが EHLO 命令を認識したが、その命令の論拠が受け入れられな いものである場合、コード501を返します。 サーバーSMTPは、EHLO 命令を認識したが、装備されていない場合、コード 502を返します。 サーバーSMTPがSMTPサービスはもはや入手できない(例えば、切迫したシス テム停止により)ときめた場合、コード421を返します。 如何なるエラー応答の場合、クライアントSMTPは HELO もしくは QUIT 命令 を出すべきです。 4.6. 拡張のないサーバーからの応答 (Responses from servers without extensions) RFC 821 に適合しているがここで特定された拡張をサポートしていないサー バーSMTPは、 EHLO 命令を認識しなく、RFC 821 で特定されたようにコード 500を返します。サーバーSMTPは、このコードを返した後同じ状態に留まる べきです(RFC 821 セクション 4.1.1 参照)。クライアントSMTPは、次い で HELO or a QUIT 命令を出すかもしれません。 4.7. 不適切に装備されたサーバーからの応答 (Responses from improperly implemented servers) SMTPサーバーによっては、 EHLO 命令請求によってSMTP転送チャンネルの接 続を来ることが、知られています。この切断は直ちにもしくは応答を送った 後に起こり得ます。このような振る舞いは、切断は QUIT 命令が出された後 だけに起こるべきと明確に宣言している RFC 821 のセクション 4.1.1に違 反します。 けれども、最大の相互操作性を成し遂げるために、拡張されたSMTPクライア ントは、EHLO が送信された後サーバーの接続切断を応答を、返す前もしく は後に、チェックするようコード化されることが、薦められています。これ が生じた場合クライアントは、操作がSMTP拡張を使用しないでうまく完結で きるかどうかを決定しなければなりません。それが可能なら、新しいチャン ネルを開き、 HELO 命令を使用できます。 別の不適切な装備のサーバーは、 EHLO が送られたそして拒絶された後 HELO 命令を受け付けません。ケースによってはこの問題は、 EHLO の失敗 応答後 RSET を送信し次いで HELO をすることで働くようにすることができ ます。これをするクライアントは、多くの装備が RESET に答えて失敗コー ド(例えば、503命令の間違った連続)を返すこと、に気付いておくべきで す。このコードは安全に無視することができます。 5. IANA 登録(Initial IANA Registry) SMTPサービス拡張のIANAの初期値登録は、以下の登録項目から構成されてい ます: Service Ext EHLO Keyword Parameters Verb Added Behavior ------------- ------------ ---------- ---------- ------------------ Send SEND none SEND defined in RFC 821 Send or Mail SOML none SOML defined in RFC 821 Send and Mail SAML none SAML defined in RFC 821 Expand EXPN none EXPN defined in RFC 821 Help HELP none HELP defined in RFC 821 Turn TURN none TURN defined in RFC 821 [5] で選択性として定義されているSMTP命令に対応しています。(必須 SMTP命令は、[5] に従って、HELO・MAIL・RCPT・DATA・RSET・VRFY・NOOP そして QUIT です。) 6. メール FROM and RCPT TO パラメター(MAIL FROM and RCPT TO Parameters) SMTP用に計画された拡張は、MAIL・FROM そして RCPT TO 命令と協調する、 追加パラメーターの使用ができます。これらの命令の構文は、[1] の基本的 な定義と同じように再度 [2] の命名法を使用して、以下のものです: esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; syntax and values depend on esmtp-keyword esmtp-value ::= 1* C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250 dbc.mtview.ca.us says hello ... サーバーSMTPは、[5] で必須と定義されたSMTP命令だけを 装備していることを指しています。 (2) 対照的に、この書式相互作用は: S: C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.us says hello S: 250-EXPN S: 250-HELP S: 250-8BITMIME S: 250-XONE S: 250 XVRB ... サーバーSMTPはSMTP EXPN と HELP 命令・一つの標準サービス 拡張( 8BITMIME )そして二つの非標準と未登録サービス拡張 (XONE と XVRB)も装備していることを指しています。 (3) 最後に、SMTPサービス拡張をサポートしていないサーバーは、以下のよ うに作動します: S: C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 500 Command not recognized: EHLO ... 応答 500は、サーバーSMTPがここで定義された拡張を装備し ていないこと、を指しています。クライアントは、普通HELO 命令をおくり、RFC 821 で特定されたように、前に進みます。 追加議論は、セクション 4.7 を見てください。 9. 安全性への配慮(Security Considerations) この RFC は安全性問題を議論していませんし、電子メールでもはや固有で ない安全問題を生じたり、RFC-821 の完全に適合した装備で存在するとは考 えられません。それは、EHLO verbに応答経由で、サーバーメール機能の告 知を提供しています。しかし、この RFC で定義されたサービス拡張の如何 なる初期設定の告知による全ての情報は、メール転送や配達に必要な verb の選択的精査によって、容易に推定され得ます。別の RFC で記載されてい るサービス拡張の安全装備は、それらfRFC で取り扱われるべきです。 10. 謝辞 この文書は、多くの人達のアイデアとそのアイデアへの反応と別の人の提案 の集大成を表わしたものです。Randall Atkinson・Craig Everhart・Risto KankkunenそしてGreg Vaudreuil氏は、共著者とも言えるにふさわしいアイ デアと文章を与えてくれました。その他の重要な示唆や文章や励ましが、 Harald Alvestrand・JimConklin・Mark Crispin・Frank da Cruz・'Olafur Gudmundsson・Per Hedeland・Christian Huitma・Neil Katin・Eliot Lear・ Harold A・Miller・Keith Moore・John Myers・Dan Oscarsson・Julian Onions ・Rayan Zachariassen そして IETF SMTP Working Group の参加者から届き ました。勿論、個人がここに代表されたアイデアの集大成の責任を取る必要 はありません。実際、ケースによっては、特殊な批判への反応は問題同一視 を認めることですが、オリジナルに提案されたものとは全く異なる解決を含 むこともありました。 11. 参照資料(References) [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993. [4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993. [5] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, October 1989. 12. 座長・編集者・著者への連絡 John Klensin, WG Chair MCI 2100 Reston Parkway Reston, VA 22091 Phone: +1 703 715-7361 Fax: +1 703 715-7436 EMail: klensin@mci.net Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Moutain View, CA 94043-2186 USA Phone: +1 415 968 1052 Fax: +1 415 968 2510 EMail: mrose@dbc.mtview.ca.us Einar A. Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA, 92647-5615 USA Phone: +1 714 842 3711 Fax: +1 714 848 2091 EMail: stef@nma.com Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA USA Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@mordor.stanford.edu