ネットワーク・ワーキンググループ J.マイヤーズ RFC:2033 カーネギーメロン カテゴリー:情報 1996年10月 ローカルメール転送プロトコル Local Mail Transfer Protocol このメモのステータス このメモはインターネット・コミュニティーに情報を提供します。このメ モは、どんな種類のインターネット標準も指定しません。このメモの配布 制限はありません。 1. 概要 SMTP[SMTP][HOST-REQ] およびそのサービス拡張 [ESMTP] はメイルを 信頼的にかつ効率的に転送するためにメカニズムを提供します。SMTP プロ トコルのデザインは、事実上メイル配達キューを管理することをサーバー に要求します。 ある限られた状況下(公衆網上の独立したホスト間のメイル交換エリア外) においては、メイル・レシーバーがキューを管理しないシステムをインプ リメントすることが望ましい。このドキュメントはそのようなシステムへ メイルを輸送するための LMTP プロトコルについて記述します。 LMTP は ESMTP の代替プロトコルですが、それは ESMTP のシンタックスお よびセマンティクスを使用します(少数の変更有)。この設計は、LMTP が ESMTP のために定義された拡張を利用することを可能にします。LMTP は特 定の先の配置およびコンフィグレーションによってのみ使用されるべきで す。そして TCP ポート 25 上で使用してはいけません(MUST NOT)。 目次 1. 概要.........................................................1 2. ドキュメント中のきまり.......................................2 3. イントロダクションと概観.....................................2 4. LMTPプロトコル...............................................3 4.1. LHLO、HELOおよびEHLOコマンド.................................4 4.2. DATAコマンド.................................................4 4.3. BDATコマンド.................................................5 5. インプリメンテーション必要条件...............................6 6. Acknowledgements.............................................6 7. 参照.........................................................7 8. セキュリティ考察.............................................7 9. 著者アドレス.................................................7 2. ドキュメント中のきまり "C:" または "S:" はクライアントおよびサーバーによってそれぞれ送られ た行であることを示しています。 3. 紹介と概観 SMTP プロトコルのデザインは、実際のところメイル配達キューを管理する ことをサーバーに要求します。これは単一のメイル処理が多数の受取人を 指定するかもしれないからです。そして DATA コマンドの最終の "." は全 処理のステータスを示すために単に1つの返答コードを返すかもしれません。 例えば、もしサーバーが2人の受取人のための処理を与えられ、1人目への 配達は成功し、2人目への配達が一時的な失敗条件に遭遇したとしても、状 況をクライアントに通知するメカニズムはありません。サーバーはメッセー ジをキューし、後で2人目の受取人にそれを配達する試みしなければなりま せん。 このキューに対する要求は、SMTP が元来設計された状況下(ネットワーク につながれたホスト間のメイルの格納中継 )において は有益です。ある限られた状況下では、キュー管理を実行するためにクラ イアントに頼るかわりに、キューを管理しないサーバーを持つことが望ま しい。例として、以下のように設計されたメイル・システムを持った仮定 のホストを考えてみてください: TCP port 25 +-----------------+ ---------------------->| | ######### | Queue |<># Mail # TCP port 25 | Manager | # Queue # <----------------------| | ######### +-----------------+ Local * ^ Local * Local IPC * | IPC * IPC * | * * | * * | * V | V Non-SMTP +----------+ +----------+ Protocol | Gateway | | Local | ######### <==============>| Delivery | | Delivery |>># Mail # | Agent | | Agent | # Spool # +----------+ +----------+ ######### ホストのメイル・システムは3つの独立してやりとりを行なっているサブシ ステムを持ちます。1番目はキュー・マネージャー(従来の SMTP エージェ ントの役割)であり、TCP の上の他のホストから、もしくは他のホストへメッ セージを転送したり、決まった記憶装置中のメイル・キューを管理します。 他の2つは、ホストが責任を持つドメイン内のアドレスへの配達を扱うエー ジェントです。1つは、他のあるメイル・システム間の gatewaying を実行 します。もう1つは、決まったメイル・スプールへメッセージを配達します。 キュー・マネージャーから配達エージェントへメッセージを転送するため にローカルのプロセス間通信チャンネル上の SMTP を使用することは望ま しいでしょう。しかしながら、それは、配達エージェントにメイル・キュー を管理することを要求するためにエージェントの複雑さを著しく増加させ るでしょう。 コマンドライン引き数として封筒アドレス(es)を持った配達エージェント を起動し、その後終了コードで配達エージェントにステータスを通知させ る一般的な方法には3つの重大問題があります: エージェントはすべての 受取人に適用される1つの終了コードを単に返すことしかできません。これ は DSN[DSN] や ENHANCEDSTATUSCODES[ENHANCEDSTATUSCODES] のような ESMTP 拡張に対処するためにインターフェースを拡張することは困難です。 また、一時的条件によりシステムライブラリによってもたらされた終了は、 しばしばパーマネント・エラーとして解釈されます。 LMTP プロトコルは、DATA コマンドの最終の "." の後、各受取人に1つの 返答を返します。したがって、キュー・マネージャーが配達エージェントに メッセージを転送する時に SMTP の代わりに LMTP を使用するよう設定さ れていれば、配達エージェントは最終の "." の後、各受け取り人へ配送を 試み、個々に各受取人へのステータスを報告します。LMTP プロトコルを使 用するべき接続は上の図中の星印で描かれています。 ネットワークから、あるいは配達エージェントからキュー・マネージャー にメッセージを転送する場合は、LMTP プロトコルを使用することが有益で はないことに注意してください。キュー・マネージャーはメイル・キュー をインプリメントします。したがって、それはメッセージを格納し後の配 送のために責任をとるかもしれません。 4. LMTPプロトコル LMTP プロトコルは、このドキュメントによる修正部分以外は、サービス拡 張[ESMTP]を備えた SMTP プロトコル SMTP[SMTP][HOST-REQ] と同一です。 「成功した」RCPT コマンドは肯定完了返答コードを返す RCPT コマンドと して定義されます。 「肯定完了返答コード」は STD 10の付録E、RFC 821[SMTP] において、1番 目の数字が "2" であるコードと定義されています。 4.1. LHLO、HELOおよびEHLOコマンド ESMTP の HELO と EHLO のコマンドは LHLO コマンドにより置き替えられ ます。両方のパーティーが検知されるために同じプロトコルを使用してい るとは限らないところで、これは誤配置を許します。 LHLO コマンドは、ESMTP[ESMTP]の EHLO コマンドに対して同一のセマンティ クスを持っています。 ESMTP の コマンド、HELO と EHLO は LMTP の中には現れません。LMTPサー バーは、これらのコマンドに肯定完了返答コードを返してはいけません (MUST NOT)。返答コード "500" が推奨されます。 4.2. データ・コマンド LMTP プロトコルでは、DATA コマンドに1つの制限が加えられ、最後に送ら れた "." への返答の仕方が変更されました。 追加された制限は、メイル処理に成功した RCPT コマンドがひとつもなかっ た場合、DATA コマンドは 返答コード "503" で失敗しなければなりません (MUST)。 変更部分は、最終 "." の後に、サーバは RCPT コマンドが出された順に、 メイル処理で先に成功した個々の RCPT コマンドに対しサーバーが返答を 返すというものです。たとえ同じ forward-path を与える複数の成功した RCPT コマンドがあったとしても、成功した個々の RCPT コマンドに対し返 答があるに違いありません。 最終 "." への返答のうちの1つが肯定完了返答のとき、サーバーは配送へ の責任を持つか、対応する受取人へメッセージを転送します。この責任を 真剣に受けとめなければなりません、つまり、軽薄な理由のためにメッセー ジを失ってはいけません(MUST NOT)。(例えば、後のホストクラッシュ、あ るいは予測可能な資源不足のため) 多行応答はまだ単一の応答と考えられ、単一の RCPT コマンドに対応します。 例: S: 220 foo.edu LMTP server ready C: LHLO foo.edu S: 250-foo.edu S: 250-PIPELINING S: 250 SIZE C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: RCPT TO: S: 550 No such user here C: RCPT TO: S: 250 OK C: DATA S: 354 Start mail input; end with . C: Blah blah blah... C: ...etc. etc. etc. C: . S: 250 OK S: 452 is temporarily over quota C: QUIT S: 221 foo.edu closing connection 注:上記の例において、クライアントおよびサーバーの両方のドメインネー ムは同一です。これは例において、クライアントおよびサーバーが同じメ イルドメインの異なるサブシステムであるからです。 4.3. BDATコマンド サーバーが ESMTP CHUNKING 拡張[BINARYMIME] をサポートする場合、 LAST パラメータを含んでいる BDAT コマンドは、RCPT コマンドが出され た順に、メイル処理で先に成功した個々の RCPT コマンドに対し応答を返 します。たとえ同じ forward-path を与える複数の成功した RCPT コマン ドがあったとしても、成功した個々の RCPT コマンドに対し応答があるに 違いありません。先のメイル処理に成功した RCPT コマンドがない場合、 BDAT LASTコマンドは返答を返しません。 BDAT LAST への返答のうちの1つが肯定完了返答のとき、サーバーは配送へ の責任を持つか、対応する受取人へメッセージを転送します。この責任を 真剣に受けとめなければなりません、つまり、軽薄な理由のためにメッセー ジを失ってはいけません(MUST NOT)。(例えば、後のホストクラッシュ、あ るいは予測可能な資源不足のため) 多行応答はまだ単一の応答と考えられ、単一の RCPT コマンドに対応します。 LAST パラメーターのない BDAT コマンドの振る舞いは変更されません;そ れらは相変わらず1つの返答を返します。 5. インプリメンテーション必要条件 LMTP は SMTP とは異なるプロトコルなので、TCPサービス・ポート25上で 使用してはいけません(MUST NOT)。 サーバー実装は PIPELINING[PIPELINING] および ENHANCEDSTATUSCODES[ENHANCEDSTATUSCODES]ESMTP拡張 をインプリメント しなければなりません(MUST NOT)。サーバー実装は 8BITMIME[8BITMIME]拡 張をインプリメントすべきです(SHOULD)。 LMTP の使用は、[DUP-MSGS] に記述された状況を悪化させることが可能で す。この同期問題を回避するために、次の必要条件がインプリメンテーショ ンで決められています: 配送や複数の受け取り人へのメッセージ転送に対し素早く責任を持つこと ができ、どんな必要な通知メッセージでも送ることができるサーバ実装は LMTP プロトコルをインプリメントすべきではありません(SHOULD NOT)。 LMTP プロトコルは広域ネットワーク上で使用されるべきではありません (SHOULD NOT)。 サーバーはできるだけ早く各返答を返すべきです(SHOULD)。次の受取人に 対してかなりの時間を配達に費やすであろう場合は、LMTP の出力バッファ をフラッシュすべき(SHOULD)であり、そうすることでクライアントに早く 返答が送られます。 クライアントは、処理する前にすべての返答が返ってくるのを待つよりも、 返事が来れば処理すべき(SHOULD)です。すべてではなく、いくつかの返事 の後に接続が閉じた場合、クライアントは到着した返答を処理し、残りは 一時的失敗として扱わなければなりません(MUST)。 6. Acknowledgments This work is a refinement of the MULT extension, which was invented by Jeff Michaud and was used in implementing gateways to the Mail-11 mail system. Many thanks to Matt Thomas for assisting me in understanding the semantics of the Mail-11 MULT extension. 7. References [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME transport", RFC 1652, July 1994. [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988. [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., "SMTP Service Extensions", RFC 1869, November 1995. [HOST-REQ] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123 section 5, October 1989. [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995. [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. There are no known security issues with the issues in this memo. 9. Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 EMail: jgm+@cmu.edu -- Translated by Takato Satsuma