RFC1870 日本語訳
1870 SMTP Service Extension for Message Size Declaration. J. Klensin,N. Freed, K. Moore. November 1995. (Format: TXT=18226 bytes) (Obsoletes RFC1653) (Also STD0010) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group J. Klensin, WG Chair
Request For Comments: 1870 MCI
STD: 10 N. Freed, Editor
Obsoletes: 1653 Innosoft International, Inc.
Category: Standards Track K. Moore
University of Tennessee
November 1995
SMTP Service Extension
for Message Size Declaration
メッセージサイズ宣言のための
SMTPサービス拡張
このメモの位置づけ
この文書は、インターネットコミュニティのためのインターネット標準ト
ラックプロトコルを指定し、改良のための提案と議論を要望する。標準化
の情勢およびこのプロトコルの地位については 最新版の"Internet
Official Protocol Standards" (STD 1) を参照してください。このメモ
の配布は無制限です。
1. 要旨
このメモは、SMTPクライアントおよびサーバが、メッセージサイズのクラ
イアントの概算に(おそらく一時的に)基づいてメッセージを受理すること
を断る機会をサーバに与えるために相互に作用してもよいようなSMTPサー
ビスの拡張を定義する。
2. はじめに
インターネットメッセージプロトコルのMIME拡張は、インターネットメー
ルにおいて以前にサポートされていなかった多くの種類のデータの送信に
備えた。MIMEの使用の予期される結果の一つは、以前の場合よりもさらに
幅広いメッセージサイズの範囲をSMTPが運ぶことが予期されることです。
これは、サーバとして動作しているシステムによって要求されるリソース
(例、ディスクスペース)の量へ強い影響を持つ。
このメモは、クライアント("sender-SMTP")がサーバ("receiver-SMTP")に
メッセージのサイズを宣言し、そのあと、そのサーバがクライアントへ宣
言されたメッセージサイズに基づいてメッセージを進んで受理するかしな
いかを明示するかもしれない、および、サーバ("レシーバSMTP")がクライ
アント("sender-SMTP")に進んで受理する最大メッセージサイズを宣言す
るかもしれない、SMTPサービスの拡張を定義するために [5]で定義された
機構を使用する。
3. サイズ宣言拡張のためのフレームワーク
以下のサービス拡張は、したがって定義される:
(1) SMTPサービス拡張の名称は、"Message Size Declaration" です;
(2) この拡張と関係するEHLOキーワード値は、"SIZE" です;
(3) 一つのオプションのパラメータは、このEHLOキーワード値に与えられ
る。サーバが受理するバイトでの固定最大メッセージサイズを示す10
進の数。パラメータの構文は、[2]の augmented BNF 表記法を使用し、
以下のようになる:
size-param ::= [1*DIGIT]
0(ゼロ)のパラメータ値は、固定最大メッセージサイズは有効でない
ことを明示する。もしパラメータが省略されたならば、サーバの固定
最大メッセージサイズについての情報は伝達されされない。
(4) キーワード"SIZE"を使用する一つのオプションのパラメータは、MAIL
FROMコマンドへ付け加えられる。このパラメータと関係する値は、送
信されるであろうメッセージのサイズを示す10進の数です。パラメー
タの構文は、[2]の augmented BNF 表記法を使用し、以下のようにな
る:
size-value ::= 1*20DIGIT
(5) SIZEキーワードおよび値の可能な付加によって、MAIL FROM コマンド
ラインの最大長は26文字だけ増加される。
(6) この拡張によって付加的なSMTP動詞は定義されない。
このメモの残りは、SMTPクライアントおよびサーバの振る舞いに影響を与
えるこの拡張のためにどの様にしてサポートするかを指定する。
4. メッセージサイズ宣言サービス拡張
SMTPサーバはメッセージサイズの固定された上限を持つかもしれない。ク
ライアントによるこの固定された上限より大きいメッセージを転送しよう
とする試みは失敗するでしょう。付け加えて、サーバは通常、それが到来
するメッセージを格納するための限られたスペースを持つ。メッセージの
転送は、それによってまた格納スペースの欠乏により失敗する、しかし、
のちほど成功するかもしれないだろう。
[1]で定義された未拡張のSMTPプロトコルを使用するクライアントは、
メッセージ全体をサーバ(これは転送されたメッセージを廃棄する)へ送信
したあとで、そのような失敗を告知されることのみができる。しかしなが
ら、もしクライアントとサーバの両方がメッセージサイズ宣言サービス拡
張をサポートするならば、任意の転送が試みられる前にそのような条件は
検出されるかもしれない。
大きなコンテントを中継しようとするSMTPクライアントは、サーバがそれ
ぞれのサービス拡張のいくつかをサポートするかどうかを決定するために
SMTPセッションを開始するためにEHLOコマンドを発行するかもしれない。
もしサーバがEHLOコマンドへコード 250で応答し、また、応答がEHLOキー
ワード値SIZEを含むならば、メッセージサイズ宣言拡張はサポートされる。
もし数値パラメータがEHLO応答のSIZEキーワード値に続くならば、それは、
サーバが進んで受理する最も大きなメッセージのサイズを示している。ク
ライアントによるこの制限より大きなメッセージを転送しようとする試み
は、恒久的失敗(552)返答コードとともに拒絶されるでしょう。
メッセージサイズ宣言拡張をサポートするサーバは、下に記述されるMAIL
コマンドの拡張されたバージョンを受理するでしょう。サーバによってサ
ポートされるとき、クライアントは、それが送信しようとするメッセージ
のサイズの概算を宣言するために([1]で定義されるようなMAILコマンドの
代わりに)拡張されたMAILコマンドを使用するかもしれない。サーバはそ
して、もしそれがそのサイズのメッセージを転送しようとする試みが失敗
することを決定したならば、適切なエラーコードを返す。
5. 定義
メッセージサイズは、CR-LFの組を含み、しかし、SMTP DATAコマンドの終
了のドットあるいは二重にされたクォートしたドットを含まない、DATAコ
マンドへの返答コード 354を受け取ったあとでSMTPクライアントによって
送信されるオクテトの数として定義される。
固定最大メッセージサイズは、サーバがいつも進んで受理できる最も大き
なメッセージのメッセージサイズとして定義される。固定最大メッセージ
サイズより大きな任意のメッセージを転送しようとする試みは常に失敗す
るでしょう。固定最大メッセージサイズは、SMTPサーバのインプリメント
されたものかもしれない、あるいは、それはサーバの管理者によって選ば
れたものかもしれない。
宣言されたメッセージサイズは、特定のメッセージのメッセージサイズの
クライアントの概算として定義される。
6. 拡張されたMAILコマンド
送られるメッセージのサイズをサーバに告知しようとするとき、拡張され
たMAILコマンドはクライアントによって発行される。拡張されたMAILコマ
ンドは、アドレスのあとにSIZEパラメータがあらわれることを除いて、[1]
で定義されるようなMAILコマンドと同一です。
この拡張されたコマンドの完全な構文は、[5]で定義される。esmtp-
keyword は "SIZE"です、また esmtp-value のための構文は、上記の
size-value のための構文によって与えられる。
SIZEパラメータと関係する値は、オクテットでの宣言されたメッセージサ
イズを10進数で表現したものです。この数は、メッセージヘッダ、本文
(body)および行と行の間のCR-LFシーケンスを含み、しかし、SMTP DATAコ
マンドの終了するドットあるいは二重にされたクォートされたドットを含
まないようにすべきです。だた一つのSIZEパラメータは、単一のMAILコマ
ンドで指定されるかもしれない。
理想的には、宣言されたメッセージサイズは本当のメッセージサイズに等
しい。しかしながら、メッセージサイズの実際の計算は実行不可能である
かもしれないから、クライアントは発見的に引き出された概算を使用する。
そのような発見的方法は、宣言されたメッセージサイズが普通実際のメッ
セージサイズよりも大きくするために選ばれるべきです。(これは、学問
的な点でおもに、SMTP DATAのドットを数え上げるあるいは数え上げない
ようにする効果を持つ。)
注意: サーバは、DATAコマンドでのコンテントの終わりを決定するために
SIZEパラメータを使用してはならない。
6.1 拡張されたMAILコマンドを受け取ったときのサーバの動作
SIZEパラメータを含む拡張されたMAILコマンドを受け取り次第、サーバは、
宣言されたメッセージサイズがそれの固定最大メッセージサイズを越える
かどうかを決定するべきです。もし宣言されたメッセージサイズがそれの
固定最大メッセージサイズより小さいならば、サーバはさらに、メッセー
ジがそれの受取人のそれぞれへ中継あるいは配達されることができるまで、
十分なリソースが宣言されたメッセージサイズのメッセージをバッファに
格納するために、および、それを安定したストレージにおいて保持するた
めに利用可能かどうかを決定しようとするかもしれない。
サーバは、拡張されたMAILコマンドへMAILコマンドのために [1]で定義さ
れたエラーコードのどれかで応答するかもしれない。付け加えて、以下の
エラーコードの一つが返されるかもしれない:
(1) もしサーバが現在、示されたサイズのメッセージを受理するための十
分なリソースを欠乏し、しかし、のちほどメッセージを受理すること
ができるかもしれないならば、それは、コード "452 insufficient
system storage" で応答する。
(2) もし示されたサイズがサーバの固定最大メッセージサイズよりも大き
いのならば、サーバは、コード "552 messeage size excees fixed
maximum message size" で応答する。
サーバは、例えばクライアントが不正確な発見的サイズ概算を使用した場
合に起こるかもしれないような、拡張されたMAILコマンドにおいて宣言さ
れたものよりも実際に大きなメッセージを受理することは許可されるが、
しかし、要求されない。
6.2 拡張されたMAILコマンドへの応答を受け取ったときのクライアントの動作
クライアントは、拡張されたMAILコマンドへのサーバの応答を受け取り次
第、以下のように動作する:
(1) もしコード "452 insufficient system storage" が返されたならば、
クライアントは、次にRESTコマンド(もしそれが他のメッセージを送ろ
うと試みるならば)あるいはQUITコマンドのいずれか一方を送るべきで
す。クライアントはそして、のちほどメッセージをサーバへ送ること
を試みることを繰り返す。
(2) もしコード "552 messeage exceeds fixed maximum messeage size"
が受け取られたならば、クライアントはすぐにRESTコマンド(もしそ
れが付け加えてメッセージを送ろうと試みるならば)あるいはQUITコ
マンドのいずれか一方を送るはずです。クライアントはそして、メッ
セージが配達不可能であることを宣言し、適切な通知を(もし差出人
のアドレスがMAILコマンドにおいて示されるならば)差出人へ返す。
拡張されたMAILコマンドへの返答における成功の(250)返答コードは、
メッセージ転送が成功する絶対的保証を構成しない。拡張されたMAILコマ
ンドを使用するSMTPクライアントは、DATAコマンドを発行したあとすぐに、
あるいは、メッセージの転送のあとのいずれか一方で、一時的および恒久
的エラー返答コード(コード 452および 552を含む)の両方をハンドルする
ために準備される。
6.3 宣言されたサイズより大きなメッセージ
ひとたびサーバが特定のサイズのメッセージを受理することを(拡張され
たMAILコマンドを通して)承知したならば、それは、転送されたメッセー
ジの実際のサイズが宣言されたメッセージサイズよりも大きくないならば、
DATAコマンドの転送フェーズのあとで 552返答コードを返さないに違いな
い。サーバはまた、宣言されたメッセージサイズよりもいくらか大きな
メッセージを受け取ることを選ぶかもしれない。
クライアントは、それの実際のサイズよりも小さくメッセージを宣言する
ことを許可される。しかしながらこの場合、成功の(250)返答コードは、
サーバがメッセージを受理することあるいはそれを行うための十分なリ
ソースを持つこと保証しない。サーバは、それのDATA転送のあとでそのよ
うなメッセージを拒絶するかもしれない。
6.4 メッセージサイズに基づく受取人ごとの拒絶
この拡張をインプリメントするサーバは、特定の受取人に対する宣言され
たサイズのメッセージを受理することを進んでしないことに基づいて、
RCPTコマンドへの応答で 452あるいは 552返答コードを返してよい。
(1) もし 452コードが返されたならば、クライアントは、のちほど同じ受
取人へ配達するためのメッセージを再びキューに入れるかもしれない。
(2) もし 552コードが返されたならば、クライアントは、のちほど同じ受
取人へ配達するためのメッセージを再びキューに入れてはならない。
7. 最小の使用法
"最小の(mimimal)"クライアントは、サーバがメッセージをいつも受理で
きるかどうかを決定するために、それが中継しようとするメッセージのこ
れの(おそらく概算された)サイズを、(EHLO応答におけるSIZEキーワード
へのパラメータからの)サーバの固定最大メッセージサイズと、単純に比
較するためにこの拡張を使用するかもしれない。そのようなインプリメン
テーションは、拡張されたMAILコマンドを通してメッセージサイズを宣言
する必要はない。しかしながら、サーバのリソース制限およびメッセージ
サイズの受取人毎の制限のためにメッセージサイズの一時的限定を発見す
ることはできないでしょう。
このサービスを使用する最小のサーバは、受理できるもっとも大きなメッ
セージのサイズをクライアントに告知するために、あるいは、メッセージ
サイズの固定された制限がないことをライアントに告知するために、SIZE
キーワード値を単純に使用するかもしれない。そのようなサーバは拡張さ
れたMAILコマンドを受理し、またもしクライアントの宣言したサイズが
(もしあるならば)それの固定されたサイズ制限を超過したならば 552返答
コードを返さなければならない。しかし、それはメッセージサイズの"一
時的(temporary)"制限を検出する必要はない。
EHLO SIZEキーワードへの数値パラメータはオプションです。もしパラ
メータが全く省略されたならば、それは、サーバが固定最大メッセージサ
イズを広告しないことを示している。EHLOコマンドへの応答でパラメータ
を持たないSIZEキーワードを返すサーバは、宣言されたサイズのメッセー
ジを転送するための、および、それの受取人へ配達あるいは中継されるこ
とができるための安定したストレージユニットにおいてそれを維持するた
めに、十分なリソースが利用可能であるかをみるための最初のチェックを
することなしにサイズ指定を含む拡張されたMAILコマンドへ肯定的(250)
応答を発行してはいけない。もし可能ならば、サーバは、メッセージを転
送するために十分なストレージスペースを実際に予約するべきです。
8. 例
以下の例は、いくつかの恒久的および一時的失敗をもつサイズ宣言の使用
を例証する。
S:
C:
S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
C: EHLO ymir.claremont.edu
S: 250-sigurd.innosoft.com
S: 250-EXPN
S: 250-HELP
S: 250 SIZE 1000000
C: MAIL FROM: SIZE=500000
S: 250 Address Ok.
C: RCPT TO:
S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
C: RCPT TO:
S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
C: RCPT TO:
S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
...
C: .
S: 250 Some recipients OK
C: QUIT
S: 221 Goodbye
9. セキュリティの考察
このメモに記述されたサイズ宣言拡張は、恐らく粗雑なサービス拒絶攻撃
を助長するために使用されることがありうる。特に、SIZEパラメータに含
まれる情報および拡張されたMAILコマンドの使用の両方は、効力のある
サービス拒絶攻撃を考案するための何かを速く簡単に作り出す。しかしな
がら、インプリメンテーションがとても弱くないならば、これらの拡張は
SMTPとともに常に存在しているわけではない攻撃の受けやすさを全く作り
出さない。付け加えて、問題は信頼されるシステムを巻き込んでアドレス
されない。また、このRFCにおいて記述される機構を通じた情報の可能な
リリースではない。
10. 謝辞
この文書は、初期の Working Group の作業から得られたものです。Jim
Conklin, Dave Crocker, Neil Katin, Eliot Lear, Marshall T. Rose,
Einar Stefferud は、このおよび以前のメモの両方の進行中の初期の作業
への応答で広範囲にわたるコメントを提供した。
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] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
"SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
International, Inc., Dover Beach Consulting, Inc., Network
Management Associates, Inc., Brandenburg Consulting, November
1995.
[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, BBN, January 1986.
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
Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
EMail: moore@cs.utk.edu
一覧
スポンサーリンク
