Spamhaus に登録されてしまったら通知する仕組みをAWS サーバレス構成で作ってみよう(前編)

こんにちは、SCSKでテクニカルエスコートサービスを担当している兒玉です。
自社のサービスの情報などを メールで配信されている方はかなり多いのではないでしょうか。

そんな メール 配信をお仕事の一部とされている人の悩みの一つが、自社の配信システムがSPAM配信者としてマークされてしまって配信不能になってしまうことです。

もちろんそこに登録されないように不達メールを投げないようにメーリングリストの対象をメンテナンスしたり、DKIM、DMARCなどの仕組みを導入したりはもちろん行っていると思いますが、その上でもどうしても登録されてしまった場合に気が付けないと何のアクションも取ることができません。毎日人手をつかって確認するのも大変なので、AWSで自動化してみようということにしました。

本記事(前編)では、生成AIを活用して要件定義から設計、実装計画を立てるまでを解説します。

事前調査

自分のIPアドレスが、Spamhaus の SBL (Spamhaus Blocklist) に登録されているかどうかは誰でも確認できます。

Attention Required! | Cloudflare
※商用利用には、Fair Use Policyに基づくライセンスが必要です。
Spamhaus DNS Blocklists Fair Use Policy

 

調査を進めて行って、わかったことをファイルに雑多にまとめていきます。 

Kiro に要求を伝える

まとめたファイルと、それを整理してやってほしいこと、使ってもらいたい言語や環境を整理します。

# Spamhaus に登録されている場合に通知をする仕組みをAWSサーバレスで構築

## 目的

ダイレクトメール送信サービスを運営しています。
Spamhausというスパムメールが送信されてくる IP アドレスなどのリストを管理している団体があるのですが、その団体が管理しているSBL (Spamhaus Blocklist) に自分のIPアドレスが登録されてしまった場合には、email に通知が来るようにしたいです。

## 仕様要件

調査は簡単にかつ安価に行いたいので、EventBridge で定期的(1時間に一回, パラメータで変更可能)に自分の使用している IP アドレス(複数)を Lambda 関数を使用して nslookup コマンドを使用して SBL (Spamhaus Blocklist) からの応答を確認して、登録されている場合には Amazon SNS 経由で email で管理者に通知するシステムを構築します。

- Lambda関数の言語は Python 3.13 とします。
- CloudFormationを使用してデプロイします。
- CloudShell からデプロイします。
- 作成されるリソースのうち、タグ付け可能なリソースにはコスト配分タグとして Cost: <指定されたコスト配分タグ名> を付けます。
- 問い合わせに必要な Spamhaus から払い出されるDQSキー(Data Query Service Key 、サービスへのクエリが誰からのものか特定するキーのようなもの、文字列)は Secrets Manager から取得する
 - CloudFormation テンプレートでは、Secrets ManagerのString値としては "CHANGE-YOUR-DQS-KEY-LATER" として作成し、デプロイ後別途変更することとする。
- パラメータとして以下の値を指定します
- IP アドレス(単数あるいは複数)
- 調査間隔 n 時間間隔(時間単位、デフォルトは1時間間隔)
- リソースの タグ名 Cost につける コスト配分タグ名>
- リソースのNameタグの Prefix として付与される prefix (10文字以内-長いと制約に引っかかってエラーになるリソースが出るため)

DNS問い合わせの仕組みなので大丈夫だと思いますが、連続して問い合わせを行うとこちらがスパマー認定されてしまっては困るので、複数IPアドレスに対する問い合わせの場合には 1秒 待ちを入れることにします

## DQS Keyの形式

abcdefghijklmnopq123456789
のような形式です。

## DQS Keyを使用した問い合わせ

nslookup [逆順IP].[DQS_KEY].[リスト名].dq.spamhaus.net
ですが、今回は SBL(Spamhaus Blocklist)が対象なので、

```bash
nslookup [逆順IP].[DQS_KEY].sbl.dq.spamhaus.net
```

となります。


### サンプル応答

#### OK応答例(SPAM IPと判定されていない)

```bash
$ nslookup 109.62.249.54.[DQS_KEY].sbl.dq.spamhaus.net
Server: 127.0.0.53
Address: 127.0.0.53#53

** server can't find 109.62.249.54.[DQS_KEY].sbl.dq.spamhaus.net: NXDOMAIN
```

#### NG応答例(SPAM IPと判定されている)

```bash
$ nslookup 2.0.0.127.[DQS_KEY].sbl.dq.spamhaus.net
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: 2.0.0.127.[DQS_KEY].sbl.dq.spamhaus.net
Address: 127.0.0.2
```

## ブロックのリターンコード

各ブロックリストのリターンコード
SpamhausのDNSBLでは、異なるリストに対して異なるリターンコードが使用されます:

リスト リターンコード 意味
SBL 127.0.0.2 スパム送信源
CSS 127.0.0.3 低評価送信者
XBL 127.0.0.4-127.0.0.7 乗っ取られたホスト
PBL (ISP提供) 127.0.0.10 ISPが提供したポリシーリスト
PBL (Spamhaus) 127.0.0.11 Spamhausが推定したポリシーリスト
DROP 127.0.0.9 悪意のある組織(SBLと併用)


# 参考資料

spamhaus_pre_survey.ini に、事前調査した結果を配置しました。

このテキストを、Kiro に伝えます。Spec Mode を選択するのを忘れずに。

Kiroが要件ドキュメントを作成

しばらく考えて、要件ドキュメント(requirements.md)を作成してくれます。用語集も作成してくれるのが初めてこのドキュメントを見ることになる人にとっては嬉しいのと、日本のシステムの仕様書などにはあまり書かれない ユーザーストーリー が書かれているのが嬉しいですね。これは誰がどうしたいためのシステムだとわかりやすく、また、後日見たときに ”この機能は何のために入ってるんだっけ?” という判断をする際にも有用です。
英語で作成してくれますが、LLMなので、日本語に翻訳してもらうこともできます。せっかくなので別ファイルで翻訳もしてもらいました。
英語と日本語の requirements を見比べていて気が付きました。英語の方は WHEN …, The System SHALL … という形式になっていて、やること、誰が、どんなときにするのかわかりやすい気がします。日本語でもその訳文なので、…のときシステムは…しなければならない となるのですが、記法を縛らない限り日本語では主語がなくても違和感がないので、勘違いしないように読むのはなかなか大変なこともありますが、記法がはっきりしている英語版のほうがわかりやすいかもしれません。あと、 “SHALL” “WHEN” “THE System” が大文字になっていて見やすいんです。
無理やり日本語でも使おうとすれば、

WHEN レートリミット超過が発生したら, システム SHALL exponential backoff ロジックでリトライする。

とかにするか、”のとき” “システムは” “しなければならない”を太字にするとかでしょうか。日本語だと少し不自然な表現になることもありますが、構造を理解するには英語版の方が適していると感じました。
要件ドキュメントをレビューして、OKなら、Move to Design phase ボタンで次に進みます。

設計ドキュメントの作成

要件ドキュメントから、Kiro が 設計ドキュメント(Design.md)を作成してくれます。

設計ドキュメントでは、テキストベースで図を記載する事のできる Mermaid 記法という記法でアーキテクチャ図を記述してくれます。
Kiro に Markdown Mermaid 図の preview 機能拡張を追加して preview することで図として表示してみることができます。

Kiro が作成したアーキテクチャ図

テキストだけの説明だとこの図を頭に浮かべるのは難しいので、Mermaid図化してくれるのありがたいですね!
これを見るだけでわかった気になれます。
設計ドキュメント(design.md) を見て足りないと思ったところがあれば、追加を指示します。問題なければ Move to implementation plan ボタンで次の工程に進みます。
Kiro の 設計ドキュメント作成とその承認

設計ドキュメントを元に、実装計画(tasks.md) を作成してくれました。
ここでは、 コア部分のみのタスクを実装するか、全タスクを順に実装していくのかを選択できます。
全タスクの実行にはそれなりに時間がかかるので、さっと作りたいときはコア部分のみ(Keep optional tasks(faster MVP))を選択します。
後から全部実行したり個別に実行したりもできるので、この時点でどちらか決まってしまうというわけではありませんので安心してください。

 Kiro が実装計画(Tasks)を作成

今回はここまで。

タイトルとURLをコピーしました