« 2007年2月 | トップページ | 2007年4月 »

2007/03/30

Windows Mailでメールを削除できない不具合?



幸いにも、私自身は遭遇したことがないのですが、Windows Mailにはメールを削除できなくなる現象があるらしいです

---- 2007年4月8日午前7時18分ごろ追記 start ----
その後、1週間もしないうちに自分の環境でも同じ問題が発生し、他人事ではなくなりました。その涙のトラブル日記と一応の解決までの長い道のりを下記にまとめました。

● (再掲載)Windows Mailで「ゴミ箱」内のメールが削除できなくなる現象 -- 自分の環境でも起こりました! http://shimax.cocolog-nifty.com/search/2007/04/windows_mail_b60a.html

---- 2007年4月8日午前7時18分ごろ追記 end ----

●Windowsメールを使用中、急にごみ箱のメールが削除できなくなりました。消せないメールの内容はすべて、
「メッセージを表示できませんでした。メッセージを表示しているときに予期せぬ問題が発生しました。 メモリやディスク領域が不足していないかどうかを確認してから、もう一度メッセージを表示してください。」
と表示され、削除しようとすると「不明なエラーが発生しました」と出てきます。

http://q.hatena.ne.jp/1170914826

この問題は、上記質問者だけではなくて、

●PLANEX@OKWave Vistaメールの削除ができません。
http://internet.okwave.jp/qa2827652.html

また、本家マイクロソフト社のニュースグループでも、

●Discussions in Outlook Express
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?
dg=microsoft.public.jp.outlookexpress.win&cat=ja_JP_bb
38873b-d9bd-4299-9be2-efed48a8581e&lang=ja&cr=JP


かなり頻繁に、この話題は出ています。

最後に、こちらには、「Windows Mail Repair Utility」というソフトが紹介されています。ちょっと使ってみるのは怖い気もしますが、こういうソフトでデータベースを修復すると正常化するかもしれません。そう言えば、Windows MailにはOutlook Expressで見られた「フォルダの最適化」というメニューがないように思えます。とにかく、今は自分の環境では起こったことがないので、幸いです。

なんとなく症状からして、以前書いた

●Windows Mailのメッセージルールのバグ(「一」で始まる件名の登録ができない件)
http://shimax.cocolog-nifty.com/search/2007/03/windows_mail_64e3.html

と同じで、特定の漢字・特定の文字コード・パターンを持つメールが原因で、データを正しく認識できない不具合がWindows Mailにはあるように思えます。特定のメールがダウンロードできない現象をOutlook Expressで経験したことが何度かありますが、それと同じで、今回の現象も特定のメールが引き金になっているような気がします。



| | コメント (0) | トラックバック (0)

2007/03/27

「Welcome to Adobe GoLive」というページタイトルがGoogleで30万件以上存在する

だからどうというわけでないのですが、今日あることを調べていたら、「Welcome to Adobe GoLive 6」というページタイトルに出くわしました。明らかに、GoLiveの解説サイトとは違う普通の企業のホームページでした。

気になって、Googleで検索してみたら、30万件以上(2007年3月26日現在)も存在したというわけです。

http://www.google.co.jp/search?hl=ja&c2coff=1
&q=%22Welcome+to+Adobe+GoLive%22&lr=lang_ja


最新バージョンのAdobe GoLive CS2.0 日本語版 Windows版でどのような仕様になっているかわかりませんが、少なくとも過去には、デフォルトでは「Welcome to Adobe GoLive 6」というページタイトルがテンプレートか何かで使われていて、ユーザーがページタイトルを自分でしっかり設定しないと、このデフォルトのページタイトルが使われる仕様だったようです。ここを書き換えないといけないということを理解できない人がGoliveを使っていることも不思議ですが、こういう仕様はどうかと思いますね。「無題」「無題ドキュメント」というのも味気ないですが、一番無難なように思えます。

とはいえ、SEOと叫ばれて久しいのですが、「Welcome to Adobe GoLive」であれ「無題ドキュメント」であれ、これらのページタイトルでは到底上位にランクされるのは厳しそうです。

| | コメント (0) | トラックバック (0)

2007/03/26

海外のレンタルサーバを借りてはいけない理由(FTPアップロード・トラブル顛末記)



私は今、海外のレンタルサーバを2つ借りている。ColdFusionを扱うことができるレンタルサーバは当時は、日本では非常に少なかったり、きわめて高額だったため、海外のレンタルサーバを借りたのが一つだ。もう一つは、amazonのアフィリエイト用ページ(Amazon Web Serviceのために静的なHTMLページを大量に保管するディスクスペースを必要だった)のために借りたのだった。

ただ、結果的に海外のレンタルサーバを借りたのは大失敗だった。サーバのレスポンス自体は、海外であっても日本であっても、それほど気にならない場合が多いです。しかし、海外のレンタルサーバのサポートは概して駄目というか、最悪である。

名誉のために最初に断っておくと、私は英語は苦手ではない。数年前の話ですが、TOEICは940点でした。そのため、英作文は何の問題もありません(と思う)。しかし、彼ら(サポート)とのやり取りは1回や2回で済んだことがありません。

今、二つ借りていますが、実はその前にも1個借りていたことがあって(数ヶ月で解約。因果関係ははっきりしまっせんが、そのレンタルサーバと契約後、大量の英文スパムメールが届くようになりました。)、合計3つの海外レンタルサーバを借りた経験があることになりますが、全部が全部そうです。

返事の速度はそう悪くはないが、「文章を読まずに、キーワードだけを拾って、適当な回答をコピー&ペーストしている感じ」「絶対に謝らない」「サーバに障害が起こっているのに、確認することなく、こちらの設定ミスの責任して、初心者扱いする」という特徴が共通してあるようです。また、過去のやり取りを参照するということは基本的にせず、毎回、同じことを最初から何回も説明させます。

また、初回の納品時に、まともにPHPが動かないことや、データベースの設定が間違っていたりとか、考えられないミスをしてくれたことも2回ありました。完全に素人です。日本では考えられないことです。

つい先日も、FTPをめぐって、トラブルになり、解決まで5日もかかりました。FTPソフトで接続すると、サーバに接続できますが、ファイルのアップロードができません。正確に言うと、ファイルのアップロードがほぼ終了した時点で、それ以上進まなくなります。FTPソフトがフリーズしたような状態になります。サーバから、転送が完了した旨のシグナルがFTPソフトに返ってこないので、FTPソフトがいつまでもそのシグナルが戻ってくるのを待っているというような感じでした。

>PASV
227 Entering Passive Mode (*,*,*,*,*,*)
>STOR test.php
150 Accepted data connection
で必ず留まります。

結局、FTPソフトの接続を手動で無理やり切るしかありません。再接続すると、さっきアップしたファイルはちゃんとアップロードされています。でも、次のファイルをアップロードしようとすると、また同じところで留まります。仕方がないので、強制終了をしてと繰り返していると、仕舞いには、

421 Too many connections (4) from this IP.

おいおい、ちょっと待てよ。「このIPアドレスからの接続が多すぎる」って、あんたのせいじゃないか? しかも、いくら手動で接続を切っているとは言え、このFTPソフトがきっと接続を切る旨のコマンドを「おたく」に送信しているはずだけど、それさえも受け取れていないというわけ?

1ファイルをアップするごとに接続を強制終了させ、その上、私のIPアドレスからの接続情報というかプロセスは残っているのかで、とにかく同じIPアドレスからはアクセスできなくなってしまいます。そのたびに、ルータをリセットして再接続し、IPアドレスを取得しなおさなければなりません(固定IPではなくて、こういうとき良かった)。にっちもさっち行かないので、サポートに問い合わせすることにしました。

最初の回答:FTPにログインできないならパスワードをリセットする必要があるから、古いパスワードと新しいパスワードを知らせてください。

はーん? そもそもFTPにログインできない理由は? パスワードが間違っているならその旨のメッセージが出るだろうし、それなら「古いパスワード」を聞かれたところで、間違っているだろうから、教えられないはずだが・・・。そもそも、まずいったんはサーバの状況を確かめてから回答しろという感じがしませんか?

たしかに最初の私の質問の仕方も悪かったと思い、FTPログなども付けて再質問しました。すると、数時間後、いつ直ったのか分からないが、「without any trouble.」でアップロードできたという回答メールが届いた。確かに、この回答メールが届いた直後、テストすると直っている。無茶苦茶腹がたったが、彼らに話しても無駄である。我慢することにしました。彼らには、「質問した当時と、今自分たちがそのサポート要請メールを読んでいる時間には差があり、また、自分の知らないところで同じ会社の人間が他の人からのサポート要請メールを元に修正してしまった後だったかもしれない」ということには、思いも及ばないようである。それなのに、「何の問題もなくアップロードできた」といって、こちらを被害妄想の塊の素人扱いするのか、Japだと思って馬鹿にしているのか、とにかく腹が立ちます。

その上、翌日にはまた、全く同じトラブル発生。仕方がないので、今度は、リアルタイム・チャットというのにチャレンジ。ところが、「スタッフがすぐに出るのでもうしばらくお待ちください」という趣旨の英語が出るけれど20分以上待っても出てこない。2・3分おきにAjaxか何かでメッセージはリロードされるが毎回同じメッセージの連続。あきらめかけたところ、やっと出てきた。

結果的にこの最初のチャット・スタッフは一番まともだった。問題を確認し、シニア技術者にこの問題を回すという。「as soon as possible」に対応するという。これで一安心か・・・。

翌日、修正した旨の回答メールが来たので、心を弾ませながら、アクセスしてみると、ぜんぜん直っていない。回答メールをこのスタッフが送った当時は確かに直っていたということがあったのかもしれないということを認識しつつ、それに配慮した返信メールを出した(日本人は情が細やかです)。

ただ不安なので、再度、オンラインチャットに臨んだ。この2回目のチャット・スタッフが完全に素人だった。こちらでFTPをやってみるので、IDとパスワードを教えろという。ここまでは昨日と同じ展開だ。最初にチャットに望む前に、本事案のリファレンス番号などは伝えているが、どうやら読んでいないらしい。いつものことだとそれはあきらめたが、FTPのIDとパスワードを教えてから、待てども暮らせども、うんともすんとも言ってこない。しばらくすると、4分置きぐらいに計5回程度、「今調べているので、もうちょっと待ってくれ」というコメントばかり入れてくる。FTPでファイルをアップロードして現象を確認することだけに何分かかるんだ!!

合計20分ほど待って、「アップロードできた。http://サーバ名/hogehoge_test.html 」にアクセスしてみろとかいう。さらに、こちらが何の応答する間もなく、こういう時だけ間髪入れずに、「他のことで、何か助けることができることはないか?」とか言ってきて、問題はさも解決したかのように言ってくる。ファイルを一つ一つアップロードすることはできるが、FTPソフトがそこで固まってしまって、次のファイルのアップロードをするにはいったん強制的に接続を切らなければならないことが問題なのに、20分もかかって一つのファイルをアップして、何を得意がっているんじゃ?

「Did you manage to finish your FTP connections normally?」と詰め寄ると、「No.」と短く答えてきた。はあ? 平然とよくそういうことがぬけぬけと言えたもんだ。「それじゃ、どう考えても直っていないでしょう」という波動で詰め寄り、さらに昨日のチャット内容などもとうとうと再度説明して、やっと「リファレンス番号は何だ?」とか聞いてくる。「それはチャットが始まる前に入力したはずであり、それなら何のために入力させたの?」 と思うが、彼らにはそういう話は通じない。とにかく話を引き伸ばして、こちらが諦らめるのを待っているかのようだ。

そして、結論として、レベル2のサポートが関与するようにこの事案をアップデートするとかいってきて、レベル2のサポートが「as soon as possible」に問題を解決すであろうとかいう。「as soon as possible」って昨日も言っていたけど、「結局いつなのか?」と聞くと、「as soon as possible」と言ってくる。あんた、英語分かっているの? 日本人舐めていない?

このチャット・サポート人物は最悪だと思う。「bye」といって、強制的に会話をストップさせた。ただ、レベル2からの回答はいっこうに来ない。問題をやっとまともに認識し始めたから、いい加減に「直った」とか言えないからかもしれないと思いつつ、既に数日が過ぎていたので我慢も限界に。

3度目のオンラインチャットに挑戦。時間帯が違ったからか、今度はすんなりつながった。今度もチャットが始まる前にも所定のフォームにリファレンス番号を入力したが、チャットが始まってすぐに、「My issue number is ******.」と打ってみた。すると、さすがにそれは無視できないようで、こちらの過去ログを見てくれた。「今、level2のサポートが対処している。すぐに連絡がいくはずだから待て」という。「『as soon as possible』って昨日も一昨日も言っていたけれど、結局いつなのよ? 」と問い詰めると。「as soon as possible」という。「できるだけ早く」って単なる努力目標か、言い訳なわけ? 

4日間も5日間もFTPできない状況で、「できるだけ早く」対処して、解決できないって、どうなのよ?「できるだけ早く」解決できるように努力して、結果的にそうならなかったら、日本人は「すいません」と真っ先に言いますが、彼らの精神構造はそうではありません。「lelel 2 support」が駄目なら「level 3 support」はないのかと聞くと、highest priorityを置くように、私の事案(issue)をアップデートするという。すると、数時間後、確かに直っていた。最初から、そういう人間に任せてくれていれば数時間で解決していたはずなのに・・・。単にまともに対処するのが面倒だっただけではないかと思う。



続きを読む "海外のレンタルサーバを借りてはいけない理由(FTPアップロード・トラブル顛末記)"

| | コメント (0) | トラックバック (0)

2007/03/19

Thunderbirdから日本語ファイル名の添付ファイルを送信すると、Windows MailやOutlook Expressでは文字化けする理由



Thunderbirdから日本語ファイル名の添付ファイルを送信すると、Outlook Expressでは「ATT0437.pdf」のように「ATT」で始まる英数字のファイル名に文字化けする現象があります。この問題の原因及び解決方法は、

http://www.mozilla-japan.org/kb/solution/3067

に書いてあります。抜粋させていただくと、

Thunderbird 1.5 は、RFC 2231 と呼ばれる標準規格に準拠し、メッセージを送信する際ヘッダ (本文の前に付加されるメタ情報) に書き込む添付ファイル名の形式に変更を行いました。(・・・中略・・・)この規格に対応していないメールクライアント (Outlook、Outlook Express、一部の携帯電話など) で、こうしたヘッダの付いたメッセージを受信した場合、ファイル名が復元されません。その結果、文字が途切れる、「att」で始まる名前に置き換わる、あるいは添付ファイルそのものが認識されない、といった現象が起こり得ます。

ということらしいです。

つまりは、Thunderbirdの規格の方が正しくて、その正しい規格を理解できないOutlook Expressの方が馬鹿であるということを暗に言っているのですが、この問題はVistaのWindows Mailで解消されているかといいますと、解消されていません。

Windows MailやOutlook Expressから送信した日本語ファイル名の添付ファイルはThunderbirdでも正しく(=期待通りに)受信できますが、その逆は成り立ちません。

ただ、個人的な意見では、どちらが正しい実装かにかかわらず、送り先の人が使っているメールソフトをよく知らない場合には、日本語のファイル名の添付ファイルは最初から避けたほうが無難かと思います。下記サイトを読んでみれば、メールソフトによって対応がまちまちであり、日本語ファイル名の添付フィルを送るのは冒険であると感じます。

● Shishimushi - M2 添付ファイルの文字化け
http://kawatarou.info/note/opera/m2_attached_file.htm

●人力検索はてな - Mac OS Xのメールソフト(Mail.app)から、Windowsユーザーへ添付ファイルを送信するとき、日本語だと文字化けしてしまいます。 これを防ぐために、わざわざ英文字にファイル..
http://q.hatena.ne.jp/1158340438

●MUAs for Windows - table 3: Japanese
http://www.emaillab.org/win-mailer/table-japanese.html

どういても使いたい場合には、zip圧縮して、そのzipファイルには英数字のファイル名をつけておいて(あるいは、環境によってzipファイルのファイル名は文字化けすることを理解したうえで「日本語.zip」にして)送れば、受け取った側で回答してできるファイルのファイル名は文字化けしません。

もちろん、Outlook ExpressやWindows Mailが、RFC 2231に準拠するようになれば、他のメールソフトもそれに追随するはずですし、数年前は「差出人名に日本語を使うのは、MIMEエンコードをサポートするメールソフトが限定的であるのに無謀だ」という議論がなされていたのが、今ではほとんど(全く?)聞かれないのと同じように、数年後には、「添付ファイルのファイル名はRFC 2231に準拠するのが当然」であり、「日本語のファイル名で添付して何の問題もない」「もし、文字化けするメールソフトがあったら、そのメールソフトが100%悪い。誰もそんなメールソフトは使わないだろう。」というふうになるのかもしれません。

そもそも、Thunderbirdだって、最初からRFC 2231に準拠していたわけではなく、バージョン1.5になってからのようです。

●RFC 2231 style encoding should be used for filename parameter of attachment (instead of RFC 2047 style)
https://bugzilla.mozilla.org/show_bug.cgi?id=193439

で報告されているバグ報告を受けて「修正された」ということらしいです。

「修正された」が故に、文字化けが起こる皮肉な現象が起こっているのですが、そういう意味で、新しいOSに付属するWindows Mailの実装に期待をしていたThunderbird 1.5ユーザーもいたのではないかと思いますが、結局は残念な結果に終わりました。



日本hpのオンラインストア「hp directplus」

| | コメント (0) | トラックバック (0)

2007/03/17

VistaのWindows Mailに「#」をURLとして認識できないバグ



Windows Vistaのデフォルト・メールソフト「Windows Mail」に新たなバグ発見です。URLに含まれる「#」をURLとして認識なしないために、例えば、
http://www.example.com/hogehoge.html#3
などというリンクがメールの中にあっても、このリンクをクリックすると、ブラウザ(私の場合は「IE7」)は
http://www.example.com/hogehoge.html
にアクセスします。そのため、ページ内リンク(ジャンプ)を含むURLの機能が有効になりません。

これは、Windows VistaのOSとしての不具合・仕様なのか確かめるために、Vistaにインストールしている秀丸メールやBecky!、Thunderbirdで確かめてみましたが、やはり、Windows Mailだけのバグのようです。また、同じMicrosoft社製であっても、Outlook 2007(試用版)でもこの不具合は確認できませんでした。

しかも、訳が分からないのは、「Windows Mail」のプレビュー画面では、「#」以降のURLも青色になっていますからURLとして認識しているようなのですけどね・・・。



日本hpのオンラインストア「hp directplus」

| | コメント (0) | トラックバック (0)

2007/03/11

Windows Mailのメッセージルールのバグ(「一」で始まる件名の登録ができない件)



Windows Vistaの新デフォルト・メールソフト「Windows Mail」。Outlook Expressの後継ソフトだけあって、使い勝手はよく似ています。ただ、Outlook Express時代にはなかったバグも出現しているようで・・・。

迷惑メール対策を有効にしていると、メッセージルールよりもそちらの方が優先されるようで使い勝手が悪いので、私は、Winows Mailの迷惑メール対策は無効にしています(メニューの『ツール』→『迷惑メールのオプション』で設定)。その上で、ウイルスバスター2007の迷惑メール対策を使っています。

ウイルスバスター2007の迷惑メール対策はかなり優秀で、迷惑メールの9割近くは見事に迷惑メールかどうか判定できます。ところが、特定のメールは明らかに、出会い系サイトからの架空の話に基づく性の誘いなのですが、いつもいつも判定に失敗します。他のメールは見事に判定できているのに、特定のメールだけです。トレンドマイクロ社がこの業者からお金でももらっているのではないかと勘ぐりたくなるぐらいに(冗談です。)、毎回失敗します。

一例を挙げますと、「貴方は近所のオバサンを抱けますか?~」という件名のメール。毎日何通も来るのに、なぜかウイルスバスターは黙認状態です。また、「Cial1s S0ft Tabs ~」という件名のメールにもいつも無反応です。「Soft」ではなく「S0ft」と数字が混じっているからではなさそうですが・・・。

いずれにせよ、このような場合、Windows Mailのメッセージルールの力を借りなければなりません。ところが、こういうウイルスバスター2007が無反応のスパムメールの中で、はっきりとした件名は忘れましたが、「一日間の限定です」というような件名のメールの登録には失敗しました。これが、このブログ記事の本題です。

具体的には、メニューの『ツール』→『メッセージルール』→『メール』で、件名が「一日間の限定です」である場合に、専用迷惑メールフォルダーに移動するように登録しようとすると、間違いなく登録したにもかかわらず、左のようなエラーメッセージが表示される場合があります。

赤字の「指定した言葉が含まれる場合」をクリックすると、間違いなく、先ほど登録した「一日間の限定です」は残っているのに! です。

いろいろ調べてみた結果、「一」で始まる件名の登録ができないことが分かりました。「一人で寂しいです」や「一人の女性になってみたいので」も登録に失敗します。

なぜ、「一」で始まる件名が駄目なのかは分かりません。「一」が二文字目以降に来る場合は問題ありません。また、「一」以外の文字でも、例えば、一定のバイト文字列を持つ文字が一文字目に来ると不具合が発生し、このような登録ができない現象が他にも発生するのかは、まだ分かりません。

もちろん?、Outlook Expressにはこのような不具合はありませんでした。Windows Mail固有のバグのようです。



Vista搭載パソコンも登場!! 全国送料無料

| | コメント (2) | トラックバック (0)

2007/03/05

Vistaについて(まとめ)

Vistaについて過去にこのブログで書いた記事を一覧できるように、新しくページを作成しました。Windows Mailのバグ・文字化けについてや、IE7の新セキュリティ設計についてのメインの内容です。その他、XPとのデュアルブートの失敗談やシェア調査など。

http://shimax.cocolog-nifty.com/vista/

| | コメント (0) | トラックバック (0)

« 2007年2月 | トップページ | 2007年4月 »