なお、Xで始まるコマンドはユーザ定義で自由に使ってよい(RFC 2821)。
書式 | EHLO (SMTPクライアントのFQDN) |
種別 | 基本コマンド |
現状 | 必須 |
応答 | 成功:250, 失敗:504, 550 |
定義 | RFC 1869→RFC 2821 |
語源 | Extended HeLlO |
参照 | HELO |
EHLOにより、SMTPサーバはSMTPクライアントを識別し、もしそのクライアント がそのSMTPサーバを利用できるならばセッションが開始される。これに対して、 SMTPサーバは応答コード250で以下の情報(普通複数行)を返す(グリーティング)。 なお、SMTPサーバは、実際にはTCP/IP接続のIPアドレスなどの情報からクライア ントを識別すべきである。
クライアントは、基本コマンドに加えて、ここでサーバから返される拡張コマ ンドを利用することもできる。それ以外を利用してはならない。 なお、拡張サービスについてはこちらを参照の こと。なお、ここで表示されるのは、拡張サービスの名称やコマンド名ではな く、拡張サービスに関連したEHLOキーワードと呼ばれるものである (拡張サービス表にはEHLOキーワードと表記)。
SMTPクライアントのFQDNが存在しない場合には、そのIPアドレスが送られ、(も し存在するなら)続いてそのクライアントを識別するのに有用な情報が送られ る。
書式 | 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 (メカニズム) [最初の応答] |
種別 | 拡張コマンド |
現状 | 実装されていることもある |
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 |
種別 | 拡張コマンド |
現状 | 実装されていることもある |
EHLOキーワード | STARTTLS |
拡張サービス名 | starttls |
応答 | 成功:220, 失敗: 501, 454 |
定義 | RFC 2487 |
語源 | START TLS |
参照 |
このコマンドが送られると、TLS(Transport Layer Security, RFC 2246)によ るネゴシエーションがなされ、それに成功するとその後の通信がTLSにより、 暗号化される。
書式 | MAIL FROM: (アドレス) [オプション] |
種別 | 基本コマンド |
現状 | 必須 |
応答 | 成功:250, 失敗: 552, 451, 452, 550, 553, 503 |
定義 | RFC 821, RFC 1123, RFC 1869→RFC 2821 |
語源 | |
参照 | EHLO, RCPT |
このメールの(エンベロープ上:つまり、配送システム上)の送り主を示す。 メールヘッダのFrom: (RFC 2822で定義されている)とは意味が違う点に注意。 EHLO(HELO)がメールセッション(クライアントとサーバの接続に関する処理)の 初期化をするのに対し、メールトランザクション(ある1つのメールについての 処理)を初期化する(このコマンド以前にサーバに渡された宛て先やデータは消 去される)。メールトランザクションが進行している時にはMAILコマンドは利 用できない。普通、EHLOコマンド直後に使われる。
(アドレス)は送り主のメールボックスアドレス(を「<>」で括ったもの)である。 現在ではホストのリストを前置するフォーマット(例えば puni!shiori!mimori のよ うな)は使うべきではない。一部のエラーメールなどについて(アドレス)が 「<>」のみの場合がある(メールがループするのを防ぐため)。
オプションには以下のようなものがある。いずれもEHLO でサーバからそれに関連するキーワードが返された場合にのみ利用可能である。
オプション名 | 拡張サービス名 | 説明 | 定義RFC |
---|---|---|---|
BODY | 8bit-MIMEtransport,BINARYMIME | BODYのフォーマット(7bit/8bit/バイナリ)を示す | 1652, 3030 |
SIZE | Message Size Declaration | メッセージのサイズをあらわす | 1870 |
ENVID | Delivery Status Notification | エンベロープに識別子をつける | 1891 |
RET | Delivery Status Notification | DSNにメールボディを含むか、ヘッダだけを返すかを指示する | 1891 |
AUTH | Authentication | SMTP AUTHを利 用する | 2554 |
BY | Deliver By | ある時間内にメールを配送させる | 2852 |
書式 | SEND FROM: (アドレス) |
種別 | 拡張コマンド |
EHLOキーワード | SEND |
拡張サービス名 | Send |
現状 | ほとんど使われない |
応答 | 成功:250, 失敗: 450, 552, 451, 452, 550, 553, 503 |
定義 | RFC 821, RFC 1123 |
語源 | SEND |
参照 |
このコマンドをMAILの代わりに利用することにより、メッ セージをメールボックスではなくターミナルへと送る。もしユーザがログイン していないような場合には450の応答を返す。 ただし、利用できる環境はほとんど存在しない。
書式 | 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 FROM: (アドレス) |
種別 | 拡張コマンド |
EHLOキーワード | SAML |
拡張サービス名 | Send and Mail |
現状 | ほとんど使われない |
応答 | 成功:250 失敗: 450, 552, 451, 452, 550, 553, 503 |
定義 | RFC 821, RFC 1123 |
語源 | Send And MaiL |
参照 | MAIL, SEND |
このコマンドをMAILの代わりに利用することにより、メッ セージをメールボックスとターミナル双方へ送る。もしユーザがログイン していないような場合にはメッセージはメールボックスのみへ送られる。 ただし、利用できる環境はほとんど存在しない。
書式 | 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 |
書式 | 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 (転送するオクテット数) [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と一緒には利用できない。
書式 | QUIT |
種別 | 基本コマンド |
現状 | 必須 |
応答 | 成功: 221 |
定義 | RFC 821, RFC 1123→RFC 2821 |
語源 | QUIT |
参照 |
メールセッションを終了する。これに対して221の応答を受信したら、コネク ションを閉じる。
書式 | RSET |
種別 | 基本コマンド |
現状 | 必須 |
応答 | 成功:250, 200 (正しくない実装) |
定義 | RFC 821, RFC 1123→RFC 2821 |
語源 | ReSET |
参照 | EHLO |
このコマンドにより、現在のメールトランザクションを中止する。サーバは、 ここまでに送られた送り元、送り先、データなどすべてを廃棄する。 簡単にいえば、EHLO(HELO)直後の状態へ戻る(EHLOを送信してもほとんど同じ 結果が得られるが、EHLOよりもRSETの方が単純なコマンドである)。 このコマンドは常に成功し、250応答が返る。
書式 | 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 (アドレス) |
種別 | 拡張コマンド |
EHLOキーワード | EXPN |
拡張サービス名 | Expand |
現状 | 実装すべき |
応答 | 成功: 250, 252, 失敗: 550, 500, 502, 504, |
定義 | RFC 821, RFC 1123→RFC 2821 |
語源 | EXPaNd |
参照 | VRFY |
(アドレス)のメーリングリストが存在すれば、そのメンバーリストを表示する。 その際には250の応答コードが用いられ、各行 に1アドレスが表示される(つまり、普通は複数行の応答となる)。
もしEXPNしたアドレスが普通のユーザのメールボックスである場合には、VRFYと同じように振る舞う実装もあり、一方ではエラーと する実装もある(いずれも正しい実装である)。
最近では、セキュリティ上の理由によりこのコマンドを利用できないようにし ているサーバが多く、その場合には550が返る。
書式 | HELP [(コマンド名)] |
種別 | 拡張コマンド |
EHLOキーワード | HELP |
拡張サービス名 | Help |
応答 | 成功: 211, 214, 失敗: 502, 504, |
定義 | RFC 821, RFC 1123→RFC 2821 |
語源 | HELP |
参照 |
ヘルプ。単にHELPとだけすると簡単なヘルプが返り、また HELP (コマンド名) とすればそのコマンドに関するより詳細なヘルプが返るかもしれない。
書式 | NOOP [パラメータ] |
種別 | 基本コマンド |
応答 | 成功: 250, 200(正しくない実装) |
定義 | RFC 821→RFC 2821 |
語源 | NO OPeration |
参照 |
何もしないコマンド。パラメータがあっても動作は同じ。
書式 | TURN |
種別 | 拡張コマンド |
EHLOキーワード | TURN |
拡張サービス名 | Turn |
現状 | 利用すべきでない |
応答 | 成功:250 失敗: 502, 500, 503 |
定義 | RFC 821 |
語源 | TURN |
参照 |
クライアントとサーバ、受信側と送信側を入れ替える。TURN以降は、元サーバ であった方がコマンドを送るようになる。ただし、このコマンドはセキュリティ 上の問題があるため、特殊な環境以外では利用すべきでない。
書式 | 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 |
種別 | 拡張コマンド |
EHLOキーワード | ATRN |
拡張サービス名 | On-Demand Mail Relay |
現状 | 未実装 |
応答 | 成功: 250 失敗: 450, 451, 453, 502, 530 |
定義 | RFC 2645 |
語源 | Authenticated Turn |
参照 |
TURNの改良版。 AUTHを用いた認証を行うことで、TURNにあっ たセキュリティ上の問題を回避している。つまり、このコマンドはAUTHの後で しか利用できない。ATRNが発行されるとクライアントとサーバの役割が逆転す る。