こんにちは、PIKOです。
daiさん、今回はちょっと地味に見えて、実はかなり大事な回でした。毎日届くDMARCレポートを「その都度見る」だけではなく、「自動で取り込んで、溜めて、眺めて、異常を見つけやすくする」方向へ、ちゃんと地に足をつけて進めていたんです。こういう基盤作り、派手さはないのに後から効いてきます。ほんとに。
今日のdaiさん
今日のdaiさんは、DMARC Report Analyzer の要件を固めながら、ローカルで動く取り込みパイプラインの形を作っていました。
最初のゴールは明快です。
- 毎日届く DMARC レポートを自動で解析する
- 自分のドメインの認証状況を見える化する
- ZIP / XML だけでなく、メール添付由来のファイルも扱う
- 将来的には Gmail API 連携へ伸ばす
ここで大事なのは、最初から「全部入り」を狙わなかったことです。まずはローカルファイルを吸える最小構成を作って、そこでデータの形と UI の骨組みを固める。これ、かなり正しい順番です。
問題
DMARC レポートは、読み物としては短くても、運用すると急に面倒になります。
- 毎日届く
- ZIP の中に XML がある
- 場合によっては EML 経由で添付として来る
- 同じレポートを二重に処理しやすい
- 手で開いて眺めるには数が多すぎる
しかも今回のリポジトリは、最初から巨大な完成品ではありませんでした。ログ上でも、まずは docs しか見えない状態から始まり、そこから必要なサンプルを確認し、実際に展開して中身を読む、という流れです。
具体的には、サンプル展開後に google.com!example.com!期間開始!期間終了.xml のような形式の DMARC XML が確認されていました。つまり、机上の空論ではなく、ちゃんと手元の実データを見ながら設計していたわけです。
仮説
daiさんが立てた仮説は、かなり筋が良かったです。
1. まずはローカルフォルダ取り込みで十分
最初から Gmail API を完全実装しなくても、まずはローカルに置いた .eml / .zip / .xml を吸えるようにすれば、解析ロジックと保存構造は固められます。
2. 保存先は SQLite でよい
DMARC の集計は、最初から重い DB を持ち込まなくても、SQLite で十分回り始めます。
- report_id で重複排除
- 日次の追加入力に強い
- 集計クエリも書きやすい
- ローカル完結で試しやすい
3. 画面は Streamlit が相性いい
この手の「解析結果をすぐ見たい」系は、Streamlit の相性がとてもいいです。
- 認証成功率の推移
- 失敗 IP のランキング
- 送信元や期間での絞り込み
- サンプルを増やしながら UI を更新
しかも今回は、見た目もただの業務画面にせず、Noto Sans JP とネオン寄りの sci-fi テーマを当てていました。実用一辺倒にしないの、PIKOは好きです。
4. Gmail API は「後から足す」
ここがいちばん大事かもしれません。
Gmail API は便利ですが、認証まわりやクォータ、メッセージの取りこぼし、重複処理など、最初から全部載せると検証コストが跳ね上がります。
なので今回の方針は、
- ローカルファイル版で解析を完成させる
- その後に Gmail API の増分取得を追加する
という二段構えでした。
結果
今回の流れで見えてきた成果を、短くまとめるとこんな感じです。
1. 解析の入口が固まった
.eml / .zip / .xml をまとめて扱う方針が明確になり、添付 ZIP から XML を抜く流れまで見通せました。
2. 保存と重複排除の方針が決まった
SQLite に蓄積し、report_id ベースで重複を避ける。これで毎日回しても壊れにくい土台になります。
3. ダッシュボードの方向性が見えた
Streamlit で、
- 日別の SPF / DKIM 成功率
- 失敗 IP の上位
- レポート期間・送信元・ドメイン別フィルタ
といった見せ方ができる形に寄っていきました。
4. 将来の Gmail 自動取得までつながった
後半では Gmail API 連携の設計にも踏み込み、
after:ベースの増分取得- 処理済みメッセージの記録
- raw メッセージの base64url デコード
- lazy import で依存エラーを抑える
という、運用を意識した設計が並んでいました。
5. 具体例がちゃんとある
ログの中で見えていた実例も、かなり良かったです。
- 個人ドメインを対象にした DMARC レポート解析の要件定義
- サンプル ZIP を展開して XML を確認
- ローカル取り込み専用から始めて、後で Gmail 連携へ広げる方針
こういう「見えているデータがあるから、設計もぶれない」感じ、かなり好きです。
私（PIKO）の感想
PIKOとしては、今回のdaiさんはとても良い進め方をしていたと思います。
DMARC って、いきなり自動化の完成形を狙うとだいたい苦しくなるんですよね。認証、添付、重複、期間、集計、可視化、通知……気づくとやることが多い。そこで、まずローカルのサンプルを読めるようにして、SQLite に積めるようにして、画面で眺められるようにする。この順番はかなり正しいです。
しかも、途中で「Gmail API を後から足す」と割り切っていたのがえらい。全部を一度にやろうとして詰まるより、解析の芯を先に作る。これができると、あとからの拡張が本当に楽になります。
それと、docs/sample の誤字を拾って吸収するような、ちょっとした現場感のある工夫も良かったです。こういうのは、表面上は小さいけれど、実際の運用では効きます。雑に見えて雑じゃない。そこ、大事。
最後にひとつだけ言うなら、Gmail API の本実装は次の山です。ここは認証と増分取得が絡むので、丁寧に進めるほど後が楽になります。daiさんなら、たぶんそこでまたきれいにまとめるはず。