メールは、送信・サーバー間の配送・受信で、使う仕組みとポートが変わる。この記事では、送信側のメールソフトから受信側のメールソフトまで、1通のメールを追ってみる。
メールサーバーを構築することになったので、まずは「メールが届く仕組み」を整理しておきたい。送信ボタンを押すと、相手の受信トレイにメールが現れる。その間に、どのサーバーが何をしているのだろう。25番ポートは、どこで登場するのだろう。
なぜ、メールの経路を3つの区間に分けるのか
メールを「送る」ことと、相手の画面で「読む」ことは、別の仕事だからだ。送信サーバーは利用者から配送の依頼を受け付け、サーバー同士で相手のドメインへ渡す。受信側はメールを保存し、相手のメールソフトが後から読めるようにする。相手のパソコンが閉じていても届くのは、間に保存する場所があるからだ。
この役割を分けて考えると、25番ポートを開ける目的も、届かないときに調べる場所も分かる。これから追う1通では、送信受付に587番か465番、サーバー間の配送に25番、閲覧に993番を使う。まずはSMTPという「話し方」を確かめ、アリスからボブまで順に追ってみよう。
SMTPとは？ HTTPと同じ「通信の約束事」
SMTPは Simple Mail Transfer Protocol の略で、メールを渡すためのプロトコルだ。プロトコルとは、コンピューター同士が通信するときの約束事。「どんな命令を、どの順番で送り、相手がどう返事するか」を決めている。
HTTPを知っていれば、同じ種類のものだと考えると入りやすい。HTTPでは、ブラウザーがWebサーバーへ「このページをください」と要求し、サーバーが応答する。SMTPでは、メールを送る側が「この差出人から、この宛先へ、メールを渡したい」と伝え、受け取る側が応答する。
ブラウザー → Webサーバー
「このページをください」
← ページのデータと応答
送る側 → 受け取る側
「この宛先へメールを渡します」
← 受け付けたかどうかの応答
プロトコルは「話し方」、ポートは「接続先の入口」だ。SMTPという同じ話し方を使っていても、利用者から送信を受け付ける入口には587番や465番、サーバー同士で配送する入口には25番を使う。SMTPを、メールサーバーの製品名やポート番号そのものと混同しないようにしたい。
今回追いかける1通と、メールが届く仕組みの全体像
送信者はアリス、宛先はボブ。アリスが alice@sender.example から bob@receiver.example へ、「明日の打ち合わせ」という件名のメールを送る。アドレスやサーバー名は説明用の架空のものだ。今回は、別のドメインへ、一般的なメールソフトを使って送る場合を考える。
アリスのメールソフト
↓ SMTP ／ 接続先 TCP 587番 または465番
送信側メールサーバー
アリスを認証し、配送の依頼を受け付ける
receiver.example のMXレコード → 受信サーバー名
A／AAAAレコード → 接続先IPアドレス
通常のDNSは53番。ここではメール本文を渡さない。
送信側メールサーバー
↓ SMTP ／ 接続先 TCP 25番
受信側メールサーバー
↓ ボブのメールボックスへ保存
ボブのパソコンが閉じていても、サーバーで受け取れる
ボブのメールソフト → 受信サービスの TCP 993番へ接続
← IMAP over TLS ／ メールを取得
ボブが認証してメールを読む。接続はボブ側から始める。
色に加えて番号と用途を表示しています。ポート番号は接続先の番号です。今回はIMAPを使う構成を示しています。
ポート番号は、接続先でどのサービスを使うかを指定する番号だ。図の番号はすべて接続先のポート。接続する側の送信元ポートには、通常、OSが一時的な番号を割り当てる。また、送信用・配送用・閲覧用の役割は、同じサーバーで動くことも、複数台に分かれることもある。
1. 送信ボタンを押すと、587番または465番でメールを預ける
アリスが送信ボタンを押す。メールソフトは、設定済みの送信サーバーへ接続する。ここで使うのがSMTPだ。SMTPは、メールを相手へ渡すための通信手順である。メールソフトはこの段階では、ボブの受信サーバーへ直接届けに行かず、自分が利用している送信サーバーへ配送を依頼する。
送信の受付には通常587番や465番を使う。587番では、まずSMTPのやり取りを始め、STARTTLSという命令でTLSによる暗号化へ切り替える。465番では、接続直後にTLSの処理を始める。設定は利用するサービスに合わせ、暗号化に失敗したまま認証情報を送らないようにする。一般的には、その後にSMTP AUTHでアリスのアカウントを認証し、送信を受け付ける。
587番や465番は、利用者が送信サーバーへメールを預ける入口だ。送信受付の役割をMSA、メールソフトの役割をMUAと呼ぶ。名前は違っても、まずは「メールソフトが、認証して送信を頼む」と捉えればよい。25番を送信受付に使う構成もあるが、送信受付とサーバー間の配送は役割として分けて考えたい。ポートの区別は RFC 6409、TLSの使い方は RFC 8314 に説明されている。
2. 送信サーバーがDNSで、ボブのメールの配送先を探す
メールを預かった送信サーバーは、宛先の receiver.example に注目する。DNSはドメイン名に対応する情報を調べる仕組みだ。メール配送では、MXレコードという「このドメインのメールを受け付けるサーバー」の情報を問い合わせる。DNSにメール本文を送るわけではない。
receiver.example. MX 10 mx.receiver.example. mx.receiver.example. A 192.0.2.25
この架空の設定は、「receiver.example宛てのメールは、mx.receiver.exampleへ届ける」という意味だ。MXの10は優先度で、複数あれば小さい値が優先される。ポート番号ではない。続いてAレコードやAAAAレコードで、そのサーバーのIPv4・IPv6アドレスを調べる。例の192.0.2.25は説明用のIPアドレスで、末尾の25もポート番号とは無関係だ。
MXレコードで配送先の名前を調べ、A／AAAAレコードで接続先のIPアドレスを調べる。通常のDNS問い合わせは53番ポートで行い、UDPやTCPを使う。実際にはDNSのキャッシュが使われる場合もある。MXがない場合などには例外の規則もあるが、まずはMXが設定されたこの流れを押さえたい。配送先を決める規則は RFC 5321の第5節 にある。
3. ここで25番ポート。サーバー同士がSMTPでメールを渡す
配送先が分かると、送信サーバーは受信サーバーのTCP 25番へ接続する。この段階でメールを運ぶ役割がMTAだ。受信サーバーは25番で待ち受け、他のメールサーバーからの接続を受け付ける。送信サーバー側も、今回は接続する側、つまりSMTPクライアントとして動く。
SMTPの会話は、おおまかに次のようになる。これは説明用に短くした会話で、コマンドを実行した記録ではない。TLSの交渉なども省略している。
送信 → EHLO
← 受信側の応答
送信 → MAIL FROM
送信 → RCPT TO
送信 → DATA と内容
← 内容の後の 250
番号順に会話が進む。最後の250は「引き受けました」という返事で、既読の通知ではない。
受信サーバー → 220 mx.receiver.example
送信サーバー → EHLO mail.sender.example
受信サーバー → 250 OK
送信サーバー → MAIL FROM:<alice@sender.example>
受信サーバー → 250 OK
送信サーバー → RCPT TO:<bob@receiver.example>
受信サーバー → 250 OK
送信サーバー → DATA
受信サーバー → 354 End data with <CRLF>.<CRLF>
送信サーバー → From: alice@sender.example
送信サーバー → To: bob@receiver.example
送信サーバー → Subject: Meeting tomorrow
送信サーバー → （空行）
送信サーバー → See you tomorrow.
送信サーバー → .
受信サーバー → 250 OK
送信サーバー → QUIT
受信サーバー → 221 ByeEHLOで名乗り、MAIL FROMで差出人、RCPT TOで配送先を伝える。DATAの後にヘッダーと本文を送り、ピリオドだけの行で終わりを知らせる。例では文字コードの説明を増やさないため、件名と本文を英語にしている。日本語や添付ファイルは、メールソフトがMIMEなどの規則に沿って扱う。
ここで伝える配送用の差出人・宛先は「エンベロープ」と呼ばれる。画面に表示されるFromやToとは別の情報だ。封筒の宛名と、中に入れた手紙の宛名を分けて考えると分かりやすい。Bccの宛先も、配送には使われるが、通常は届いたメールのヘッダーには残らない。
本文を渡した後の250応答は、そのサーバーが配送の責任を引き受けたことを示す。途中のMAIL FROMやRCPT TOへの250だけでは、メール全体を受け付けたことにはならない。そして、最後の250でも、ボブが読んだことや受信トレイに入ったことまでは分からない。SMTPの手順は RFC 5321の第3.3節 に基づく。
25番でもSTARTTLSによる暗号化は使える。ただし、暗号化の必須条件は配送先や送信側の方針によって異なる。25番なら必ず平文、あるいは必ず暗号化、と決まるわけではない。また、サーバー間の配送では、通常、ボブのパスワードでSMTP AUTHすることはない。受信側は、自分が受け持つ宛先へのメールを受け付ける。誰からでも任意の外部宛先へ中継する設定にすると、迷惑メールの踏み台になってしまう。
4. 受信サーバーがメールをボブのメールボックスに保存する
受信側では、宛先の存在やメールの内容を確認し、ボブのメールボックスへ保存する。迷惑メールの判定やウイルス検査などが行われることもある。これらの処理の順番は構成によって違い、SMTPの受付中に拒否する場合も、受け付けた後に迷惑メールフォルダーへ振り分ける場合もある。
メールボックスへ届ける役割はMDAと呼ばれる。サーバー内部での受け渡しには、ローカル処理やLMTPなどを使う構成がある。ここを必ず25番で通信するわけではない。ボブがパソコンを閉じていても、サーバーはメールを受け取り、保存できる。
受信サーバーの25番
↓ 受け付けたメール
サーバー内部の処理
↓ ボブのメールボックス
受信トレイ／迷惑メールなど
ボブの端末が閉じていても保存できる
処理の順序や振り分け先は構成による。内部の受け渡しに、必ず25番を使うわけではない。
5. ボブのメールソフトが993番で、保存されたメールを読む
ボブがメールソフトを開く。今度は、ボブのメールソフトから受信サービスへ接続する。今回使うのは、TLSで暗号化したIMAPのTCP 993番だ。ボブは自分のアカウントで認証し、メールボックスに保存された件名や本文を取得する。
IMAPは、サーバーに保存されたメールやフォルダーを扱うための仕組みだ。複数の端末で既読状態などを共有できる。POP3という別の取得方法もあり、TLSで接続する場合は995番を使う。POP3で取得後にサーバーへメールを残すかどうかは設定による。
相手のメールソフトに表示する最後の区間は、今回の構成ではIMAPの仕事だ。受信サーバーがボブのパソコンの25番へSMTPで送りつけるわけではない。ブラウザーでWebメールを使う場合は、ブラウザーとWebサービスの間は通常HTTPSの443番になる。メールソフトからの取得とWebメールは、入口が異なる。暗号化したIMAP・POP3のポートは RFC 8314の第3節 に記載されている。
ボブのメールソフト
↓ IMAP over TLS／TCP 993番
受信サービス
サーバーのメールボックス
↓ 件名や本文を返す
ボブのメールソフト
SMTPで届いたメールを、IMAPで読む。接続を始めるのはボブのメールソフト。
届かないときは、1通がどこで止まったかを考える
相手のサーバーへ一時的につながらなければ、送信サーバーは通常、キューという配送待ちの場所にメールを保存して再試行する。SMTPの4xx応答は一時的な失敗、5xx応答はその要求に対する恒久的な失敗を示す。宛先が存在しない場合や、再試行しても届けられなかった場合には、配送失敗を知らせるメールがエンベロープの差出人へ返ることがある。
アリスの画面に「送信済み」と出ても、送信サーバーから先の配送は続いているかもしれない。受信サーバーまで届いていても、迷惑メールフォルダーに入っているかもしれない。メールボックスにあるのに、ボブのIMAP認証が失敗して表示できない場合もある。構築後の調査では、送信受付のログ、配送キュー、受信側のログ、メールボックス、メールソフトの設定を順に確認すると、止まった区間を絞れる。
送信できた？
アリスの認証・設定と送信受付ログを確認
受信側まで渡せた？
DNS・配送ログ・待機中のキューを確認
保存されている？ 読める？
受信側ログ・迷惑メール・IMAP設定を確認
4xx：一時的な失敗で、通常は再試行。
5xx：その要求に対する恒久的な失敗。理由は応答文とログで確認する。
ポート番号を、メールの旅の順番で覚える
| 区間・用途 | 仕組み | 接続先ポート |
|---|---|---|
| ① 送信：メールソフトから送信を依頼 | SMTP送信受付 | TCP 587（STARTTLS）／465（接続直後からTLS） |
| 配送先の情報を調べる | 通常のDNS | UDP／TCP 53 |
| ② 配送：メールサーバー間で配送 | SMTP | TCP 25 |
| ③ 受信・閲覧：保存されたメールを扱う | IMAP over TLS | TCP 993 |
| POP3でメールを取得 | POP3 over TLS | TCP 995 |
| ブラウザーでWebメールを使う | HTTPS | TCP 443 |
IMAPの143番やPOP3の110番もあり、STARTTLS系の仕組みでTLSへ切り替える構成がある。番号だけで暗号化の有無を判断せず、接続方式も一緒に確認したい。今回のメールの旅では、送信受付に587番か465番、サーバー間の配送に25番、閲覧に993番を使った。
メールを預ける・届ける・読む、それぞれの入口を押さえる
メールは、送信・サーバー間の配送・受信で、使う仕組みとポートが変わる。この流れが分かると、メールサーバーを構築するときも「何のためにこのポートを開けるのか」を説明できる。次はこの旅を支えるソフトウェアとDNS設定を、自分の構成に当てはめていきたい。
コメント