メールアドレスはいかにして載せるべきか

2009/07/29 | めも

アドレスをエントリ内に打ってて思ったこと.

メールアドレス表記に細工して蒐集エンジンに拾われないようにすること,例えば

hoge◎example.com

が常識化してる気がするけど,個人的には試してもベタで書いてしまうのとあんまり違いを感じない.スパムフィルタが優秀だから気づかないとかではなくて,一時期ほど平に書いてあるアドレスに鬼の如くスパム送るってことがされなくなった気がする.実地に調査したデータみると面白そうだ.mailto つけとくとどの程度差が出るのか……とか興味ある.

で実際にそういう細工の効果の度合いについて推測してみると, @ を☆とかアットとか [at] とかにしたところで,そういう文化はスパマーさんもご周知な以上,ちょっとパターン調べてちょっと正規表現弄るだけで手間というほど手間かけずに 8 割 9 割対応できちゃうし,さすがにそれくらいの脳味噌はもってる人たちだと思うんだよなぁ*1.ドメイン部分の調査に . を使っていることが多そうだから,それも [dot] なり _ なりにする,くらいすればどうかわからんけど.

そんなことするより, JavaScript が ON だとみなしていいモダンな環境ならメールアドレス部分をスクリプトでなんらか動的に書き出したりすれば問題なくなる話だとは思う.google ですら js で内容ゴリゴリ書き換わるページの扱いは考えあぐねてるくらいだし,ブラウザでスクリプト走らせてからソースの調査とかいう対策は効率の点からいってやらないだろうし*2,まあ 9 割 9 分 9 厘 9 毛安全.

それよりは認知度が高そうな,アドレスを画像にしておくっていう手はより簡単確実そうに見えて,そうでもない.CAPTCHA 破られまくってるし.

やるとすれば全ての画像を解析対象にするのは現実的じゃないので,メールアドレスが描いてありそうな画像ファイルに限定して読ませる……とかやるのかな.その絞り込み条件は画像サイズ*3*4とか,それらしいファイル名*5の辞書作るとかでそれなりの精度が出そう.で,いざ OCR な段になれば対象はきっとメールアドレスであるというバイアスの元に読めばいいので精度高そうだし,明らかに無理そうだこれ違う画像だろという判断も簡単.

……という風に素人でもなんとかできそうな程度には危ない.とはいえ単純に正規表現でガシガシ拾っていくのに比べれば実装がめんどいのと調査効率が落ちることの二点から現実的には問題ないが.

ただ画像ファイルにする方法は,メールアドレス毎に画像を用意するのが若干めんどい上に,コピペ不可能,実際にページの上に表示した際にもああこれ画像だなあという違和感,浮いた感じが拭えない*6等という欠点が目立つ.

JavaScript にやらせる方法なら一度スクリプト用意すれば画像をいちいち作る手間はないし,実際にブラウザで見る時には平にアドレスが書いてあるわけで自然.なんなら mailto でアンカーつけちゃっても問題ない.逆にこちらの欠点は JavaScript 切ってあると残念っていうこと.

総合するとブログのエントリだとか,wiki 内ページだとか,そういうテキストテキストした場所に自然かつ安全に埋めるには スクリプトに頑張ってもらうのがいいんでないかと思ったのが結論.

でもって大事なアドレスでもないしクライアントサイドでフィルタあるから別に拾われても構わんよという開き直りができるなら(俺はできる状況),そのままベタ書きすればいいだけの話.

  1. と思いきやメールアドレス収集ツール今だけ特価 39,800 円! とかを使っている残念な人ばっかだという話も聞く. []
  2. そんな一部の漏れにこだわってる暇があればより多くのページをクロールする. []
  3. デカすぎる画像はメールアドレスでない可能性が高い.ある程度以上に横長の画像がメールアドレスである可能性が高い. []
  4. 画像ファイルのピクセルサイズ調査は(jpeg gif png あたりの規格詳しく知らないので合ってるか知らんけど)画像ファイルの先頭 1KB くらい読めばヘッダ部から判断できそうなので画像を全てダウンロードするなんて馬鹿なことはしないで済むはず. []
  5. address とか mail とかでもうかなりの割合だろう. []
  6. これはフォント合わせてサイズ合わせてレイアウト頑張ってすれば改善はするだろうけどそんな馬鹿みたいなことは普通しない. []

Trackback URL

コメント (11) to メールアドレスはいかにして載せるべきか

カネゴン
2009/7/30 木曜日

アドレスに無意味な文字列を足して
1234567890address@gmail.com
としている人もいましたよ~

wh
2009/7/30 木曜日

アドレス中のほげほげは消してね,とか併記すればおkっていうわけね
誤ったアドレス掴ませてささやかな嫌がらせをすることができるっていう点で勝れているかもしれないw

ゲスト
2009/7/30 木曜日

実際にアドレス収集ツールだったりを作ってみようとか考えたりしますのん?

wh
2009/8/1 土曜日

信念としては邪悪なことは大嫌いで,目の敵にしてるくらいなのでやりませんね.実装想定してみて楽しむだけです.
仮に暇を持て余したとか,非常な興味を持ったとかで作ったとしても,一人でニヤニヤするだけで,公に晒してここは酷いインターネッツですねを加速させるつもりは毛頭ない感じ

くろば
2009/8/2 日曜日

前に言ってた「ワードサラダに『場所XXで人を殺す』文言を混ぜて勝手に掲示板に書き込むウイルス」は本当に感動した。実現すれば日本という国を破壊できると思う。

wh
2009/8/3 月曜日

山田系ウイルスをはじめ「掲示板に勝手に書き込むウイルス」自体は既に色々あるので,あとはパターンを特定されない程度に複雑な形でそれっぽい犯行予告文を生成する機構がつけばおしまいだね.
自分ではやらんけど誰かやってくれたら警察と世論がどう動くのかは気になる.


2009/8/4 火曜日

アドレスを改行使って縦書きにするってのはどうですか?

wh
2009/8/4 火曜日

強度と一般ユーザの利便性の両方の観点からみて、@ を☆に変えたりするのと同程度だと思います

くろば
2009/8/13 木曜日

http://www.suzukikenichi.com/blog/msnbot-reads-javascript-and-what-about-googlebot/
だってさ。まあスパマーさんのソフトウェアがそういうのに対応してるかは知らんのだが。

とりあえずこんな文を書いてみたりはした。
var strs=[’93;&#x30′,’3089;ぶ’,'&#x67′];strs.unshift(’07e;&#x30′,’71;&#x’);strs.push(’#x3′,’5927;&’,'4c;く&#x’); var strs2=[]; for (var i=strs.length-1; i>=0; i–) {strs2.push(strs[i]);} document.write(’「’+strs2[3]+strs2[6]+strs2[1]+strs2[2]+strs2[7]+strs2[5]+strs2[0]+strs2[4]+’」’);
javascript+数値文字参照 この程度なら天下のGoogle様なら読めるのだろうか。 これは手動で書いたけど、フォームで入力したら全文字を数値文字参照で分解して云々するスクリプトを出力、なんてのができたら面白そうですね。暇な時作ろっと。
ただ、どんなにJavascript解析や画像解析の技術進んだ所で、「必要な情報とそうでない情報を取捨選択」するのは当分bot程度にはできないだろうから、わざとtitleやらalt情報を混ぜ込んだdisplay:none;な画像挟んだり、文字解析プログラムが誤爆するようにアルファベット単体の画像ファイルも表示して「不要な画像を挟んでいます(コピー・ペーストすれば正しいメールアドレスを取得できます)」とか、んでそれらも全部一文字ずつ分解して↑みたいなスクリプトで出力とか、考えだすと面白くてキリないですね。

ゲスト
2009/8/18 火曜日

微妙に関係ないけど
オススメのキーロガー対策教えてくださいな

wh
2009/9/3 木曜日

>>くろば
へーそれは知らんかった.google 様にできないことはない! 俺信者乙です!
>この程度なら天下のGoogle様なら読めるのだろうか。
コードをメタに解釈するだけではなくて,解釈した上で想定される呼び出し順とか考えて実際に実行もしてみているなら,最後の document.write の引数が処理されたときにその文字列がクサいと判定されちゃうはずなので,その前段階でいかに複雑なロジックで文字列が生成されていようと関係ないと考えられるです.
こちら側がそれをも回避して,より難しくしようとするなら,一度に文字列をまとめて追加することはせず,また,全て追加しおわった状態の DOM を走査してもメールアドレスが出てこないような処理をすればいいんではないかと思います.
まあ「display:none;な画像挟んだり」と同じようなもんですが,例えばページの onload 時とか,該当タグの hover 時とかに分けて DOM 走査をしてバラバラに要素を追加していって,しかもその結果できあがる要素群が,例えば css から margin などをうまく調整されているから文字列として連続しているように見えるだけで,実際に DOM 上では遠く離れた要素であるようにするとか(コピペできないけど).
まあ思考実験としては面白いけど,実用レベルとして何か意味があるのかといわれればアレだよね(w

 
>>オススメのキーロガー対策教えてくださいな
ぶっちゃけキーロガーは現在の OS の仕組みからして排除しようのない,とてもやっかいなブツだと思います.小細工ではどうしようもない気がします.
ファイアウォールのポリシーしっかり管理して外部に持ち出されないようにするとか,キー入力をグローバルフックしてるアプリケーションそれぞれを検証するようなプログラムを導入するとか(最近のアンチウイルスソフトウェアならこれはやってくれているような気もする).
でもどちらもアドホックな対応で本質的ではないですね.OS 自体にユーザの物理的入力の管理ポリシーみたいな機能がつかないとどうしようもないんではないかと思います.

コメントをどうぞ