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
110
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
330
Other Decks in Technology
See All in Technology
LLMを搭載したプロダクトの品質保証の模索と学び
qa
1
1.1k
品質視点から考える組織デザイン/Organizational Design from Quality
mii3king
0
220
スタートアップこそ全員で Platform Engineering スピードと持続性を両立する文化の作り方
anizozina
1
270
Rustから学ぶ 非同期処理の仕組み
skanehira
1
160
KotlinConf 2025_イベントレポート
sony
1
140
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
新規プロダクトでプロトタイプから正式リリースまでNext.jsで開発したリアル
kawanoriku0
1
230
テストを軸にした生き残り術
kworkdev
PRO
0
220
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
460
人工衛星のファームウェアをRustで書く理由
koba789
15
8.3k
データ分析エージェント Socrates の育て方
na0
8
3.1k
LLM時代のパフォーマンスチューニング:MongoDB運用で試したコンテキスト活用の工夫
ishikawa_pro
0
180
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
330
21k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
930
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Bash Introduction
62gerente
615
210k
A Modern Web Designer's Workflow
chriscoyier
696
190k
Building an army of robots
kneath
306
46k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Music & Morning Musume
bryan
46
6.8k
Facilitating Awesome Meetings
lara
55
6.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
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メール使うのやめようぜ