SMTPコマンドリファレンス

なお、Xで始まるコマンドはユーザ定義で自由に使ってよい(RFC 2821)。

1. セッション開始

EHLO - SMTPセッションの開始

書式EHLO (SMTPクライアントのFQDN)
種別基本コマンド
現状必須
応答成功:250, 失敗:504, 550
定義RFC 1869→RFC 2821
語源Extended HeLlO
参照HELO

EHLOにより、SMTPサーバはSMTPクライアントを識別し、もしそのクライアント がそのSMTPサーバを利用できるならばセッションが開始される。これに対して、 SMTPサーバは応答コード250で以下の情報(普通複数行)を返す(グリーティング)。 なお、SMTPサーバは、実際にはTCP/IP接続のIPアドレスなどの情報からクライア ントを識別すべきである。

  1. サーバ自身の名前(FQDN)
  2. このサーバで利用できる拡張サービス

クライアントは、基本コマンドに加えて、ここでサーバから返される拡張コマ ンドを利用することもできる。それ以外を利用してはならない。 なお、拡張サービスについてはこちらを参照の こと。なお、ここで表示されるのは、拡張サービスの名称やコマンド名ではな く、拡張サービスに関連したEHLOキーワードと呼ばれるものである (拡張サービス表にはEHLOキーワードと表記)。

SMTPクライアントのFQDNが存在しない場合には、そのIPアドレスが送られ、(も し存在するなら)続いてそのクライアントを識別するのに有用な情報が送られ る。


HELO - SMTPセッションの開始

書式HELO (SMTPクライアントのFQDN)
種別基本コマンド
現状必須
応答成功:250, 失敗:504, 550
定義RFC 821, RFC 1123, (RFC 2821)
語源HELlO
参照EHLO

HELOにより、SMTPサーバはSMTPクライアントを識別し、もしそのクライアント がそのSMTPサーバを利用できるならばセッションが開始される。これに対して、 SMTPサーバは応答コード250でサーバ自身の名 前(FQDN)を返す(グリーティング)。

SMTPクライアントのFQDNが存在しない場合には、そのIPアドレスが送られ、(も し存在するなら)続いてそのクライアントを識別するのに有用な情報が送られ る。

現在では、このコマンドではなくEHLOを利用すべきであ り、HELOはEHLOを理解できない古いクライアント、サーバのためにのみ存在す る(が、サーバはHELOをサポートしなければならない)。


AUTH - SMTP認証

書式AUTH (メカニズム) [最初の応答]
種別拡張コマンド
現状実装されていることもある
EHLOキーワードAUTH
拡張サービス名Authentication
応答 成功:250, 334, 失敗: 432, 534, 538 454, 530, 501, 504, 535
定義RFC 2554
語源AUTHentication
参照

このコマンドにより、サーバとクライアントがSASL(RFC 2222)を利用して相互 認証できるようになる。 (メカニズム)はCRAM-MD5やDIGEST-MD5などのダイジェスト化アルゴリズムであ り、どれが利用できるかについてはサーバからのEHLOに明記されている。 [最初の応答]は、サーバからのチャレンジのレスポンスで、BASE64でエンコー ドされる(これを送らない場合には、サーバから334が送られるので、それに対 してBASE64エンコードされたレスポンスを返す)。 AUTHコマンドは1度の接続中、1度だけしか利用できず、またメールトラン ザクション開始前(終了後)にのみ、利用できる。


STARTTLS - TLSによるセッションの暗号化

書式STARTTLS
種別拡張コマンド
現状実装されていることもある
EHLOキーワードSTARTTLS
拡張サービス名starttls
応答 成功:220, 失敗: 501, 454
定義RFC 2487
語源START TLS
参照

このコマンドが送られると、TLS(Transport Layer Security, RFC 2246)によ るネゴシエーションがなされ、それに成功するとその後の通信がTLSにより、 暗号化される。


2. メールトランザクションの開始

MAIL - メールを送る

書式MAIL FROM: (アドレス) [オプション]
種別基本コマンド
現状必須
応答成功:250, 失敗: 552, 451, 452, 550, 553, 503
定義RFC 821, RFC 1123, RFC 1869→RFC 2821
語源MAIL
参照EHLO, RCPT

このメールの(エンベロープ上:つまり、配送システム上)の送り主を示す。 メールヘッダのFrom: (RFC 2822で定義されている)とは意味が違う点に注意。 EHLO(HELO)がメールセッション(クライアントとサーバの接続に関する処理)の 初期化をするのに対し、メールトランザクション(ある1つのメールについての 処理)を初期化する(このコマンド以前にサーバに渡された宛て先やデータは消 去される)。メールトランザクションが進行している時にはMAILコマンドは利 用できない。普通、EHLOコマンド直後に使われる。

(アドレス)は送り主のメールボックスアドレス(を「<>」で括ったもの)である。 現在ではホストのリストを前置するフォーマット(例えば puni!shiori!mimori のよ うな)は使うべきではない。一部のエラーメールなどについて(アドレス)が 「<>」のみの場合がある(メールがループするのを防ぐため)。

オプションには以下のようなものがある。いずれもEHLO でサーバからそれに関連するキーワードが返された場合にのみ利用可能である。

オプション名拡張サービス名説明定義RFC
BODY8bit-MIMEtransport,BINARYMIME BODYのフォーマット(7bit/8bit/バイナリ)を示す1652, 3030
SIZEMessage Size Declarationメッセージのサイズをあらわす1870
ENVID Delivery Status Notification エンベロープに識別子をつける 1891
RET Delivery Status Notification DSNにメールボディを含むか、ヘッダだけを返すかを指示する 1891
AUTHAuthenticationSMTP AUTHを利 用する2554
BYDeliver By ある時間内にメールを配送させる2852


SEND - ユーザのターミナルにメッセージを送る

書式SEND FROM: (アドレス)
種別拡張コマンド
EHLOキーワードSEND
拡張サービス名Send
現状ほとんど使われない
応答成功:250, 失敗: 450, 552, 451, 452, 550, 553, 503
定義RFC 821, RFC 1123
語源SEND
参照MAIL

このコマンドをMAILの代わりに利用することにより、メッ セージをメールボックスではなくターミナルへと送る。もしユーザがログイン していないような場合には450の応答を返す。 ただし、利用できる環境はほとんど存在しない。


SOML - ユーザのターミナルかメールボックスへメッセージを送る

書式SOML FROM: (アドレス)
種別拡張コマンド
EHLOキーワードSOML
拡張サービス名Send or Mail
現状ほとんど使われない
応答成功:250 失敗: 450, 552, 451, 452, 550, 553, 503
定義RFC 821, RFC 1123
語源Send Or MaiL
参照MAIL, SEND

このコマンドをMAILの代わりに利用することにより、メッ セージをメールボックスではなくターミナルへと送る。もしユーザがログイン していないような場合にはメッセージはメールボックスへと送られる。 ただし、利用できる環境はほとんど存在しない。


SAML - ユーザのターミナルかメールボックスへメッセージを送る

書式SAML FROM: (アドレス)
種別拡張コマンド
EHLOキーワードSAML
拡張サービス名Send and Mail
現状ほとんど使われない
応答成功:250 失敗: 450, 552, 451, 452, 550, 553, 503
定義RFC 821, RFC 1123
語源Send And MaiL
参照MAIL, SEND

このコマンドをMAILの代わりに利用することにより、メッ セージをメールボックスとターミナル双方へ送る。もしユーザがログイン していないような場合にはメッセージはメールボックスのみへ送られる。 ただし、利用できる環境はほとんど存在しない。


3. 受信者の決定

RCPT - メールの送り先(envelope)を示す

書式RCPT TO: (アドレス) [オプション]
種別基本コマンド
現状必須
応答 成功:250, 251, 失敗: 550, 551, 552, 553, 450, 451, 452, 503
定義RFC 821, RFC 1123, RFC 1869→RFC 2821
語源ReCiPienT
参照EHLO, MAIL

メールをどこに送るのか、という受信者を指定するコマンド。 メールヘッダのTo:やCc:など(RFC 2822で定義されている)とは意味が違う点に 注意。同じメッセージを複数の宛て先に送る場合、1回のメールトランザクショ ンでこのコマンドを複数回使うことができる。なお、MAILコマンドより後にし か利用できない。

宛て先のアドレスに普通のもの(mimori@puni.netなど)とする他、 「@iyadesu.org:mimori@puni.net 」というように書けば iyadesu.org を経由 (リレー)してmimori@puni.net へとメールが送信される(ただし、 iyadesu.org がメールリレーを許可していなければ、550エラーとなってしまう)。

オプションには以下のようなものがある。いずれもEHLO でサーバからそれに関連するキーワードが返された場合にのみ利用可能である。

オプション名拡張サービス名説明定義RFC
NOTIFY Delivery Status Notification DSN送出の条件を決める 1891
ORCPT Delivery Status Notification 元々の送り先を示す 1891


4. メッセージのサーバへの転送

DATA - メッセージの転送

書式DATA
種別基本コマンド
現状必須
応答 成功:250, 354, 失敗: 451, 554, 503 552, 554, 451, 452,
定義RFC 821, RFC 1123→RFC 2821
語源DATA
参照BDAT

メールのデータを送信するためのコマンドで、MAIL, RCPTの後に使われる。 DATAコマンドに対してパラメータはなく、サーバが受理するならコマンドその ものに対してまず354応答が返される。これが返されたら、クライアントは DATAの内容(つまりメールメッセージの内容:ヘッダとボディ)を送信する。こ こで1行は78文字(全角なら39文字)以内であるべきで、998文字以内でなければ ならない(RFC 2822)。 送信してよいデータは7ビットASCIIすべて。ただし、スペース、CRLF以外は送 信すると誤動作するかもしれない。また、「8bitMIME」で拡張されることもあ る。

データ(メッセージ)のおわりは「.」(ピリオド)だけの行で示される。本当に 「.」だけのデータを送信したい場合のため、送信側(クライアント)は「.」で 始まる行の先頭にもう1つの「.」をつけくわえ、サーバは行頭の「.」を取り 除く。つまり、「.forward」とだけ書いた行は「..forward」として送信され、 サーバで元に戻される。「.」だけの行なら「..」として送信される。

データの終わりに対し、サーバは成功(250)か失敗を返す。成功が返されたと きにサーバはそのメッセージを配信したり、リレーしたり、キューに入れた りする。この時点でクライアントはこのメッセージに関する一切の責任を、サー バに渡したことになる(つまり、ここで成功が返された後には再送してはなら ない)。


BDAT - バイナリメッセージの転送

書式BDAT (転送するオクテット数) [LAST]
種別拡張コマンド
EHLOキーワードCHUNKING
拡張サービス名CHUNKING
現状ほとんどのシステムで未実装
応答 成功:250, 354, 失敗: 451, 554, 503 552, 554, 451, 452,
定義RFC 3030
語源DATA
参照BDAT

このコマンドにより、BINARYデータの転送が可能となる。つまり、DATAであれ ば<CRLF>で区切られる、<CRLF>.<CRLF>で終了という制限 があるが、BDATでは単に転送オクテット数をBDATコマンドへのパラメータとす ることで、いかなるデータでも送信可能となる。

MAILへのオプションパラメータSIZEと異なり、データオクテット数は厳密で ある(データの終わりを判別するためのオクテット列が存在しないので当然だ が)。また、DATAと異なり、BDATに対して3yzの応答はなく、指定した量のデータを受信して 始めて250応答が返る。

1つのメールトランザクションでBDATコマンドを何回使ってもよいが、最後に は「LAST」オプションが必要である。

BDAT 0 LAST

のようにすると、BDATにより送信するデータがもうないことを示すことができ る。

BDATはDATAと一緒には利用できない。


5. メールセッションの終了

QUIT - メールセッションの終了

書式QUIT
種別基本コマンド
現状必須
応答 成功: 221
定義RFC 821, RFC 1123→RFC 2821
語源QUIT
参照

メールセッションを終了する。これに対して221の応答を受信したら、コネク ションを閉じる。


6. その他のコマンド

RSET - メールトランザクションのリセット

書式RSET
種別基本コマンド
現状必須
応答 成功:250, 200 (正しくない実装)
定義RFC 821, RFC 1123→RFC 2821
語源ReSET
参照EHLO

このコマンドにより、現在のメールトランザクションを中止する。サーバは、 ここまでに送られた送り元、送り先、データなどすべてを廃棄する。 簡単にいえば、EHLO(HELO)直後の状態へ戻る(EHLOを送信してもほとんど同じ 結果が得られるが、EHLOよりもRSETの方が単純なコマンドである)。 このコマンドは常に成功し、250応答が返る。


VRFY - メールアドレスの確認

書式VRFY (アドレス or ユーザ名)
種別拡張コマンド
EHLOキーワードVRFY
現状実装すべき
応答 成功: 250, 251, 252, 失敗: 550, 551, 553, 502, 504,
定義RFC 821, RFC 1123→RFC 2821
語源VeRiFY
参照EXPN

(アドレス or ユーザ名)が存在するかどうかを確認する。 実際にそのサーバ上のメールボックスが存在することを確認できたら、250の応答コードでユーザのメールボックス名(と、 オプションでユーザのフルネームなど)が返される。 メールボックスが別サーバにあるなどの理由で実際には確認できないが、文法 上は正しいなら252が返される。また、その引 数で複数のアドレスにマッチするなどの場合には551が返る。

もしVRFYしたアドレスがメーリングリストの場合には、EXPNと同じように振る舞う実装もあり、一方ではエラーと する実装もある(いずれも正しい実装である)。

最近では、セキュリティ上の理由によりこのコマンドを利用できないようにし ているサーバが多く、その場合には550が返る。


EXPN - メーリングリストアドレスの展開

書式EXPN (アドレス)
種別拡張コマンド
EHLOキーワードEXPN
拡張サービス名Expand
現状実装すべき
応答 成功: 250, 252, 失敗: 550, 500, 502, 504,
定義RFC 821, RFC 1123→RFC 2821
語源EXPaNd
参照VRFY

(アドレス)のメーリングリストが存在すれば、そのメンバーリストを表示する。 その際には250の応答コードが用いられ、各行 に1アドレスが表示される(つまり、普通は複数行の応答となる)。

もしEXPNしたアドレスが普通のユーザのメールボックスである場合には、VRFYと同じように振る舞う実装もあり、一方ではエラーと する実装もある(いずれも正しい実装である)。

最近では、セキュリティ上の理由によりこのコマンドを利用できないようにし ているサーバが多く、その場合には550が返る。


HELP - ヘルプ

書式HELP [(コマンド名)]
種別拡張コマンド
EHLOキーワードHELP
拡張サービス名Help
応答 成功: 211, 214, 失敗: 502, 504,
定義RFC 821, RFC 1123→RFC 2821
語源HELP
参照

ヘルプ。単にHELPとだけすると簡単なヘルプが返り、また HELP (コマンド名) とすればそのコマンドに関するより詳細なヘルプが返るかもしれない。


NOOP - 何もしない

書式NOOP [パラメータ]
種別基本コマンド
応答 成功: 250, 200(正しくない実装)
定義RFC 821→RFC 2821
語源NO OPeration
参照

何もしないコマンド。パラメータがあっても動作は同じ。


TURN - サーバとクライアントを入れ替える

書式TURN
種別拡張コマンド
EHLOキーワードTURN
拡張サービス名Turn
現状利用すべきでない
応答成功:250 失敗: 502, 500, 503
定義RFC 821
語源TURN
参照

クライアントとサーバ、受信側と送信側を入れ替える。TURN以降は、元サーバ であった方がコマンドを送るようになる。ただし、このコマンドはセキュリティ 上の問題があるため、特殊な環境以外では利用すべきでない。


ETRN - サーバのqueueをクライアントから扱う

書式ETRN
種別拡張コマンド
EHLOキーワードETRN [option] [node name]
拡張サービス名Remote Queue Processing Declaration
現状実装されていることが多い
応答成功: 250, 251, 252, 253 失敗: 458, 459, 500, 501
定義RFC 1985
語源Extended Turn
参照

SMTPコネクションを利用してサーバからクライアントへメールを転送する。 [node name]として自ホストの完全な名前(DNSのMX, CNAMEいずれでも良い) をいれると、サーバはそれが本当かどうか確認し、その上でメールをこのセッ ションでクライアントへと送る。 オプションで@[domain name](たとえば @example.com)とすると、そのドメイ ンあてのすべてのメールがクライアントへ送られる。#[queue name](たとえば #uucp)とすると、そのqueueにあるメールが送られる。


ATRN - 認証されたTURN

書式ATRN
種別拡張コマンド
EHLOキーワードATRN
拡張サービス名On-Demand Mail Relay
現状未実装
応答成功: 250 失敗: 450, 451, 453, 502, 530
定義RFC 2645
語源Authenticated Turn
参照

TURNの改良版。 AUTHを用いた認証を行うことで、TURNにあっ たセキュリティ上の問題を回避している。つまり、このコマンドはAUTHの後で しか利用できない。ATRNが発行されるとクライアントとサーバの役割が逆転す る。


Mimori Yuki <mimori@puni.net>
$Id: ref.html,v 1.6 2003/06/08 09:25:33 s-v Exp $