電子メールの仕組み（SMTP・POP・IMAP）｜情報Ⅰ 最強120講義 第75講

こんにちは、数強塾代表の藤原進之介です。『最強120講義』第75講は「電子メールの仕組み」です。キューの上では共通テスト重要度Bとして置いた講なのですが、一次資料に当たって考えを改めました。令和8年度の本試験に出題され、しかも正答率が約1割という設問を含んでいたからです。その根拠は第7章で全部お見せします。

この講で使うのは、第68講のTCP/IP 4階層のいちばん上、アプリケーション層です。第74講で見たHTTPと正反対の性質を持つプロトコルを扱う、と考えてください。その対比が、本講いちばんの武器になります。

1. まず、国の資料が「郵便」と書いている

総務省「国民のためのサイバーセキュリティサイト」の「電子メールの仕組み」に、次の2文が並んでいます。原文のまま引きます。

同じ1通のメールの話をしているのに、途中で動詞が変わっています。前半は「転送する」＝押し出す。後半は「取りに行く」＝引き取る。

第74講で見たWebは、全区間が「取りに行く」でした。ブラウザが要求して、サーバが答える。要求していないものは1バイトも来ない。メールはそうではありません。あなたが何も要求していないのに、知らないサーバから届く。これがメールの正体であり、迷惑メールという現象が原理的に成立してしまう理由でもあります。

2. なぜ送信と受信でプロトコルが違うのか

ここが最初の山場です。理由は難しくありません。やっている作業が違うからです。

• 送る側の仕事：宛先のサーバを見つけて、そこへ押し込む。相手はサーバなので24時間起きている。だから押し込める。
• 受け取る側の仕事：自分のサーバの箱から取り出す。自分の端末（スマホ・パソコン）は寝ていることがある。電源が切れている、圏外にいる。だから押し込めない。

「相手の端末に直接届ければいいのでは」と思うかもしれません。無理です。相手の端末はいつ起きているか分かりませんし、そもそもIPアドレスが日によって変わります。だから、いつでも起きているサーバを間に置いて、そこまでを配達、そこから先を取り出しに分けた。配達と取り出しは別の作業ですから、別の規約になります。

総務省の同じサイトの用語辞典（英字）に、両方の定義があります。

「送信と転送」と「取りに行く」。国の用語辞典の定義文そのものの中に、押すのか引くのかが書き分けられています。名前も正直で、POPは Post Office Protocol ＝「郵便局プロトコル」です。郵便局まで取りに行く、という比喩がそのまま名前になっています。

図1　メールは4区間をバケツリレーする。区間ごとに「動く側」が違うから、プロトコルが分かれる。

なお、送信側サーバが宛先のサーバをどうやって見つけるのかは、メールの仕事ではなくDNSの仕事です。ドメイン名から「そのドメイン宛のメールを受け取る係のサーバ」を引く仕組み（MXレコード）を使います。ここは第71講（DNS）の担当なので、そちらに渡します。本講で押さえるのは「宛先を探すのは別の仕組みに外注している」という一点だけで十分です。

3. POPとIMAPの違いは「どこに本体を置くか」

受け取り側のプロトコルには2つあります。違いは1つだけ、メールの本体をどこに置くかです。

POPが作られた時代、メールを読む機械は1人につき1台でした。だから「落として消す」で何も困りません。むしろサーバの容量が貴重だったので、落として消すのが正しかったのです。

ところが、スマホとパソコンとタブレットで同じアドレスを使う時代になると、この設計が破綻します。スマホで落として消してしまったら、パソコンには永遠に届きません。仮に消さない設定にしても、今度は「スマホでは既読、パソコンでは未読」という矛盾が起きます。

ここは情報Ⅰの他の単元とまったく同じ考え方だと気づいてください。データベースの講で「同じデータを2か所に持つと矛盾する」と言うのと、同じ理屈が同じ形で出ています。

4. なぜ差出人を詐称できてしまうのか ── 封筒と便箋

本講の最大の山場です。結論を先に言います。メールには「封筒」と「便箋」があり、そこに書く差出人は別々に書けるからです。

インターネットのメールは、2つの規格に分かれて定義されています。この分かれ方そのものが原因になっています。

つまり、2つの規格が、意図的に互いの領分に触れないように書かれています。封筒の規格は中身を規定せず、中身の規格は封筒を規定しない。

さらにRFC 5321の3.6.3節には、こう書いてあります。

そして便箋側のFromについて、RFC 5322の3.6.2節はこう定義しています。

「著者を指定する」であって、「著者を証明する」ではありません。自己申告なのです。

IPA（独立行政法人情報処理推進機構）が、この事実を一般向けにはっきり書いています。

だからIPAの助言は「添付ファイルを開かない／記載のURLからアクセスしない／記載の電話番号に電話しない／返信しない」の4つになります。差出人欄を見て判断してはいけない、が前提にあるのです。

4-1. 「技術が先、対策が後」という構造

ここで大事なのは、これは欠陥ではなく、順番の問題だということです。

SMTPが作られたのは、インターネットがまだ研究者どうしの小さな輪だった時代でした。全員が顔見知りなら、差出人を確かめる仕組みは要りません。要らないものを作らなかっただけで、設計として間違っていたわけではない。世界中の誰でも参加できる場になった瞬間に、前提のほうが壊れたのです。

だから対策は全部あとから足されました。しかも、足す場所はメールの外側です。

• SPF：そのドメインのメールを送ってよいサーバの一覧を、DNSに書いておく
• DKIM：送信側が電子署名を付け、検証用の公開鍵をDNSに置く（第17講の公開鍵暗号がここで効きます）
• DMARC：SPFとDKIMの結果をどう扱うか（受け取る／隔離する／捨てる）を、DNSに書いておく

3つとも置き場所がDNSなのがポイントで、メールの規格そのものは1文字も変えていません。壊さずに外から補強するという、後付け対策の典型です。

では、40年たって行き渡ったのでしょうか。総務省『令和7年版 情報通信白書』が数字を出しています。

5. 添付ファイルはなぜ容量が増えるのか

もう1つ、地続きの話です。写真を添付すると、元のファイルより大きくなって送られます。

つまり、メールという土管はもともとUS-ASCIIのテキストしか運べません。画像もPDFも、そのままでは通らない。

そこでMIMEは、バイナリを文字に化けさせて載せることにしました。それがBase64です。RFC 2045の6.8節がその仕組みを書いています。

8ビット単位のデータを、6ビット単位に割り直す。1文字で6ビットしか運べないので、24ビット（3バイト）を運ぶのに4文字要る。ここから膨張率が出ます。

ただし実際のメールには、もう1つ効く要素があります。76文字ごとに改行が入るという規定です。改行（CRLF）は2バイトなので、これも数えます。

約1.37倍。次の章で、自分の手で確かめます。

第31講の文字コード、第36講の圧縮とつながる話でもあります。せっかく圧縮して小さくしても、添付にした瞬間に1.37倍に戻される。「圧縮してから送る」の効果を見積もるときは、この係数を忘れてはいけません。

6. 手で確かめる

6-1. Base64の膨張率を、紙と鉛筆で出す

1. Base64は1文字で6ビットしか運べない。
2. 元のデータは1バイト＝8ビット。
3. 最小公倍数は24ビット。つまり3バイト（24ビット）＝4文字（24ビット）でぴったり合う。
4. よって膨張率は 4 ÷ 3 ＝ 1.3333…倍。
5. さらに出力は76文字ごとに改行する。76文字は 76 × 6 ＝ 456ビット ＝ 57バイトぶん。
6. 改行CRLFは2バイト。よって57バイトが78バイトになる。78 ÷ 57 ＝ 1.3684…倍。

3バイトに満たない端数は「=」で埋めます（パディング）。だから1バイトでも4文字、2バイトでも4文字になります。小さいファイルほど膨張率は悪くなる、ということです。

6-2. Pythonで検算する

上の手計算が正しいかを、実際に走らせて確かめます。以下は2026年8月3日に実行し、出力を確認したものです。

import base64
# 純粋な符号化だけ
for n in [1, 2, 3, 1024, 3000]:
    enc = base64.b64encode(b"\x00" * n)
    print(n, "バイト ->", len(enc), "文字   比", len(enc) / n)
# 76文字ごとの改行（CRLF）を含めた場合
for n in [57, 570, 57000]:
    enc = base64.encodebytes(b"\x00" * n).replace(b"\n", b"\r\n")
    print(n, "バイト ->", len(enc), "バイト   比", len(enc) / n)

実行結果です。

1 バイト -> 4 文字   比 4.0
2 バイト -> 4 文字   比 2.0
3 バイト -> 4 文字   比 1.3333333333333333
1024 バイト -> 1368 文字   比 1.3359375
3000 バイト -> 4000 文字   比 1.3333333333333333
57 バイト -> 78 バイト   比 1.368421052631579
570 バイト -> 780 バイト   比 1.368421052631579
57000 バイト -> 78000 バイト   比 1.368421052631579

手計算の 4 ÷ 3 ＝ 1.3333… と 78 ÷ 57 ＝ 1.3684… に、きれいに一致しました。1バイトのときに比が4.0になっているのが、パディングの効果です。

1MB（1,048,576バイト）の写真で試すと、1,434,898バイトになりました。386,322バイトぶん増えています。「10MBまで」という添付の上限があるサービスで、実際に送れるファイルが7MB台までなのは、この係数のせいです。

日本語の本文でも同じことが起きます。

import base64
s = "こんにちは"
b = s.encode("utf-8")
print(len(b), "バイト ->", len(base64.b64encode(b)), "文字", base64.b64encode(b).decode())

15 バイト -> 20 文字 44GT44KT44Gr44Gh44Gv

UTF-8で15バイトのひらがな5文字が、20文字になりました。15 × 4 ÷ 3 ＝ 20 で、ぴったり合います。

件名（Subject）のようなヘッダに日本語を書いたときも、同じ理屈で符号化されます。

from email.header import Header
print(Header("こんにちは", "utf-8").encode())

=?utf-8?b?44GT44KT44Gr44Gh44Gv?=

「?b?」の b がBase64を表します。本文は化けていないのに件名だけ化けるという現象を見たことがあるなら、それはここが読み解かれずに素通りしている状態です。

6-3. ヘッダを読む ── Receivedは下から上へ

実際に届いたメールのヘッダを開くと、次のような行が並んでいます。以下は私が説明用に作った例です（アドレスはRFC 2606の例示用ドメイン、IPアドレスはRFC 5737の例示用アドレスを使いました。実在の第三者の情報は一切含みません）。

Return-Path: <bounce@relay.example.net>
Received: from mx.example.com (mx.example.com [192.0.2.10])
        by mail.example.jp with ESMTP id 4X2Qz1
        for <taro@example.jp>; Mon, 3 Aug 2026 10:12:04 +0900
Received: from relay.example.net (relay.example.net [198.51.100.7])
        by mx.example.com with ESMTP id 9K7Lm3
        for <taro@example.jp>; Mon, 3 Aug 2026 10:12:01 +0900
From: "事務局" <info@example.org>
To: taro@example.jp
Subject: =?utf-8?b?44GK55+l44KJ44Gb?=
Content-Type: multipart/mixed; boundary="b1"

読み方は2つだけ覚えれば十分です。

(1) Receivedは下から上へ読む。中継したサーバが、自分の行をいちばん上に足すからです（RFC 5321 3.6.3が「自分のReceived:を足す以外はするな」と書いていた、あのReceivedです）。だからいちばん下がいちばん古い。上の例では relay.example.net → mx.example.com → mail.example.jp の順に渡ってきた、と読みます。このメールが実際に通った経路が、そのまま記録に残っているわけです。

(2) Return-PathとFromが一致しているとは限らない。上の例では次のようになっています。

• Return-Path（＝封筒に書かれた差出人。エラーの返送先）… bounce@relay.example.net
• From（＝便箋に書かれた差出人。画面に表示される）… info@example.org

画面に出るのはFromだけです。Return-Pathはふつう、開かないと見えません。この2つが食い違うこと自体は正常な運用でも起きます（メール配信サービスを経由する場合など）。ですが、なりすましが成立する隙間もここにあります。

自分宛のメールのヘッダは、多くのメールソフトで「メッセージのソースを表示」「元のメッセージを表示」といったメニューから見られます。自分に届いた本物のメールで、一度やってみてください。ただし他人に見せるときは、実在のアドレス・IPアドレス・組織名を必ず伏せること。ヘッダには経路上のサーバ名やIPアドレスが残っており、それ自体が個人や所属の手がかりになります（第9講の個人情報の考え方が、そのままここに効きます）。

6-4. 封筒と便箋が別物であることを、プログラムの側から確かめる

もう1つ、コードで見える形の証拠があります。Pythonの標準ライブラリで、メールを送る関数の引数を見てみます。

import smtplib, inspect
print(list(inspect.signature(smtplib.SMTP.send_message).parameters))
print(list(inspect.signature(smtplib.SMTP.sendmail).parameters))

['self', 'msg', 'from_addr', 'to_addrs', 'mail_options', 'rcpt_options']
['self', 'from_addr', 'to_addrs', 'msg', 'mail_options', 'rcpt_options']

msg（メッセージ本体＝便箋）と、from_addr / to_addrs（封筒）が、別々の引数になっています。便箋の中にもFrom:とTo:は書いてあるのに、封筒のぶんをもう一度別に渡す設計です。

これはPythonの都合ではありません。RFC 5321とRFC 5322が別々の規格だという事実が、そのままプログラムの引数の形に現れているだけです。仕様の分かれ目は、こういうところに漏れ出ます。

7. 共通テストではこう出る（重要度B ── ただし実測は要注意）

7-1. 実際に出た。しかも、いちばん取れていない

大学入試センター『令和8年度大学入学共通テスト 問題評価・分析委員会報告書（本試験）』の『情報Ⅰ』問題作成部会の見解（自己評価）に、はっきり書かれています。原文です。

高等学校教科担当教員側の評価も、同じ報告書に載っています。

配点も確認しました。令和8年度本試験の正解表では第1問は20点で、問4に相当する解答記号はシ1点・ス2点・セ2点・ソ1点の計6点です。第1問20点のうち6点がメールでした。

7-2. どういう構造の設問だったか

問題文・選択肢・図は大学入試センターの著作物なので転載しません。設問の構造だけ説明します。

• 送信者と受信者、そのあいだに送信側メールサーバと受信側メールサーバの2台が描かれた概念図が与えられる。
• a：宛先アドレスの書き間違いを3通り示し、それぞれについて「配送不能を最初に検出したのはどちらのサーバか、そしてその理由は何か」の組合せを選ばせる。
• b：この配送の過程で通信先のIPアドレスを特定する仕組みを4択で選ばせる（答えはDNS）。

つまり問われているのは、「メールがどこを通り、どの段階で何が分かるのか」です。

7-3. だから、原理で考えるしかない

aの型を突破する鍵は、サーバはその時点で何を知っているのかを1段ずつ考えることに尽きます。

• 送信側サーバが最初に知るのは、宛先の @ より右側（ドメイン名）。そこが存在するかどうかは、DNSに聞けば送信側でその場で分かる。
• 一方、@ より左側（ユーザ名）が存在するかどうかは、宛先のドメインを預かっているサーバしか知らない。送信側サーバは、他人の家の郵便受けの名札を持っていない。
• したがって、ドメイン名の誤りは早い段階で、ユーザ名の誤りは遅い段階で分かる。

これは第2章の図1で見た「バケツリレー」の直接の帰結です。リレーだから、情報が分かるタイミングもリレーの順番に並ぶ。暗記ではなく、図を1本引いて指でたどれば出ます。

bは完全に第71講の内容です。メールの講なのに答えはDNS——これが、共通テストが単元をまたいで問うということの実例になっています。

7-4. 出題実績を、調べた範囲で正直に書く

私が確認できた範囲は次のとおりです（大学入試センターが公開している問題PDFを全文検索しました。2026年8月3日取得）。

• 令和8年度 本試験：第1問 問4が電子メール（上記）。本文に「メールサーバ」4件・「DNS」1件。
• 令和8年度 追・再試験：問6で、SNSやメールを装ったメッセージからアカウント情報をだまし取る手口と、その後の不正ログインが違反する法律を問う型。「フィッシング」2件。
• 令和7年度 本試験・追再試験：メールは題材として登場するだけ（部員への連絡文面、収集したメールアドレスの取扱い）で、仕組みは問われていない。
• 試作問題：第1問 問1が「情報社会の中で日常的に利用されるSNSやメール，Webサイトなどの利用時の注意点や情報の信ぴょう性の判断」（大学入試センター「令和7年度大学入学共通テスト 試作問題『情報』の概要」2022年11月9日公表）。

7-5. 引っかけの急所5つ

1. 「送信も受信も同じプロトコル」ではない。送信はSMTP、受信はPOP／IMAP。ただし送信者の端末から送信側サーバへ渡すところもSMTPです（ここを「受信側だからPOP」と誤る答案が多い）。
2. POPとIMAPを「新しい／古い」で覚えない。違いは「本体をどこに置くか」。複数端末という条件が出てきたらIMAP。
3. Fromが本物である保証はない。「差出人が学校のドメインだから安全」は成り立ちません。
4. 添付は元より大きくなる。「10MBのファイルは10MB制限に収まる」は誤り。
5. 宛先サーバを探すのはDNS。メール自身の機能ではありません。

7-6. 私が作った類題

8. 情報Ⅱではこうなる

8-1. 語数調査 ── 情報Ⅰの本文には、メールの仕組みが書かれていない

まず事実を出します。私が数えた範囲は次の3資料です。

• 学習指導要領（平成30年告示）解説 情報編（第1部＝共通教科と第2部＝専門教科を分けて計数）
• 情報Ⅰ教員研修用教材 全6分冊（前付＋第1〜4章）
• 情報Ⅱ教員研修用教材 全7分冊（序章・第1章・第2章・第3章前半・第3章後半・第4章・第5章）

いずれも空白と改行を除去してから数えました（PDF抽出は語の途中で改行が入るためです）。

用法の内訳（素朴に数えると誤るところ）を書いておきます。

• 情報Ⅱ教材の「POP」2件は、プロトコルのPOPではありません。どちらも第2章の「POP広告（Point Of Purchase）」、つまり書店の店頭広告です。素朴に検索すると「情報Ⅱ教材にPOPが2件ある」と誤って報告することになります。プロトコルとしてのPOPは情報Ⅱ教材に0件です。
• 情報Ⅱ教材の「ヘッダ」6件も、メールのヘッダではありません。第4章のパケットフィルタリングの「パケットのヘッダー」1件と、第3章前半・第5章の表形式データの「ヘッダー」5件です。メールヘッダは0件。
• 情報Ⅱ教材の「同報」1件も、メールの同報送信ではありません。第1章でソーシャルメディアの性質を「時間軸（即時性）、人数（同報性）、閉鎖性、匿名性」と並べている中の1語です。
• 情報Ⅰ教材のSMTP・POP各1件は、同じ1文の中にあります。第4章 学習18のTCP/IP 4階層モデルの説明中の列挙「TCP, IPv4, IPv6, DHCP, HTTP, SMTP, POPなど様々なプロトコル」だけで、それぞれが何をするプロトコルなのかは1行も説明されていません。

なお、文部科学省の授業・研修用コンテンツのスライドPDFの一部は画像化されており、全文検索の対象にできません。上の「0件」はテキスト抽出できた資料の範囲での0件です。この限界は明記しておきます。

8-2. ここに「情報Ⅰの本文の空白」がある

そのうえで、いちばん重い事実を書きます。情報Ⅰ教員研修用教材 第4章 学習18の【学習活動の目的】には、はっきりこう書いてあります。

ところが同じ学習18の「学習活動とそれを促す問い」は、展開1＝プロトコルの必要性／展開2＝公衆無線LANの危険性／展開3＝安全な接続は不便な接続かの3つで、電子メールの仕組みを扱う展開は1つも用意されていません。

第4章全体で「電子メール」が出てくるのは3か所だけで、その中身は次のとおりです。

1. 上に引いた【学習活動の目的】の1行
2. 演習2「電子メールのチェックやWebサイトの認証などにおいて、暗号化がなされているのか調べてみましょう」
3. ネットワークのトラブル対応の箇条書き「電子メールを送信できない」

これは第74講がWeb／HTTPについて見つけたのとまったく同じ構造です（第74講は「Webそのものを扱う展開は用意されていない」と記録しました）。同じ1行の目的に並んで書かれている「電子メール」と「Web」が、両方とも中身を持っていない。

そして違いはここからです。メールのほうは、令和8年度の本試験に出ました。しかも第7章のとおり、正答率が約1割の設問を含んでいました。

8-3. 情報Ⅰでの扱い ── メールは「使う道具」

情報Ⅰでのメールは、一貫して使う側の道具として出てきます。

• 学習指導要領解説 情報編（共通教科）の「電子メール」6件は、すべてコミュニケーション手段の例としての登場です。原文で言えば「情報を伝えるメディアには電話，テレビ・ラジオなどのような同期型のものと，手紙，電子メール，新聞のような非同期型のものがある」、「個人と個人でやりとりする電子メール，不特定多数に向けて情報を発信するWebサイト，コミュニティを形成するSNS」といった形です。
• ただし1か所だけ、仕組み側に踏み込んでいます。情報Ⅰ (4)ア(ア) の解説に「電子メールを送受信するときの情報の流れなどを取り上げ，安全で効率的な情報通信ネットワークの設計に必要なことを扱う」とあります。「情報の流れ」を扱えとは書いてある。書いてあるのに、教員研修用教材の側に展開が無い、というのが8-2の話です。
• 情報Ⅰ教材 第1章では、標的型メール攻撃の説明の中で「メールの件名や送信者名を偽装し、内部関係者を装ってウイルス添付のメールを送信する」とあります。偽装できるという事実は書かれているが、なぜ偽装できるのかは書かれていない。本講の第4章は、まさにその「なぜ」を埋めるために書きました。

8-4. 情報Ⅱでの扱い ── 「作る側の部品」と「守る対象」に変わる

情報Ⅱでは、メールの立ち位置が3方向に変わります。教材の記述に当てて具体的に書きます。

(1) メールサーバが「情報システムの構成部品の表の1行」になる（第4章 学習19）
情報Ⅱ教員研修用教材 第4章 学習19「情報システム全体の情報の流れ」の図表7「サーバの種類」に、次の1行があります。

同じ表にファイルサーバ・Webサーバ・データベースサーバ・コミュニケーションサーバ・プリントサーバが並びます。情報Ⅰでは「メールを送る」だった動作が、情報Ⅱでは「自分が組むシステムに、どのサーバを置くか」という選択肢の1つになります。

(2) メールアドレスが「設計上の弱点」になる（第4章 学習20）
同 学習20「情報システムの情報セキュリティ」で、リスト型攻撃の説明にこうあります。

情報Ⅰでは、メールアドレスは「自分の連絡先」でした。情報Ⅱでは、自分が設計する画面の入力欄になり、その設計の仕方が攻撃されやすさを決めます。同じ学習20はXSS・CSRF・ブルートフォース攻撃も並べており、メールアドレスがその一覧の中に位置づけられているのがポイントです。

(3) 誤送信の防止が「ルールの問題」から「設計の問題」に変わる（第1章 学習2）
情報Ⅱ教員研修用教材 第1章 学習2「情報セキュリティの必要性」に、共通教科の一次資料で唯一 To／Cc／Bcc が出てくる箇所があります。

(4) 情報システムからの連絡手段としてのメール（第1章 学習1）
同 第1章には、ネットショッピングの情報の流れの中で「ネットショッピングの購買情報から商品の発送データが運送会社に送られ，その配送情報がネットショッピングサイトの個人ページに反映されるだけでなく，電子メールなどによる配送日時の連絡，Webページを使った配送日時及び配送場所の変更なども柔軟に対応できるようになってきている」とあります。人が人に書くメールではなく、システムが人に送るメールです。情報Ⅱでは、メールがシステム間連携の出口の1つとして扱われます。

(5) テストの対象になる（第4章 学習24）
第4章 学習24では、作ったシステムに対して「セキュリティテスト」という節が立ちます。原文は「情報システムを実際に運用する際は，開発者以外のユーザーが操作したり，他のコンピュータからアクセスできる環境に置かれたりすることがある。そのため，しっかりとしたセキュリティ対策が必要となる。システムの利用が始まってしまうと，脆弱性の改修が難しくなってしまうことがある」。ここでの攻撃手法の一覧に、(2)のリスト型攻撃が入ります。情報Ⅰの「怪しいメールを開かない」が、情報Ⅱでは「稼働前にテストする項目」になるわけです。

8-5. 一言でまとめると

9. まとめ

1. メールは郵便であり、Webのように「取りに行く」ものではない。送りつけられる。だから迷惑メールが原理的に成立する。
2. 送る仕事と取り出す仕事は別作業だから、SMTPとPOP／IMAPに分かれている。
3. POPとIMAPの違いは本体をどこに置くか。複数端末で使うなら、状態は1か所（サーバ）に置くしかない。
4. 封筒（エンベロープ）と便箋（ヘッダ）は別物で、中継サーバは便箋を読んではいけない（RFC 5321 3.6.3）。だからFromは自己申告にすぎない。
5. SPF・DKIM・DMARCは全部あとからDNSに足した外付けで、2024年9月時点のJPドメイン名でSPF約88.4％・DMARC約32.6％（総務省『令和7年版 情報通信白書』）。
6. 添付が膨らむのは、テキストしか運べない土管にバイナリを載せているから。Base64で4 ÷ 3倍、改行込みで約1.37倍。
7. 令和8年度本試験でメールの仕組みが出題され、正答率約1割の設問があった。情報Ⅰの一次資料の本文に、その説明は無い。

今日持ち帰ってほしいのは、番号やアルファベットではありません。「郵便だから途中に置き場所が要る」「封筒と便箋は別々に書ける」——この2つの因果だけです。この2つから、送受信でプロトコルが分かれる理由も、なりすましができてしまう理由も、全部導けます。