SMTPでメール送信の舞台裏をあやつる：TCP/IPアレルギー撲滅ドリル（3）
素朴な疑問
- サーバにプチ復讐?!
- 仕事のメールなんて見たくありません！
- メールはメールサーバってのが処理するんですよね？
- 2種類のメールサーバに名前はありますか？
- メール送信の舞台裏をのぞく
- 簡単だというなら、実際のやりとりを見せてください！
- メールサーバに与えるメールってどんな形ですか？
- メールに漢字を書いてもいいんですよね？
- そんなに便利なら、どうしてPC内部でもJISコードを使わないんですか？
- メールサーバとSMTPでお話しする
- メールサーバもHTTPのようにプロトコル体験できますよね？
- SMTPのプロトコル体験をするにはどんな注意が必要でしょう？
- 実際にSMTPサーバと話している様子を説明してください
メールサーバにプチ復讐?!
仕事のメールなんて見たくありません！
こんなナヤミをお持ちの方、かなり多いんじゃないでしょうか？ 見なくていいのなら絶対に見たくないけど、給料もらっている以上、業務の1つとして見ないわけにもいかないし。でもなぁ、メールを開いて目に飛び込むのは、顧客からのクレーム、健康診断の数値が悪いから再検査受けろ、ダメな上司の尻ぬぐい etc. ……。ふう、ユウウツ。もっと前向きなメール来ないの？
そんなときは、そう、あなた自身が前向きになるのが一番。気分の悪いメールはちょっと放っておいて、何か自分の役に立つことを身に付けましょうよ。そう、ここではストレスの根源になっているメールをターゲットにするなんてどうでしょう？ あなたあてにストレスを運んでくるメールの、「だれにも見せたくない隠れた営み」をつかんでプチ復讐！ なんて今回はちょっとサディスティックな気分でいきましょう。
メールはメールサーバってのが処理するんですよね？
そのとおり。でも、メールサーバって1種類じゃないんです。ここではまず普通の「手紙」を考えてみます。思いや怒りをしたためた手紙は、受取人と差出人の住所と氏名を書いて、手近なところにあるポストに投かんします。投かんした手紙は郵便局に集められ、そこであて先別に仕分けし、受取人の地域を担当する郵便局に送り届けられます。そしてその担当郵便局が受取人の自宅のポストに手紙を配達します。この様子はメールの配送と、うり二つなので、図1ではそれぞれを対応させて書いてみました。
図1 郵便の配送とメールの配送を比較してみるとよく似ているここで注目したいのが「ポスト」という文字。上の文には「ポスト」が2回登場しました。1つは差出人が「送りたい手紙を預ける」ポスト、もう1つは受取人が「届いた手紙を取り出す」ポストです。この2つは同じ「ポスト」という名前ですが、それぞれの働きは別ですよね？
例えていうなら、このポストに相当するのが「メールサーバ」です。メールサーバの中にも、ポストと同様に、「送りたいメールを預ける」メールサーバと、「届いたメールを取り出す」メールサーバがあります。この両方があって、初めて、メールの送信から受信までの一連の流れが完成するわけです。
2種類のメールサーバに名前はありますか？
これらのサーバにはそれぞれ名前があります。普通は、メールを預ける方をSMTPサーバ、メールを取り出す方をPOP3サーバといいます。プロバイダからの設定通知に、こんな名前が書いてありませんでしたか？きっとあるはずです。
ところで、この2つのサーバ名にくっついているSMTPとかPOP3ってのは、そのサーバが利用するプロトコルの名前です。メールサーバにメールを預けるときには、普通、SMTPというプロトコルを使います。また、メールサーバからメールを取り出すときには、普通、POP3というプロトコルを使います。
ここでは、まずSMTPから見ていきましょう。SMTPは「Simple Mail Transfer Protocol」の略です。その名前どおり、プロトコルそのものは至ってシンプルで、普通のユーザーが理解するのも難しくはありません。ストレスを運んでくる憎らしさから、難攻不落の天守閣と思いがちですが、意外と手に負える相手ですので、肩の力を抜いても大丈夫です。
メール送信の舞台裏をのぞく
簡単だというなら、実際のやりとりを見せてください！
SMTPが本当に複雑でないことは、図2をご覧になれば分かると思います。これは、メールを送信するときの、メールソフトとSMTPサーバのやりとりです。
図2 典型的なSMTPメッセージのやりとりユーザーPCがメールサーバのポート25番に接続すると、メールサーバは
"220 smtp.xxxxxx.ne.jp Service ready"
のようなメッセージを返します。このメッセージは、3けたの数字、スペースを1つ、文字メッセージが続くスタイルになっていて、メールソフトなどのプログラムは先頭の3けたの数字を使って処理します。じゃあ、文字メッセージは何のためにあるのかって？それは、そう、人間向けの情報なんです。だから、この部分はメールサーバによって違います。図2中ではブルーで書いている部分です。
数字の220が何を意味するかは表1を見てください。これはメールサーバが「準備ができたこと」を知らせるメッセージであることが分かります。
| 応答コード | 意味 |
|---|---|
| 220 | サーバの準備完了 |
| 221 | サーバのコネクション終了 |
| 250 | 要求が正常に終了 |
| 354 | メール送信の開始要求 |
| 500 | 構文エラー、認識できないコマンド |
| 503 | コマンドの順番がおかしい |
| 550 | 指定ユーザのメールボックスがない、利用不可能 |
| 表1 主な応答コードとその意味 | |
メールを送ろうとしているPCは、まず「HELO 自分のマシン名」というコマンドをメールサーバに送ります。この意味は表2を見てください。
| コマンド | パラメータ | 意味 |
|---|---|---|
| HELO | マシン名 | メール送信の開始を宣言する |
| MAIL FROM: | ＜送信元アドレス＞ | 送信元（エラーの通知先）を指定する |
| RCPT TO: | ＜送信先アドレス＞ | メールの送信先を指定する |
| DATA | メール本文を開始する | |
| QUIT | メール送信を終了する | |
| RSET | メール送信を中断する | |
| NOOP | 何もしない | |
| 表2 主なSMTPコマンドとその意味 | ||
これからメールを送信したいこと、そして自分のマシン名をメールサーバに知らせる意味があります。図では、コマンドを受け取ったメールサーバは、“250 smtp.xxxxxx.ne.jp”という応答を返しています。これはコマンドの処理が正しく完了したことを表しています。
この後ユーザーPCは、「MAIL FROM:」コマンドで送信元アドレス（正確には、エラーが発生したときに、それを通知するアドレス）、「RCPT TO:」コマンドで送信先アドレスを通知します。それぞれ問題がないことから、メールサーバは “250 OK”を返しています。
これでメール送信に必要な準備が整いました。いよいよメールメッセージをメールサーバに送信します。「DATA」コマンドを送り、 “354 Start mail input; end with
これで送信は完了です。最後に「QUIT」コマンドを送ると、メールサーバから “221 smtp.xxxxxx.ne.jp Service closing transmission channel”といったようなメッセージが返ってきて、メールサーバへの接続が切れます。
どうですか？ 簡単だって話はウソじゃないでしょう？ ちなみに、実際のメールサーバは、セキュリティのことなどを考えて、もっと複雑なことをやっています。なお、最近ではESMTPというSMTPを機能アップした規格も使われています。でもベースはSMTPですから恐れるに足りません。またESMTP対応のメールサーバではSMTPの手順もそのまま使えます。
メールサーバに与えるメールってどんな形ですか？
DATAコマンドから先頭の.（ピリオド）までの間、メールサーバに送るメールがどんな形なのか、確かに気になりますね。ではそれを見ていきましょう。
図3がそのあらましです。前半にヘッダと呼ばれる部分、1行空けて、後半にメール本文を書きます。メール本文は、まさにメール本文ですから、説明は不要ですよね。問題は前半のヘッダです。
図3 SMTPに与えるメールのスタイルメールに関して、ちょっとでもかじったことがある方なら、このヘッダの部分に、送信者、あて先、タイトルなどが書かれていることをご存じだと思います。そう、このヘッダはメールの配送をコントロールする、さまざまな情報を書き込む部分です。
でも、SMTPでメールを配送するときには、このヘッダ情報は何の働きも「しません」。つまり、たとえあて先が書いてあっても、そのあて先にメールを配ってくれる、というようなことはしないのです。ヘッダもメール本文も、全体を単に送信するべきメッセージとして扱います（正確にいうと、配送した記録など若干の情報が書き込まれます）。
じゃあ送信先はどこで指定するのかって？ そう、これはさっき登場した「RCPT TO:」コマンドで指定します。SMTPが1対1のメール転送しかできないため、こんな作りになっています。普通のメール配送では、SMTPでメール転送を始める前に、あらかじめ別の処理としてTo:やCc:の情報を読み出し、あて先別の転送情報を作ります。その情報を配送先サーバ別にSMTPで転送する、という流れになります（図4）。
図4 メールの配送先はメールヘッダのTo:ではなくRCPT TO:で決まるメールに漢字を書いてもいいんですよね？
ご存じのとおり、メール本文に漢字を書くこともできます。ただ、ちょっと面倒なことがあります。それは、メールで使える漢字の表し方と、PCが処理に使っている漢字の表し方が違うという点です。
あ、もちろん漢字そのものが違うわけじゃありませんよ。例えば「人」という漢字があります。これを表す数は、PCの内部では「144,108」と決められています。しかしメールの中では「63,77」と書かないといけません。
文字とそれを表す数の対応を示したものは、一般に文字コードと呼ばれています。PCの内部処理で使う文字コードは、普通「シフトJIS」と呼ばれるものです。「人」という漢字が「144,108」になるのは、シフトJISに沿って表した場合です。一方、メールの本文に漢字を使うとき、「JIS」という文字コードに沿って書かないといけません。JISコードでは「人」という字を「63,77」と表すのです（図5）。
図5 同じ漢字でも文字コードが違うと数値が違うなぜこんな面倒なことになっているんでしょうか？ それを知るヒントの1つはメールの歴史を考えると見えてきます。メールがアメリカ生まれなのは皆さんご存じですよね。そんなことから、もともとメールで扱えるのは英語だけでした。
英語に使用する文字であるアルファベットは、文字コードは0〜127で表すことができます（鋭い方なら、この数字が7bitで表せる数値であることに気付かれたと思います）。このことから、メールサーバが取り扱える文字コードも、おのずと0〜127の範囲だけ扱えばいいということになっていました。
実はさっきのJISコードというのは、この0〜127しか使えないという制限の中で、日本語の漢字をちゃんと表せるように作られた文字コードです。この文字コードを使えば、英語用のメール配送の仕組みであっても、漢字のメールが送れてしまうってわけですね。これを考えた人はホント頭がイイと感心しちゃいます。
そんなに便利なら、どうしてPC内部でもJISコードを使わないんですか？
JISコードが万能というわけではありません。というのも、使える数字が限られることから、「ここからは漢字」「ここで漢字終わり」のような「切り替えマーク」を使っているのですが、これがちょっと不便なことがあるんです。
図6を見てください。同じ「63,77」という文字コードの部分が、上では「人」という漢字を表し、下では記号「？」と英字「M」を表します。上では「63,77」の前にある「27,36,66」が「ここから漢字」マークになっていて、それ以降は漢字として解釈するというルールだからです。下はそれがないので英数字として解釈します。
図6 JISコードは同じ数字が別の文字を表すことがあるもしこの部分だけを抜き出してしまうとどうでしょう？ そう漢字なのか英数字なのか分からなくなってしまいます。また、文字数を数えたいとき、同じ5つの数値なのに、上は漢字1文字、下は英字5文字と、一目では判断することができず、常に文字の先頭から数えていかないといけません。こういった点から、PC内部の処理に使うには、JISコードはあまり便利なものではありません。
これに対して、シフトJISコードでは、0から255までの数値（1byteで表せる値）をフルに使います。漢字はすべて2つの数値で表し、漢字を表す最初の数字は、いくつかの特定の数値と決まっています。そのため切り替えマークは使う必要がなく、おかげで文字数を数えたり、途中で切り出した部分が漢字かどうか判定するのが、とてもやりやすくなっています。PCの内部処理には、こちらの方が効率的なのは、一目で分かりますよね。
そんなわけで、いまのPCでは、プログラムの処理はシフトJISなど処理効率のよい文字コードで処理して、インターネットに送り出すときはJISに変換、そんな方法を取っています。
メールサーバとSMTPでお話しする
メールサーバもHTTPのようにプロトコル体験できますよね？
はい、もちろんできます。ただ、試してみるにはHTTPよりはちょっと厄介です。というのも、メールサーバによっては、それを使っていい人が限られていたり、何かの形でログインすることが必要になるからです。よそさまのサーバを勝手に使って、大量のダイレクトメールを送り付けるなど、マナーに全く外れた行為をするやからが増えたことに対する、プロバイダなどの自衛策です。その状況を知っておいて、ちゃんと正しい使い方をすれば、心配することはありません。
SMTPのプロトコル体験をするにはどんな注意が必要でしょう？
先に書いたとおり、telnetでSMTPを試してみるには、接続するSMTPサーバを決めないといけません。これには、普段、あなたが使っているメールサーバ、言い換えれば、メールソフトのSMTPサーバ欄に設定しているメールサーバを使うのが適当です。
プロバイダのメールサーバは、通常、
- ダイヤルアップやADSLなど、自社が提供する回線からの接続なら利用制限なし
- 他社プロバイダからの接続なら、先にメールボックスを読み出すことで利用制限解除
のような設定になっているものが多いようです。ですので、プロバイダに加入したときに「こう設定してください」と通知されたメールサーバに対して、同じプロバイダからアクセスするのであれば、だいたい1に該当します。この場合は、メールサーバの利用制限を気にする必要はありません。
もし、そうでない場合、普通は、2に書いたとおり、先にメールボックスを読み出さないといけません。一度メールボックスを読み出すと、その後の何分間か、そのIPアドレスを持ったコンピュータからメールサーバを送信できるようになります。その間に速攻で試してみてください。
なお、プロバイダによっては、この2つの方法以外でメールサーバを保護している可能性もゼロではありません。その場合には、接続を試してみることはちょっと難しいかもしれません。
実際にSMTPサーバと話している様子を説明してください
ここでは先の方法で利用制限がない、または解除した状態だと考えて進めます。では最初に送信するメールを用意しましょう。ここでは図7のようなものを用意しました。
From: fukunaga@atmarkit.co.jp To: yuji@someone.com Subject: TEST MAIL THIS IS TEST MAIL. PLEASE IGNORE ME. .
From:には、利用するメールサーバを提供するプロバイダから割り当てられている、自分のメールアドレスを書きます。To:にはメールを送信する相手ですが、ここでは自分が使っている別のメールアドレスなどを書いておきます。またSubject:にはメールのタイトルを書きます。
なお、先にも説明したとおり、本文に漢字を書くためには、文字コードを変換する必要がありちょっと面倒です。ここでは英数字だけでガマンしておくのが無難です。
そうすると、telnetクライアントからメールサーバに接続します。SMTPが利用するポートは25番です。ポート番号の指定をお忘れなく。SMTPサーバから、“221 何とかかんとか”という応答があったら、まずは接続成功です（図8）。
220 smtp.atmarkit.co.jp ESMTP Sendmail 8.11.6/8.11.6; Sun, 13 Apr 2003 20:31:00 +0900 HELO pc1.atmarkit.co.jp 250 smtp.atmarkit.co.jp Hello pc1.atmarkit.co.jp [192.168.1.13], pleased to meet you MAIL FROM:<fukunaga@atmarkit.co.jp> 250 2.1.0 <fukunaga@atmarkit.co.jp>... Sender ok RCPT TO:<yuji@someone.com> 250 2.1.5 <yuji@someone.com>... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: fukunaga@atmarkit.co.jp To: yuji@someone.com Subject: TEST MAIL THIS IS TEST MAIL. PLEASE IGNORE ME. . 250 2.0.0 h3D9jed03778 Message accepted for delivery QUIT 221 2.0.0 smtp.atmarkit.co.jp closing connection
これから先は、図2を参考にしながら、HELO、MAIL FROM:、RCPT TO:を指定します。HELOには自分のマシン名（なければ適当な名前）を、MAIL FROM:にはメールヘッダのFrom:に書いた自分のアドレスと同じものを、RCPT TO:にはメールヘッダのTo:に書いたあて先と同じものを、それぞれ指定してください。なお、途中で打ち間違えたときは、最初からやり直す方が確実です。
次に、DATAコマンドを入力して、“354何とかかんとか”という応答が返ってきたら、先に用意したメール本文をコピー＆ペーストしましょう。すると、メールサーバからは “250何とかかんとか”という応答が返ってくるはずです。これで送信完了です。QUITで接続を終了します。ほら、簡単でしょ。やっぱり、“Simple”Mail Transfer Protocolです。
送信が終わったら、しばらく待ってから、メールが届いているかチェックしましょう。さっきRCPT TO:に指定したメールボックスを開いてみてください。ほら、届いていますね（図9）。
Return-Path: <fukunaga@atmarkit.co.jp> Delivered-To: yuji@someone.com Received: (qmail 27321 invoked from network); 13 Apr 2003 11:51:48 -0000 Received: from unknown (HELO smtp.atmarkit.co.jp) (10.0.0.15) by smtp.someone.com with SMTP; 13 Apr 2003 11:51:48 -0000 Received: from smtp.atmarkit.co.jp (localhost [127.0.0.1]) by smtp.atmarkit.co.jp (8.11.6/8.11.6) with SMTP id UAA26016 for <yuji@someone.com>; Sun, 13 Apr 2003 20:31:29 +0900 (JST) Date: Sun, 13 Apr 2003 20:31:29 +0900 (JST) From: fukunaga@atmarkit.co.jp To: yuji@someone.com Message-Id: <200304131131.h3D9jed03778@smtp.atmarkit.co.jp> Subject: TEST MAIL THIS IS TEST MAIL. PLEASE IGNORE ME.
え、メールが見つかりませんか？ もしかすると、メール受信箱の最後に表示されているかもしれませんので、ちょっと確認してみてください。テストに使ったメールのヘッダに、Data:フィールドを書いていないので、メールソフトが一番後に並べてしまうことがあります。
もし、そこに来てなければ、もうちょっと待ってみましょう。メールの配送に時間がかかることがあります。いくら待っても到着しませんか？ だとすると、何かの原因でうまく送信できなかったのかもしれません。メール本文やSMTPのコマンドで指定した、送信先、送信元に問題がないか、もう一度確認してみてください。
いかがでしょうか。ちょっと手ごわそうなメール送信プロトコルも、こうやって少しずつ理解を深めれば、案外と何とかなるものだと思いませんか？
次回は、もう1つのメールプロトコル「POP3」を丸裸にしてみたいと思います。こちらはメールを読み出すためのプロトコルです。どうぞお楽しみに。
今回は、メールを預ける（送信する）SMTPプロトコルについてお話しました。連載第4回『ちょっと地味なPOP3でメールを読む』で、メールを取り出すPOP3プロトコルを勉強してメールを受信してみましょう。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。