Scribble at 2024-04-07 23:12:02 Last modified: 2024-04-07 23:14:52

このところ５年ほど、受託案件でフォームをつくるときは index.html にエラー画面と確認画面を一緒にコーディングして JavaScript で切り替えるというコードを書いていたのだが、今回のコーポレート・サイトで改修する問い合わせフォームでも同じ方針を維持する。セッションでいたずらや RPA 野郎を排除するのは、最終の PHP でやるわけだし、どのみち自動投稿のプログラムは submission の最終フローに向かって POST のデータを投げてくるに決まっているからだ。まぁ、index.html から初めて、人が入力するのと同じ手順で１ページずつブラウザの自動制御で投稿してもいいし、そういう疑似送信をやる RPA ツールや自称マーケティング・ツールもある。

昔話になるが、似たようなことは20年前に僕も PHP で実装して、「１ページめにリクエストしたかのような疑似リクエストを投げる」→「２ページめに遷移したかのような疑似リクエストを投げる」・・・などとやって、ウェブ・アプリケーション開発の師匠みたいな人物に呆れられたこともあったが（ちなみに、その人は C 言語でウェブ・アプリケーションを書いていた）、20年前なら僕らのようなレベルのエンジニアにとっては簡単に思いつくアイデアだったわけだよ。そして、まともなプログラマというのは、思いついたことは実装できるものだ。だって、こうすれば相互リンク先のサイトに何百万アクセスでも送信できるんだから。１回めと２回めのリクエストのタイミングを最大20秒くらいの間隔以内でランダムにしたり、偽のリクエストを送る頻度もランダムにしておけば、ウェブ・サーバのログだけでは殆ど人なのかプログラムなのか区別はつかない。ちなみに、UA 文字列ですら幾つかのパターンからランダムで選んでたし、送信元は当然ながらランダムに選んだ国内のプロキシだ。今現在ですら、応用情報技術者ていどの知識しか無い人には区別できないであろう。（これは、或る意味ではチューリング・テストに対する皮肉にもなっている。）

ということで、もちろん DOS 対策なども必要なのだが、とにもかくにも毎日のように送信されてくるクズ営業メールの大半を、正当な理由でもってフィルタリングしたい。Google Chat で通知を受け取っている役員や他の部門長の仕事の邪魔にもなるし、場合によってはバカみたいな内容にいちいち反応してしまうことだってある。取引先や顧客などからの問い合わせやクレームは正しく受け取って対応しなくてはいけないのはもちろんだが、それ以外のメールなんて、はっきり言って 99.9999% はカスだ。それらを無視して致命的な機会喪失が起きるなんてことはないよ。それに、文面とか送ってくる頻度を見てると、だいたい同じようなメール DM 業者がやってるみたいだし。特に M&A と人材紹介とオフショア関連は、問い合わせの送信主体が違っていても、同じところから送られてるような気がする。（あるいは、同じ名簿屋のリストを使ってるかだ。）