Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Web開発者が知っておきたいメール技術の基礎
Search
Toshiki003
March 27, 2026
Technology
62
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Web開発者が知っておきたいメール技術の基礎
社内学習会で使用したスライドです。
Toshiki003
March 27, 2026
More Decks by Toshiki003
See All by Toshiki003
プログラム実行時、メモリとCPUはどのように 連動して動くのか
toshiki003
1
220
Other Decks in Technology
See All in Technology
MCP Appsを作ってみよう
iwamot
PRO
4
660
作って終わりにしない タイミーのセマンティックレイヤー育成の現在地
chanyou0311
4
2.4k
Claude Codeをどのように キャッチアップしているか
oikon48
13
8.2k
やさしいA2A入門
minorun365
PRO
12
1.9k
非エンジニアがClaudeと挑んだ「1ヶ月間プロダクト30本ノック」
askokc
0
580
Socrates × Looker 〜セマンティックレイヤーで進化するデータ分析エージェント〜
hanon52_
3
2.4k
なぜ Platform Engineering の土台に Kubernetes を選ぶのか
r4ynode
2
650
気づかぬうちにセキュリティ負債を生むAPIキー運用
sgwrmctk
0
150
白金鉱業Meetup_Vol.24_「AIエージェントは分けるほど良い」は本当か? / Is it true that “the more you divide AI agents, the better”?
brainpadpr
1
390
20260619 私の日常業務での生成 AI 活用
masaruogura
1
220
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
130
いまさら聞けない「仕様駆動開発入門」 〜AI活用時代の開発プロセスを考える〜
findy_eventslides
2
130
Featured
See All Featured
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
480
How to Ace a Technical Interview
jacobian
281
24k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
360
The untapped power of vector embeddings
frankvandijk
2
1.8k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
330
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.4k
Building Applications with DynamoDB
mza
96
7.1k
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
840
Designing for humans not robots
tammielis
254
26k
RailsConf 2023
tenderlove
30
1.5k
It's Worth the Effort
3n
188
29k
Transcript
Web 開発者が知っておきたい メール技術の基礎 2026-03-27 1
アウトライン 1. なぜ学ぶ? ― 実務との接点 2. メールの使い方と送受信の全体像 3. プロトコルの詳細とポート番号 4.
代表的なメールサーバー 5. 現代のメール運用とまとめ 6. 補足資料(時間次第) 2
なぜメール技術を? 4 月からの業務でメールサーバー移行を担当 メール技術について予習中 入り口部分やメールの全体像の理解はぜひ広めたい 学習で終わらせず価値に変えたい → 学習会開催& スライド資料化 3
1. なぜ学ぶ? ― このテーマを学ぶ意味 いまはGmail やMicrosoft 365 など便利なサービスがある そのため、メールの仕組みを意識せずに使えてしまう しかし、Web
開発の実務ではメールに関する問題が普通に起こる → 仕組みを知っていると、設計・実装・障害調査がしやすくなる 4
1. なぜ学ぶ? ― 具体例 会員登録メールの送信 パスワード再設定メールの送信 お問い合わせ通知や各種アラートの送信 メールが届かない・迷惑メールに入るといった調査 送信基盤として Amazon
SES や SendGrid を使う場面 など 5
2. メールの使い方は3 種類ある 1. メールソフトで使う 例: Outlook, Thunderbird, iPhone メール
2. Web メールで使う 例: ブラウザで開く Gmail, Yahoo! メール 3. クラウドメールサービスを使う 例: Gmail, Microsoft 365 ※ Gmail のように「Web メール」かつ「クラウドメールサービス」に該当するものも あります これらは見た目や使い方の違いです。 裏側では共通してメールのプロトコルが使われています。 6
2. メールソフトがやること・プロトコルがやること メールソフトでできること(見た目の印象) 作成・編集・送信・閲覧・検索・削除・フォルダ分け … プロトコルが担っていること(実態) SMTP → メールを「送る」だけ POP3
/ IMAP → メールを「受信側からアクセスする」ためのもの 作成・編集などはメールソフト側の機能が中心です(※IMAP はサーバー上の検索・ フォルダ操作も可能) この違いを意識すると、このあとのプロトコル解説が理解しやすくなります! 7
2. 裏側で使われる主なプロトコル プロトコル 役割 SMTP メールを送るためのプロトコル POP3 メールを受信するための古典的なプロトコル IMAP サーバー上のメールボックスを同期しながら扱う受信プロトコル
前のスライドの通り、どれも機能は非常にシンプル。 まず全体像を見てから、それぞれを深掘りします 8
2. 送受信の全体像① 登場人物は5 つ 送る人 → 作成画面 → 送信サーバー →
受信サーバー → 読む人 9
2. 送受信の全体像② 10
2. 送受信の全体像③ 11
2. Web (HTTP )と何が違うのか?① 12
2. Web (HTTP )と何が違うのか?② 観点 Web メール プロトコル数 1 つ(HTTP
) 2 つに分かれている 通信モデル リクエスト⇄レスポンス 送信→ 中継→ 保管→ 受信 サーバー 基本1 台で応答 送信側・受信側で別 Web は 1 つのプロトコルで双方向完結 するシンプルな構造 メールは 送りと受けで仕組みが分かれている のが特徴 この構造の違いが、メール特有の複雑さの根本原因 13
2. なぜサーバーが分かれているのか? Web (HTTP ) → 送り手と受け手が同時にオンライン。1 台で即座にやり取り メール →
送り手と受け手が同時にオンラインとは限らない。中間で預かる仕組み が必要 郵便 メール 役割 ポストに投函 送信サーバーに渡す SMTP 郵便局が配送 サーバー間を中継 SMTP 届け先の郵便受けに届く 受信サーバーに保管 ― 郵便受けを開けて読む 取りに行く POP3/IMAP 「届ける」と「受け取る」はそもそも別の行為。だからサーバーも分かれている 14
3. SMTP とは メールを次の相手に引き渡していく仕組み 使われる場面 利用者の端末から送信サーバーへ渡す 送信サーバーから相手先メールサーバーへ配送する バケツリレーのように、メールを中継していくイメージ 15
3. POP3 とは 受信サーバーからメールを取得するためのプロトコル 特徴 比較的シンプル サーバーから端末へダウンロードする考え方が中心 複数端末での同期にはあまり向かない 設定次第でサーバーから削除する運用が一般的だったため、現代は後述するIMAP が
主流 16
3. IMAP とは サーバー上のメールを同期しながら扱うためのプロトコル 特徴 サーバーにメールを置いたまま扱える 複数端末で状態を共有しやすい 現代的なメール利用と相性がよい スマホとPC の両方で同じ受信箱を見る感覚に近い
17
3. POP3 と IMAP の違い 観点 POP3 IMAP 動作モデル 取得中心
同期中心 複雑さ シンプル やや複雑 端末数 単一端末寄り 複数端末に向く 現代との相性 やや古い 現代の利用形態と相性がよい 受信プロトコルとしては、IMAP の考え方を優先して押さえるとよい 18
3. メール関連の主なポート番号 プロトコル ポート 用途 今の立ち位置 SMTP 25 サーバー間配送 サーバー間専用
SMTP 587 送信(クライアント→ サーバー) 主流 SMTP 465 送信(implicit TLS ) 復権中 POP3 110 受信(平文) 非推奨 POP3 995 受信(暗号化) IMAP 推奨 IMAP 143 受信(STARTTLS ) 利用可 IMAP 993 受信(暗号化) 主流 まず覚えるべきは 587 (送信)と 993 (受信)の2 つ 19
4. 代表的なSMTP サーバー(送信側) 分類 名前 特徴 クラウド Amazon SES AWS
連携◎ 大量配信・従量課金で低コスト クラウド SendGrid REST API が使いやすい。分析機能が充実 クラウド Mailgun 開発者向けAPI 重視。テスト環境が便利 オンプレ Postfix Linux 定番MTA 。設定シンプルで実績豊富 オンプレ Sendmail 最古のMTA 。設定は複雑だが柔軟 オンプレ Exchange Windows 環境の定番。AD 統合 開発用 Mailpit ダミーSMTP 。ローカルで動くOSS 版。Laravel 等で人気 開発用はメールの閲覧ができるが、SMTP で受けたメールをHTTP で表示するだけ 20
4. 代表的なPOP / IMAP サーバー(受信側) ソフトウェア 対応プロトコル 特徴 Dovecot POP3
/ IMAP Linux 環境で最も広く使われる。軽量で高速 Courier POP3 / IMAP Maildir 形式に強い。Dovecot と並ぶ選択肢 Cyrus IMAP IMAP 大規模環境向け。ISP などで採用実績あり Microsoft Exchange POP3 / IMAP / MAPI Windows 統合環境の定番。独自プロトコル MAPI も持つ ポイント Dovecot + Postfix の組み合わせがLinux メールサーバーの定番構成 クラウドメール(Gmail, Microsoft 365 )を使う場合これらを意識する機会は少ない 21
5. いまどきのメール運用 多くの現場では Gmail や Microsoft 365 を使う アプリからの通知メールは Amazon
SES や SendGrid を使うことが多い 自前でメールサーバーを運用する機会は少ない 仕組みを知っていると何がよいか メールが届かない原因を切り分けやすい プロトコル / DNS / TLS の関係が分かる クラウドサービスの役割を正しく理解できる 実務でログや設定を見るときに怖くなくなる 22
5. Web 開発者として、どこまで理解すればよいか まずは次のレベルで十分: 3 つのプロトコルの役割の違いを説明できる メールの送受信の流れを説明できる メールソフト / Web
メール / クラウドサービスの違いを説明できる 主なポート番号を見て、何の通信かだいたい分かる ここまで分かれば、実務でかなり役に立つ 23
5. まとめ メール技術は古いが、今でも実務に直結する知識 利用者の見え方と、裏側の仕組みは分けて考えると良い プロトコルの主な役割は「送る」と「受信側からアクセスする」こと Gmail などの便利なサービスの裏にも基本技術がある 自前運用の優先度は高くないが、基礎理解しておく価値はある 24
5. 参考書籍 本学習会の内容は以下の書籍を参考にしています。 より深く学びたい方はぜひ手に取ってみてください。 メール技術の教科書(翔泳社) https://www.shoeisha.co.jp/book/detail/9784798183930 SMTP / POP /
IMAP の仕組みからセキュリティまで体系的に解説 本日の内容はこの書籍のごく一部です 25
確認問題 今日の内容を振り返ってみましょう!(全3 問) 26
Q1. メールソフトでの「作成・編集・検索・削除」は、誰が担っている? A. SMTP サーバーが処理している B. IMAP サーバーがフォルダ管理として処理している C. メールソフト(クライアント側)が処理している
27
Q1. 答え:C メールソフト(クライアント側)が処理している プロトコルが担うのは「送る」と「受信側からアクセスする」こと。 作成・編集といった機能はメールソフト側の仕事が中心です。 IMAP にはサーバー上のフォルダ操作機能もありますが、 「検索・作成・編集」はクライアント側の機能であり、本日の学習の核心です 28
Q2. Web アプリ(HTTP )と比べた、メールの構造上の最大の特徴は? A. メールは1 回の通信で送信が完了しない(中継が必要) B. 送信と受信で異なるプロトコル・異なるサーバーを使う C.
メールは必ず暗号化されて通信される 29
Q2. 答え:B 送信と受信で異なるプロトコル・異なるサーバーを使う HTTP は1 つのプロトコルでリクエスト⇄レスポンスを完結できます。 メールは送信(SMTP )と受信(POP3/IMAP )で仕組みが分かれているのが根本的な 違いです。
A の「中継が必要」も事実ですが、それはSMTP の内部動作の話。 「送りと受けで仕組みが違う」ことが構造上の最大の特徴です 30
Q3. POP3 ではなくIMAP が現代の主流である最大の理由は? A. IMAP の方がプロトコルとしてシンプルだから B. POP3 は暗号化通信(POP3S
)に対応していないから C. IMAP はサーバーにメールを残し、複数端末で同期できるから 31
Q3. 答え:C IMAP はサーバーにメールを残し、複数端末で同期できるから POP3 は「ダウンロード中心」で、設定次第でサーバーから削除する運用が一般的でし た。 IMAP は「サーバーに残したまま同期」するため、スマホ・PC 両方から同じ受信箱を見
られます。 A は逆です(IMAP の方が複雑) 。B も誤りで、POP3S は存在します(ポート995 ) 32
補足資料 時間に余裕があれば紹介します 33
補足: さらに学ぶなら 次のテーマにつなげやすい: DNS と MX レコード(メールの宛先解決の仕組み) SPF / DKIM
/ DMARC (なりすまし防止の認証技術) バウンスと配信レピュテーション(届かないメールの原因と対策) メール送信の非同期処理と再送設計(キューイング、リトライ戦略) SMTP とSFTP の違い(名前が似ているが全く別物) メール技術の歴史(後述) 34
SMTP サーバーは実際にはリレーされている 35
セキュリティソフト入りの場合 36
メール認証 37
メール技術の歴史 ― Web より20 年先輩である 年 出来事 1971 ARPANET 上で最初のネットワークメール送信(
@ 記号の誕生) 1982 SMTP が標準化(RFC 821 ) 1984 POP が登場 1986 IMAP の原型が Stanford で開発 1989 Tim Berners-Lee が WWW を提案(← ここでやっとWeb 登場) 1991 WWW 一般公開 / 1997 HTTP/1.1 標準化 メールが設計された時代は常時接続が当たり前ではなかった 「送る」と「溜めて取りに行く」を分けたのは、当時の環境では自然な設計だった 38
なぜ古い設計が今も使われているのか 例えるなら「ガラケー時代の設計が、スマホ時代でもそのまま現役」という状態 変えられない理由 世界中の何十億ものメールサーバーがSMTP で相互接続している 1 台でも新プロトコルに対応しなければ、メールが届かなくなる → 全員が一斉に切り替えないと移行できない(事実上不可能) その代わりに行われていること
SMTP 自体は変えず、上に認証や暗号化を後付けしている TLS (暗号化) 、SPF / DKIM / DMARC (認証) Gmail や Microsoft 365 も、裏側では1982 年のSMTP で通信している 基本設計が古いからこそ、SPF/DKIM/DMARC などの「補強技術」が必要 39
EOF ありがとうございました 40