Simple Mail Transfer Protocol

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動

Simple Mail Transfer Protocol(シンプル メール トランスファー プロトコル、SMTP)または簡易メール転送プロトコルは、インターネット電子メールを転送するプロトコルである。通常 TCPポート番号 25 を利用する。 転送先のサーバを特定するために、DNSMXレコードが使われる。RFC 5321標準化されている。

概要[編集]

SMTPはIETFにおいて標準化されたメール転送のためのプロトコルである。1980年9月にメール転送プロトコル(Mail Transfer Protocol)という名称のプロトコルが RFC 772 において提案され、2回の改訂を経て1982年8月に簡易メール転送プロトコル(SMTP)という名称で RFC 821/ STD0010 [1] として標準(Standard)になった。

その後 2001年4月に SMTPは他のRFCの内容もあわせて改訂され、RFC 2821[2] として提案標準(Proposed Standard)になった。RFC 821 から約20年を経て改訂版が発行されたのは、おもにインターネットの普及にともなって様々なメール拡張機能が実装され、それらをささえる部分を整理する必要があったからである。サーバ外からの攻撃や、IPv6のアドレスにも対応できるよう、またSPFSender Policy FrameworkRFC 4408)、DKIMDomainKeys Identified MailRFC 4871)などにも対応すべく 2008年10月に再度改訂(RFC 5321[3]された。

SMTP はメールサーバMTA(Mail Transfer Agent) 間の転送だけでなく、MUA(Mail User Agent) からメールサーバにメールを送信するときにも使われることが多い。ただし、この場合受信したサーバ側のふるまいがサーバ同士の転送と異なる点が多いため、サーバ側をMSA(Message Submission Agent)と呼びポート番号587を利用し、通常のMTAと分けることが多くなってきている (RFC 5321RFC 4409 が推奨になった)。

SMTPは本来テキストベースのプロトコルであり、全ての要求/応答メッセージやメールデータが7ビットASCIIでなければならないという制限があったが、英語以外の言語やバイナリファイルを扱う需要があった。そのため、電子メールにMIME(Multipurpose Internet Mail Extensions)という規格ができたり、SMTP自体でも8ビットで伝送する拡張(RFC 1652)が標準化された。

プロトコル[編集]

SMTPにおいてはサーバとクライアントの役割が明確に分離されている。RFC 5321によれば、それらは下図のように記述される。

RFC 5321によるSMTPにおけるサーバとクライアントの役割

SMTPではクライアントがサーバに接続するとただちにサーバ - クライアント間に "SMTP セッション" が確立され、その後、両者の間でFTPのような対話型でコマンドやそれに対する応答やメールがやりとりされる。セッションの終了のためにはQUITコマンドが使用されるが、この点においてもFTPとの同様である。

コマンドはEHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, VRFYなどで、空白で区切られた引数がひとつまたは複数続く場合がある。標準のコマンドでは全て4文字ASCIIである。応答は3桁の応答コードで同様に引数が続く場合がある。また、人間が読むための応答コードに対応する文字列が続く場合があるが、SMTPクライアントは応答コードのみによって動作を決定しなければならない。メールデータは<CRLF>で、1行が<CRLF>を含め1000バイトを超えないように区切られる。また、コマンドと引数はメールアドレスの@より前のローカルパートを除き大文字小文字は区別されない。

SMTPにおいてはトランスポート・プロトコルとして通常 TCP が使用されるが、それに限定されることはない。

コマンド[編集]

EHLO(拡張HELLO)またはHELO(HELLO)コマンドはSMTPサーバーにSMTPクライアントのドメイン名を知らせる。クライアントはEHLOコマンドを使うべきだが、古いサーバーはEHLOコマンドに対応せずエラーを返す。その場合はHELOコマンドを使用しても良い。完全修飾ドメイン名を引数に取る。

MAILコマンドは電子メールをSMTPサーバーへ送る一連のメールトランザクションを開始する。引数に'FROM:<エラーを報告するのに使用される送信元メールアドレス>'を取る。

RCPT(RECIPIENT)コマンドは電子メールの宛先を指定する。宛先が複数の場合は複数回コマンドを実行する。引数に'TO:<宛先メールアドレス>'を取る。

DATAコマンドはメールデータをSMTPサーバに渡す。引数は許されず、DATAコマンドの直後に改行し、メールデータを何行か続ける。'.'のみの行が現れたらメールデータの終了を示し、メールトランザクションも終了する。もとのデータにピリオドのみの行があっても正しく動作するように行の先頭がピリオドであれば追加で行頭にピリオドを付加し、SMTPサーバーは受け取ったら取り除く。また、メールトランザクションはMAIL、RCPT、DATAの順で実行されなければならない。

QUITコマンドは接続を終了する。クライアントがQUITコマンドを送信したらサーバーは応答コード221を返し接続を閉じる。引数は許されない。

RSET(RESET)コマンドは現在のメールトランザクションを中止する。引数は許されない。

NOOP(NO OPERATION)コマンドは何もしない。SMTPサーバーは必ず250 OKを返す。引数があっても無視される。

HELPコマンドはヘルプを表示する。引数に対応するかはソフトウェアによる。

その他、VRFY, EXPNコマンドがある。VRFY, EXPN, HELP, NOOP, RSET, QUITコマンドはいつ実行されても良い。

応答コード[編集]

200番台は成功を表す。

300番台はコマンドは受け入れられたが追加の情報を待っていることを表す。DATAコマンドへの応答に354が使われる。

400番台は一時的エラーを表す。

500番台は永続的エラーを表す。

[編集]

bob@example.com から alice@foo.com へメールを送る場合。

# クライアントがサーバーへの接続を開く
S: 220 foo.com ESMTP Postfix # 挨拶応答。サーバーがfoo.comであることを示す。
C: EHLO example.com # クライアントがexample.comであることを示す。
S: 250 foo.com greets example.com
C: MAIL FROM:<bob@example.com> # 送信元
S: 250 Ok
C: RCPT TO:<alice@foo.com> # 宛先
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.com> # メールデータの開始
C: To: Alice Example <alice@foo.com>
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 4 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: . # メールデータの終了
S: 250 Ok
C: QUIT
S: 221 Bye
# サーバーが接続を閉じる

トレース情報[編集]

SMTPサーバーはDATAコマンドでメールデータを渡され、メールトランザクションが終了したら必ず先頭にRecievedヘッダフィールドを追加しなければならない。すでにRecieved行があっても、書き換えたり削除したり順番を替えたりしてはならない。RecievedヘッダフィールドはFROM <ドメイン名> (<IPアドレス>) BY <ドメイン名> (<IPアドレス>) VIA <トランスポートプロトコル(TCPなど)> WITH ESMTP(またはSMTP) ID <RFC 5322のメッセージID> FOR <メールアドレス> <日時(RFC 5322形式)>の情報で構成される。FROM節はEHLOコマンドで示された送信元ドメイン名とTCP接続から判明する送信元のIPアドレスとを両方含むべきである。VIA, WITH, ID, FOR節は任意である。

また、SMTPサーバーはメールの最終配送を行う場合、先頭にReturn-pathヘッダフィールドを追加しなければならない。Return-pathヘッダフィールドはMAILコマンドの<送信元メールアドレス>を挿入する。SMTP環境から出ていく時、SMTPの送信元メールアドレス情報が失われないようにするためである。この、エラーを報告するのに使用される送信元メールアドレスは実際の送信者のメールアドレスと異なることも可能である。

SMTP の認証機構[編集]

SMTP-AUTH[編集]

前述のSMTP標準にはユーザー認証機構が含まれていないが、インターネットの普及に伴ってその必要に迫られたため SASL メカニズムを利用した認証機構が RFC 2554 - SMTP Service Extension for Authentication(SMTP-AUTH)として標準化された。この標準の最新文書は RFC 4954 である。

POP before SMTP[編集]

SMTP-AUTH 標準化以前に普及したユーザー制限方法。メール送信する前にメール受信(POP3ログイン)を要求するため、こう呼ばれる。RFC 2476 - Message Submission において、クライアントを制限する方法の一つに挙げられたもの。

関連するRFC[編集]

  • RFC 1123 – Requirements for Internet Hosts—Application and Support (STD 3)
  • RFC 1870 – SMTP Service Extension for Message Size Declaration (оbsoletes: RFC 1653)
  • RFC 2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
  • RFC 2920 – SMTP Service Extension for Command Pipelining (STD 60)
  • RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
  • RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC 2487)
  • RFC 3461 – SMTP Service Extension for Delivery Status Notifications (obsoletes RFC 1891)
  • RFC 3463 – Enhanced Status Codes for SMTP (obsoletes RFC 1893, updated by RFC 5248)
  • RFC 3464 – An Extensible Message Format for Delivery Status Notifications (obsoletes RFC 1894)
  • RFC 3798 – Message Disposition Notification (updates RFC 3461)
  • RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
  • RFC 4408 - Sender Policy Framework (SPF) Authorizing Use of Domains in E-Mail, Version 1
  • RFC 4952 – Overview and Framework for Internationalized Email (updated by RFC 5336)
  • RFC 4954 – SMTP Service Extension for Authentication (obsoletes RFC 2554, updates RFC 3463, updated by RFC 5248)
  • RFC 5068 – Email Submission Operations: Access and Accountability Requirements (BCP 134)
  • RFC 5248 – A Registry for SMTP Enhanced Mail System Status Codes (BCP 138) (updates RFC 3463)
  • RFC 5321 – The Simple Mail Transfer Protocol (obsoletes RFC 821 aka STD 10, RFC 974, RFC 1869, RFC 2821, updates RFC 1123)
  • RFC 5322 – Internet Message Format (obsoletes RFC 822 aka STD 11, and RFC 2822)
  • RFC 5504 – Downgrading Mechanism for Email Address Internationalization
  • RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures - obsoletes RFC 4871, RFC 5672
  • RFC 6409 – Message Submission for Mail (STD 72) (obsoletes RFC 4409, RFC 2476)
  • RFC 6522 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes RFC 3462, and in turn RFC 1892)
  • RFC 6531 – SMTP Extension for Internationalized Email Addresses (updates RFC 2821, RFC 2822, RFC 4952, and RFC 5336)
  • RFC 7504 - SMTP 521 and 556 Reply Codes
  • RFC 8314 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

脚注[編集]

  1. ^ J. B. Postel著: Simple Mail Transfer Protocol
  2. ^ J. Klensin 編: Simple Mail Transfer Protocol
  3. ^ J. Klensin 編: Simple Mail Transfer Protocol

関連項目[編集]