NET // communication networks
LESSON 14 / 標準編

アプリ層 ─ メール詳細(SMTP / IMAP / POP3 と MIME)

「送信」を押した瞬間にメールが旅をするしくみ。基礎編(第7回) ではプロトコル名と全体像を学びましたが、本講では実際の SMTP コマンド対話、POP3 と IMAP の動作モデル、MIME による添付ファイルの表現を中心に扱います。標準 編なので、まずはメールがどう運ばれ、どう保存され、どう表現されるかを押さえます。認証・暗号化・なりすまし対策は アプリ層プロトコルのセキュア化 でまとめて扱います。

学習目標

本講を終えると、以下の問いに答えられるようになる。

本講は 第7回 電子メールのしくみ(基礎) の上に乗ります。第3回 プロトコルと TCP/IP 階層 のアプリケーション層の代表的事例の1つで、第5回 DNS(ドメイン名解決)とも密接に関わります(MX レコード)。STARTTLS / SMTPS / IMAPS / POP3S / SMTP-AUTH / SPF / DKIM / DMARC などのセキュリティ関連 は TLS や認証の知識が前提のため、アプリ層プロトコルのセキュア化 でまとめて扱います。

このレッスンの目次

01 送受信モデル 基礎編では「送信側サーバ」「受信側サーバ」と単純化しましたが、実際のメールシステムは… 02 SMTP 詳細 SMTP(Simple Mail Transfer Protocol) は、メールを… 03 SMTP 対話 実際に Alice( from@aaa.example ) のメーラーが、サーバ … 04 POP3 vs IMAP 送信が終わると、メールは受信側サーバの メールボックス に置かれます。受信者の MU… 05 MIME・ヘッダ 元々の SMTP は 「7 ビット ASCII の本文」 (つまり英数記号のみ)しか… 06 セキュリティへ接続 SMTP そのものは素朴なので、認証・暗号化・なりすまし対策はセキュリティ回で整理… 07 まとめと用語 本講の重要語句を整理 08 確認問題 理解度を問題でチェック

送受信モデル — 4種のエージェントが連携する

基礎編では「送信側サーバ」「受信側サーバ」と単純化しましたが、実際のメールシステムは 役割の異なる複数のソフトウェア が連携して動いています。専門的にはこれらを「エージェント(agent)」と呼びます。代表的な4つを押さえましょう。
POINT MUA(Mail User Agent) = メールアプリ(Outlook、Thunderbird、Gmail 画面など)
MSA(Mail Submission Agent) = ユーザからメールを 受け付ける 入口サーバ(587番)
MTA(Mail Transfer Agent) = サーバ間の 中継・配達 を担う(Postfix、Sendmail 等)
MDA(Mail Delivery Agent) = 受信側で メールボックスに格納 する役

ステップで見る:エージェントの連携

メール1通が、投函・中継・格納・読み出しへ進む 送信者 MUA メールアプリ MSA 投函口 587 送信側 MTA 中継役 DNS MXレコードで 宛先MTAを探す 受信側 MTA 25で待受 MDA 配達・格納 メールボックス 受信者 MUA 赤:送信・中継は SMTP / 緑:受信者の読み出しは POP3 または IMAP ① MUAがMSAへ投函 SMTP Submission / 587 ② MSAが送信側MTAへ渡す ここからサーバ側の中継処理 ③ DNSでMXを調べる bob側の受信MTAを見つける ④ MTA間で転送 SMTP / 25 ⑤ MDAがメールボックスへ格納 受信者ごとの保管場所に置く ⑥ 受信者MUAが POP3 / IMAP で読む
ステップ1. 送信者の MUA は、書いたメールを MSA に投函します。現代ではこの区間は Submission ポートの 587 を使うのが基本です。
ステップ2. MSA はユーザから受け付けたメールを、サーバ側で中継を担当する MTA に渡します。実装上は同じサーバソフトの別役割として動くこともあります。
ステップ3. 送信側 MTA は、宛先ドメインの MX レコード を DNS に問い合わせ、次に接続すべき受信側 MTA を探します。
ステップ4. 送信側 MTA は、見つけた受信側 MTA へ SMTP/25 でメールを転送します。ここが「メールサーバ間の中継」です。
ステップ5. 受信側 MTA が受け取ったメールは、MDA に渡され、受信者の メールボックス に格納されます。
ステップ6. 受信者の MUA は、メールボックスにあるメールを POP3 または IMAP で読み出します。送る経路と読む経路はプロトコルが違います。
1 / 6

図の見方:メール1通は MUA → MSA → MTA → 受信側MTA → MDA → メールボックス と進み、受信者の MUA はあとから POP3 / IMAP で読み出します。投函(MUA→MSA)は 587番、サーバ間中継(MTA↔MTA)は 25番、受信読み出しは POP3/IMAP と役割を分けて見ると整理しやすいです。

用語の整理

略称正式名称役割実例
MUAMail User Agentユーザがメールを書く・読むアプリ。送信は MSA に投函、受信は POP/IMAP でメールボックスから取得Outlook、Thunderbird、Apple Mail、スマホのメールアプリ
MSAMail Submission AgentMUA からの投函を受け付ける入口。587番ポート(認証や暗号化の詳細は セキュア化回)Postfix の submission ポート
MTAMail Transfer Agentサーバ間でメールをリレーする本体。DNS の MX レコードを引いて宛先サーバを探すPostfix、Sendmail、Exim
MDAMail Delivery Agent最終的に受信者のメールボックス(ファイル/DB)へ書き込む。フィルタや振り分けもここprocmail、Dovecot LDA、Maildrop

つながる知識: MTA がメールを次の MTA に渡すとき、宛先ドメイン(例:bbb.example) の MX レコード を DNS に問い合わせて「このドメインのメールはどのサーバ宛に送ればよいか」を特定します。詳しくは 第5回 DNS 、および 第14回(標準 DNS 詳細、準備中)で扱います。

SMTP の詳細 — 送信専用プロトコル

SMTP(Simple Mail Transfer Protocol) は、メールを 送る 場面で使われるテキストベースのプロトコルです。RFC 5321 で標準化されており、TCP の上で動きます。テキストベースなので telnet で「手動会話」もできるのが面白いところです(後述)。
POINT SMTP は テキストベースの「コマンド-レスポンス」型 プロトコル。
クライアントが 大文字4文字程度のコマンド を1行ずつ送り、サーバは 3桁の数字 + メッセージ で応答する(例:220、250、354、221)。

SMTP の標準ポート ─ 25

SMTP の基本ポートは 25/tcp(MTA 間の中継)。MUA から MSA への投函にはほかに 587(Submission)、TLS を被せた 465(SMTPS)もあり、認証や暗号化のしくみが組み合わされて運用されます。これらの TLS 化版・認証(SMTP-AUTH / STARTTLS)については TLS の知識が前提なので、アプリ層プロトコルのセキュア化 でまとめて扱います。

OP25B(Outbound Port 25 Blocking): 多くの ISP は、家庭の回線から 外向きの 25 番ポートへの通信 をブロックしています。これは過去にウイルス感染した家庭 PC が踏み台にされ、迷惑メールを大量にばらまいた経緯への対策。「家庭の MUA は ISP の MSA(Submission)経由で投函しなさい」という設計に統一されたわけです。家庭からの投函では実質 587 番が使われますが、その上で動く認証・暗号化の話はセキュア化回へ回します。

EHLO と HELO ─ ESMTP 拡張

歴史の浅い拡張版を ESMTP(Extended SMTP) と呼びます。クライアントは挨拶コマンドとして HELO(古典的)ではなく EHLO を使うのが現代では一般的。サーバが対応する拡張機能(STARTTLS、AUTH、SIZE など)が応答に列挙されます。

もっと詳しく:SMTP のレスポンスコード(3桁)の意味

SMTP のサーバ応答は 3桁の数字。1桁目で大まかな成否、2・3桁目で詳細を表します。

HTTP のステータスコード(2xx/3xx/4xx/5xx)と分類思想がよく似ています。テキスト系プロトコルの定番パターンです。

SMTP コマンド対話を1ステップずつ追う

実際に Alice(from@aaa.example) のメーラーが、サーバ mail.bbb.example に対して Bob 宛のメールを送る場面を、6ステップ で追ってみましょう。サーバの応答(数字)とクライアントのコマンド(英大文字)が交互に飛び交います。「次へ」を押しながら見てください。
クライアント (送信側 MTA) サーバ mail.bbb.example TCP 接続(25番ポート) 220 mail.bbb.example ESMTP Postfix EHLO mail.aaa.example 250-mail.bbb.example / 250-STARTTLS / 250 AUTH MAIL FROM:<from@aaa.example> 250 OK RCPT TO:<to@bbb.example> DATA … (本文) … <CRLF>.<CRLF> 354 → 250 OK QUIT 221 Bye
ステップ1:TCP 接続 と 220 応答. クライアント MTA はサーバの 25 番ポートに TCP で接続。サーバは挨拶として 220 mail.bbb.example ESMTP Postfix のような 1 行を返します(220 = サービス準備完了)。ESMTP という単語がここに含まれているのが、現代の MTA の典型。
ステップ2:EHLO で挨拶. クライアントは自分のホスト名を名乗って EHLO mail.aaa.example を送ります(古典的な HELO でも動く)。サーバは複数行で 対応する拡張機能の一覧 を返します(STARTTLS、AUTH PLAIN LOGIN、SIZE など)。最後の行だけ「250 」(スペース)、それ以前は「250-」(ハイフン)で続行を示すのが慣例です。
ステップ3:MAIL FROM で送信元を宣言. MAIL FROM:<from@aaa.example> と書きます。これは エンベロープ送信元(SMTP プロトコル上の差出人) と呼ばれ、メール本文ヘッダの From: とは 別物 です。サーバは 250 OK で応答。
ステップ4:RCPT TO で宛先を宣言. RCPT TO:<to@bbb.example>。同報の場合は RCPT TO: を 宛先の数だけ繰り返し ます(To/CC/BCC をここで全部展開する)。受け付けると 250 OK。
ステップ5:DATA で本文を投入. DATA コマンドの後、サーバは 354(中間応答=さあどうぞ)を返します。クライアントは ヘッダ(From:、To:、Subject:、Date: など)+ 空行 + 本文 を1行ずつ送り、「.」だけの行(CRLF . CRLF) で終端を示す。受理されれば 250 OK。
ステップ6:QUIT で切断. 用件が終わったら QUIT。サーバは 221 Bye を返し、TCP コネクションも閉じる。これで1通分のセッションが完了。複数通を送る場合は MAIL FROM から繰り返せばよい。
1 / 6

図の見方:左がクライアント、右がサーバ。時間は上から下へ流れます。クライアントは 大文字英字のコマンド、サーバは 3 桁数字 + 文章 で応答する。コマンド名(EHLO / MAIL FROM / RCPT TO / DATA / QUIT)と応答コード(220 / 250 / 354 / 221)を覚えれば、telnet で人間が手動でメール送信できるくらいシンプル。

実際の telnet セッション例

古典的には telnet コマンドでサーバの 25 番ポートに繋ぎ、人間が直接コマンドを打って動作確認できます(教育用途)。実コードを抜き出すと次のようになります。C: がクライアント、S: がサーバの行です。

$ telnet mail.bbb.example 25 S: 220 mail.bbb.example ESMTP Postfix C: EHLO mail.aaa.example S: 250-mail.bbb.example S: 250-SIZE 52428800 S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250 8BITMIME C: MAIL FROM:<from@aaa.example> S: 250 2.1.0 Ok C: RCPT TO:<to@bbb.example> S: 250 2.1.5 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: From: Alice <from@aaa.example> C: To: Bob <to@bbb.example> C: Subject: Hello C: C: This is a test. C: . S: 250 2.0.0 Ok: queued as 9F2C1B4 C: QUIT S: 221 2.0.0 Bye

考えてみよう: このやり取りには パスワードも本人確認も全く出てきません。古い SMTP の素朴さがよく分かります。これが オープンリレー 問題の温床になり、後年の SMTP-AUTH や STARTTLS による補強に繋がりました。送信元ドメインのなりすまし対策も含め、メールの安全化は セキュア化回 で扱います。

受信プロトコル — POP3 と IMAP の動作モデル

送信が終わると、メールは受信側サーバの メールボックス に置かれます。受信者の MUA はそれを取りに行きます。代表的な受信プロトコルは POP3 と IMAP の2つ。性格がはっきり違うので、用途に応じて選びます。
POINT POP3(110) = メールを ダウンロード し、(基本)サーバから消す。1端末向き
IMAP(143) = メールを サーバに置いたまま 読む。複数端末で同期可能
※ TLS 化版(POP3S=995 / IMAPS=993)は セキュア化回 で扱う

なぜ受信も SMTP ではだめなのか

SMTP は 相手へメールを押し出す(push)ため のプロトコルです。送信側 MTA が受信側 MTA に接続し、「この宛先にこの本文を渡します」と届ける用途には向いています。一方で、受信者の MUA がしたいことは メールボックスの中を見る ことです。たとえば「届いているメールの一覧を見たい」「1通だけ本文を取りたい」「既読・未読を変えたい」「フォルダを同期したい」という操作が必要になります。

SMTP は配達、POP3 / IMAP は取り出し。 もし受信も SMTP だけで行うなら、受信者の PC やスマホが常に起動し、外部から接続できるメールサーバとして待ち受けなければなりません。現実には端末は電源が切れていたり、移動中だったり、NAT やファイアウォールの内側にいたりします。そこでメールはいったん受信側サーバの メールボックス に保管され、ユーザの端末はあとから POP3 や IMAP で取りに行く、という役割分担になっています。

動作モデルを見比べる

POP3 ─ Post Office Protocol version 3

クライアント POP3 サーバ 受信箱 → 取得後は空になる RETR(全件ダウンロード) メール本体 + DELE で削除

図の見方:POP3 は「サーバから手元へ取り込んで、サーバ側からは消す」が基本動作。受信箱はクライアント側だけに移動する。

IMAP ─ Internet Message Access Protocol(version 4)

PC スマホ IMAP サーバ 受信箱(残ったまま) 既読/未読 / フォルダ分け 同じメールにアクセス(状態は同期) 既読にすると両方で既読

図の見方:IMAP ではメール本体も状態(既読・未読・フォルダ)もすべてサーバ側に集約され、複数の端末がそれを共有する。スマホで読んだメールが PC でも自動的に既読になる仕組み。

POP3 と IMAP の直接比較

観点POP3IMAP
標準ポート(平文)110/tcp143/tcp
標準ポート(TLS 化版)セキュア化回 で扱う(POP3S=995 / IMAPS=993)
メールの保持場所クライアント側(基本)サーバ側
複数端末の同期困難容易(状態もサーバ側)
サーバ容量少なくて済む大量に必要
オフライン利用得意(手元にある)キャッシュ機能で対応
部分取得(ヘッダのみ等)限定的得意
フォルダ管理(サーバ側)できないできる
現代の主流少数派主流

Q. 「自分のスマホと PC で同じメールが見える、しかも片方で既読にすると両方で既読になる」のはなぜでしょう。考えてからクリック。

MIME ─ 添付ファイル・日本語・複数本文を運ぶ

元々の SMTP は 「7 ビット ASCII の本文」(つまり英数記号のみ)しか想定していませんでした。これでは日本語も画像も PDF も送れません。そこで MIME(Multipurpose Internet Mail Extensions) という拡張規約が後付けされました。RFC 2045〜2049 で標準化されています。
POINT MIME = SMTP の 本文部分に「種類」と「複数の塊」を表現できるようにする 拡張。
1) Content-Type でデータ種別を宣言、2) Content-Transfer-Encoding で 7-bit に変換、3) multipart/* で本文と添付を1通にまとめる。

典型的なメールヘッダの構造

メール本体は ヘッダ + 空行 + 本文 で構成されます。ヘッダは フィールド名: 値 という1行の集合。代表的なフィールドを抜き出すと:

From: Alice <from@aaa.example> To: Bob <to@bbb.example> Cc: cc@ccc.example Subject: =?UTF-8?B?44GT44KT44Gr44Gh44Gv?= ← 日本語の Subject(MIME B エンコード) Date: Sat, 25 Apr 2026 10:00:00 +0900 Message-ID: <msgid@aaa.example> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_001" Received: from mail.aaa.example by mail.bbb.example with ESMTP … ← 中継サーバが追記 Received: from alice-pc by mail.aaa.example … ← 上から下が時系列で逆順

multipart/mixed ─ 本文と添付を1通にまとめる

添付ファイル付きメールでは multipart/mixed という構造が使われます。本文と添付を 境界文字列(boundary) で区切って1通の本文に並べる、という発想です。

MIME は「1通の本文」をパートに分けて入れる約束 メール全体: multipart/mixed Content-Type: multipart/mixed; boundary="OUTER" パート1:本文 multipart/alternative = 同じ本文の別表現を入れる text/plain 普通のテキスト本文 こんにちは text/html HTML版の本文 <p>こんにちは</p> パート2:添付 PDF report.pdf Base64で文字列化 JVBERi0xLjQK... --OUTER --OUTER --OUTER-- SMTP から見ると、これ全体が1通の長いテキスト本文として運ばれる ① ヘッダで「このメールは multipart/mixed」と宣言 boundary は、パートの区切り線に使う合図 ② 本文は plain と html の2種類を入れてよい ③ 添付は種類名 + Base64文字列として入る ④ 受信側のメールアプリが boundary を見て部品に戻す
ステップ1. メールヘッダの Content-Type: multipart/mixed が「このメールは複数パートを持つ」と宣言します。boundary は各パートの区切り線です。
ステップ2. 本文部分には text/plain と text/html のように、同じ内容の別表現を入れることがあります。メールアプリは表示できる方を選びます。
ステップ3. 添付ファイルは application/pdf のような種類を持つ別パートになります。PDF や画像のようなバイナリは、SMTP で運びやすいように Base64 で文字列化されます。
ステップ4. SMTP はこの全体を1通の長い本文として運びます。受信側のメールアプリが boundary と Content-Type を読んで、本文・HTML版・添付ファイルに分解して表示します。
1 / 4

図の見方:multipart/mixed は「本文と添付を一緒に入れる外箱」です。その中に multipart/alternative として text/plain と text/html を入れ、別パートとして PDF などの添付を入れます。境界文字列(boundary)は区切り線であり、SMTP は全体を1通のテキストとして運びます。

小問:写真を添付したメールで、なぜ画像データが Base64 でエンコードされるのか?
正解:C。Base64 は 圧縮ではなくむしろサイズが約 4/3 倍に増える エンコード。目的は SMTP の 7-bit ASCII 制約に合わせて任意のバイナリを「英数記号64文字 + パディングの = 」だけに納めることです。A は誤り(増える)、B は別の話(暗号化)、D は副次的でしかない。

メールのセキュリティは別回で扱う

ここまでで、メールが SMTP で送られ、POP3 / IMAP で取り出され、MIME で本文や添付を表す ことを見てきました。ただし現実のメールでは、これに加えて 投函者の認証、通信の暗号化、送信元ドメインのなりすまし対策 が必要です。これらはセキュリティの知識とセットなので、詳しくは アプリ層プロトコルのセキュア化 へ回します。
POINT メール詳細回では 配送のしくみ を中心に見る。
メールセキュリティ回では SMTP-AUTH / STARTTLS / SMTPS / IMAPS / POP3S / SPF / DKIM / DMARC をまとめて見る。

ここでは名前だけ押さえる

話題ざっくり何を守るか詳しく扱う場所
SMTP-AUTH投函してきた利用者が正規ユーザかメール系のセキュア化
STARTTLS / SMTPS / IMAPS / POP3Sメールの送受信経路を暗号化するメール系のセキュア化
SPF / DKIM / DMARC送信元ドメインのなりすましを見抜く送信元ドメイン認証

つながる知識: SMTP はもともとかなり素朴なプロトコルなので、「送れる」だけでは安全とは言えません。メールの安全性は、SMTP そのものに後から認証・暗号化・ドメイン認証を重ねて作られています。

まとめと用語チェック

SUMMARY 1. メール送受信は MUA / MSA / MTA / MDA という4つのエージェントが連携。投函 587、中継 25、受信 110/143
2. SMTP は テキスト型コマンド-レスポンス。EHLO → MAIL FROM → RCPT TO → DATA → QUIT の流れ
3. POP3(110) は手元にダウンロード型、IMAP(143) はサーバ常駐型。複数端末同期は IMAP
4. MIME は SMTP の本文に「種類」と「複数の塊」を載せる拡張。multipart/mixed で本文+添付、Base64 でバイナリを 7-bit 化
5. オープンリレー は古い SMTP の負の遺産。現代の MTA は自ドメイン宛のみ受信、投函は認証必須
6. SMTP-AUTH / STARTTLS / SMTPS / IMAPS / POP3S / SPF / DKIM / DMARC など、認証・暗号化・なりすまし対策は セキュア化回 で扱う

用語チェック

用語1行説明
MUA / MSA / MTA / MDAメーラー / 投函口 / 中継エージェント / 配達(格納)エージェント
SMTP(25 / 587)送信プロトコル。MTA 間中継=25、Submission=587。TLS 化版は セキュア化回
EHLO / HELOSMTP の挨拶コマンド。EHLO は ESMTP 拡張用
MAIL FROM / RCPT TO / DATA / QUIT送信元宣言 / 宛先宣言 / 本文投入 / 切断
エンベロープ送信元SMTP の MAIL FROM。ヘッダの From: とは別物
POP3(110)受信プロトコル。ダウンロード型。TLS 化版 POP3S(995)は セキュア化回
IMAP(143)受信プロトコル。サーバ常駐型・複数端末同期。TLS 化版 IMAPS(993)は セキュア化回
MIME / multipartSMTP 本文に種類・複数パートを表現する拡張規約
Base64 / Quoted-Printableバイナリや非 ASCII を 7-bit ASCII に変換する符号化方式
OP25BOutbound Port 25 Blocking。ISP が家庭回線の外向き 25 番をブロックする迷惑メール対策
オープンリレー誰のメールでも中継してしまう古い MTA 設定。スパムの踏み台に
メールセキュリティSMTP-AUTH / STARTTLS / SPF / DKIM / DMARC など。詳しくは セキュア化回
NEXT: 第15回(標準) は FTP(ファイル転送)。SMTP と同様にテキスト型コマンド-レスポンスで動きますが、 制御接続とデータ接続を分離 する独特の設計を見ます。さらに先の TLS/PKI → アプリ層プロトコルのセキュア化 で、本講で触れた STARTTLS / SMTPS / IMAPS / POP3S といった TLS 化版を詳しく扱います。

確認問題

問1. メールシステムにおける MTA(Mail Transfer Agent) の役割として最も適切なものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. ユーザがメールを書く・読むためのアプリケーション
B. 受信メールをユーザのメールボックス(ファイル)に最終的に書き込む役割
C. メールサーバ間でメールをリレーし、宛先ドメインの MTA まで配達する役割
D. メールアドレスを IP アドレスに変換する役割
正解:C
MTA は Mail Transfer Agent。サーバ間でメールを転送するエージェントで、宛先ドメインの MX レコードを DNS で引き、相手 MTA の 25 番ポートに SMTP で接続して配達します。A は MUA(Mail User Agent)、B は MDA(Mail Delivery Agent)、D は DNS リゾルバの役割。

問2. SMTP コマンドの順序として、メール1通を送る基本的な流れに最も近いものはどれか。

次の選択肢から最も適切なものを選択してください。
A. EHLO → DATA → RCPT TO → MAIL FROM → QUIT
B. EHLO → MAIL FROM → RCPT TO → DATA → QUIT
C. MAIL FROM → EHLO → DATA → RCPT TO → QUIT
D. HELO → QUIT → MAIL FROM → DATA → RCPT TO
正解:B
正しい流れは TCP 接続 → サーバの 220 → クライアントの EHLO(挨拶)→ MAIL FROM(差出人宣言)→ RCPT TO(宛先宣言、複数可)→ DATA(本文投入、. で終端)→ QUIT(切断)。封筒の宛名(From, To)を先に告げてから中身を入れる、と覚えると順序が腑に落ちます。

問3. POP3 と IMAP の違いとして最も適切な記述はどれか。

次の選択肢から最も適切なものを選択してください。
A. POP3 は送信用、IMAP は受信用のプロトコルである
B. POP3 は TLS で暗号化できるが、IMAP は暗号化できない
C. IMAP はメールを必ず端末にダウンロードしてサーバから消すが、POP3 はサーバに残す
D. IMAP はメールをサーバに置いたまま管理するため複数端末で状態を共有しやすく、POP3 は基本的にダウンロード後にサーバ側から削除する
正解:D
POP3(110/995)は「サーバから取ってきて消す」のが基本動作で、1端末向き。IMAP(143/993)は「サーバに置いたまま読み書きし、既読・フォルダ分けもサーバ側で管理する」ため、スマホと PC で同じ状態が見える。A は両方とも受信用、B は両方 TLS 化可能(POP3S/IMAPS)、C は POP と IMAP の動作が逆になっており誤り。

問4. MIME が必要になった理由として最も適切なものはどれか。

次の選択肢から最も適切なものを選択してください。
A. SMTP は元々 7-bit ASCII の本文を想定しており、日本語や添付ファイルをそのまま扱いにくかったため
B. SMTP を UDP の上で動かすため
C. MX レコードを不要にするため
D. メールを必ず暗号化するため
正解:A
MIME は、元々テキスト中心だったメールに 日本語・HTML・添付ファイル・複数パート を載せるための拡張です。Base64 や Quoted-Printable は、7-bit ASCII しか扱いにくい環境でもデータを運べるようにするための符号化です。

問5. 古い SMTP の オープンリレー 問題に対する現代の対策として、関係しないものを1つ選べ。

次の選択肢から最も適切なものを選択してください。
A. MUA からの投函を受ける Submission ポート(587)でユーザ認証を必須にする
B. ISP が家庭回線の外向き 25 番ポートをブロックする(OP25B)
C. メールクライアントが TCP の代わりに UDP で送信する
D. 自ドメイン宛以外のメール中継を MTA で拒否する設定にする
正解:C
SMTP は信頼性のある順序付き配送が必要なので TCP を使うのが大前提で、UDP に置き換えるという話は出てきません。A・B・D はすべてオープンリレー対策の標準的な3点セット ─ 投函時の認証、家庭回線からの直接送信の遮断(OP25B)、自ドメイン以外の中継拒否、です。認証・暗号化・送信元ドメイン認証の詳しい中身は アプリ層プロトコルのセキュア化 で扱います。
← PREV
第13回 DNS の階層と解決手順
NEXT →
第15回 FTP（ファイル転送）