迷惑メールの中身を鑑賞しよう(3)Amazonからの『配⁠送​先情⁠報のご⁠確認・ご 修正‌のお願い』

ちょっとマジなメールをのぞいちゃったから、今日はもう少し笑えそうなものにした。
ざっと見ただけで、まだ中身の解析とかはしていない。
怖くない笑えるものだと良いな……。

さて、先ずは画像。

Amazonから配送先の不備メール
Amazonから配送先の不備メール

タイトルは『配⁠送​先情⁠報のご⁠確認・ご 修正‌のお願い』
送信者名は『【Amazon】』
で、AppleのMail.appはメーリングリストからと解釈した。
個別に送る筈なのに、メーリングリスト判定されちゃダメだろう。
画像の右下に見えるのは添付ファイル。
これをUTF-8で開いてみた。

添付ファイルををUTF-8として開く
添付ファイルををUTF-8として開く
次にUTF-16として開いてみた。
添付ファイルををUTF-16として開く
添付ファイルををUTF-16として開く
意味のない屑ファイルっぽいが、何の残骸が埋まっていたのだろうね、判らんな〜。
そして、文字列からチェックを受けないようにAmazonの文字はなく、画像を貼り付けている。
全体的にチャチなもんだわ。

当然ながらヘッダーを見てみる。

digest.dejinzdh.comは実際に存在し、日本のMicrosoftのレンタルっぽい。
但し、逆引きはできない。詰まり設定が中途半端であった。

メーリングリスト扱いされたのは、これのせいらしい。
List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
多分、他からの使い回しで、この辺りを全く弄っていなかったのだろう。

Received: from mail.36d7796.cloud ([171.81.174.214])
これも出鱈目なドメインと逆引きできないip addressであった。

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=au.com; s=au; t=1788302644;
h=Received:From:Reply-To:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding;
DKIMをauとして騙ったが、

と、docomoのサーバのチェックでdkim=fail header.d=au.com header.s=au;のようにFail判定されてる。
だけどその手前のサーバーではSPF、DKIM、DMARC共にPASSしてるからタチが悪いってか、頭悪いな。
態々auのDKIM偽装しなければ良いのにね。

このmail serverの受け取り順なんだけれど、
1.mail.36d7796.cloud ([171.81.174.214]) 中国
2.mail.62399f1.chiba.jp ([171.119.241.68]) 中国
3.digest.dejinzdh.com ([20.194.171.11]) 日本のMicrosoft(dejinzdh.comは中国)
4.mfsmax.docomo.ne.jp(ip複数のどれか)
で、最初のmail.36d7796.cloudが受け取ったのは、
Received: from mail.36d7796.cloud ([171.81.174.214])
(Authenticated sender: client114@digest.dejinzdh.com)
by mail.62399f1.chiba.jp (SendGrid Mail Service) with ESMTPSA id UZ9Z1ZIC-E2EF-2446-2AA1.1
for ;
TLS1_3, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (authenticated bits=0); Wed, 02 Sep 2026 07:43:58 +0900
と、digest.dejinzdh.comのアカウントなんだよね。
訳判らない、遠回りをしている。
こうやってみると、「mail.36d7796.cloudへ投げれば、どこか経由で何とかして貰える」ような流れ、若しくはmail.36d7796.cloudが複数のアドレスを持っているのかもしれない。
そこでアドレスの置き換えをして各々に配送するのかも。
こういったのは妄想が捗るね。
因みに中国の二つのサーバーは、どちらも逆引きも正引きもできない。つまり野良である。

で、最後のdigest.dejinzdh.com(逆引きはできない)だけはDMARC迄作り込んだ迷惑メール配送サーバーだと予想できるわな。

で、妄想する訳だ。
client114@digest.dejinzdh.com(差出人)はメール本文、タイトルを作ってダミーアドレスでmail.36d7796.cloudへ送信。
若しくはclient114@digest.dejinzdh.com込みでmail.36d7796.cloudが作っているのかもしれないが……その辺は判らん。
Received: from mail.36d7796.cloud ([171.81.174.214])
(Authenticated sender: client114@digest.dejinzdh.com)
by mail.62399f1.chiba.jp (SendGrid Mail Service) with ESMTPSA id UZ9Z1ZIC-E2EF-2446-2AA1.1
for ;
TLS1_3, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (authenticated bits=0); Wed, 02 Sep 2026 07:43:58 +0900
と、あるように、
SendGrid Mail Serviceってのはメルマガ等の「同一文を一斉配送」するシステムらしい。(Google AIさんによる)
そこで出来上がった大量のメール群を、digest.dejinzdh.com経由で一斉放流するって全体のシステムっぽい。

これを作った人は凄いって思えるけれど、運用的にね。
List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click
残してメーリングリストになっちゃってたり、ゴミ(qt9daevJsh.gdq)が残っていたり、au騙って失敗してたり。
末端が流れをさっぱり判っていないってことだねぇ。
と、いうのが今回の感想でした。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)