アカウント名:
パスワード:
フィッシングドメインからのホモグラフ電子メールアドレスとアドレス帳のホモグラフ対象メールアドレスとを文字列判定をせず画像判定していますってことなんですかね？
# なかのこびとさんもたいへんだんだよー
正規化処理を挟んでるんじゃないかと思うけど、なぜそこに入れた? という疑問が。
そりゃ、例えば日本だとメールアドレスを全角で登録するような人がいるから、でしょ。
たとえメールアドレスに全角を入れたとしても、よく似た文字を使った別のメールアドレスを同じものとして扱う必要は一切ないんだが。同一視するのがうれしいケースがあるとすれば、手入力した文字列でメールアドレスを検索するときくらい。文字列検索用のロジックをメールアドレスの同一判定にまで適用する意味があるのはどういう時なのか知りたい。
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。だから、校合はともかく必要なの。
で、受信者の正規化のアルゴリズムと送信者の正規化のアルゴリズムが違っている場合は、このストーリーみたいな話が起こりうる。手書きとかOCRとか、そういう問題ではないと思うよ。
必要なのはそうだけど、どうなってたら一致と見做すかはメールの規格で決まってるんだから、それ用のアルゴリズムを使ったら良い話ですよね。やり方は、メールサーバを作ったことがあるような企業だったらどこでも知ってるはず。
あるいは元々そうしてたけど、アホなユーザから「アドレス帳に(全角英数字で)入れてるのが候補に出ないんだけど!」とクレームが来て、ユーザ本位な企業体質から言われるままに対応しちゃったとかですかね。
…それよりは、最初からメールアドレスの仕様も何も考えず、とりあえず何かやるときは使うことになってる「アプリ組み込みタイプのAccessDBライブラリ」をそのまま持って来ちゃってて、その万能過ぎる検索性能のせいでやらかす仕様になってたのが後々問題になって来た、という方がありそうですかね。
まぁこの件はMSの実装がオカシイだけですね。
なんというか iso-8859 系話者は case-insensitive な文字列比較が好きなんだけど、それと同様に似た文字を合致させる(ウムラウトを無視してヒットさせたりする）機能をドメイン名にまで何も考えずに適用してしまっているんでしょうね。
Google検索でもウムラウトとか無視して検索してくれますからね。我々みたいなウムラウトってどうやって入力するんだ、みたいな人からすると便利っちゃあ便利な時はあるんだけども。
個人的にこれ系の実装でいままで一番びっくりしたのは寿司＝ビール問題とかよりもOracle のパスワード比較で case-insensitive だったところですね…
ウムラウトならまだ見て分かるが、ギリシャ文字のοとかキリル文字のоとかになると、本当にラテン文字のoと区別がつかないからね。
Oracle使うユーザーは昔のやつ一切手を入れずそのまま動かせるのが条件みたいなのが多いから…
一文字でも変更必要だと、それにかかる費用を請求するから担当呼べ！とマジで逝ってると思えるヤツも実際いたし。
セキュリティ的な問題を無視して互換重視みたいなのは設定で切り替えできるようになってると良いな。
向こうからすると、「へ」「べ」「ぺ」と「ヘ」「ベ」「ペ」は違う文字だ！と信じている日本人のほうがクレージーに見えたりして。
↑かいてるうち関連リンクの
メルぺイが一部加盟店で利用制限へ。フィッシングメール急増のため
が変だと、いま気づいた。
Oracleについては、いまはそうなってますね
シ ツ ン ソ みんな同じじゃないですかー
英語圏でもAとÄ Â Åは同じだと思われてるんじゃないのか
送信者なんていくらでも偽装できるのだし送信者がアドレス帳にある人と同一だと判定しなければならない理由がいまいちわからないなぁ。
勝手に表示を省略して変更しちゃう機能が邪魔だとしか思えないんだけど、どんなメリットが有るの？
# あれ一度間違ってキャッシュされると、なんかコマンドでクリアするんでしたっけ？
日本だとそう多くはないのだが、ラテン文字圏だと、似たような名前や同姓同名が結構いる。間違えても社内ならまだいいが、社外だと洒落にならんことがある。そういう間違いを防ぐために、アドレス帳の顔写真の代わりに会社のロゴを登録しておくと、少なくとも送信者は瞬時に判別できる。当然のことながら、稚拙な偽装アドレスも見抜ける。
もちろん、偽装されている可能性はあるけど、アカウントを乗っ取られていることもあるし、乗っ取りや偽装がなくても送信者の不注意による危険なメールの転送もあり得るから、基本的には本文や添付ファイルの形式・サイズなどの妥当性で判断するしかない。
そして、メールアドレスを精査するのは、怪しいと判断したときだけ。メールアドレスだけで判断できる眼力は俺には無い。
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。
Gmail の . の扱いに対応しなきゃとか、色々あったのかも知れませんね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
すげー実装だ (スコア:1)
フィッシングドメインからのホモグラフ電子メールアドレスと
アドレス帳のホモグラフ対象メールアドレスとを
文字列判定をせず
画像判定しています
ってことなんですかね？
# なかのこびとさんもたいへんだんだよー
Re: (スコア:0)
正規化処理を挟んでるんじゃないかと思うけど、なぜそこに入れた? という疑問が。
Re: (スコア:0)
そりゃ、例えば日本だとメールアドレスを全角で登録するような人がいるから、でしょ。
Re:すげー実装だ (スコア:0)
たとえメールアドレスに全角を入れたとしても、よく似た文字を使った別のメールアドレスを同じものとして扱う必要は一切ないんだが。
同一視するのがうれしいケースがあるとすれば、手入力した文字列でメールアドレスを検索するときくらい。
文字列検索用のロジックをメールアドレスの同一判定にまで適用する意味があるのはどういう時なのか知りたい。
Re:すげー実装だ (スコア:2, 参考になる)
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。だから、校合はともかく必要なの。
で、受信者の正規化のアルゴリズムと送信者の正規化のアルゴリズムが違っている場合は、このストーリーみたいな話が起こりうる。手書きとかOCRとか、そういう問題ではないと思うよ。
Re: (スコア:0)
必要なのはそうだけど、どうなってたら一致と見做すかはメールの規格で決まってるんだから、それ用のアルゴリズムを使ったら良い話ですよね。
やり方は、メールサーバを作ったことがあるような企業だったらどこでも知ってるはず。
あるいは元々そうしてたけど、アホなユーザから「アドレス帳に(全角英数字で)入れてるのが候補に出ないんだけど!」とクレームが来て、
ユーザ本位な企業体質から言われるままに対応しちゃったとかですかね。
…それよりは、最初からメールアドレスの仕様も何も考えず、
とりあえず何かやるときは使うことになってる「アプリ組み込みタイプのAccessDBライブラリ」をそのまま持って来ちゃってて、
その万能過ぎる検索性能のせいでやらかす仕様になってたのが後々問題になって来た、という方がありそうですかね。
Re:すげー実装だ (スコア:2)
まぁこの件はMSの実装がオカシイだけですね。
なんというか iso-8859 系話者は case-insensitive な文字列比較が好きなんだけど、
それと同様に似た文字を合致させる(ウムラウトを無視してヒットさせたりする）
機能をドメイン名にまで何も考えずに適用してしまっているんでしょうね。
Google検索でもウムラウトとか無視して検索してくれますからね。
我々みたいなウムラウトってどうやって入力するんだ、
みたいな人からすると便利っちゃあ便利な時はあるんだけども。
個人的にこれ系の実装でいままで一番びっくりしたのは寿司＝ビール問題とかよりも
Oracle のパスワード比較で case-insensitive だったところですね…
[Q][W][E][R][T][Y]
Re: (スコア:0)
ウムラウトならまだ見て分かるが、ギリシャ文字のοとかキリル文字のоとかになると、本当にラテン文字のoと区別がつかないからね。
Re: (スコア:0)
Oracle使うユーザーは昔のやつ一切手を入れずそのまま動かせるのが条件みたいなのが多いから…
一文字でも変更必要だと、それにかかる費用を請求するから担当呼べ！とマジで逝ってると思えるヤツも実際いたし。
Re: (スコア:0)
セキュリティ的な問題を無視して互換重視みたいなのは設定で切り替えできるようになってると良いな。
Re: (スコア:0)
向こうからすると、「へ」「べ」「ぺ」と「ヘ」「ベ」「ペ」は違う文字だ！と信じている日本人のほうがクレージーに見えたりして。
Re: (スコア:0)
↑かいてるうち関連リンクの
メルぺイが一部加盟店で利用制限へ。フィッシングメール急増のため
が変だと、いま気づいた。
Re:すげー実装だ (スコア:1)
Oracleについては、いまはそうなってますね
[Q][W][E][R][T][Y]
Re: (スコア:0)
シ ツ ン ソ みんな同じじゃないですかー
Re: (スコア:0)
英語圏でもAとÄ Â Åは同じだと思われてるんじゃないのか
Re: (スコア:0)
送信者なんていくらでも偽装できるのだし
送信者がアドレス帳にある人と同一だと判定しなければならない理由がいまいちわからないなぁ。
勝手に表示を省略して変更しちゃう機能が邪魔だとしか思えないんだけど、
どんなメリットが有るの？
# あれ一度間違ってキャッシュされると、なんかコマンドでクリアするんでしたっけ？
Re: (スコア:0)
日本だとそう多くはないのだが、ラテン文字圏だと、似たような名前や同姓同名が結構いる。間違えても社内ならまだいいが、社外だと洒落にならんことがある。そういう間違いを防ぐために、アドレス帳の顔写真の代わりに会社のロゴを登録しておくと、少なくとも送信者は瞬時に判別できる。当然のことながら、稚拙な偽装アドレスも見抜ける。
もちろん、偽装されている可能性はあるけど、アカウントを乗っ取られていることもあるし、乗っ取りや偽装がなくても送信者の不注意による危険なメールの転送もあり得るから、基本的には本文や添付ファイルの形式・サイズなどの妥当性で判断するしかない。
そして、メールアドレスを精査するのは、怪しいと判断したときだけ。メールアドレスだけで判断できる眼力は俺には無い。
Re: (スコア:0)
いや、だから、Outlookは、foo@example.comから来たメールの送信者がアドレス帳にあるFOO@EXAMPLE.COMと同じ人なのか判定しなきゃいけないんだよ。
Gmail の . の扱いに対応しなきゃとか、色々あったのかも知れませんね。