[ Top page ]

« ハイパーテキスト転送プロトコル (HTTP) とクッキー | メイン | SMTP におけるセキュリティ機能 »

セッション制御

簡易メール転送プロトコル (SMTP)

簡易メール転送プロトコル (Simple Mail Transfer Protocol, SMTP) は IETF において標準化されたメール転送のためのプロトコルである. ここでは,SMTP が最初に標準化された RFC 821 から約 20 年をへた改訂版 RFC 2821 の内容を中心として,SMTP に関する調査結果について記述する.

1980 年 9 月にメール転送プロトコル (Mail Transfer Protocol) という名称のプロトコルが RFC 772 において提案され,2 回の改訂を経て 1982 年 8 月に簡易メール転送プロトコル (SMTP) という名称で RFC 821 / STD0010 (J. B. Postel 著: Simple Mail Transfer Protocol) として標準 (Standard) になった. その後 2001 年 4 月に SMTP は他の RFC の内容もあわせて改訂され,RFC 2821 (J. Klensin 編: Simple Mail Transfer Protocol) として提案標準 (Proposed Standard) になった. RFC 821 から約 20 年を経て改訂版が発行されたのは,おもにインターネットの普及にともなって様々なメール拡張機能が実装され,それらをささえる部分を整理する必要があったからである.

1. SMTP の概要

SMTP の概要について,前記の RFC 2821 の調査結果を中心として記述する. SMTP においてはサーバとクライアントの役割が明確に分離されている.RFC 2821 によればそれらは 図1 のように記述される.

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server
図1 SMTP におけるサーバとクライアントの役割

SMTP においてはクライアントがサーバに接続するとただちにサーバ-クライアント間に "SMTP セッション" が確立され,その後,両者の間でコマンドやそれに対する応答やメールがやりとりされる. SMTP セッション中には複数のメール・トランザクションがふくまれうる. セッションの確立のためにメッセージ送受信をともなわない点では SIP や RTSP とはことなっている. セッションの終了のためには QUIT コマンドが使用されるが,これが SIP でいえば BYE メッセージに対応している. SMTP においてはトランスポート・プロトコルとして通常 TCP が使用されるが,それに限定されることはない.

2. メッセージの構造

SMTP の要求メッセージは先頭にコマンド動詞 (SIP などにおけるメソッド名に相当する) があり,それに引数がつづく形式である. 要求メッセージの例を 2 個あげる.

EHLO bar.com

MAIL FROM:<Smith@bar.com>

第 1 のメッセージはクライアントがそのドメイン名とサポートするサービス拡張の内容をサーバに知らせるためのものであり,サーバに接続してサーバからの応答があった直後に送信される. これを仮に SIP によって代用するなら,ドメイン名は REGISTER メッセージまたは INVITE メッセージによって通知し,サービス拡張は OPTIONS メッセージによって通知することになるであろう.

第 2 のメッセージはクライアントからサーバに転送するべきメールの存在を通知するためのものである. メールの内容じたいは,あとで DATA コマンドにつづけて送信される.

要求メッセージに対する応答メッセージは先頭に 3 桁の応答コードを含んでいる. 応答メッセージの例をあげる.

250 OK

3. 要求メッセージの種類

要求メッセージにおいて指定することができるコマンドとして,前記の RFC 2821 において規定されたものはつぎの 10 種類である.

(1) EHLO (Extended Hello) と HELO (Hello)
クライアントをサーバに識別させるためのコマンドである. HELO はRFC 821 (SMTP 初版) から存在するコマンドであり,EHLO はサーバごとにことなる拡張機能があつかえるようにするために HELO を拡張したコマンドである. 引数としては SMTP クライアントがあつかうドメイン名だけをとる. EHLO に対する応答メッセージには拡張機能のリストがふくまれる. EHLO コマンドの例をあげる.
EHLO bar.com
これは,このコマンドを送信するクライアントが bar.com というドメインのメールを扱うことをあらわしている.
(2) MAIL
クライアントからサーバに送信するべきメールに関する情報をおくるコマンドである. 引数としてメールの送信者のメールボックス (アドレス) をとる. MAIL コマンドの例をあげる.
MAIL FROM:<Smith@bar.com>
これは Smith@bar.com というユーザからのメールを送信することをあらわしている.
(3) RCPT (Recipient)
サーバからメールを受け取るべきユーザを通知するためのコマンドである. 引数としてメールの受信者のメールボックスをとる. RCPT コマンドの例をあげる.
RCPT TO:<Jones@foo.com>
これは Jones@foo.com というユーザへのメールを受信することをあらわしている.
(4) DATA
サーバにメールの内容を送信する際におくるコマンドである. このコマンドに対してサーバが 354 の応答メッセージをかえしたあと,データ (メールの内容) がつづく. データの終了は "." だけからなる行によって表現される. DATA コマンドとそれに対する応答については 5 節を参照.
(5) RSET (Reset)
現在のメール・トランザクションを中断し終了させるために使用する. SIP でいえば CANCEL メソッドに対応する.
(6) VRFY (Verify)
このコマンドの引数がユーザかメールボックスであることを確認するためのコマンドである. VRFY コマンドとそれに対する応答の例を前記の RFC 2821 から引用する.
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
ここでは,Crispin というユーザに対する問い合わせの結果,Crispin が存在し,それが正確には Mark Crispin <Admin.MRC@foo.com> であるという応答を得ている.
(7) EXPN (Expand)
このコマンドの引数がメーリングリストであることを確認し,もしそうであればそのメンバーリストをえるためのコマンドである. EXPN コマンドとそれに対する応答の例を前記の RFC 2821 から引用する.
C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
ここでは,Example-People というメーリングリストに関する問い合わせの結果,メンバーは Jon Postel <Postel@isi.edu>,Fred Fonebone <Fonebone@physics.-foo-u.edu>,Sam Q. Smith <SQSmith-@specific.-generic.com> の 3 人であるという応答を得ている.
(8) HELP
サーバからヘルプ情報をえるためのコマンドである. 引数としてコマンド名を指定することもできる.
(9) NOOP (No operation)
効果のないコマンドである.引数を指定することができる.
(10) QUIT
SMTP セッションを終了し,接続をきるためのコマンドである. 引数はない.

4. 応答メッセージの種類

応答メッセージはつぎのように分類される.

(1) 成功的事前応答 (1xx)
100 番台のメッセージは,要求を成功裏にうけとり,処理中であることをあらわす成功的事前応答 (positive preliminary reply) メッセージである. 前記の RFC 2821 において定義された成功的事前応答メッセージは存在しない.
(2) 成功的完了応答 (2xx)
200 番台のメッセージは,要求が成功したことをあらわす成功的完了応答 (positive completion reply) メッセージである. 成功的完了応答メッセージとして前記の RFC 2821 においてはつぎのものが定義されている: "211 System status, or system help reply", "214 Help message", "220 <domain> Service ready", "221 <domain> Service closing transmission channel", "250 Requested mail action okay, completed", "251 User not local; will forward to <forward-path>", "252 Cannot VRFY user, but will accept message and attempt delivery".
(3) 成功的中間応答 (3xx)
300 番台のメッセージは,要求を成功裏にうけとったがそれを完了するにはクライアントが追加情報を送信する必要があることをあらわす成功的中間応答 (positive intermediate reply) メッセージである. 前記の RFC 2821 において定義された成功的中間応答メッセージはつぎの 1 個だけである: "354 Start mail input; end with <CRLF>.<CRLF>".
(4) 一時的失敗完了応答 (4xx)
400 番台のメッセージは,一時的な原因によってコマンドが受理されず要求された動作をおこなわなかったことをあらわす一時的失敗完了応答 (transient negative completion reply) メッセージである. 一時的失敗完了応答メッセージとして前記の RFC 2821 において定義されたものはつぎのとおりである: "421 <domain> Service not available, closing transmission channel", "450 Requested mail action not taken: mailbox unavailable", "451 Requested action aborted: local error in processing", "452 Requested action not taken: insufficient system storage".
(5) 恒久的失敗完了応答 (5xx)
500 番台のメッセージは,恒久的な原因によってコマンドが受理されず要求された動作をおこなわなかったことをあらわす恒久的失敗完了応答 (permanent negative completion reply) メッセージである. 恒久的失敗完了応答メッセージとして前記の RFC 2821 において定義されたものはつぎのとおりである: "500 Syntax error, command unrecognized", "501 Syntax error in parameters or arguments", "502 Command not implemented", "503 Bad sequence of commands", "504 Command parameter not implemented", "550 Requested action not taken: mailbox unavailable", "551 User not local; please try <forward-path>", "552 Requested mail action aborted: exceeded storage allocation", "553 Requested action not taken: mailbox name not allowed", "554 Transaction failed".

5. 標準的なシーケンス

ドメイン bar.com にいるユーザ Smith と foo.com にある SMTP サーバとの通信シーケンスを前記の RFC 2821 から引用する. クライアントが送信するメッセージには C:, サーバが送信するメッセージには S: を先頭につけてある.

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RCPT TO:<Brown@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ... etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

セッション開始とともにサーバから応答メッセージ 220 がおくられ,これに対してクライアントは EHLO コマンドをおくる. サーバからの応答には拡張機能として 8 bit MIME, Size, DSN, Help があることがふくまれている. その後,送受信するべきメールに関する情報を MAIL コマンドと RCPT コマンドによっておくり,その後 DATA コマンドを使用してメールの内容をおくる. DATA コマンドによるメールの送信は "." だけをふくむ行によって終了する.

6. メールシステムの標準的な構成

前記の RFC 2821 によれば,SMTP におけるシステム (サーバ / クライアント) はつぎの 4 種類に分類できる.

(1) 起源システム (originating system)
メールをインターネットにおくりだす SMTP クライアントである.
(2) リレー・システム (relay system)
SMTP サーバとしてメールを SMTP クライアントからうけとって,SMTP クライアントとして他の SMTP サーバにわたす (すなわちルーティングをおこなう) システムである.
(3) 配送システム (delivery system)
受信したメールを保管して,POP, IMAP などを使用したユーザからのアクセスに対応するシステムである.
(4) ゲートウェイ・システム (gateway system)
ことなるメール転送プロトコルを使用するシステム間でメールを送受信するためのシステムである. ことなるプロトコルをもつシステムをつなぐ必要がないときは存在しない.
Keywords:

コメントを投稿

bulb403_7501-1.jpg

螺旋 3D 印刷技術を使用してつくったこのような「3D デザインランプ」を 3d-dl.com で売っています.

Powered by Movable Type