スモールビジネスのIT日誌

• (2021-05-02 17:05:41)

一週間前から、毎日こんなメールが来る：




など、文面はいろいろ変化している。

そして、これら一文の下に付いている大きな「楽天ログイン」という赤いボタンを押すと、フィッシングらしきサイトへ連れて行かれる。

楽天さんも、こういう自社を装ったスパムメールにはさぞ迷惑しているだろう、どんな対策をしているのかな、と楽天さんのサイトを見に行ってみた。

この種のスパム・詐欺メールに対して、注意喚起を盛んに行っていた。

その中で、興味深かったのが、下記の部分。


「万が一、不審なメールに記載されているURLをクリックしてしまったら、速やかに以下の対応を行ってください」。


無線LANをOFFにしたら、ネットが全部使えなくなる、OFFにして、どうしろの部分は書かれていない。要約すれば「セキュリティソフト会社や警察に相談してほしい」。

「当社には問い合わせしないでくれ！」という本音がにじみ出ている。

ここまで言うのなら「本スパム・詐欺メールと楽天はいっさい無関係です。当社に連絡いただいてもサポートできません」と明示した方がクリアな気もする。

が、楽天の法務部さんが練りに練った文言がこれなんだろう。

• (2021-04-27 15:06:42)

メルマガ購読していないが、毎日送られてくる。止める方法は下記の申請画面の「お問い合わせ詳細」欄に配信停止の旨を書いて送らねばならない。


( 勝手に送りつけるメールを止めてもらうために、担当者の氏名・カタカナ・電話番号まで要求する楽天銀行さん、ここまでさせる？ )

たかだかメルマガの解約、しかも勝手に送りつけてくるメルマガの解約に、ここまで、利用者の手を煩わせる。楽天銀行よ、おかしいと思いませんかね？

自分たちは公開しない電話番号を要求

この解約申請のナゾの一つが、電話番号が必須であること。

自分たちは公開していないくせに、ユーザーには書かせる理由は？

解約に電話番号はいらんでしょう。

• (2021-04-22 05:57:24)

キャリアメールは必要か？

近頃、リリースしたドコモの「ａｈａｍｏ」というプランには「@docomo.ne.jp」のキャリアメールが付いていない。

その理由についてこんな記事があった。

記事内では「今時の若い人はメールなんて使わない」と言い切っているが、そんなことはない、これが第一の理由で、多くの人が移行をためらい、悶々としている。

そもそも、ahamoはNTTドコモの若手社員が企画し「今時の若い人はメールなんて使わない」という意見から、キャリアメールが排除された。井伊基之社長は「キャリアメールはあったほうがいいんじゃないか」という意見だったようだが、若手社員の考えを尊重して、キャリアメールの導入を見送った。(ITmedia Mobile、2021年03月05日)

「若手社員の考えを尊重して」なんて、笑ってしまう。

あの企業に、そんな文化があるはずもない。

この発言は総務省への皮肉であって、本音はプラン変更防止対策と、社内のサポート業務の軽減と考える人が多数派だろう。

企業を奴隷と見なしている役人様へのカウンターに見えて笑える。

お役人様のやり方を見ていると、なんか江戸時代みたいな身分制度を感じる。

江戸時代と違う点は支配階級が誰であるかを巧妙に隠し、それでいて「主権は国民のみなさまにある」と吹聴するやり方が、江戸時代より進化した。

メールとメッセンジャーは別物

ところで、若い世代はLINEなどのメッセージアプリ(チャットアプリ)を使っているので、メールは使わないという話について。

メールとLINEはかなり別物に見える。

「LINEがあるから、メールを使わない」でなく「はじめからメールは必要ない」人々の方が圧倒的に多いだろう。

メールは社会インフラとして残るし、メッセンジャーは会話ツールとして残ると思う。

それぞれ独自の道がある。

• (2021-04-20 10:11:38)

受信済みのメールを重複受信するトラブル

私のBecky! はメールデータのバックアップの意味と、複数地点での受信のため、受信してもメールをメールサーバから削除しない設定にしている。

そして、たまにメールサーバ内のメールを手動で削除して、メールサーバが満杯になることを避けている。

今日は新規受信をしたら、受信済みのメールもすべて再受信した。このトラブルに関する記録。

どこまで受信したかの記録 = datファイル

どこまで受信したか、Becky! は「○○.dat」ファイルに記憶しており、通常はそのファイル以降を受信するよう設計してある。

この機能は毎日、過酷に使い込んでも問題なく機能するが、しかし、ごくまれに、受信済みメールを重複受信することがある。

今日はそんなトラブルだった。

原因はよくわからないが、「○○.dat」ファイルが壊れたか？

このトラブルで、メールサーバに残っていた3,000通以上のメールを再受信しはじめた。

受信完了までに時間もかかるけど、同じ重複メールがリストに並ぶ姿も見苦しい。

すぐに受信キャンセルしたが。数百通を重複受信した。

やったこと

(1) メールサーバの受信済みメールを、とりあえず削除したい →
新しく一時アカウントを作成し「受信メールをサーバに残す」チェックを外して、受信する。

レンサバ側に用意されているWebベースのメール操作アプリでは一度に50通しか削除できず、気が遠くなる。

(2) 「○○.dat」ファイルは自動生成されるので、一度これを消して、新規に作成させる

(3) Becky! には重複ファイルを削除してくれる機能がある：
［ファイル］→「フォルダ］→［重複メールを削除］

「データの整合性エラー」もたまに

重複受信はまれに起きるトラブルだが、ついでに、これまたまれに起きるトラブルに「データの整合性エラー」がある。

これは具体的にどのファイルに整合性エラーが発生しているのか状況も、原因も、エラーが起きるプロセスも、ボクにはわからない。

とにかく、何かの整合性に問題が発生しているのだ。

しかし、こちらにも解消アプリが準備されている：
［ファイル］→「フォルダ］→［復旧］

やぱり、Becky! は最強

Becky! はこのようにいろいろなトラブルが、まれに発生するがすばらしい。

メーラーとしての機能がすばらしいし、トラブルになっても復旧確率の高さも安定している。

トラブっても、原因と対策方法を求めて、フォルダ内をながめて、いろいろやれば、たいていはメールデータを失わず復活できる。

フォルダごとバックアップしておけば、データは最低でも必ず現状レベルには戻せる、その柔軟性が凄い。

バックアップの思想がシンプルで実用的なのだと思う。

そして、システム全体の設計思想がロバストである。

大量のデータでもシステムが壊れたり遅くなることない。

たとえば、10GBを超えても、普通に機能し続けるところが凄い。

映画「ターミネイター」のようなタフさが気に入っている。

• (2021-04-15 10:44:06)

昨日の「○月○日オープン」のwebページは注意を要する の続き・・

(1) キャッシュさせないメタタグ

サーバー側をライブにしても、顧客側のブラウザでライブにならないトラブルの対策として、このページhtmlには下記のメタタグを入れている。

効いているのか、効いていないのか、私の環境ではあまり意味がないようだ。

＜meta http-equiv="Pragma" content="no-cache"＞
＜meta http-equiv="Cache-Control" content="no-cache"＞
＜meta http-equiv="Expires" content="0"＞

(2) htaccessでキャッシュ無効化

下記の例は「html、php、css、js」をキャッシュさせない記述。

＜Files ~ "\.(html|php|css|js)$"＞
Header add Pragma "no-cache"
Header set Cache-Control no-cache
＜/Files＞

画像(jpg、gif、png)もさせたくないときは
＜Files ~ "\.(html|php|jpe?g|gif|png|css|js|pdf)$"＞

今回、これは入れてなかった。

キャッシュの保持時間やユーザーやブラウザによって違うので、すべてをカバーできるわけでないが、オープン1週間前くらいには仕込んでおくべきかな。

テストした範囲では効いているので、次回の本番で効果を見てみたい。

(3) クエリパラメータで別ファイル化(css、js、画像ファイル)

URLの一番末尾に「?」ではじまる文字列を追加する方法。

末尾「?」以下はクエリパラメータと呼ばれる。

たとえば、この記事のURLは下記のとおり：

https://www.tokyocafe.net/slog/?eid=850

「?eid=850」の部分がクエリパラメータ。

クエリパラメータとはURL内で、検索用の「検索フィールド」と「検索値」を挿入する手法と空想している。

「?」+ クエリパラメータ +「=」+ パラメータ値

クエリパラメータ付きURLは平文htmlにも使用可能で、平文の場合「?」以下は無視される。

しかし、ユーザーブラウザにはクエリパラメータごとにユニークな「違うURL」と認識されるらしい。

そこで、これを使用することで、新しいURLと見なさせキャッシュ防止の効果があるとのこと。

ネット検索すると「○○.css」ファイルや「○○.js」ファイルのファイル名を、html文内でクエリパラメータ化することでキャッシュ防止のテクニックを解説してくれているページが多数ある。

(例)

＜script src="base.js?p=(new Date()).getTime()"＞＜/script＞

＜link rel="stylesheet" href="./○○.css?＜?php echo date('Ymd_Hi'); ?＞" type="text/css"＞

→ たとえば、4月15日10時45分なら、下記となる：
＜link rel="stylesheet" href="./○○.css?20210415_1045" type="text/css"＞

この例だと、1分単位で「○○.css」は新しい別のファイルと見なされる。

「Y=年数」「m=月」「d=日」「H=時間」「i=分」「s=秒」。

htmlファイル更新時はどうする？

ここで疑問はhtmlファイル更新したとき、どうやってブラウザに更新を知らせるのか？

上の方法はcssファイルとjsファイルの更新時の話。

cssが更新されたら、そのリンク元のhtmlも(更新した)と見なされるのか？

それはないと思うが・・

検索しても、「○○.html」ファイルをクエリパラメータ化する記事は見いだせなかった。

「○○.css?XXX」より「○○.html?XXX」のはずだが・・

なぜなんだろう、cssも変更することはあるが、同じ頻度もしくはcssよりもhtmlファイルの更新頻度が高い。

キャンペーン前の商品設定の変更などはhtmlの変更が多いと思う。

ならば、htmlファイルにクエリパラメータを付けて、メインの流入をユニークなURLにする方が確実に思える。

しかし、流入リンクの多さや、検索エンジンのリンクは操作できないなど、リンク元の「○○.html?XXX」が広範囲でコントロールしにくいという事情があるのか。

(4) JavaScriptでスーパーリロード

Chromeなどの多くのブラウザは「Ctrl + F5」でスーパーリロードが実行される。

これをユーザーでなく、JavaScriptを使用してブラウザに自動的にさせるとよい気がする。

→ location.reload(true);

(Macもこれでスーパーリロードされるのか知らんが、たぶん、行くだろう)

次の記事のコードはそのまま使えそう：
webサイト訪問者に一度だけスーパーリロードをしてもらう


docCookies.setItem("temp", "true"); //適当なcookieの書き込みを行い、
if("true" == docCookies.getItem("temp")){ //正常に利用できる環境であれば実行
if("true" != docCookies.getItem("refresh")){ //初回訪問時は実行される
docCookies.setItem("refresh", "true"); //2回目以降はcookieに値が書き込まれているので実行されない
docCookies.removeItem("temp");
location.reload(true); //ブラウザのキャッシュを使わずにリロードを実行
}else{
docCookies.removeItem("temp");
}
}

スーパーリロードで買物カゴもリセット？

スーパーリロードはcookieを削除しないか？という問題が脳裏をかすめた。

cookieが消えると、買物カゴからも入れている商品が失われる。

Chromeで試した範囲では削除されなかった。

しかし、他のバージョンやMacやiOSではどういう挙動になるか不明なので、他に方法があるならしたくない。

結論

テストしてみたら、現状では「htaccessによるキャッシュ無効化」で効果が出ているようである。

他の手法は必要に応じて、部分的に採用したい。