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
Gmailに届け
Search
tosio
February 15, 2024
Technology
0
52
Gmailに届け
2024/2/1 Omotesando.rb
tosio
February 15, 2024
Tweet
Share
More Decks by tosio
See All by tosio
断頭台の大魔族がつながりレシピをお勧めしてくれるLINEbot
tosiooooooo
0
910
ソースコードのソースコードを読みたい
tosiooooooo
0
160
Other Decks in Technology
See All in Technology
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
devops_vtj
6
3.2k
エンジニア向け会社紹介資料
caddi_eng
14
220k
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
720
MySQLのロックの種類とその競合
yoku0825
6
1.6k
頼られるのが大好きな 皆さんへ - 支援相手との期待の合わせ方、突き放し方 -/For_people_who_like_to_be_relied_on
naitosatoshi
1
290
ここがすごいよ! AWS Systems Manager!
saichan11
0
1.8k
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
630
LINE WORKSへ簡単通知!Incoming Webhookアプリの紹介
mmclsntr
0
110
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
「単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる」のか検証してみた
terara
0
380
Featured
See All Featured
How GitHub (no longer) Works
holman
305
140k
WebSockets: Embracing the real-time Web
robhawkes
59
7.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
42
2.7k
How to Think Like a Performance Engineer
csswizardry
4
590
The Cult of Friendly URLs
andyhume
75
5.9k
KATA
mclloyd
20
13k
Into the Great Unknown - MozCon
thekraken
20
1.3k
Statistics for Hackers
jakevdp
792
220k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
GitHub's CSS Performance
jonrohan
1026
450k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
A Tale of Four Properties
chriscoyier
155
22k
Transcript
2024/2/1 Medley.inc Yuji Tamai Gmailに届け
(引用)https://news.yahoo.co.jp/articles/b958c2ddf8ec356c4f2a3043aa8dfb50159d5f7f
神奈川県公立高等学校入学者選抜インターネット出願システム とは 従来アナログで行ってきた、願書提出→ 受験料支払い→受験票受け取り→合格 発表→入学料支払い、をネット上で完結 するシステム
経緯
1/10 gmailに届かない障害の報告が出る。おそらくこの日にローンチ。 1/11-15 障害が回復しない報告が続く。 (引用)https://www.pref.kanagawa.jp/docs/dc4/system.html
1/16 SNSでバズり始める (引用)https://togetter.com/li/2296622
1/13にもう結論出てた (引用)https://kanagaku.com/archives/69326
Eメールのセキュリティの歴史 • 創世記はザル、なりすましし放題だった • スパムメール、ウィルスメールが横行する • 2000年: 「OP25B」(Outbound Port 25
Blocking)という概念ができる • 2004年: DNSにSPFレコードという送信元情報を乗せる仕組みができる • 2007年: DKIMというEメールの公開鍵認証ができる • 2007年: IPレピュテーション、ドメインレピュテーションという価値観ができる ◦ レピュテーション=評判 • 2012年: DMARCという受信レポートを受け取れる仕組みができる
SPF(Sender Policy Framework) (引用)https://ent.iij.ad.jp/articles/172/ 「このサーバから送信します」の設定。これはなされていた🟢
DKIM(DomainKeys Identified Mail) (引用)https://ent.iij.ad.jp/articles/172/ メールの公開鍵認証設定。これは1/16時点でされていなかった❌
DMARC(Domain-based Message Authentication、Reporting and Conformance) (引用)https://ent.iij.ad.jp/articles/172/ "v=DMARC1;p=quaranti ne;pct=25;rua=mailto:dma
[email protected]
nkanagawa.jp"
受信サーバに対するポ リシー違反に対する指示 設定は隔離
最初の問題はこれだったのでは
1/17 DKIMの設定がされ、MXレコードの設定が正しくなる。 1日5000通未満にするためか、送信ドメインが3つになる。 これはまずいのでは🤔 (引用)https://twitter.com/ockeghem/status/1747541684312011163
None
公式が「似たような3パターンのドメインから送る」仕様にしてしまうと、 第三者が似たようなドメイン取って悪さしやすくなるのでは?
公式 shutsugankanagawa.jp のwhois
syutsugankanagawa.jp のwhois
nyushi-kanagawa.jp のwhois (公式は nyuushi-kanagawa.jp) あやしい
SPF、DKIM、DMARC ちゃんと設定したんだったら、 ドメイン3分割しなくてもよかったのでは?🤔
1/19 SPFレコードが "v=spf1 include:spf.baremetal.jp -all" 現在 SPFレコードが "v=spf1 include:spf.baremetal.jp include:spf.aams5.jp -all"
Eメール配信サービスを使う理由 IPスロットリング • Eメールの送信元IPに対して制限をかける受信メールサーバの機能 • 1分間に〜通まで、1時間に〜通まで、1日に〜通まで などの制限がある • 制限はサービスによってまちまち。公開していない。 •
新規のIPはめちゃめちゃ厳しい ◦ 1時間に60通くらいしか送れない • 一度ブロックされると数時間受け取ってもらえない ◦ お願いするとちょっと早く受け取ってくれる • 特に厳しいところ ◦ Gmail ◦ Apple系(icloud.com, me.com, mac.com) ◦ Microsoft系(outlook.com, hotmail.com, mns.com)
IPスロットリングを避けるIPウォームアップ • 時間をかけてちょっとずつ送信数を増やす • IPレピュテーションをあげる (引用)https://twilio-cms-prod.s3.amazonaws.com/documents/Generic_IP_Warmup_Schedule.pdf
Amazon SESでもIPウォームアップは対応している (引用) https://aws.amazon.com/jp/about-aws/whats-new/2017/03/amazon-ses-can-now-autom atically-warm-up-your-dedicated-ip-addresses/
(引用)https://xtech.nikkei.com/atcl/nxt/news/24/00109/ (引用)https://www.pref.kanagawa.jp/docs/dc4/system.html
結論 Eメール使うのやめようぜ