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
68
Gmailに届け
2024/2/1 Omotesando.rb
tosio
February 15, 2024
Tweet
Share
More Decks by tosio
See All by tosio
断頭台の大魔族がつながりレシピをお勧めしてくれるLINEbot
tosiooooooo
0
1k
ソースコードのソースコードを読みたい
tosiooooooo
0
230
Other Decks in Technology
See All in Technology
Engineer Career Talk
lycorp_recruit_jp
0
190
AIチャットボット開発への生成AI活用
ryomrt
0
170
SSMRunbook作成の勘所_20241120
koichiotomo
3
160
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
AI前提のサービス運用ってなんだろう?
ryuichi1208
8
1.4k
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
9
1.1k
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
EventHub Startup CTO of the year 2024 ピッチ資料
eventhub
0
120
Lexical Analysis
shigashiyama
1
150
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Code Reviewing Like a Champion
maltzj
520
39k
BBQ
matthewcrist
85
9.3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
The Language of Interfaces
destraynor
154
24k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
The Invisible Side of Design
smashingmag
298
50k
GitHub's CSS Performance
jonrohan
1030
460k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
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メール使うのやめようぜ