2019年3月29日(金) 13時39分05秒 [ソフトウェア]

Thunderbirdの受信ボタンで一括受信させるアカウントと対象外アカウントとを分ける設定方法

Thunderbirdの受信ボタンで一括受信させるアカウントと対象外アカウントとを分ける設定方法

Mozilla製メーラ「Thunderbird」では、複数のメールアカウントを設定できます。（まあ、たいていのメーラがそうですが。）
ツールバーにある受信ボタンを押したときには、デフォルトの動作では、すべてのメールアカウントの受信処理が一気に行われます。
受信ボタンにある「▼」ボタンを押すことで、アカウント1つずつ独立して受信することもできます。

ただ、例えば5つ存在するアカウントの内、普段は4つだけを一括受信したい、というような場合に、1つずつ受信操作するのは面倒です。

Thunderbirdには、「受信ボタンを押したときに一括受信の対象にするかどうか」をアカウントごとに設定できますから、一括受信の例外にしたいアカウントがある場合にはそのアカウントにだけ一括受信しないよう設定しておけば、指定のアカウント以外のすべてのアカウントだけを一括受信できます。

この仕様は便利なんですが、設定箇所がとても分かりにくいところにあるので、なかなかその機能に気づけません。(^_^;)
というわけで、ここに設定方法をメモしておきます。

以下は、Thunderbirdで「受信ボタンを押したときの一括受信対象にしたり、一括受信対象から外したりする方法」の解説です。

※下記に掲載しているのは、Windows10上で動作する Thunderbird 60.6 での画面イメージです。

▼1. アカウント設定画面を開きます。

Thunderbirdのアカウント設定画面は、以下の操作で開けます。

• メニューバーを表示している場合（または、[Alt]キーを1回押してメニューバーを表示させた場合）は、メニューの「ツール」→「アカウント設定」をクリックします。
• ツールバーの端にあるハンバーガーボタン［≡］を押した場合は、メニューの「オプション」→「アカウント設定」をクリックします。

▼2. 望みのアカウントに属する「サーバー設定」ページを開きます。

Thunderbirdのアカウント設定では、アカウント毎に「TOP」・「サーバー設定」・「送信控えと特別なフォルダー」……などの設定ページがあります。
その中から「サーバー設定」ページを開きます。

▼3. 設定画面ページ下部の「メッセージの保存」枠内にある「詳細」ボタンをクリック。

ここが一番分かりにくいところです。
設定画面ページの下部には「メッセージの保存」という枠があります。（狭い画面の場合は下方向にスクロールしないと見えないかもしれません。）

この枠内の右上あたりに見える「詳細」ボタンをクリックします。

まさか、一括受信時の対象にするかどうかの設定が「メッセージの保存」カテゴリに属しているとは予想しませんよね……。
なんでこんなUIになっているのか。

▼4. アカウントの詳細設定画面で「新着メールの取得時にこのサーバーも同時に受信」チェックボックスをON/OFFする。

ここで、図のような「アカウントの詳細設定」画面が開きます。
受信先フォルダを自ら設定している場合には、ここで「新着メールの取得時にこのサーバーも同時に受信」チェックボックスが操作できるようになっています。

• このチェックボックスをONにすれば、このアカウントが一括受信の対象になります。
• このチェックボックスをOFFにすれば、このアカウントは一括受信の対象外になります。

以上です。

複数のメールアカウントで受信トレイを統合している場合に使いたい

Thunderbirdに複数のメールアカウントを設定した場合、デフォルトの状態では、メールアカウントごとに受信トレイが別々に作成されます。
メールアカウントの用途が、例えば「個人用」と「仕事用」に完全に分かれているような場合はその仕様の方が良いかもしれませんが、個人用のメールアカウントが複数個ある場合に、メールアカウント単位で受信トレイが分割されると不便です。
なので、複数のメールアカウントを設定していても、受信トレイは1つに統合している方々も多いでしょう。（私もそうです。）

そのような場合には、一括受信の例外にしておきたいメールアカウントもあったりするのですよね。
例えば、

• 自動バックアップ用途に使っているため、普段は受信処理をしないアカウントとか。
• 非常用に用意してあるだけで普段は使わないプロバイダ提供のメールアカウントとか。（まあ、これは受信処理をしても何も来ないだけなので問題はないでしょうが。）
• サーバからの定期報告だけが届く専用のメールアカウントとか。
• ネット通販を利用するためだけに作成したアカウントで、普段は広告メールがよく届くから日常受信の対象外にしたいとか。(^_^;)

そういう場合には、上記でご紹介したように、一括受信の対象外に設定しておくと便利です。

2019年3月19日(火) 14時24分05秒 [Web関連]

さくらインターネットでのHTTPSリダイレクトの書き方がOS更新後に変わるらしい

HTTP→HTTPSリダイレクトの書き方が変わるようで、昔の非公式な書き方のままだとページが表示されなくなるとアナウンス

先月あたりから何度か、さくらインターネットのサポートから「サーバのOSを更新するよ」という連絡が届いていました。
ウェブサーバのOSがFreeBSD 11にアップグレードされるに伴って、.htaccessファイルに書くHTTP→HTTPSのリダイレクト仕様にも変更があるとのこと。

以前は、さくらインターネット独特の書き方が必要でしたが、今は既に標準的な書き方でリダイレクト可能になっています。標準的な書き方が使えるようになった点は分かりやすくて良いのですが、従来の書き方をそのまま使っていると、OS更新後にはページが表示できなくなるという注意が書かれていました。

さくらインターネットでHTTPをHTTPSにリダイレクトする古い書き方には、

• 公式に解説されていた方法(SetEnvIfを使う書き方)と、
• さらに以前に非公式にネット上に書かれていた方法(環境変数X-Sakura-Forwarded-Forを使う書き方)

があります。(もしかしたら他にもあるかも知れませんが)

前者の場合は放置していても.htaccessファイルが自動で修正されるようですが、後者の場合はページが表示されなくなるとのこと。(^_^;)
うちの.htaccessファイルを調べたところ後者の書き方を採用していたので、すべて書き直しました。(^_^;)

※OS更新後には従来の書き方が使えなくなるものの、OS更新前の現時点でも既に標準的なリダイレクトの書き方でHTTP→HTTPSのリダイレクトは可能になっているとのことなので、OS更新を待たずに今.htaccessファイルを書き換えて問題ないようです。

昔のHTTP→HTTPS公式リダイレクト方法

さくらインターネットのサーバ上でHTTP接続をHTTPSにリダイレクトする方法としては、公式には以下の方法が（以前は）アナウンスされていました。

SetEnvIf REDIRECT_HTTPS (.*) HTTPS=$1
RewriteEngine on
RewriteCond %{ENV:HTTPS} !on
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

この1行目にある「SetEnvIf REDIRECT_HTTPS (.*) HTTPS=$1」の記述は、OS更新時に自動でコメントアウトされるっぽいです。
これを書いたままだとページが表示されなくなるとのこと。

さらに昔の、非公式HTTP→HTTPSリダイレクト方法

また、それよりも前に、以下のような X-Sakura-Forwarded-For という環境変数を使ったリダイレクトテクニックが（公式サイト以外で）紹介されていました。

RewriteEngine On
RewriteCond %{ENV:HTTPS} !^on$
RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
RewriteCond %{REMOTE_ADDR} !=202.181.97.51
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

※REMOTE_ADDRに書かれているIPアドレス(202.181.97.51)は固定ではなく、さくらインターネットで自身が利用しているサーバのIPアドレスです。
これを最初に見たときは、ずいぶん面倒な方法を採らないとリダイレクトできないんだな、と思いましたが。(^_^;)

上記のようにX-Sakura-Forwarded-For環境変数を使う方法だと、OS更新後にはリダイレクトできなくなる(ページも表示されなくなる？)そうなので修正が必須です。
そもそもこの環境変数はさくらインターネットが公式にサポートしている書き方ではないので、自動修正の対象にはなっていないっぽいですね。
最初にこの書き方を考えた人は、どうやってこの書き方を編み出したのか気になりますが。(^_^;)

自サイト内ではかなりこの書き方を使っていたので、フォルダ内を検索して修正する必要がありました。

これからの標準的なHTTP→HTTPSリダイレクトの書き方

新しい書き方（既に利用可能）は、下記のようにシンプルなよくある書き方です。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

■参考：さくらインターネットサポート情報：

• FreeBSDのアップデートに伴う変更点
• .htaccessによるアクセス制御

うちのサイトは、ディレクトリによってはHTTPSへ強制リダイレクトすると若干困るところもあったりして、サイト内で一括のリダイレクトはしていないので、リダイレクトのための.htaccessファイルがかなり分散しているんですよね……。
ざっと修正したハズなんだけども、漏れがないと良いな……。(^_^;;;

2019年3月14日(木) 16時24分41秒 [Web関連]

サイト内検索サービスのYahoo!カスタムサーチが終了、Googleカスタム検索に切り替え

サイト内検索窓を作れるYahoo! カスタムサーチがサービス終了

長年、当サイト内にある各ページの右肩には「Yahoo! カスタムサーチ」の検索窓を置いていました。
これはYahoo!が提供するサイト内検索専用の検索窓で、指定ドメインに限定したページだけを対象にして検索結果が得られます。利用料は無料です。対象ページに画像が掲載されている場合は(OGPなどの記述がなくても)、その画像も検索結果に併せて表示される点がちょっと便利でした。

現在のYahoo! JapanはGoogleの検索エンジンを利用している検索サイトですから、要するに「Yahoo!の皮を被ったGoogle」によるサイト内検索サービスです。Googleのクローラーが情報収集していったページしか検索結果には出てこないので、リアルタイムに情報が反映されるような(＝サーバに設置した検索機能のような)サイト内検索機能ではありませんが、ざっくりサイト内を検索してもらうには充分でした。

しかーし。

先月あたりに、とうとうこの「Yahoo! カスタムサーチ」サービスも終了されてしまうと連絡が届きました。
2019年3月31日(日)でサイト内検索サービスは使えなくなるとのことです。
うちに届いたお知らせ文面は以下の通り。

平素よりYahoo!検索カスタムサーチをご利用いただきありがとうございます。
こちらのメールは、カスタムサーチをご利用いただいているお客様にお送りしております。

カスタムサーチはサービス公開以降、みなさまのご要望に応えるべくサービスの改善や維持に努めてまいりましたが、2019年3月31日をもちまして、サービスを終了することになりました。

ご利用いただいている皆様には大変ご迷惑をおかけしますが、なにとぞご理解の程よろしくお願いいたします。

＜提供終了日＞
2019年3月31日

＜お客様への影響＞
2019年4月1日以降、カスタムサーチを利用した機能にアクセスできなくなります。
サービスの管理画面をはじめ、作成したカスタムサーチのURL、お客様のページに組み込んだウェブ検索やサイト内検索の機能など全てが、ご利用・表示できなくなりますのでご注意ください。

純粋にサイト内検索だけが表示されて、広告は一切表示されないサービスだったので使いやすかったのですが。まあ、そういうサービスだからこそ収益にはならないわけで、これ以上のサービス継続にメリットはないということなのでしょうね。

検索窓用のHTMLにはYahoo!のバナー画像とリンクがありましたから、サイト内検索機能を設けている全ページからリンクされるというSEO効果は(Yahoo!側に)あったと思いますが、そういうのがなくても元々Yahoo! Japanには莫大なアクセスが集まっているわけですしね。(^_^;;;

代わりのサイト内検索機能を探す

というわけで、「Yahoo!カスタムサーチ」サービスが終了してしまうのは仕方がないので、代わりのサービスを探す必要があります。
探す必要があります、と言っても、国内の検索エンジンシェアは90％以上がGoogle（※Yahoo! Japanも含む）で、あとほんの数％だけBingがある程度ですから、選択肢はほとんどありません。
Bingには特にサイト内検索機能を無料で提供するサービスはなさそうでしたので、素直にGoogleのサイト内検索機能である「Googleカスタム検索」を使うことにしました。(^_^;)

その結果、検索窓の表示は下図の右側のようになりました。

「Googleカスタム検索」では、特にバナー画像やリンクの掲載は求められないので、右肩の検索窓もシンプルになりました。そもそも、検索窓のHTML自体に(Googleからの)指定はないので、好きなように入力フォームを作れます。

▼検索語によってはリスティング広告が先に表示される

なんで今までGoogleのサービスを使わずにYahoo!の検索窓を設置していたのかというと、検索結果に表示される広告の有無が異なるからです。

「Googleカスタム検索」も無料で利用できるのは大変大変ありがたいのですが、検索語が一般的な単語の場合には、検索結果の上部にはリスティング広告が表示されるんですよね。
無料で利用できる以上、広告が表示されるのは仕方がないんですが。
（むしろ、Yahoo! カスタムサーチに広告が表示されなかったという方が驚きという感じでもあります。）

ただ、バナー広告などと違って、リスティング広告は検索結果の一部であるかのように表示される形なので、サイト内検索機能として提供すると、ちょっと紛らわしいな……という気はしていたのでした。(^_^;)

上図は、左側が「Yahoo!カスタムサーチ」を使ってうちのサイト内を検索した例、右側が「Googleカスタム検索」を使ってうちのサイト内を検索した例です。右側の赤丸部分はリスティング広告であって、うちのサイト内にあるページではありません。もうちょっと背景色とかで見分けが付きやすかったら望ましかったんですが。
とはいえ、無料でこれだけの機能が提供されているわけですから、特に文句はありません。(^_^;)

検索結果の上部にリスティング広告が表示される可能性があるという点を除けば、従来と検索結果は変わらないと思います。
元々検索に使われるエンジンは同じわけですし、検索結果を出すデータベースも同じわけですからね。(^_^;)

Googleカスタム検索の便利な特長

Googleカスタム検索では、検索対象サイトを正規表現で細かく指定できます。
ドメインだけを指定することもできますし、指定ディレクトリだけを対象にすることもできます。正規表現が使えるので、どのようなURLで構成されているサイトでも、きっちりサイト内だけに限定した検索が可能なのではないかと思います。

条件を複数個同時に設定することもできるので、2つのドメインを同時に対象にしてサイト内検索をすることもできます。
せっかくなので、 *.nishishi.com と *.nishishi.org の2ドメインが対象になるよう設定してみました。
（サブドメイン名部分にワイルドカード「*」を指定すれば、そのドメインのサブドメインすべてを対象にできます。）

▼Googleカスタム検索の設定(設置)方法

Googleカスタム検索を新たに使う方法は簡単で、Googleカスタム検索ページにアクセスして、「新しい検索エンジン」ボタンを押して設定すれば良いだけです。Googleのヘルプ「カスタム検索とは Getting started with Custom Search」にも説明があります。

検索結果は、Googleサイト側に表示することもできますが、自サイト内(＝自分の所有するドメイン下)に表示することもできます。その場合、ページデザインはかなり自由自在にできますから、自サイトの既存デザインに合致するような装飾の中にサイト内検索結果を表示できます。

便利です。

2019年3月10日(日) 16時40分46秒 [ニュース]

Wall Street Journalを毎日新聞IDで契約すると6割引だがタイムアウトが早すぎて毎度のログインが面倒

ウォール・ストリート・ジャーナルを読むには毎日新聞の「デジタル毎日」ID経由だと安い

Wall Street Journalのウェブサイト内には、無料で全文が読める記事もありますが、ほとんどは有料記事な感じです。

で、ウォール・ストリート・ジャーナルを単独で直接契約すると月額2,899円ですが、毎日新聞のデジタル毎日ID経由だと月額1,058円(税抜980円)で読めます。6割引以上です。36.6％くらいですね。
デジタル毎日IDには「1日100円」というコースもあるので、月に10日未満しか閲覧しないなら1日単位で払った方が安いですけども。契約コースの比較表によると1日(ワンデー)コースでもウォール・ストリート・ジャーナルを読めるようです。

初月は無料ということなので、試しにスタンダードコース(月額課金コース)で登録してみました。
確かに、ウォール・ストリート・ジャーナルの記事が読めます。月額千円なら払いやすいので、これで全文が読めるのは嬉しいです。ついでに毎日新聞の記事も含めて、その系列サイトの有料記事も読めます。^^;

デジタル毎日IDを作ってスタンダードプランを契約した後、Wall Street Journalサイト側でも手続きすると、Dow Jones (dowjones.com) からも「会員登録完了のお知らせ」メールが届きました。Wall Street Journalからのメールは、差出人名がダウ・ジョーンズなんですね。ダウ・ジョーンズって人名であり会社名でもあったのか。(^_^;)

Wall Street Journalサイト側のログイン数制限は特に書かれていないので分からないんですが、デジタル毎日ID側は5台まで同時ログインできると書かれていました。
とりあえず、自宅メインPC・仕事用ノートPC・Androidタブレット・iPod touchの4台でログインしてみました。特に問題なく閲覧できています。毎日新聞の記事も、ウォール・ストリート・ジャーナルの記事も。

Wall Street Journalサイト側の単独IDが発行されるわけではないので、閲覧は常に迂回が必要

めでたくウォール・ストリート・ジャーナルを読む権利が得られたわけですが、
デジタル毎日IDでは「Wall Street Journalサイト自体のID」が発行されるわけではないため、Wall Street Journalサイト側のログインフォームではログインできません。
試しに、Wall Street Journalサイトのログインフォームにデジタル毎日のIDとパスワードを入れてみましたが通りませんでした。

ウォール・ストリート・ジャーナルを読むためには、毎日新聞サイトへ移動して、デジタル毎日IDでログインした状態にして、毎日新聞サイト側が用意しているリンクを経由してWall Street Journalサイトにアクセスする必要があります。
この点が面倒ですね。
ただ、1度その手順を踏んでおけば、2度目からは直接記事ページにアクセスしてもちゃんと読めました。
デジタル毎日ID経由でログインしたという情報のCookieがあれば良いようです。

毎日新聞側のヘルプにも、ログイン状態はCookieで維持されていると書かれていました。
なお、このログイン仕様の問題で、Wall Street Journalアプリでのログインはできないとのこと。
あくまでもブラウザ経由で記事が読めるだけです。(充分ですが)

▼Twitterアプリを使って毎日ID経由でウォール・ストリート・ジャーナルの記事を読む方法

私は、Twitterでウォール・ストリート・ジャーナル日本版の公式アカウントをフォローしているので、TwitterのTLから記事が読めると便利です。
しかし、モバイルOS版のTwitterアプリから、そのままストレートに記事ページへアクセスしても記事は読めません。
先程と同様に、最初の1回は、デジタル毎日IDでログインしている状態でWall Street Journalサイトにアクセスしてログインする必要があるからです。

これがやや面倒なんですよね。
モバイルOSでも、普通のブラウザならブックマークを経由して移動すれば良いんですが、Twitterアプリの内蔵ブラウザだとブックマーク機能とかありませんから。
モバイルTwitterアプリから見る場合は、以下の迂回路を使うことで記事の閲覧は可能でした。

1. まず、Twitterアプリ上で毎日新聞公式アカウントのツイートを経由して毎日新聞の記事ページにアクセス。
2. そこから毎日新聞TOPページへ移動して、デジタル毎日IDでログイン。
3. そのTOPページにあるカテゴリ一覧からWSJ（Wall Street Journal）のリンクを踏む。
4. 表示されるウォール・ストリート・ジャーナル記事一覧ページからリンクを踏んで記事ページへ移動。

上記の手順なら閲覧できました。
かなりの迂回ですが、1度その手順を踏んでおけば、2度目からは直接記事ページにアクセスしてもちゃんと読めました。

▼Wall Street Journal側のタイムアウト（セッション期限）が早すぎる！

しかし！
まだ問題があります。

Wall Street Journalサイト側のログイン状態のタイムアウトが速すぎるんです。(^_^;)
たぶん、最後のログインから10分くらいアクセスがなければ、強制ログアウトしてしまうっぽいです。

デジタル毎日IDの方は、ログイン状態がかなり長く保つんですけども（今のところまだ1度も強制ログアウトはされていないので、どれくらいの日数持つのかは分かりませんが）。

なので、ウォール・ストリート・ジャーナルの記事を読みたいと思ったときには、ほぼ毎回、一旦毎日新聞サイトにアクセスした上でウォール・ストリート・ジャーナル記事一覧のリンクを踏んで、Wall Street Journalサイトでの再ログイン処理が必要です。
これはモバイル端末から読む場合には特に激しく面倒ですね……。

PCで閲覧する場合なら、ブラウザの別タブでリンクを踏めば良いだけなので楽ですが。
モバイル端末でも、ブラウザアプリを単独で使えばまあ多少は面倒さを回避できそうな気もしますが、Twitterアプリの内蔵ブラウザで見ようとすると厳しいです。(ブックマークとか、別タブ機能とかがないので。)

Twitter自体をTwitterアプリで読むのは止めて、モバイル版ブラウザの1つのタブで閲覧すれば、そのブラウザのブックマークに先程のURLを登録しておけば済みますが。
うーむ、それが最も現実的な方法かな……？

頻繁に閲覧しないなら1日単位のスポット契約でも良いかな

モバイル端末でのログインがあまりにも面倒な場合は、月額固定のコースではなくて、「1日100円」のコースでPCから読みたいときにだけスポット契約的に使う方が良いかも知れません。
モバイル端末なら、電車待ちの時間とかにちょっとiPod touchとかで読めるので毎日読むかなとも思うんですが、そうでないなら(PCからしか読まないとすれば)毎日は読まない気もしますし。(^_^;)
まあ、毎日読まないとしても、月に10日間以上読むなら月額固定の方が安いわけですが。
どちらになるかは、しばらく試してみないと分かんないかな……。

▼毎日ID側のログイン状態は長く保持されているんだけど

デジタル毎日IDのログイン状態は、どうも少なくとも24時間以上維持されているっぽいです。
まだ一度も再ログインを求められたことがありません。

Wall Street Journalサイト側もセッション有効期限をもっと長く（せめて24時間くらいに）してくれると良いんですけどもねえ……。
まあそこは、正規価格で契約しているユーザとの差別化という意図なんでしょうか。(^_^;;;
しかし、2.7倍ですもんね……。料金が。
それはちょっと躊躇してしまいます。^^;

まあ何にせよ、6割引で、ウォール・ストリート・ジャーナルの記事は読めた、という話でした。

追記(2019/05)：セッション維持期間が長くなった？

最近はどうも、いきなりWSJサイトへアクセスしても、ちゃんとログイン状態が維持されているような気がします。
ちょっとセッション維持期間が長くなったのかも知れません。
Twitterから、ふと気づいたときにWSJ記事へ飛んでも、再認証を求められるケースはとても減りました。だいたい毎日1本でも閲覧している限りは大丈夫っぽいようになっているような気が。
改善してくれたのかな？^^;