RFC1869 日本語訳
1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E.Stefferud, D. Crocker. November 1995. (Format: TXT=23299 bytes) (Obsoletes RFC1651) (Obsoleted by RFC2821) (Also STD0010) (Status: STANDARD)
RFC一覧
英語原文
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サービス拡張
このメモの位置づけ
この文書は、インターネットコミュニティのためのインターネット標準ト
ラックプロトコルを指定し、改良のための提案と議論を要望する。標準化
の情勢およびこのプロトコルの地位については 最新版の"Internet
Official Protocol Standards" (STD 1) を参照してください。このメモ
の配布は無制限です。
1. 要旨
このメモは、サーバSMTPがサポートするサービスの拡張についてそれがク
ライアントSMTPに告知できるための手段を定義することによってSMTPサー
ビスを拡張するためのフレームワークを定義する。SMTPサービスの拡張は、
IANAに登録される。もしこのサービス拡張の特徴が要求あるいは提供され
ることができなければ、このフレームワークは現状のSMTPクライアントあ
るいはサーバの修正を要求しない。
2. はじめに
単純メール転送プロトコル(SMTP) [1]は、メッセージ転送エージェントの
中継機能のための有効な安定した基礎を提供している。10年もたっている
が、SMTPは弾力のあるものを優れて提供している。それにもかかわらず、
たくさんのプロトコルの拡張についての必要性は明らかになっている。こ
の文書は、これらの拡張を個別のおよび偶然の実在物として記述するより、
むしろ単一の首尾一貫した方法ですべての将来の拡張を備えさせることが
できるフレームワークを提供する安直なやり方でSMTPの能力を高める。
3. SMTPの拡張のためのフレームワーク
SMTPのサービス拡張の目的のために、SMTPはエンベロープおよびコンテン
トを含むメールオブジェクトを中継する。
(1) SMTPエンベロープは安直です。またSMTPプロトコルのユニット
の列として送られる: これは、差出人のアドレス(エラー報告は
そこへ向けられるはずです); 配送モード(delivery mode) (例、
受取人のメールボックスへ配達); および、一つ以上の受取人の
アドレスです。
(2) SMTPコンテンツは、SMTP DATAプロトコルユニットで送られ、二
つの部分を持つ: ヘッダおよび本文(body)。ヘッダはRFC822に
従うフィールド/値 (field/value)部分の収集物を形成する。一
方、本文は、もし構造化されれば、MIME [3] に従って定義され
る。コンテンツは本質は原文どうりであるであり、US ASCIIレ
パートリー(ANSI X3.4-1986)を使用して表現される。(MIMEのよ
うな)拡張がコンテンツの本文の制限を緩和するかもしれないけ
れども、コンテンツのヘッダは常に US ASCIIレパートリー使用
して符号化される。[4]で定義されるアルゴリズムは、US ASCII
レパートリー以外のヘッダ値を表現するために使用され、一方、
それでもなおUS ASCIIレパートリーを使用してそれらを符号化
する。
SMTPは広くまた丈夫に配備されたものではあるが、インターネットコミュ
ニティのいくつかの部分はSMTPサービスを拡張することを望んでいるかも
しれない。このメモは、拡張されたSMTPクライアントおよびサーバが互い
をそういうものとして認識すること、および、サーバはそれがサービス拡
張をサポートしていることについてクライアントに告知することができる
の両方の手段を定義する。
SMTPサービスへの任意の拡張が少しも考慮されないことは、強調されなけ
ればならない。SMTPの力強さは、主としてその単純さからくる。多くのプ
ロトコルについての経験は次のように示される:
少数のオプションをともなうプロトコルは遍在する傾向にある、一方、
多数のオプションをともなうプロトコルは無名である傾向にある。
これは、それの利点にかかわらずそれぞれおよびすべての拡張は、それの
インプリメント、配備およびインターオペラビリティのコストに関して注
意深く詳細に調べられなければならない。多くの場合、SMTPサービスの拡
張のコストは多分この利点より勝る。
この環境を考慮に入れれば、このメモの中において記述される拡張のため
のフレームワークは次のものからなる:
(1) 新たなSMTPコマンド (セクション 4)
(2) SMTPサービス拡張の登録 (セクション 5)
(3) SMTPの MAIL 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, RFC821 の変更
この仕様は、何らか方法で既存のサービスに大きな影響を与えることなし
に STD 10, RFC821 を拡張することを意図する。必要な小さな変更は下に
列挙される。
4.1.1. 最初のコマンド
RFC821は、SMTPセッションにおける最初のコマンドはHELOコマンドでなけ
ればならないと述べている。この必要条件はこの文書により、セッション
がEHLOあるいはHELOのいずれか一方で開始することを許すように改正する。
4.1.2. 最大のコマンドライン長
この仕様は、SMTPの MAIL FROM および RCPT TO が付加パラメータおよび
パラメータ値を認めるように拡張する。結果としてRFC821によって課され
たコマンドライン長512文字の制限をこえる MAIL FROM および RCPT TO
ラインは可能です。この制限はこの文書により任意のパラメータを持たな
いコマンドラインにのみ適用するように改正する。新しい MAIL 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の中の一つで応答する。
このコマンドはHELOコマンドの代わりに発行される。また、HELOコマンド
が適切であろうと思われるときに発行されるかもしれない。つまり、EHLO
コマンドが発行され成功の応答が返されたならば、その後のHELOあるいは
EHLOコマンドは、サーバSMTPがコード 503で返答することに帰着するで
しょう。EHLOコマンドが成功したならば、クライアントSMTPは返された情
報を全くキャシュしてはならない。つまり、拡張された能力についての情
報が必要であるならば、クライアントSMTPはそれぞれのSMTPセッションの
開始においてEHLOコマンドを発行しなければならない。
4.3. 成功の応答
もしサーバ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 )
; 普通の HELO chit-chat
greeting ::= 1*
ehlo-line ::= ehlo-keyword *( SP ehlo-param )
ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; 構文および値は ehlo-keyword に依存する
ehlo-param ::= 1*<任意の CHAR, ただし SP および全ての
コントロール文字 (US ASCII 0-31) を除く>
ALPHA ::= <52種のアルファベットのいずれか一つ
(大文字の A から Z, および,
小文字の a から z まで)>
DIGIT ::= <10種の数字のいずれか一つ
(0 から 9 まで)>
CR ::= <復帰文字
(ASCII 10進コード 13)>
LF ::= <改行文字
(ASCII 10進コード 10)>
SP ::= <スペース文字
(ASCII 10進コード 32)>
EHLOキーワードが大文字、小文字あるいは大文字と小文字の混合によって
指定されるかもしれない。にもかかわらず、それらは常に大文字と小文字
を区別しない作法で認識され処理される。これはRFC821において始められ
た実施の単純な拡張です。
IANAはSMTPサービス拡張の登録を保守する。各々のそのような拡張との関
係は、EHLOキーワード値(EHLO keyward value)で対応する。IANAに登録さ
れた各サービス拡張はRFCにおいて定義されなければならない。各々のRFC
は standards-track でなければならない、あるいは、IESG-認可の実験的
なプロトコルとして定義されなければならない。定義は次のものを含まな
ければならない:
(1) SMTPサービス拡張の原文上の名称;
(2) この拡張と関係する、EHLOコマンドのキーワード値;
(3) EHLOキーワード値と関係するパラメータの構文および可能な値;
(4) この拡張と関係する、任意の付加SMTPの動詞 (付加動詞は、
EHLOキーワード値と同じように、普通はあるが、あることを
必要とはしない);
(5) MAIL FROM あるいは RCPT TO 動詞と関係する任意の新しいパラ
メータの拡張;
(6) どのようにして、サーバおよびクライアントSMTPの振る舞いに
影響を及ぼす拡張をサポートするか;
(7) 拡張がコマンド MAIL FROM, RCPT TO あるいはその両方の最
大長をRFC821における指定を越えてふやしている増加量;
付け加えて、大文字あるいは小文字の "X"で始まる任意のEHLOキーワード
は、ローカルのSMTPサービス拡張を参照する。これは標準化されたよりも
むしろ双務的な、協定を通して使用される。"X"で始まるキーワードは登
録されたサービス拡張で使用されてはいけない。
"X"で始まらないEHLOの応答において示される任意のキーワード値は、標
準、standards-track、あるいは IANAに登録された IESG-認可の実験的な
SMTPサービス拡張に該当しなければならない。この規則に従うサーバは、
登録された拡張に記述されていない非"X"接頭辞のキーワード値を提供し
てはならない。
付加動詞はEHLOキーワードと同じ規則によって結び付けられる; 特に、
"X"で始まる動詞は、登録されていないあるいは標準化されていないロー
カルの拡張であり、"X"で始まらない動詞は常に登録されている。
4.4. 失敗の応答
もしある理由のためにサーバSMTPがそれがサポートしているサービス拡張
をリストすることができなければ、それはコード 554を返す。
失敗応答の場合、クライアントSMTPはHELOあるいはQUITコマンドを発行す
るべきです。
4.5. 拡張されたサーバからのエラー応答
サーバSMTPがEHLOコマンドを認識し、しかし、コマンド引数が受理不可能
ならば、それはコード 501を返す。
サーバSMTPがEHLOコマンドを認識し、しかし、インプリメントしていない
ならば、それはコード 502を返す。
サーバSMTPが、SMTPサービスがすでに利用可能ではないこと(例、システ
ムのシャットダウンが差し迫っているため)を決定したならば、それは
コード421を返す。
どのエラー応答の場合でも、クライアントSMTPはHELOあるいはQUITコマン
ドを発行するにべきです。
4.6. 拡張を持たないサーバからの返答
RFC821に準拠するがここで指定された拡張をサポートしないサーバSMTPは、
RFC821で指定されるようにEHLOコマンドを認識しないし、また結果として
コード 500を返す。サーバSMTPはこのコードを返したあと同じ状態に留ま
るに違いない(RFC821のセクション 4.1.1 を見よ)。クライアントSMTPは
その後HELOあるいはQUITコマンドのいずれかを発行するかもしれない。
4.7. 不適当にインプリメントされたサーバからの応答
あるSMTPサーバはEHLOコマンドを受け取るとすぐにSMTP送信チャネルを断
線することが知られている。断線はすぐにあるいは応答を送った後で起こ
るかもしれない。そのような振る舞いは、RFC821のセクション 4.1.1 に
違反する。これは、QUITコマンドを発行した後にのみ断線が起こるべきで
あると明白に述べている。
それにもかかわらず、最大のインターオペラビリティを成し得るために、
EHLOコマンドを使用する拡張されたクライアントSMTPがEHLOコマンドを
送り、返答が返る前あるいは後のいずれかでサーバの接続閉鎖を検査する
ようにコーディングされることは提案される。もしこれが起きたならば、
クライアントは任意のSMTP拡張を使用する操作が成功完了することができ
るかどうかを決定しなければならない。もしできるならば、新たな接続が
開かれることができ、EHLOコマンドが使用されることができる。
他の不適切にインプリメントされたサーバは、EHLOコマンドを送り拒絶さ
れたあとでHELOコマンドを受理しない。いくつかの場合、この問題は、
EHLOコマンドへの失敗応答の後でRSETコマンドを送り、その後HELOコマン
ドを送ることにより取り掛かることができるかもしれない。これを行うク
ライアントは、多くのインプリメンテーションはRSETの応答において失敗
コード(例、503 Bad sequence of commands)を返すことに気がつかなけれ
ばならない。このコードは安全に無視されることができる。
5. 初期の IANA 登録
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コマン
ドに該当する。([5] に従い、必須のSMTPコマンドは HELO, MAIL, RCPT,
DATA, RSET, VRFY, NOOPおよびQUITです。)
6. MAIL FROM および RCPT TO のパラメータ
SMTPのために計画された拡張のいくつかが MAIL FROM および RCPT TO
コマンドと関係する付加パラメータを使用することは認識される。[1]か
らの基礎的定義はもちろん[2]のABNF表記法を再度使用する、これらのコ
マンドの構文は:
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 / "-")
; 構文および値は esmtp-keyword に依存する
esmtp-value ::= 1*<任意の CHAR, ただし "=", SP, および全て
のコントロール文字(US ASCII 0-31) を除く>
; 次のコマンドは、拡張されたパラ
; メータを受理するために拡張された
inner-esmtp-cmd ::= ("MAIL FROM:" reverse-path) /
("RCPT TO:" forward-path)
全ての esmtp-keyword値は、上で記述されたIANA 登録処理の一部のよう
に登録されなければならない。この定義のみが将来の拡張のためのフレー
ムワークを提供する; 拡張されない MAIL FROM あるいは RCPT TO パラ
メータは、このRFCによって定義される。
6.1. エラーの応答
サーバSMTPが、MAIL FROM あるいは RCPT TO コマンドと関係する一つ以
上のパラメータをインプリメントできないあるいは認識しないならば、そ
れはコード 555を返す。
もしある理由のためにサーバが MAIL FROM あるいは RCPT TO コマンドと
関係する一つ以上のパラメータを一時的に収容することができなければ、
および、もし特定のパラメータの定義がある他のコードの使用に権限をゆ
だねることができなければ、それはコード 455を返すに違いない。
あるパラメータおよびそれらの値に特有のエラーは、パラメータの定義を
したRFCにおいて指定される。
7. Received: ヘッダフィールドの注釈
SMTPサーバは、適切な Received: フィールドをそれらが受け取る全ての
メッセージのヘッダへ付け加えることを要求される。"with ESMTP"の項は、
任意のSMTPサービス拡張が使用されたとき、このフィールドへ付け加えら
れるべきです。"ESMTP"はこの文書によりIANAに登録された標準プロトコ
ル名のリストへ付け加えられる。
8. 使用例
(1) 次の形式の相互動作:
S:
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. セキュリティの考察
このRFCは、セキュリティの問題を議論しない。また、すでに電子メール
に特有でない、およびRFC-821に十分に準拠するインプリメンテーション
に存在しない何らかのセキュリティ問題が起こることを信じない。これは、
EHLO動詞への応答を通してサーバのメールの能力の発表を提供する。しか
しながら、このRFCで定義されたサービス拡張の初期セットのいくつかの
発表によって与えられた全ての情報は、メールの輸送および配達すること
を要求とする動詞の選択的な調査によってたやすく推論されることができ
る。他のRFCにおいて記述されるサービス拡張のセキュリティの含みは、
それらのRFCの中で扱われる。
10. 謝辞
この文書は、多くの方々のアイデアおよびアイデアへの反応およびその他
の提案の統合したものを説明する。Randall Atkinson, Craig Everhart,
Risto Kankkunen, Greg Vaudreuil は、アイデアおよび共同執筆者と見な
されるのに十分なテキストを寄稿した。その他の重要な提案、テキストあ
るいは応援は Harald Alvestrand, Jim Conklin, 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. 参照文献
[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
一覧
スポンサーリンク
