スモールビジネスのIT日誌

• (2022-07-15 11:13:35)

3ヶ月前に投稿した「Gmail、SPFレコード不備で巨大バナー警告」の続き。

アラートはまだ一部続いていた

3ヶ月前の対策ではSPF設定で一段落したと思っていたが、まだこの "なりすまし警告アラート" が表示される人がいることがTwitterで間接的にわかった。

Twitterにてそういう投稿をしている人がいた。

当社でテストする範囲では再現性がない。

何かのまちがいでないのか、という疑問もあるし様子見だった。

様子見

「様子見」とは多くの場合、そのまま放置し忘れるというケースが多いが、このパターンだった。

ところが今回は「エラーがでているので心配になって電話しました」という人がいて、これは本物と判断した。

しかも、その人の証言からクレジット決済の確認メールがそうなったという具体的な事実が判明した。

この瞬間に、これはクレジット決済代行会社さんのメールサーバーの問題だとすぐに気づいた。

再現テスト

実際に再現テストをやってみた。gmail.comのアドレスで決済し、その決済確認メールをgmail.comで確認するとこんな感じ：


( Gmail画面 )

このメールのヘッダ情報を見ると明確にSPFエラーが記録されていた。見やすくするために抜粋すると・・

Return-Path: <○@○○.jp>
Received: from (○○○○.jp. [210.○.○.○])
by mx.google.com with ESMTPS id xxxxx
Received-SPF: softfail (google.com: domain of transitioning ○@○○.jp does not designate 210.○.○.○ as permitted sender)


「Received-SPF: softfail」になっている。 (○○○○.jp. [210.○.○.○]) の部分が決済会社さんのもの。このIPかFQDNをSPFに追加すれば、この問題はクリアされるだろう。

SPF設定の漏れ！

決済確認メールは決済会社から送信されるが、「Return-Path:」と「From:」が当社メールアドレスとなっており、当社から送信されたかのようになっている。

ここをGmailに叱られているのだろう。

このときはじめて「Return-Path:」と「From:」が当社メールアドレスである事実に気づき、SPF設定にて、この会社のメールサーバー設定を入れていなかったことを反省した。

決済会社さんの対応

設定すべき内容は上のメールのヘッダ情報内にあるが、念のため決済会社さんに「SPFに登録すべき、貴社メールサーバのIPアドレスか FQDN を教えて欲しい」と連絡すると翌日には返信が来た。

速い対応に感謝した。

しかし、決済会社さんにとってはこのトラブルは当社だけでなく多くのクライアントで発生している問題だろうし、エンジニアがいない小さな会社では困惑し途方に暮れているに違いない。

なぜ決済会社から案内してくれないのか？それくらいの配慮あっていいのでは？・・と思わないこともなかった。

(しかし、そういう案内を出すと、SPF設定サポートの問い合わせや要望がくる。自分たちの仕事でないという気持ちが強かろう、だからそこはあえて触れない・・これが本音じゃないかな・・サポートをどこで線引きするかは難しい問題である)

とりあえず、SPFを設定し直した。これで様子を見たい。

自分が悪い

この一連のトラブルのミスは設定漏れを見過ごした自分にある。

クレジット決済結果の通知メールが当社メールアドレスで送信されていたことに気づいていなかったこともミス。

(こういうことがあるので、システムは本当にシンプルにして他社さんのシステムが自社内のシステムに入り込まないことが一番だと思う)

Twitterで「アラートがでている」というツイートを見たときに気づくべきだったと思う。

兆候を見逃してしまった。

兆候の段階で対応することが一番コストエフェクティブである。