MLの宛先にユーザのメールアドレスを使用しない方が良い?

ディスカッションを行うMLを除き「MLのTo:(宛先)に送信先のユーザメールアドレス(各個人のメールアドレス)を記載するのは迷惑だ」と思っていました。理由は次の通りです。

– MLの情報は私信ではない。したがってTo:である必要はない。
– To: に自分のメールアドレスが入っている場合には特別なフィルタ処理行っているユーザが多いと思われる。

商用サイトのMLなどはTo:に設定されている特別なフィルタ処理を考慮して、ユーザがメールを読んでくれやすいよう「確信犯」でTo:に送信先メールアドレスを記載していると思います。

確かに昔はTo:に送信先に個人のメールアドレスアドレスを使っていると読まれる確立が高くなり、商用MLの送信者にはある程度のメリットがあったと思います。しかし、最近はSPAMが多くなりすぎていてデメリットの方が多いのではないかと思います。

例えば、私の場合フィルタルールでTo:かCc:に自分のメールアドレスが記載されている場合、特別なフォルダに保存されて分かるように分類しています。しかし、詐欺・迷惑メールは一部の商用MLと同じくTo:に自分のメールアドレスを記載して送信してきます。MLのメールも詐欺・迷惑メールも送信先のユーザに読んでほしいので同じ事をしてきます。その結果、私の個人アドレス宛のメールフォルダには詐欺・迷惑メールと振り分け処理を行っていないMLのメールが保存されます。

詐欺・迷惑メールの多くはSPAMフィルタでほとんど削除されますが、量が多すぎて一部はフォルダに残ってしまいます。MLのメールも残っているのですが、MLのタイトルと迷惑メールのタイトルはたいして違いが無い場合も多いので間違ってMLのメールをSPAMメールとマークしてしまう場合があります。(AmazonのメールとかSPAMになっていてキャンペーンのクーポンメールがゴミ箱に行きかけたことも…)一旦、迷惑メールと判定してしまうとかなりの確立で同じMLからのメッセージは迷惑メールとして処理されてしまう事になります。これでは、「ユーザに読んでほしいからTo:にユーザの個人メールアドレスを設定する」意味が無いと思います。

確かに私信に近いカスタマイズされたML(というよりはダイレクトEメール)も多いですが、customers@example.comの様なアドレスを使い、タイトルのプレフィックスにサイト名を書いて「example.com: あなたにお勧めの10冊!」等と書いた方がスパムに分類される確率が低くなると思います。特にユーザが「迷惑だ」と思っていない場合には効果が高いと思います。

まっとうなMLは宛先にユーザのメールアドレスを使用しない方が良いように思います。

システムが自動的に送信するメールでも一部のメールにはTo:にcustomers@example.comのようなアドレスは向かない物もあると思いますが、多くの商用MLはTo:に個人メールアドレスを設定する必要は無いように思えます。

良く知られたPHPの脆弱性…

また新しいsafe_modeをバイパスできる脆弱性を利用した攻撃方法を見つけた人がいるようです。safe_modeをバイパスできる脆弱性なので大きな問題とは思いませんが、

CVSS Severity: 7.0 (High)

となっていますね….

具体的には

This issue is due to an input validation error in the “error_log()” function that does not properly validate the destination parameter, which could be exploited by malicious users to bypass the safe mode feature by supplying a “php://” wrapper with directory traversal sequences as a destination argument.

の様なことができてしまう事が問題としてあげられています。

<?php
$file=””; # FILENAME
error_log(“<? echo \”cx\”; ?>”, 3,
“php://../../”.$file);
?>

が攻撃例としてあげられています。最初のアドバイザリメールには6/10にPHP開発者に連絡しレスポンスが無かったと書いてあります。

このようなケースはsefe_modeの範疇外(sefe_modeはfail safeを提供する機能。攻撃から防御する機能ではない)なので無視された、ということだと思います。

ちなみに、セーフモードはPHP6では無くなります。個人的にはfail safe機能としては非常に有用な機能だと思いますが、セキュリティホールとしてレポートされすぎるので削除されます。以前にも書きましたが「なんだかなぁ」と感じます。

システム上のファイルにアクセスしたければデータベース経由や他のライブラリ経由でアクセスすればアクセスし放題なんですけどね… safe mode = sandbox と勘違いしているユーザが多すぎです。

安全と思われていて実は危険なソフトウェア15種 – 宣伝のためのホワイトペーパー

ホワイトペーパーというものは基本的に宣伝の為に作成するものであって「危険なソフトオウェア15種」というホワイトペーパーも宣伝の為のホワイトペーパーでしょうね。PDFのダウンロードには登録が必要らしい(?)のでPDF自体は読んでいません。「危険なソフトがインストールされていないかチェックするにはこちらを見てね」といった旨の記述がPDFにはあるらしいです。

マーケティングではパブリシティーを有効活用するのは重要な事です。このPDFはマーケティング的には、少なくとも日本では、成功していると思います。自社製品の宣伝目的だったとしても有用な注意喚起も記載されているようなので「宣伝だからダメ」と言うことは無いと思います。

このPDFによると1位はFirefox 1.0.7だそうです。Firefoxは1.0系はメンテナンスされてませんよね。Google AnalyticsのログによればこのブログにFirefoxでアクセスしているユーザのうち約13%は修正済みの脆弱性があるFirefoxでアクセスしていると思われます。賛否両論あるようですが自分が使っているソフトウェアがメンテナンスされているか知っておく事は重要だと思います。多くのユーザは自分が使っているソフトウェアがメンテナンスされているものなのか、されていないものなのか気していないです。時にはこういった注意喚起も必要と思いますが、これらを目にするのは普通のユーザではなくコンピュータを生業とする人達がほとんどでしょうね…

アンチウィルスソフトは普通に使われるようになりましたが、インストールされているがメンテナンスされている物か、脆弱性を含まないかチェックするソフトウェアがあると非常に便利だと思います。アンチウィルスソフトのメーカにがんばってもらって追加機能として付けてほしいですね。ウィルスのシグニチャ更新に比べればかなり簡単(?)にデータベースの維持はできそうに思えます。

とろろで、このホワイトペーパーにMS製品が無いのは選択基準のせいらしいですが、IEが載っていないのは危険なことは周知の事実だからとか?IEが危険と書いても話題にならないからとか?(実際「IEが危険です」と書いても話題にならないでしょうね)しかし、ユーザ数なども含めて選択するなら最も危険なアプリはダントツでIEだと思います。

セキュリティ対策は全体的な整合性が重要ですから、バージョンが古くて危険なソフトウェアなってしまっているソフトがインストールされている場合に警告するアプリは必要ですね。何故今までメジャーになるような製品が無かったのでしょうね?

ところで自分で「よくあるバージョンが古くて危険ソフトウェアのトップ5リスト」を作るならこんな感じでしょうね。

– Webブラウザ
– Webブラウザのプラグイン(Flash、音声、映像再生のプラグイン)
– インスタントメッセンジャー(Skypeもこれに含む)
– メールクライアント
– PDFリーダ(Acrobat Readerだけでなく、Linux等で利用されているフリーPDFリーダにも脆弱性がある)

なんだかここに取り上げているホワイトペーパーと同じようなリストになりますね。

爆発ノート

既に色々なところで紹介されているようですが、本当すごいですね、この爆発の仕方は。PCのリコール情報にも注意が必要ですね。

ところで燃料電池は可燃性の燃料を使いますがやはり爆発の危険性があるのでしょうかね?

また別の文字エンコーディング問題

HTTPヘッダでASCIIを文字エンコーディングに設定していてもISO-8859として解釈してしまうブラウザ(Firefox、Operaなど)とASCIIとして解釈するブラウザ(IE)とが在るためIPSなどのフィルタをすり抜けられるかも知れない、という話。珍しくIEの方が標準に厳格(?)に対処しています。

リンク先のページをIE 6で表示すると7bit ACSIIでは無視されるべき8ビット目が無視され読める文字列が表示されますが、Firefox 1.5では8ビット目を無視せずISO-8859として解釈してしまい文字化けしているように表示されます。IEの動作の方が仕様的には正しいように思えますが、Firefox、Operaの動作の方が安全ですね。

どちらかと言うとWeb開発者が注意すべき問題ではなく、JavaScriptの脆弱性を利用した攻撃などエンドユーザ側で問題になる可能性がある問題です。しかし、<, >等がどうなるのかは書いてないですね。IE6ではHTMLの特殊文字も普通に8ビット目を無視して処理するのかな?文字エンコーディングの取り扱いが関連ではいろいろありすぎで本当に困ります…

このブログには書いていませんがBOM(バイトオーダーマーク)でフィルタをすり抜けられる問題もありました。文字エンコーディング関連の問題はまだ出尽くしたとは思えないのでこれからも色々出てくるのでしょうね。

プログラム等、内部の文字エンコーディングは決めておくべき

あるMLでプログラム内部の文字エンコーディングは決めない事にしている、と言う意見を目にしました。プログラムを利用するシステムにより複数の文字エンコーディングがあるのでプログラム内部の文字エンコーディングを指定しない方が便利であることが理由だそうです。このような方針でも安全なプログラムは書けますが、セキュリティ上お勧めできない設計方針と思います。

2000年2月に公開されたCERTのXSS脆弱性問題の中でダイナミックページの文字エンコーディングは必ず指定する、と言う対策が書かれていますが、これと同様の理由でセキュリティ上の問題になってしまう場合があります。XSS問題としては文字エンコーディングを指定しない場合、ブラウザが文字エンコーディングを自動的に検出して表示する事になります。ブラウザが文字エンコーディングを自動検出すると、検出した文字エンコーディングによってはXSSが可能になる場合があります。

確か、昨年くらいに「文字化けしたページの文字エンコーディングを変えるとXSSが可能になる」と言うことでページの文字エンコーディングを変えると意図しないJavaScriptが実行される危険性が指摘されていました。こちらは文字エンコーディングの自動認識ではなく、ユーザが明示的に文字エンコーディングを切り替える事により発生する問題ですが、文字エンコーディングの妥当性を確認していれば防げる問題の一つです。

プログラム等の文字エンコーディングを指定しない場合、複数の文字エンコーディングを含むおかしな文字列を作ってしまうリスクがかなり高くなります。おかしな文字列がプログラム内部にもありえる事を前提にコードを書くとなると、必要以上に文字エンコーディングの妥当性をチェックしないと、コードの安全性を担保できなくなります。

同様にデータベースの場合にも文字エンコーディングを指定せずに複数の文字エンコーディングを含むデータを保存している場合があります。このような運用も文字エンコーディングに関連する脆弱性を発生させやすくなる原因になります。

互換性がある文字エンコーディングでも表現できる文字が異なるので困る場合があります。例えば、UTF-8とUTF-16ではUTF-8で表現できる文字はUTF-16よりかなり多いです。(注:実際にはUTF-16でも確か200万ほどのコードポイントを表現できるので、現状で困ることはほとんどないです。実際にはSJISを使っていて困る、などの場合が多いと思います。)

セキュリティ的にはシステム内部で利用する文字エンコーディングを指定しない場合と指定する場合を比べると、文字エンコーディングが指定されている方がはるかにコードが分かりやすく安全性も高くなると思います。プログラム等、内部の文字エンコーディングは指定できるシステムの場合、必ず文字エンコーディングは決定しておくべきと考えています。システムによっては内部で使用する文字エンコーディングは決め打ちでUnicodeを採用しています。

PHPはプログラム内部の文字エンコーディングを指定できます。デフォルトはISO-8859-1になっていてHTTP入力、スクリプトの文字エンコーディングを内部エンコーディングに自動的に変換する場合に利用されます。PHP6に備える意味からもUTF-8を内部エンコーディングに設定するのが良いかと思います。

French Microsoft Web site hacked

The attackers were likely able to penetrate the server running the Web site due to faulty configuration, Microsoft said in a statement Monday.

設定ミスだそうです。いわゆるページの改ざんだったようです。

http://experts.microsoft.fr/default.aspx

http://www.zone-h.org/index2.php?option=com_mirrorwrp&Itemid=44&id=4181592

の様な画面に改ざんされていたそうです。
トップページを改ざんされていたのですね。これは痛い…

Excel 0 Day攻撃のFAQ

メモ。Excel 0 Day攻撃のFAQ。

6/14にポストされ、6/16にマイクロソフトも脆弱性を確認とあります。XP上のExcel 2003/2002では確認されているそうです。Excel 2000は幾つかのベンダが影響あり、としているそうです。

最近MS Officeアプリの0 Dayが流行っているので注意が必要と思います。次はOOoとか?

PHPのバージョン統計 – 半数はPHP4.3ユーザ

PHP 4.4.2が増えてきているようですが、半数近くが4.3ユーザだそうです。
PHP 5系は低空飛行の状態のようです。

http://www.nexen.net/images/stories/phpversion/200605/evolution.milieu.en.png

アップグレードがいかに難しいかを表している数値だと思います…
セキュリティホールもあるのでスクリプトで対策するなど必要な処置やセキュリティ上の評価が行われているか心配になります…

PayPalのIDが盗まれているらしい

Netcraftによると、PayPalのIDが盗まれているらしい。

Webサイトの開発者にはセキュリティ対策としてHTTPSだけでは意味が無いことは100も承知だと思いますが、普通のユーザは「HTTPS=安全」と刷り込まれていると思います。HTTPSを使っていてもXSSに脆弱だと意味が無い良い例になりそうです…

HTTPSなのに接続先サイトを偽証できる理由は簡単です。XSSに脆弱であるため、ページの中身をJavaScriptで書き換えて別のサイトのユーザ名とパスワードを送信できてしまっているようです。当たり前の事なのですが一般ユーザはこのようなことができる事を知らないので、ブラウザの接続先とSSL/TLSの証明書が正しければ「目的のサイトにアクセスしている」と思います。今回の本当のサイトに不正なページが表示され別サイトに誘導されるケースでは用心深いWeb開発者でも普通にだまされる可能性が高いと思います。
# アクセス先のURLがおかしい、と気が付く可能性も高いですが。

WebアプリからXSSが無くなる日があるとしても当分来ないでしょうね…

これもspam? Wikiページの一部削除

これまでに時々あったのですが割りと頻繁にアクセスされている私のWikiページの一部が削除されている場合があります。「操作ミスで誤って削除したのかな?」と思って気にもしていませんでしたが、もしかしてこれもSPAMなのかも知れませんね。変なSPAMプログラムが削除しているのか?人間が削除しているのか?どちらにしてもPukiWikiにもチューリングテストが必要かも知れません。しかし、トラックバックにチューリングテストは難しいですね…

昨日気が付いたspamっぽい削除の痕跡は次の通りです。

http://wiki.ohgaki.net/index.php?cmd=backup&action=diff&page=Momonga%20Linux%2FSubversion%A5%B5%A1%BC%A5%D0%B9%BD%C3%DB&age=7
http://wiki.ohgaki.net/index.php?cmd=backup&action=diff&page=Momonga%20Linux%2FSubversion%A5%B5%A1%BC%A5%D0%B9%BD%C3%DB&age=8

このページの説明だけでWebDAVを使ったSubversionサーバが作れるようになっていたのですが後半部分が削除されています。

222.7.56.51 – – [04/Apr/2006:18:32:05 +0900] “POST //index.php HTTP/1.1” 302 – “http://wiki.ohgaki.net//index.php?cmd=edit&help=true
&page=Momonga%20Linux%2FSubversion%A5%B5%A1%BC%A5%D0%B9%BD%C3%DB” “KDDI-SA34 UP.Browser/6.2.0.9.1 (GUI) MMP/2.0”

このIPはAUのゲートウェイのIPであり確かにAUの携帯からリクエストが来ていたことが分かります。前に気が付いたときにもAUの携帯からのアクセスであった気がします。携帯であまり大きなデータをPOSTする事は無かったので気にしたことが無いのですが、POSTサイズに制限に引っかかっているのかな? そのうち調べてみよう。でも、ご存知の方、教えて頂けると助かります 🙂

PukiWiki 1.4.7

PukiWiki 1.4.7が6/12にリリースされていますね。文字エンコーディングにUTF-8を使っていると思われるバージョンもあります。

ホームページには最新版は1.4.6と記載されているのでリリースと言うよりダウンロードできるようにしてあるだけかな?

ところで今朝私のWikiにPukiwikiであるにも関わらず海外のSPAMMERからスパムが来ていました。MenuBarを仮想リンクネット(Link Farm, Splog)へのリンクに書き換えられていいました。ほんの少しだけ調べてみるとこの人たちは出来の悪いWeb Botを作っていたりいろいろ悪さをしているようです。ちなみにドイツの会社のようでした。

スパム防止は基本機能として必要な時代になりましたね…

本気だったのですね – 日本で検索エンジン開発

ある官僚が「100億あれば新しい検索エンジンがつくれるかな」と言った発言をしていた、と報道されていたのですが本当になったようです。

日立製作所や富士通、NTTなど電機、情報通信大手と東京大など国内の約30社・機関が共同で、日本独自のインターネット情報の検索エンジンの開発に乗り出す。16日にも研究組織を発足させ、2年以内の実用化を目指す。国も予算面などで支援する。

エンジン自体から再開発なのでしょうか? コアのエンジン部分だけでもオープンソースになったりすると非常にうれしいのですが無理でしょうね。この話、実現性は50%くらい、と思っていたのですが良い物ができる事を期待します。

銀行のキャッシュカードに有効期限をつけたらどうでしょう?

一般の利用者の安全性確保もできますし、不正口座を無くすにもかなり効果的だと思います。クレジットカードだと損害を補償しなければならないがキャッシュカードだと保障しなくても良い場合が当たり前だったので「キャッシュカードに有効期限をつける」と言う発想は金融機関になかったのだと思います。キャッシュカードにも有効期限をつけた方が良いですね。

結構知られている(?)と思いますが1985年までに作られたキャッシュカードには暗証番号が記録されている物もあるそうです。比較的最近のキャッシュカードでも一部を書き換えするだけで利用できてしまうカードもあるようです。今はこういったカードを持っているATMを利用すると自動的にアップグレードされたりするでしょうか?それとも最低限、キャッシュカードを更新する必要がある旨のメッセージが表示されたりするのでしょうか?

ネット取引用にOTP(One Time Password)を採用している銀行もありますが、ネット取引の安全性を担保するには別デバイスでのトランザクションの認証が一番安全だと思います。随分前、ソフトウェアキーボードがセキュアキーボードと呼ばれていた頃にこのブログに実装案(携帯等で取引を確認後に署名する方法)を書きましたが今のところ似たような方法を採用した銀行は知りません。誰も思いつきそうな方法ですが、もしかして特許の問題などがあるのかも知れませんね。

これならどうでしょう?トランザクション番号を携帯などの別端末から入力して認証を取った取引だけ許可するとか? これなら特許問題が発生するような

詐欺かな – 「出会い系サイトを運営しませんか?」メール

「出会い系サイトを運営しませんか?」とメールが来ていたのですが詐欺っぽいですね。こんなメールでも騙される人はいるのでしょう。「出会い系サイトを利用しませんか?」という内容のSPAMは山ほど来ているのですが「出会い系サイトのサイトを運営しませんか?」というSPAMは初めてです。(来ていたのかも知れませんが気が付いたのは初めて)100%の確証は無いのでメール自体は引用しません。地域別にフランチャイズと言う触れ込みですが”普通”はインターネットサイトを地域別に営業活動するものではありません。個別訪問でもして利用者を集める、ということでしょうか? まずは50万からで自宅サーバでもレンタルサーバでもOKだそうです。はっきり言って詐欺でしょう。

# 100%詐欺でも無くてもSPAMメールの送信、検索エンジンSPAM
# に利用され、そして全く利益にならないのが落ちでしょう。

既に他で詐欺であろうことは指摘されていると思いますが、少しでも騙される人が減る事に役立てば良いのですが…

ちなみにこれは日本語のメールです。きちんと日本人が書いたと思われる文章でした。英語のSPAMにはこの手のネットビジネス物の詐欺と思われる物はかなり多いのですが日本語では初めて見ました。

これからのプログラムの作り方 – 文字エンコーディング検証は必須

最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。

参考:セキュアなアプリケーションのアーキテクチャ – sandbox化

“これからのプログラムの作り方 – 文字エンコーディング検証は必須” の続きを読む

Dojo Javascript Toolkit

IBMが更にDojoを支援するらしいです。

Dojo Toolkit enabling internationalization of applications and making them fully accessible to persons with disabilities through a variety of assistive technologies,

Ajaxを使うとアクセシビリティが問題になりますが、アクセシビリティも考慮すると言うことらしいです。デモはなかなか良くできています。この近いうちにこのツールキットを使ってなにか作ってみよう。

trackbackもDNS逆引きなしホストから拒否します

海外からのコメント/トラックバックspam対策としてコメントだけはDNS逆引きなしのホストを拒否(というか登録したように見えても実際には反映しない)していたのですが、最近は一度に数百のトラックバックスパムを送ってくるSEO/SEM業者がいます。

コメントスパムに比べるとトラックバックURLを知った上でスパムを送信する必要があるのでコメントスパムに比べてトラックバックスパムの方が若干手間がかかるのですが、スパム業者もそれくらいの手間は惜しまなくなったようです。

DNS逆引きなしのホストからはトラックバックは受け付けないようにソースを修正しました。普通のまっとうなISPの場合、必ず逆引きは設定されているので普通のユーザは困ることはありません。(少なくとも日本は)逆引きくらいは簡単に設定できるのであまり意味が無いように思えますが、実際にSpamを送信してくるホストに逆引きが設定されていないケースが多いので多少は役に立つはずです。

# 三浦さんのspamパッチを試さないと…

ところでspamメールでは結構おなじみのドメイン名を使ったSpam効果測定を行っていると思われるspamが連続して送信されていました。例えば以下のドメインです。

4109.mejsef.info

(サーバはオーストリア、ドメイン所有者はポーランド、ネットワークアドレスが26ビットなので大口の一般ユーザ(?)のように思えますが逆引きはISPが設定した(?)ままの状態のようです)

4109がなんらかのIDと思われます。サイト識別IDにしては4109は短すぎるのでキャンペーン番号のようなID番号なのでしょう。いちいちDNSに登録するのが面倒では?と思われるかも知れませんが、ずっと前のspamメールのエントリにも書いたようにドメインをIDとして利用するのは、ワイルドカードをサポートしたDNSなら非常に簡単です。ほとんど手間もかかりません。DJBDNS、Apache 仮想ホスト、サーバサイドスクリプト少々、なんらかのデータベースシステム等があれば簡単に汎用的な仕組みが出来てしまいます。

マウスをぐるぐる回して高速化!?

前のエントリで

本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識

と書いたのですが、divineさんから「Word の「印刷」を劇的に速くする方法を発見。ホイールを上下するだけ!」と言うブログへのリンクを教えていただきました。(divineさん、ありがとうございます)「マウスをぐるぐるして高速化」はバカバカしいように思えるのですがマウスホイールを回すと実際に速くなる場合もあるようです。以下が速くスプールできる理由の推測です。

ご存知の様にWindows95より前(Windowsは3.1まで)はコーポレイティブ(非プリエンプティブ)なマルチタスク(アプリが自分で処理をOSに返す)でした。MS Officeの開発は少なくともWindows 3.xの頃(Windows 3.1上でOffice 4.xを実際に使っていました。実際の開発ルーツはもっと前でしょう)までさかのぼれますが、Wordの印刷処理をバックグラウンドで行うには現在のようにスレッドを作ってOSに任せる事が出来ませんでした。昔のアプリケーションではバックグラウンド処理を行うには擬似的にスレッドを実行するような感じのコードを書く必要がありました。この擬似スレッドの様に動作するコードのためにイベントが発生するたびに、より速いタイミングでバックグランド処理が行われる仕様となってしまったアプリケーションができたのだと思います。Wordのスプールの場合、再描画のスレッドとスプール処理が関連している(リンク先(Word の「印刷」を劇的に速くする方法)を参照)ためマウスのホイールを動かしてスクロールさせると速くスプール出来てしまう動作(仕様)になってしまったようです。
# 今のOfficeならこんなコードを捨てて普通にスプール用の
# スレッド作るだけで劇的にスプールが速くなると思います。
# 推測ですが。

とにかく「マウスでぐるぐる回しているとPCが速く動作する」というノウハウは100%嘘ではなく、一部では本当に処理が高速化できる!という事は書いておなければと思いここに書いています。(注:とは言っても単純に「マウスポインタだけ」をぐるぐるしているだけでは処理は速くなりません)

さて、マウスやキーボードを使っていると処理が速くなるケースはUNIXでもありえます。/dev/randomはマウスやキーボードなどからの入力を乱数生成に利用しているので一部のアプリケーション(特に強度が強い暗号処理)で乱数のシード待ち状態が発生する事があります。このような場合にはマウスポインタをぐるぐる回すと結果として処理が早く完了します。

Windowsだけでなく昔のMac OSもWindowsと同様にコーポレイティブマルチタスクでした。探してみればWindows、Mac OSがコーポレイティブマルチタスクだった頃の名残りで「マウスを動かしている(イベントを発生させている)と処理が速くなる」ケースは結構沢山あるのかも知れませんね。

マウスぐるぐるでアプリケーションの動作が高速化する場合が他にもあるでしょうか? もしご存知の方、是非教えてください。

RFC原理主義者ではないですが… 迷惑な迷惑メール対策に反対!

RFCの位置づけも、絶対的に崇め奉る技術者がいたり、そもそも読んでない(あることを知らない)なんて技術者がいたりとまちまちだが、相互接続に影響する部分は準拠しておいてほしいと思う。携帯各社のメールアドレス仕様でユーザより「PCのメールからメール送受信ができない!」とクレームを受けたことのあるタレコミ人としては、ユーザに対しきっちり警告も行わないままで、相互接続に問題がある形式を採用するのは迷惑なだけ、と思うのだが、みなさんはいかが?そもそも、メールの相互接続は保障していない!って?”

DoCoMoもAUも何を考えているのだろう?
想像力が不足しているように思えます。不正なメールアドレスを使って他のドメイン/サーバからの迷惑メールを防ぎたいなら、自分のドメインからのみ受信できる状態をデフォルトにすれば良いだけでは?

このような迷惑な仕様によって発生するサポートコストは「DoCoMoとAUに請求したいくらいだ」と思っている人も多いと思います。

時間があるAUユーザは是非自分のメールアドレスを非RFC対応メールアドレスに変更してAUサポートに電話をお薦めしたいくらいです。

ユーザ:「PCからのメールが届きません!」
サポート:「メールアドレスに一部に一般的に使えない文字が含まれているからです」
ユーザ:「使ってよいとしたのはそちらなので使えるようにして下さい。機械の事はよくわからないので受信できるようにしてもらいたいのです」
サポート:「連続した.(ドット)や@直前に.は使わないでください」
ユーザ:「もうこのアドレスにしたよ、って友人送っちゃいました。アドレス変えて送り直すってことですか?」
… 以下延々と …

と言ったサポートコールが山のようにあれば改めるかな?一端広げた仕様を狭めるのは非常に難しいので出来るだけ早く修正されることを期待したいです。

文字コードといい、いい加減なのは技術者でなくて、技術をよくわかっていない上司の鶴の一声だったりするのかも知れません….

それともユーザから「どうしてこの文字はアドレスに使えないのか?」といった問い合わせが多いのかな? 「DoCoMoでは使えるよ!」とか?

ところでこの投稿のリンク先に書いてあったAU, DoCoMoの迷惑メール対策も「いかがなものか」と思います。

半角英数字と「- (ハイフン)」「. (ピリオド/ドット)」「_ (アンダーバー)」などの記号を組み合わせた長いアドレスが、迷惑メールの防止に効果的です。

http://www.au.kddi.com/notice/meiwaku/email/mail_address/

メールアドレスの文字数別に迷惑メール受信率を調査したところ、文字数が多いほど迷惑メールを受信してしまう率が低いという結果が出ています

http://www.nttdocomo.co.jp/info/spam_mail/measure/change_add/

AU, DoCoMoは「長いメールアドレスが迷惑メール防止に効果的だ」としていますが、長いメールアドレスが迷惑メール防止に役立つとは思えません。単純に迷惑メールに辟易したユーザが長い別の新しいメールアドレスを取得しただけだと思います。

当り前ですが迷惑メール業者はメールアドレスをデータベース化し、そのデータを元に送信しているはずです。データベースに登録されるか?されないか?はメールアドレスの長さや使っている文字に関係しません。(迷惑メールを送る業者がわざわざメールアドレスがRFC準拠かチェックしているとは思えない)長いメールアドレスが迷惑メール防止に役に立つ、と言う技術的根拠を示してほしいものです。(統計的に役に立っている、という議論は無意味)

私は携帯、PHSメールアドレスを送信にはほとんど使わない&Webサイトに登録しないので迷惑メールは全くきません。@前のユーザ名部分もいつも使っている”yohgaki”です。しかもこのアドレスはずっと以前から使っています。さらに私が他のメールサービスなどでメールアドレスを設定する場合、yohgakiがユーザ名に使用できれば必ずyohgakiを使っています。yohgakiをユーザ名にすることにより迷惑メールを送信されるリスクは高くなると思われます。にも関わらず迷惑メールは受信していません。メールアドレスのユーザ名部分が分かりづらいから迷惑メールがこないのでは無く、メールアドレスがデータベースに登録されていないから迷惑メールがこないのです。
# ちなみに公開メールアドレスのyohgaki@ohgaki.netに
# は毎日数百通のSPAMメールが世界中から送信されてき
# ます。

統計的に長いメールアドレスを持つユーザが迷惑メールを受信していないのは

SPAMメールに辟易

新しいアドレスの取得を試みる

分かり易いアドレスはほぼ全て使用済み

仕方が無いので分かりづらい長いアドレスを設定する

結果として新しいメールアドレスになる ←ここだけが迷惑メールを防ぐポイント

当然新メールアドレスはSPAM業者のデータベースに登録されていない

当然、SPAM業者からSPAMメールが来ない

と考えるのが妥当と思います。メールアドレスが分かりやすいか、長いかはSPAMメール対策に何の効果ももたらしません。

更に短いメールアドレスを持つユーザは「長い期間」そのメールアドレスを使用していると考えられます。その結果として複数のSPAM業者のデータベースに登録されてしまい、多くのSPAMメールを受信していると思われます。「短いメールアドレスを持つ」事と「SPAMを受け取りやすくなる」事には全く因果関係はありません。実際、@ohgaki.netの1文字メールアドレスには1通もSPAMメールが来たことがありません。

長いメールアドレスが迷惑メール対策に有効と宣伝するのは「嘘をついている」言われても仕方ないと思います。

本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識(追記:WORDでは処理タイミングの問題で印刷スプール処理が速くなる場合があるそうです。私が聞いたのはEXCELファイルの読み込み中にマウスをぐるぐる回している速く読み込める、と言うものでしたがもしかしてこれも本当だってりします?マウスイベントでスプール処理が速くなるのはWindowsとOfficeの歴史からも納得できるのですがEXCELのファイル読み込みでも同じ現象が確認できるでしょうか?ご存知の方、是非教えてください。)を本気で信じている初心者の方も多いらしいです。「長いメールアドレスが迷惑メール対策に有効」と宣伝するのはこれと変わりありません。
# 一部のアプリケーションでスクロール中にマウスを動かすと
# 速くスクロールするのですが、この仕様が誤解の原因??

とにかく、技術的根拠が全くない迷惑な迷惑メール対策には強く反対です。RFCに違反していると知りつつ大手ネットワークサービスプロバイダがRFC違反するのにも強く反対です。RFCが気に入らないなら、RFCを変えてから変更するか、本気になってRFCの変更を提案する姿勢を見せてほしいものです。